-
Notifications
You must be signed in to change notification settings - Fork 15
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
Comments
IMO, the user should use the minor mode hook. |
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? |
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. |
@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 ;) |
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? |
Yeah, changing the per buffer mode would be nice but there's no graceful transition. exwm-wm-mode isn't bad, tbh. |
Perhaps exwm-client-mode for the global minor mode? |
Definitely, thank you.
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.)
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:
|
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:
In any case, this is only aesthetics. |
medranocalvo ***@***.***> writes:
> 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.
Yes, this is more or less the plan. We could also go the simpler route,
keeping exwm-mode as is and only introduce the new exwm-wm-mode. There
isn't much value in renamings, except if they lead to more consistency.
|
Personally, I'm not a fan of the name "exwm-wm-mode". |
I consider |
Fair enough. |
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.The text was updated successfully, but these errors were encountered: