Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add exwm-minor-mode #53

Open
progfolio opened this issue Jun 5, 2024 · 14 comments
Open

Add exwm-minor-mode #53

progfolio opened this issue Jun 5, 2024 · 14 comments

Comments

@progfolio
Copy link
Collaborator

progfolio commented Jun 5, 2024

Previous pull: ch11ng/exwm#868

@medranocalvo Has already given blessing for someone to pick up this work.

There was some discussion regarding restoring a replaced window manager when exwm-mode is disabled.
My suggestion would be to add a function to exwm-exit-functions which covers the cases we know we can replace easily and leave it up to the user to add such a function for cases we can't predict or reliably restore. Regardless, I think moving to a mode and away from "exwm-enable" is important.

@Stebalien
Copy link
Contributor

My suggestion would be to add a function to exwm-exit-functions which covers the cases we

IMO, the user should use the minor mode hook.

@minad
Copy link
Member

minad commented Jun 6, 2024

Just bike shedding, but do you have any other suggestions for a better mode name? I would have preferred exwm-window-mode (or exwm-buffer-mode) for exwm buffers and exwm-mode for the global window manager mode, but I think it is too late to change this now. Maybe exwm-wm-mode or even the verbose exwm-window-manager-mode for the global minor mode?

@ethanmoss1
Copy link

Just playing devils advocate, shouldnt there just be hooks that are available the user to initalise another window manager if they really want. Correct me if im wrong but usually when closing a window manager not in a DE youre thrown out of the session. As for in a DE, usually the WM is restarted.

As for a name if deciding to go ahead im for verbosity over shortned names, helps when learning.

@minad
Copy link
Member

minad commented Jun 6, 2024

@ethanmoss1 Yes, you can use the exwm-window-manager-mode-hook to run code during initialization and during shutdown, so one could in principle start another window manager there. But why would you? Just stick with EXWM ;)

@ethanmoss1
Copy link

There are other window managers other than EXWM?! ;)

In that case, clear documentation and examples would be better that trying to guess how a user wants another window manager to take over from. IMO, thoughts?

@Stebalien
Copy link
Contributor

Yeah, changing the per buffer mode would be nice but there's no graceful transition.

exwm-wm-mode isn't bad, tbh.

@progfolio
Copy link
Collaborator Author

progfolio commented Jun 7, 2024

Just bike shedding, but do you have any other suggestions for a better mode name?

Perhaps exwm-client-mode for the global minor mode?

@medranocalvo
Copy link
Contributor

@medranocalvo Has already given blessing for someone to pick up this work.

Definitely, thank you.

There was some discussion regarding restoring a replaced window manager when exwm-mode is disabled. My suggestion would be to add a function to exwm-exit-functions which covers the cases we know we can replace easily and leave it up to the user to add such a function for cases we can't predict or reliably restore. Regardless, I think moving to a mode and away from "exwm-enable" is important.

This issue is tangential. The difficulty is that we must manually compile a database (alist) of commands to restart the previous WM. (This should be discussed in a separate ticket.)

Just bike shedding, but do you have any other suggestions for a better mode name? I would have preferred exwm-window-mode (or exwm-buffer-mode) for exwm buffers and exwm-mode for the global window manager mode, but I think it is too late to change this now. Maybe exwm-wm-mode or even the verbose exwm-window-manager-mode for the global minor mode?

Oh, yes. I would definitely prefer that. I was not brave enough before... but now I can blame you! Ehem... We are in version 0.X.

My proposal is:

  • exwm: the EXWM global minor mode
  • exwm-x-mode or exwm-x-window-mode: the major mode of X window buffers.
  • exwm-mode: deprecate. Maybe reuse it after a couple of years?

@minad
Copy link
Member

minad commented Jun 7, 2024 via email

@medranocalvo
Copy link
Contributor

medranocalvo @.***> writes:

  • exwm: the EXWM global minor mode

I'd prefer if we adhere to the naming convention *-mode for modes. This makes them a little easier to spot, and it is more aligned with user expectations.

Yes, you are right.

Then, how about:

  • accept exwm-wm-mode (despite the redundancy... :-/)
  • obsolete exwm-mode in favor of exwm-x-window-mode (or similar). Is it possible to do this so that user configurations keep working but they receive a warning?
  • After a couple of releases/years obsolete exwm-wm-mode in favour of exwm-mode.

In any case, this is only aesthetics.

@minad
Copy link
Member

minad commented Jun 8, 2024 via email

@progfolio
Copy link
Collaborator Author

progfolio commented Jun 8, 2024

exwm-mode as is and only introduce the new exwm-wm-mode.

Personally, I'm not a fan of the name "exwm-wm-mode".
The only thing I could think of was "exwm-client-mode", but I'm not too hot on that either (though I do think it's clearer than the former).

@minad
Copy link
Member

minad commented Jun 9, 2024

I consider exwm-client-mode misleading, not meaningful enough. What about exwm-manager-mode or exwm-desktop-mode? I still find exwm-wm-mode best, since that's what it is, a mode controlling the window manager.

@progfolio
Copy link
Collaborator Author

I consider exwm-client-mode misleading, not meaningful enough. What about exwm-manager-mode or exwm-desktop-mode? I still find exwm-wm-mode best, since that's what it is, a mode controlling the window manager.

Fair enough.
Of your suggestions exwm-wm-mode is best.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants