Announcement
Collapse
No announcement yet.
MPV Player 0.32 Released With RAR5 Support, Bash Completion
Collapse
X
-
Originally posted by ssokolow View PostExcept that the things which expect SSD tend to be things like SDL-based games, where it makes all the sense in the world to ask the platform APIs to take care of it for you,it was probably lucky that you got a Linux port to begin with, and it's likely it doesn't get supported very well.
With optional SSD all becomes times harder: developer may ignore SSD and will have answer to 'your prog doesn't conform my fancy KDE theme, fix immediately' requests, or may support two code paths to make everybody happy. With SSD DE's developers will add tons of unnecessary features to their decorations and there will be always problems with these features don't work with CSD apps, so user will bombard apps support asking to make CSD optional and developers will have to support two different layouts and users will have to choose if they will loose DE's functionality or application's
With their SSD extension, KDE developers have created a big problem for every developer and all is just to save their f***ng theming feature!
And when everything is done perfectly, SSD will still look like shit, because app uses dark color theme and colors for SSD were selected to look good with lite theme.
...and, last I checked, the SDL approach was basically "If GNOME persists with not supporting SSD requests, maybe we can draw the bare minimum that can be called window decorations and consider it done."
Comment
-
You're making a lot of assumptions there.
Originally posted by Khrundel View PostNo. SSD doesn't fix any problem, it just creates them. Drawing windows decorations is just one another simple task, which can be done by any app itself or by delegation to some library of developer's choice. In CSD-only world app, toolkit, or library can just draw several primitives and fire some messages to wayland server when getting some mouse events within certain areas. Wayland window header is just a rectangle which issues 'start move window' command when getting mousedown event. I don't believe in 1-click linux ports, so adding CSD support will be least problem for developer, even without any support library.
That said, do you really think it'll make GNOME look good if it's the only desktop where games get a fugly "black rectangle with some colored squares"-type titlebar provided by SDL as "There. We've met requirements. Now shut up about it."?
Originally posted by Khrundel View PostWith optional SSD all becomes times harder: developer may ignore SSD and will have answer to 'your prog doesn't conform my fancy KDE theme, fix immediately' requests, or may support two code paths to make everybody happy.
Originally posted by Khrundel View PostWith SSD DE's developers will add tons of unnecessary features to their decorations and there will be always problems with these features don't work with CSD apps, so user will bombard apps support asking to make CSD optional and developers will have to support two different layouts and users will have to choose if they will loose DE's functionality or application's
Who is supposed to be the arbiter of whether a feature is "unnecessary". You? Until Windows 10, GNOME 3 and Microsoft disagreed pretty fundamentally over whether having multiple workspaces (ie. virtual desktops) was an "unnecessary" feature. Are you arrogant enough to believe that GNOME gets to rule by fiat on what direction all Linux desktops will go?
Originally posted by Khrundel View PostWith their SSD extension, KDE developers have created a big problem for every developer and all is just to save their f***ng theming feature!
I've heard rumours that some WMs even support *gasp* grouping arbitrary windows into a single window with WM-level tabs in the titlebar. Horror of horrors!
Thank God for Alt+F3 to pull up the KWin context menu for the active window via the keyboard.
(But, while you're on the topic of theming, it's bad enough when I have to reconfigure the theme because some idiot theme designer made it hard to identify the active window at a glance because they made only the text colour on the titlebar change between active and inactive to keep it "harmonized" with the widget theme.)
Originally posted by Khrundel View PostAnd when everything is done perfectly, SSD will still look like shit, because app uses dark color theme and colors for SSD were selected to look good with lite theme.
There's a reason that things like JWZ's The CADT Model get written.Last edited by ssokolow; 30 January 2020, 07:19 PM.
Comment
-
Originally posted by ssokolow View PostAhh, so you ascribe to the GNOME developers' delusion then? That users agree with their ideological "If game developers aren't willing to come on our terms, then screw those games"? I certainly don't.
That said, do you really think it'll make GNOME look good if it's the only desktop where games get a fugly "black rectangle with some colored squares"-type titlebar provided by SDL as "There. We've met requirements. Now shut up about it."?
What do you think happens to CSDs drawn by non-GTK applications on GNOME right now?
Yes, and this didn't used to be a problem until GNOME broke from the conventions agreed upon by every other DE, so it's GNOME that has to deal with the fallout.
Then fix it properly and standardize a means for a window to indicate to the WM whether it's using a dark-on-light or light-on-dark scheme. Don't just write a crappy "80% of the users use 20% of the features" hack and ignore the "but each user uses a different 20%" part by dismissing those users as "wrong".
Comment
-
Originally posted by Khrundel View PostAnd with which other terms game developers can disagree? Can they disagree with OpenGL specification, for example? No? They should conform to specs? And if so, why game developer can assume DE supports SSD, when even xdg-decoration specs say it is optional?- "What GNOME wants" isn't a standard
- Under Wayland, things like having support for multiple windows on the same display device are optional. It's designed to not treat things like In-Vehicle Infotainment consoles as second-class citizens the way X11 does.
Originally posted by Khrundel View PostIf game has ugly sprites or buttons why this is game's problem but when it has ugly titlebar - that is DE's fault?
Originally posted by Khrundel View PostThat is an universal answer to every pro-SSD argument: "why it is ok to you to have application's own buttons but not own titlebar". That is up to game developers. Most games are fullscreen only. If developers want some custom interface (i.e. without toolkit) and windowed mode they should draw titlebar with their style themselves.
Originally posted by Khrundel View PostHmm.... I've mentioned a problem which will always belong to SSD world and you've confirmed that that problem exists now. And we are living in SSD world. So, I was right. What is your point?
Are you next going to argue that Plasma should be pressured into implementing some kind of API that allows the taskbar to be restyled to match whatever the active window is?
There's a reason we have "common components" which are drawn by the desktop for consistency.
Originally posted by Khrundel View PostI like that argument. Just tell "everybody agree with me". KDE and sway aren't everybody. There are actually more wayland servers which don't support SSD.
Originally posted by Khrundel View PostAnd if you will look to marketshare... I bet at least half of users use Gnome.- "i bet" is not a very solid statement
- GNOME was first to something marginally usable. Of course they have a head start.
- If you're going by market share, we should all give up and go back to Windows.
Originally posted by Khrundel View PostYep, lets make crappy decision and then we will figure out how to cope with consequences. Now app developer have to had two UI layout (one for CSD and one for SSD)
Originally posted by Khrundel View Postand have to support standardized themes or some protocol extension to tell WM about his apps color theme.
Originally posted by Khrundel View PostThat is what I've meant. CSD creates problems, doesn't fix any.
Comment
-
Originally posted by ssokolow View Post"What GNOME wants" isn't a standard
Under Wayland, things like having support for multiple windows on the same display device are optional. It's designed to not treat things like In-Vehicle Infotainment consoles as second-class citizens the way X11 does.
It's the DE's fault if it expects applications to draw CSD
without acknowledging that, as far as CSD is concerned, Windows and MacOS APIs are equivalent to making Wayland APIs inaccessible, unstable, and internal, forcing all Wayland environments to guarantee availability of GTK+, and requiring all applications, Qt or otherwise, to go through GTK+ to request a drawable surface.
Except that, on Windows and MacOS, they don't have to. There's an API that they can trust to always be there which will render OS-provided CSD for them.
Which problem? The pressing need for titlebars to blend in with the windows they wrap?
Are you next going to argue that Plasma should be pressured into implementing some kind of API that allows the taskbar to be restyled to match whatever the active window is?
There's a reason we have "common components" which are drawn by the desktop for consistency.
Are you listening to yourself? That's an argument that has been thrown at GNOME 3 ever since they went off on their wildly divergent take on how a desktop should look and act.
We already had this problem since the beginning. It's called "Qt and GTK don't use the same theming interface and don't even start about the lesser toolkits"
Look at the Steam interface. Or any other CSD app. Do you realy need these window to have a native titlebar? No. Then why you require all windows except these to have it?
Comment
-
Originally posted by Khrundel View PostWayland specs say xdg-decoration is optional.
[...]
Look at the Steam interface. Or any other CSD app. Do you realy need these window to have a native titlebar? No. Then why you require all windows except these to have it?
I've got more productive things to do with my time.
Comment
-
Originally posted by ssokolow View Post
I could continue arguing, but it's clear we're not achieving rational discourse
If it is pain to see for example 30% of windows having GTK style (including decorations) it is must be even more pain to see just one window having it's own unique style. So, if you're right, all skinnable apps and all apps with their own theme just shouldn't exist. Their appearance must antagonize most users. But we see other way, even enterprise apps like MS Office tend to replace standard controls with customized. So, logic tells me that nobody cares about native look and feel. That is why both GTK and QT developers don't care about negotiating some common theme format.
Same logic tells me that simplest way to achieve a solid window appearance is not to invent 15 protocols to tell external decorator about apps color theme, and then another one protocol to allow to add some controls to the titlebar, that will just add complexity. The simplest way is to make every window to draw it's decorations itself. Most apps won't have to do anything, they are using default toolkit theme and they will got default toolkit decorations. And CSD will fix a problem with theming inconsistency: If user will choose a GTK theme and some incompatible KDE theme and install some app with minor toolkit, which doesn't support theming, there won't be problems with frankenstein UI, all titlebars will looks like parts of their windows, with perfect contrast and solid styles.
I agree with you, it is good to have access to some additional features from DE, but it can be achieved with some simple protocol extension, like delegation of contextmenu event after rigthclicking on titlebar, you don't need DE's buttons on windows headers.
Unfortunately, nobody listens to the logic. KDE developers don't want to throw out their customization features, SDL and MPV developers don't want to do additional work and hope their whining will force adult responsible people to change their mind, users are afraid of changes.
What I don't understand is why these people want to spend time and efforts to transit to wayland if their goal is to reimplement X11? X11 already exist, just use it.
Comment
Comment