- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
an article explaining why GNOME should support SSD, but also arguing against the reasons often given for why they shouldn’t
If someone could repost this to r/GNOME I would appreciate it, since I don’t have a reddit account.
You must log in or # to comment.
I think I am in the SSD camp. I absolutely hate the latest trend on MS Windows to fill the title bar with various widgets to the point where it can be hard to grab the window and move it. As with the current trend in US politics to stretch the rules well past any previous deformation, give a CSD an inch and it will eventually lead to ridiculously-adorned windows.
This is the biggest issue with CSDs aside from the wasted space coming from oversized buttons. Every developer’s gonna put different, inconsistent things in that title bar.
The close window button is basically universal, but what if I want to minimize the application? What if I want to pin it to all workspaces, stack it on top of other windows, or roll it up? With CSDs there are no standards.
Am I the only one who drags windows by holding Super or nah?
Brother, we used to be able to just use a single HID dirt basic operations like this.
I remember, but they invented better solutions 🙂
I just tried that now (didn’t know it was a thing) and it’s not a very satisfactory solution if I’m moving monitors. When I get it to where I want, I can’t just double-click to max it again like I can dragging the title bar. Can’t say I’ll use that.
🤷♂️ I used it all the time back around twenty years ago when I still was using a stacking window manager with floating windows. It’s all about practice I guess. For me it felt natural initially though.
Also holding down Super and dragging with right mouse button to resize is great.
The entire window is a much bigger click target than the title bar or the window borders (actually each quadrant would be the click target for resizing, but still a lot bigger). Fitts’s Law in action.
I don’t use it much now that I moved to tiling window manager many years ago, and now a scrolling window manager, because those are mostly controlled with use of keyboard shortcuts. But sometimes I still use this even now. 👍
I guess you could move it to another monitor then hit Super + Up to maximize, or a similar shortcut, if your window manager is a capable one. 😅
Closest I’ve come to any of that black magic hotkey fuckery is I’ve learned to hold shift when I drag to get it to snap to my tiling setup in KDE. Oh and Alt-tab for window switching and Meta-Tab for Activities.
I’m pretty much ready for Sway as you can tell.
that black magic hotkey fuckery
😂 I take it you aren’t used to working with computers much except maybe for gaming? Or what kind of computer background do you have, if you’d like to share? 🙂
Former IT and current farmer. I just did everything in the terminal.
Cool. How long ago did you make the switch to farming?
I sometimes do that too, but as it’s not a thing on Windows (which I’m forced to use at work), it’s not my default habit.
There is a third party tool called AltDrag that brings this exact thing to Windows. See if you can sneak it into your work machine somehow.
My condolences. 💜
In my mind the switch to CSD was made concurrently with the switch to mobile style burger menus and a corresponding excision of features to fit in the smaller menu area, so most apps that do it I just instinctively dislike. It’s part of what pushed me to KDE, though I still use GNOME at work
What now? GNOME doesn’t support server-side decorations? It’s been years since I last used GNOME, so I may be out of touch; but if this is true, what happens if you do run something on GNOME that simply doesn’t have any code that draws its own titlebars? Or am I misunderstanding how any of this works?
what happens if you do run something on GNOME that simply doesn’t have any code that draws its own titlebars?
Why would they not supply some default decorations when none are available?
Jesus, Gnome is such a shitshow.
Their go-to solution is libdecor, which is just a library that implements a titlebar, still putting the burden on apps (Or rather, whatever windowing library they use) to be responsible for it.
Worst thing is, I kinda get their argument against supporting it, they’re just really inflexible about it which just makes the whole issue too heated.
now that is truly idiotic
I don’t mind apps drawing their own titlebars if they have a real use for it (I’m typing this comment in a Firefox window where the titlebar has the tab bar in it), but not having any window-manager-level title bar as a fallback at all and requiring apps to do that themselves?! Window managers everywhere else have been doing this since what, the 1984 Apple Macintosh?
The idea is that it’s left up to the windowing toolkit itself (.e.g GTK or Qt, etc.), so the compositor can focus on just compositing, which makes sense IMO as it’s how other platforms handle it (Except they have a single OS provided windowing implementation). Problem is, that leads to massive fragmentation of functionality, every app has different toolbars and features based on the toolkit they use, and requires each app to handle it, which sucks and shouldn’t be the case.
Like in the Factorio case, it uses SDL for windowing, and SDL actually supports handling titlebars itself. But Factorio just wasn’t including the dependency that enabled it at that point, so all it took to fix it was including it and everything started working. But that’s still extra work that had to be done just to get minimum functionality, which wasn’t needed on e.g. KDE.
I mentioned in my other response, it’s the inflexibility that’s the actual problem. Lots of apps do want CSD, or at least control over how their windows are presented, but Gnome going “you’re on your own” is the worst outcome.
From the article:
Certain applications work poorly without SSD. These apps end up having either no titlebar or a weird one, and the user can’t move or resize them easily. Davinci Resolve is one notable example, but it’s not the only one.
