Stories with Tag window management

• Native frame transposition coming to Emacs 31

  permalink

  Posted: 2025-04-08 08:10:06

  Verbose tl;dr

  Emacs 31 introduces native frame transposition, a significant improvement for multi-monitor setups. This new feature allows users to quickly and smoothly move frames between different monitors, preserving their relative size and position. Previously, moving frames across monitors often resulted in distorted sizing or placement. With native frame transposition, Emacs now understands monitor geometries, enabling a seamless transition and a more consistent user experience across displays. This enhancement provides a more intuitive and efficient workflow for users working with multiple monitors.

  The blog post "Native frame transposition coming to Emacs 31" by Prot details a significant improvement to Emacs' window management functionality in the upcoming version 31. Specifically, it addresses the long-standing issue of inefficient and sometimes buggy behavior when rearranging Emacs frames (top-level windows). Previously, transposing frames, or swapping their positions on the screen, relied on a complex and resource-intensive process of destroying and recreating the frames entirely. This older method, while functional, suffered from several drawbacks. It could be slow, especially with complex frame setups involving multiple windows and buffers. More importantly, it could lead to the loss of frame-specific state information, such as the precise window sizes and positions within each frame, as well as any custom decorations or toolbars associated with the frames.

  Emacs 31 introduces native frame transposition, a completely revamped approach that operates at a lower level, directly manipulating the windowing system's representation of the frames. This avoids the need for the destructive recreation process. Instead, Emacs 31 can now efficiently swap the positions of frames without losing any of their associated state. This results in a noticeably smoother and faster frame transposition experience, particularly noticeable on systems with multiple monitors or complex window configurations. The blog post highlights the benefits of this change, emphasizing the improved performance and the preservation of frame state. It also provides specific command examples, illustrating how users can leverage the new functionality, such as using windmove-swap-states-left and windmove-swap-states-right to transpose frames with adjacent ones. These commands facilitate quick and seamless reorganization of the Emacs workspace, enhancing overall user productivity and providing a more refined window management experience. The author expresses enthusiasm for this new feature, portraying it as a significant step forward in Emacs' window management capabilities.

  • Emacs
  • Emacs 31
  • window management
  • Frame Transposition
  • Native Frame
  • GUI
  • User Interface
  • Text Editor
  • Software Development
  • productivity

  Summary of Comments ( 43 )
  https://news.ycombinator.com/item?id=43619437

  Verbose tl;dr

  Hacker News users generally expressed excitement about native frame transposition in Emacs 31. Several commenters highlighted the performance improvements this change brings, particularly for complex window configurations or remote sessions. Some discussed existing workarounds they'd used, like ace-window, while others anticipated how this would simplify their Emacs configurations. A few users also pointed out potential benefits for tiling window managers and speculated about possible future enhancements, such as transposing frames across different monitors. The overall sentiment was positive, viewing the change as a welcome quality-of-life improvement for Emacs users.

  The Hacker News post "Native frame transposition coming to Emacs 31" sparked a discussion with several insightful comments.

  One commenter expressed excitement about the feature, highlighting its potential to significantly improve the user experience when working with multiple frames, especially when using Emacs in a tiling window manager. They elaborated that the current behavior, where transposing frames requires manual resizing, is inconvenient and disruptive to the workflow. This new feature promises a smoother and more intuitive way to rearrange frames.

  Another user pointed out a practical application of this feature for users who present from their Emacs setup. Currently, maximizing a frame often leads to undesirable results, but with the native frame transposition, switching to a presentation setup and back could become seamless and hassle-free.

  A different commenter focused on the technical details, mentioning that this feature utilizes the underlying window manager's capabilities for frame management. They also clarified that the functionality depends on the window manager's support and might not work universally across all window managers. Specifically, they noted that tiling window managers, such as i3, do not usually handle frame sizing within their paradigm, and that transposing in this manner might not be ideal even if technically possible.

  Another discussion thread branched into the broader context of Emacs development. A user raised concerns about the relatively slow pace of development compared to other projects like Neovim. This led to a discussion about the different development philosophies, community dynamics, and the challenges of maintaining a large and complex project like Emacs. Some defended Emacs, emphasizing its stability, extensibility, and the active community that continues to contribute to its development. They cited the independent nature of Emacs' development as a reason for why features may appear at a different pace compared to a project like Neovim, where some design decisions might come from external pressures. It also touched upon the relative importance of native frame transposition compared to other features that some users might prefer were prioritized differently.

  Finally, a few comments simply expressed appreciation for the author of the original blog post for sharing the information about the upcoming Emacs feature. They acknowledged the value of such posts in keeping the community informed about the latest developments.

