Yup, but you made a small mistake. As we are talking about KDE/Plasma, Gnome, Windows XP etc. we are not talking directly about X window system and therefore also not about Wayland. I’m sure that there are such 3D interfaces (always want to try this one which looks like a game), but … “I would talk” with kwin_wayland instead of waylnad libraries directly. I know that window manager topic is big, but I really don’t want to follow hardest way - I want to do as much as possible for things that are worth. Even if there is no CSS parser library it could be useful for other.
For this I need research. I know that Plasma have lots of easy to scrape config files. If something is not possible in specified OS then I would handle {:error, :not_supported} or something like that. Well … if you are using Plasma everyday you could quickly forgot that other window managers are not so awesome. 
Sorry, I don’t get what (shell?) commands have to GUI apps and their shortcuts. Of course I would support global as default with option to override them. For example I could let you select oxygen theme and choose icons from other theme or even change a single color. All would be handled by settings viewport defined in library and final app would need only to save settings on its own and read them when initializing viewport.
Yup, I know! I don’t remember, but there was even an app for list all DBus applications and it’s calls. For example I could show and hide yakuake and added it to Plasma config file to call it on pressing <Super> key. That’s really good way.
Well there is an Plasma app so it’s possible. Anyway as you said app could store its shortcuts as in its own scope. I would even want to store my own as DBus calls. That would be definitely awesome!
For sure in details everything is bigger. Generally I want to take all supported event types and try to scrape each checking if it’s supported.
For sure I’m not expert, but in Linux I saw everything easy to find (like config files, icons etc.). Comparing to Windows where icons can be in dll files (if I remember correctly) it looks much easier.
I don’t want to write any interpreter. At very least I would use current OS interpreters to handling special cases in future. For now I’m interested only in generic things. I don’t want to reproduce something which conflicts or overcomplicates whole implementation.
Again I want to draw everything which looks like themes. It does not need to be exactly equal if it’s really so hard. Just look at Plasma settings window. What it allows to configure/change. I just want to for example expand color scheme from Plasma settings, so app (and its dependencies) could draw components based on them. Of course there goes more than colors - I’m just giving colors to now write everything. 
Yeah and require from everyone to remember them or implement app with proper autostart support for every case. It’s definitely overcomplicated, hard to remember and use. It’s just like comparing Firefox config page and Chrome flags page. For sure Chrome have less options, but it’s mainly because of project assumptions and descriptions for flags.
Default does not mean that everything is ok:
Wayland Support in Plasma
Wayland support in the KDE Plasma Workspaces is in a tech-preview state. The workspaces have been developed for X11 and much functionality relies on X11. To be able to make proper use of Wayland these bits have to be rewritten.
The most complex task is to implement Wayland support in KWin, KDE Plasma’s Compositor and Window Manager. Since 5.4 KWin is able to manage Wayland clients and this allows to start a Plasma session on Wayland.
(…)
This page was last modified on 13 January 2019, at 22:08. Content is available under Creative Commons License SA 4.0 unless otherwise noted.
Oh, I could remember it wrong. I though that version checking happens in OS library.
Yeah, but that means again drawing and handling custom window borders, movable part of QTabBar, window controls (minimize, maximize, close) etc. Nothing changes here (unlike in GTK+ when you simply had GtkHeaderBar). I would need to fetch anyway lots of information as you noted about writing custom titlebar. I just said that if we have here and here same thing (scrape, draw and handle) then there is no benefit with using one over another in this specified part (not at all). Qt have some native calls, but it’s definitely not best for Elixir as scenic is better option than :wx.
Writing huge NIF for full Qt support or writing drawing part in scenic - in both cases it’s a lot of work, but I could be wrong … btw. is it not possible to have “something in middle” like scenic which uses native calls like Qt?
Yup, the difference here is that you do not need to write so much code. I would like to see so simple solution in scenic as well.
Even if you have extra tabs above then instead of: 1 vs 2 you have 2 vs 3 bars. At any case Firefox part reduces in 33% or 50% (depends how many bars you have).
Yup, most probably handling it is too more. When I started thinking about it firstly I though more about app window and not everything around it. I probably go too far with this part. It’s just because I’m used to have everything so easily configurable in Plasma which is just “waiting for me”.
ok, so we have collision here
- Go with native interfaces
- Go with something like
NO_TITLEBARflag inQt
Or maybe it could be combined? Sorry I could get lost here.
ok, I see … so it’s just not possible to apply theme from other OS / window manager, because instead of button states (or animated images) we have scripts everywhere, right? It looks like overcomplicated for me. Is that because everything is on old X server?
Maybe I’m wrong, but personally if I would design such button I would think about animated SVG file which is simply generated based on colors (again and more) from theme file. I’m not sure why there are so many scripts. I probably assumed too much and I though that it works actually a bit easier.
That would be ok if there would be API like GtkHeaderBar, so I would just do not need to think about other things. Unfortunately I read that it’s considered as a bad practice for KDE developers and therefore they did not implemented that feature.
oh, please no! I saw already scripts with binary content and it looked so weird. Don’t tell me that there is so much staff like that. 
ok, honestly it’s just terrible
You want to add simple Windows XP theme, but you need tons of weird staff like interpreters. I don’t like how it’s solved. I don’t though that there is so much mess.
I think that you descried well why it’s so hard to scrape all information. For sure I don’t plan to finish with scraping. I would just limit it to not take too much time for it. If something is scripted then I would simply reject it. I would definitely scrape some system colors, textures etc and allow to draw “similar” themes (i.e. allow app to have good color scheme like app background).
As @massimo linked image I would most likely to create my own standard i.e. my custom window icons. As @OvermindDL1 said I would use system calls as much as possible (especially I would like to add DBus support). Maybe later I would add few extra features which are pretty easy to implement (I don’t want to overcomplicate problem and make it working after few years). Honestly I did not planned to do something like that, but I see that I don’t have a big choice. I plan to have buttons in animated SVG format which would be generated based on color scheme (like button background color).
