What exactly is your excuse for not making your own Window Manager? It's very simple to do with X11.
What exactly is your excuse for not making your own Window Manager? It's very simple to do with X11.
Falling into your wing while paragliding is called 'gift wrapping' and turns you into a dirt torpedo pic.twitter.com/oQFKsVISkI
— Mental Videos (@MentalVids) March 15, 2023
I don't want to and I don't have any reason to
Because I can't design anything remotely visually appealing and need other people to do it for me. Then I can just change it to add the functionalities I want to and keep it pretty.
More interesting would be the reimplementation of "Fancy Zones" from WIndows Powertoays.
Should be doable for all Window Manager that follow the EHWM standard.
Also somebody should pick up maintenance of existing interesting window management tools like the Expose clone skippyXD.
it's even simpler with Wayland
It's not since display manager and window manager are one thing in Wayland
Because window managers are an outdated concept that only implement some of what is necessary to run modern apps. A modern desktop is a session split into several different components - not a window manager with loosely defined purpose and eclectic features, but a session manager, settings manager, compositor, message bus, etc., all with somewhat standardized features, working together to provide up-to-date support for hints set by Qt and GTK.
Openbox werks.
>but a session manager
bloat
>settings manager
egregious and totally unjustifiable bloat, there should be no daemon and just some text files in ~/.config
>compositor
unnecessary at best, bloat at worst
>message bus, etc
standardized, standalone thing that you can use or not, independently
Openbox doesn't even support hints used by GTK to indicate that a window has received focus.
Have fun with your XTerm and XEyes and flickering unbuffered graphics that can't be scaled, and no settings changes during runtime, I guess.
>Openbox doesn't even support hints used by GTK to indicate that a window has received focus.
okay, and?
>Have fun with your XTerm and XEyes and flickering unbuffered graphics that can't be scaled,
well I didn't buy a meme monitor so scaling isn't a concern.
>Have fun with your XTerm and XEyes and flickering unbuffered graphics that can't be scaled,
once you do away with the bloat: the settings manager, the display manager, the dozen other things that modern DEs ship, then this stops being a problem. Restarting X isn't a very disruptive thing, since there's so many fewer moving parts.
DEs are like the Princess and the Pea, they keep piling extra mattresses (layers of abstraction and daemons) on top of every irritant, when what they *should* be doing is simplifying, and leaving ancillary frills by the wayside.
that last was meant to be a reply to
>no settings changes during runtime
Not only can settings be changed while running on a modern environment, but configuration is done cleanly and safely with simple set and get queries to a central registry. Why write XML and custom theme formats for Openbox, which always risk corruption due to user error, when you could instead run dconf set blah?
>but configuration is done cleanly and safely with simple set and get queries to a central registry
this is not a good thing
you're adding entirely unnecessary complexity in pursuit of a goal that brings you few benefits to begin with. dconf is fucking cancer. There's zero reason to run some bloated configuration daemon, especially since it's certain that you'll never get 100% adoption. The most your reimplementation of the Windows registry can ever be is a bag on the side of the system. That is, your system will be the over-complicated """general solution""" that isn't general at all, but merely an extra pile of crap that has to be run for some, but far from all, applications. All because you thought you knew better and you were too good for a plain old text config file. Text config files like those that have just werked, simply and straightforwardly, since time immemorial. But I guess they aren't the Current Thing™, and you, like developers, want to throw out something that works so you'll have a new toy to play with, and damn the users.
>Open two instances of an app
>Modify settings in one instance, close it
>Close second instance, which never had settings modified
>Unmodified settings are re-saved to disk
Unfortunately many such cases on GNU plus Linux
that's 1.) a corner case, and 2.) the application's responsibility to handle, if it deems it important at all.
So each and every app should implement not only their own configuration scheme, be it XML, JSON, or Vimscript, but also implement their own settings daemon and file watching system, instead of using existing common solutions.
>So each and every app should implement not only their own configuration scheme
yes. Program configuration is beyond domain-specific. There is no universal schema that will be a good fit for any, or even most, programs.
>but also implement their own settings daemon
no, no app should implement this. If you want to change the settings either you should restart the program, or it should have a function where it re-reads its config file on receiving a certain signal. (SIGHUP and SIGUSR1 seem to be popular choices for this.) There is no need to have a """settings daemon""", ever, period.
yeah, nah, if a desktop app needs to be configured in a such a way that it can't be expressed with bool and string values in dconf, it's poorly designed and should be reworked or split into multiple apps
if the configuration can be expressed with some bools and strings, why bother with the bloat of a separate daemon? You can easily represent that in a dotfile with approximately no effort. For that matter, if it really is just bools and strings, you can get the shell to do it for you.
generalized Windows Registry-style key-value stores with daemons associated with them are bad solutions to nonexistent problems. The solution is, as ever, not an additional layer of abstraction, it's to simplify what you're doing.
there's already a dozen redundant window managers.
I did. I made a vr window manager.
>What exactly is your excuse for not making your own Window Manager?
because I have a job to do and our customer doesn't want or even knows about window managers
Working on a compositor with wlroots instead. Very pleased with it aside from lack of API stability.
Many of us have jobs anon, but i only spend like 2 hours per day on wagie shit.