• Show HN: FlashSpace – fast, open-source, macOS Spaces replacement

  permalink

  Posted: 2025-02-08 17:19:23

  Verbose tl;dr

  FlashSpace is a free and open-source macOS application designed as a faster, more lightweight alternative to the built-in Spaces feature. It aims to provide smoother and more responsive virtual desktop switching, reducing lag and improving overall performance compared to the native solution. The project is hosted on GitHub and welcomes contributions.

  Wojciech Kulik has introduced FlashSpace, an open-source alternative to macOS's built-in Spaces functionality, designed with a focus on speed and efficiency. Spaces, the virtual desktop feature in macOS, allows users to organize applications across multiple desktops, enhancing productivity and window management. However, some users find the native implementation lacking in performance and customizability. FlashSpace aims to address these perceived shortcomings.

  FlashSpace is implemented using Swift and leverages Apple's private APIs. It is designed to be significantly faster than the default Spaces implementation, offering virtually instantaneous switching between virtual desktops. This increased speed aims to create a more seamless and fluid workflow for users who frequently utilize multiple desktops. The project prioritizes performance optimization to minimize delays and enhance the overall user experience.

  The project is openly available on GitHub, encouraging community involvement and contributions. The open-source nature of FlashSpace allows for transparency in its development and provides opportunities for users to customize and extend its functionality. While leveraging private APIs might introduce potential compatibility issues with future macOS updates, the open-source model allows for community-driven maintenance and adaptation to changes in the operating system. The project's README provides instructions on how to build and install FlashSpace, targeting users comfortable with compiling code from source. Though currently focused on performance and speed, the project’s future direction may include incorporating additional features and refinements based on community feedback and contributions. FlashSpace represents an attempt to provide a more responsive and dynamic virtual desktop experience for macOS users.

  • macOS
  • spaces
  • window management
  • virtual desktops
  • opensource
  • GitHub
  • productivity
  • Desktop Environment
  • utility
  • Application
  • flashspace

  Summary of Comments ( 37 )
  https://news.ycombinator.com/item?id=42984420

  Verbose tl;dr

  Hacker News users generally praised FlashSpace for its speed and open-source nature, seeing it as a welcome alternative to the built-in macOS Spaces feature. Several commenters expressed interest in features like window previews within the Spaces overview and better integration with keyboard shortcuts. Some questioned the app's stability and long-term maintenance given it's a solo project. There was also discussion about existing window management alternatives and their respective strengths and weaknesses compared to FlashSpace, with mentions of yaba, Rectangle, and Amethyst. A few users shared their own experiences with similar personal projects and the challenges of balancing feature requests with maintainability.

  The Hacker News post "Show HN: FlashSpace – fast, open-source, macOS Spaces replacement" generated several comments discussing the project, its functionality, and potential improvements.

  Several users expressed appreciation for the project, highlighting the speed and smoothness of FlashSpace compared to the built-in macOS Spaces. They found the instant switching between spaces particularly appealing. Some users who had tried other Spaces alternatives in the past noted that FlashSpace felt significantly more responsive and less buggy.

  Performance was a key topic of discussion. One user questioned the performance difference compared to other solutions and the developer (wojciechkulik, the project author) responded explaining that FlashSpace leverages Core Graphics APIs for direct screen manipulation, bypassing the potentially slower Quartz Compositor, which might be used by other methods. This explanation was well-received and contributed to the positive perception of the project's technical approach.

  The open-source nature of FlashSpace was praised, with several comments expressing interest in contributing or exploring the codebase. The use of Swift and SwiftUI was also seen as a positive aspect.

  Some users suggested potential improvements and features. One suggestion involved allowing users to configure the swipe gestures for switching spaces. Another user requested the ability to assign applications to specific spaces. Support for moving windows between spaces using keyboard shortcuts was also mentioned as a desirable feature. The developer actively engaged with these suggestions, acknowledging their value and expressing openness to implementing them in the future.

  A discussion arose about the project's name, with a few users finding the "Flash" part potentially misleading, as it might be associated with Adobe Flash. Alternative naming suggestions were offered, although no consensus was reached.

  Overall, the comments were largely positive and reflected a strong interest in the project. Users appreciated the performance improvements, open-source nature, and active engagement of the developer. While some suggestions for improvements were made, they generally served to enhance the project rather than criticize its core functionality.