| === brainwash_ is now known as brainwash | ||
| bluesabre | Mentioning CSD to Xfce people https://media2.giphy.com/media/3orif2nxe9tn5Zi4JG/giphy.gif | 22:36 |
|---|---|---|
| bluesabre | :'''D | 22:36 |
| bluesabre | (thanks ochosi) | 22:37 |
| Unit193 | I mean, considering some reaction from the devs was a range of "Please no" to "I won't work on anything that has them"...I don't think it's really the right move. | 22:48 |
| bluesabre | Yeah | 22:50 |
| bluesabre | Unit193: are these also your primary concerns? https://mail.xfce.org/pipermail/xfce/2019-October/036707.html | 22:50 |
| bluesabre | If CSD are going to exist in any form, we might be able to just solve the issue | 22:51 |
| bluesabre | (s) | 22:51 |
| Unit193 | I'm a little hazy as to the difference between CSDs and headerbars, tbh. They tend to come hand-in-hand. | 22:53 |
| Unit193 | From the sounds of it, I might be able to just drop use-header-bar from a few things, or maybe even patch it out of libxfce4ui... | 22:54 |
| Unit193 | https://wiki.gnome.org/Initiatives/CSD makes me think of what I previously knew as headerbars. Anyway, if that's the case they tend to look out of place; take up too much space; and for some reason of which I don't know why, they seem to be less responsive to clicks than alternatives. | 22:58 |
| ali1234 | CSD is a requirement for headerbars | 23:06 |
| bluesabre | Yeah, so basically we're going for 1) https://imgur.com/iom27ES for most applications (this is CSD, non-headerbar decorations), and 2) https://wiki.xfce.org/_media/releng/4.16/roadmap/general_ui/appearance-csd.png for the CSD XfceTitledDialog replacement | 23:06 |
| bluesabre | Right, but headerbars are not a requirement for CSD | 23:07 |
| ali1234 | bluesabre: you can't fix any of the issues raised on that mail while using CSD, it is impossible, because Gtk can't render xfwm themes | 23:07 |
| bluesabre | The theme is just one issue | 23:08 |
| ali1234 | it precludes all of the consistency issues | 23:08 |
| ali1234 | the functionality issues can't be solved without patching gtk | 23:09 |
| bluesabre | The window buttons (except rolling) are already supported, even custom positioning to some extent | 23:10 |
| bluesabre | Per-application CSS could, in theory, "roll up" the window contents | 23:10 |
| ali1234 | you could potentially solve the consistency issues by ripping out the decoration code of xfwm and then replacing it with something powered by gtk, but at the cost of making the functionality problem affect all apps instead of just CSD apps | 23:10 |
| ali1234 | that would also break all existing themes of course | 23:11 |
| bluesabre | Most existing themes would likely have a CSD-titlebar style similar to their Xfwm style... so that breakage could possibly be reduced | 23:12 |
| bluesabre | But I know nobody's going to let me demolish Xfwm :D | 23:13 |
| ali1234 | what do you mean "their xfwm style"? | 23:13 |
| ali1234 | the xfwm style i use does not have any matching gtk theme. i use adwaita | 23:13 |
| ali1234 | and i use orion for xfwm | 23:13 |
| bluesabre | Right, I'm saying the Orion GTK3 theme includes headerbar and titlebar GTK3 styles | 23:14 |
| ali1234 | there is no orion gtk theme | 23:14 |
| bluesabre | https://www.deviantart.com/satya164/art/Orion-GTK3-Theme-281431756 ? | 23:14 |
| ali1234 | that's from 2012. it doesn't work any more | 23:15 |
| ali1234 | like, at all, it's completely broken on modern gtk3 | 23:15 |
| bluesabre | Right | 23:15 |
| ali1234 | also the decorations in the screenshot look absolutely nothing at all like the xfwm theme | 23:16 |
| bluesabre | (I'd consider that a bug myself) | 23:17 |
| bluesabre | Say we release Xfwm5 in 2022, all existing themes would cease function without patching (or at least renaming), so eventually an unmaintained Xfwm theme would become a non-functional Xfwm theme | 23:18 |
| ali1234 | why would xfwm themes stop working? | 23:18 |
| bluesabre | Theoretically, based on them being sourced from /xfwm4 theme directories | 23:19 |
| ali1234 | just because the theme search directory was renaed? | 23:19 |
| ali1234 | that's not even something that needs fixing in the theme, that's a packaging issue... | 23:20 |
| bluesabre | Any number of reasons... I'm just saying that there's no guarantee it'd work forever, same with any software | 23:20 |
| bluesabre | (not trying to argue or discuss particular implementations anymore, just saying) | 23:20 |
| ali1234 | okay, but so what? | 23:21 |
| ali1234 | my computer might break tomorrow, i'm not going to smash it up today because of that | 23:21 |
| ali1234 | i'm probably the only person still using orion - i install it from source | 23:23 |
| bluesabre | This is all in response to: | 23:24 |
| bluesabre | > you could potentially solve the consistency issues by ripping out the decoration code of xfwm and then replacing it with something powered by gtk, but at the cost of making the functionality problem affect all apps instead of just CSD apps | 23:24 |
| bluesabre | > that would also break all existing themes of course | 23:24 |
| bluesabre | Simply saying that any given theme, if designed with consistent titlebars in CSD/Xfwm, if Xfwm were to shift away from a custom engine to a GTK one | 23:24 |
| bluesabre | Didn't mean for it to spin out of control, speaking in hypotheticals | 23:25 |
| ali1234 | okay, but there are currently zero themes where that works | 23:25 |
| ali1234 | i'm not against CSD if you can fix those issues | 23:29 |
| ali1234 | i have other issues with header bars though | 23:29 |
| ali1234 | like they make it harder to drag windows because the title bar is full of buttons | 23:30 |
| ali1234 | they encourage hamburger menus which are equivalent to normal menu bars except everything is crammed under one button | 23:31 |
| Unit193 | bluesabre: Right, so the second image could just be fixed by patching libxfce4ui, no? Or would one need to drop the glade option and a bit in the code? | 23:31 |
| Unit193 | FWIW, I couldn't agree more with https://mail.xfce.org/pipermail/xfce/2019-October/036685.html | 23:33 |
| ali1234 | how is "force quit unresponsive program" handled with CSD? | 23:36 |
| ali1234 | i suspect the answer to this is "not at all" | 23:37 |
| ali1234 | "It is fundamentally unavoidable that client-side decoration are affected by client-side lockups." - mclasen | 23:38 |
| ali1234 | https://gitlab.gnome.org/GNOME/gtk/issues/215 | 23:38 |
| ali1234 | btw, its possible to dynamically transform headerbars in to toolbars, which allows the program to gracefully disable CSD entirely in all cases | 23:40 |
| ali1234 | it requires a patch to gtk, but that patch could instead be a custom widget in libxfceui | 23:40 |
| bluesabre | I guess I just struggle with the animosity against them generally. If no functionality is lost, no menus are collapsed into a hamburger menu, and theming remained consistent (nothing that window manager theming does not currently carry over), what's the remaining issue? If it's consistency with other applications, the consistency currently stops when the titlebar stops and the rest of the app begins (developers are selfish) | 23:40 |
| bluesabre | ali1234: yeah, I thought the same (and messaged ochosi about it) | 23:41 |
| bluesabre | > Crazy idea... we could theoretically implement an XfceHeaderBar that would do toolbar things if some config was set to off, headerbar things if enabled | 23:41 |
| ali1234 | https://github.com/ali1234/headeraway shows how to do it | 23:41 |
| bluesabre | Neat | 23:41 |
| ali1234 | basically you have a widget that is either a header bar or a gtk box... and the api for both is the same, so you just proxy | 23:42 |
| bluesabre | right | 23:42 |
| bluesabre | Which sounds like a people pleaser | 23:42 |
| Unit193 | "All things being equal", but they aren't, sooo.. | 23:43 |
| ali1234 | yeah, you do lose functionality... like the ability to kill unresponsive programs... which xfwm can do now | 23:44 |
| Unit193 | Also they're too big and look awful, soo. :P | 23:44 |
| ali1234 | it's a big assumption to say all these problems can be fixed... i mean if they could, surely gtk would have done it by now? | 23:44 |
| bluesabre | I don't think GTK is interested in fixing non-GNOME things, tbh :) | 23:45 |
| bluesabre | I've been chasing nautilus and totem patches as X11 features get deprecated | 23:46 |
| ali1234 | we should come up with our own stupid UI design | 23:47 |
| ali1234 | round windows! | 23:48 |
| ali1234 | horizontal popup menus! | 23:48 |
| ali1234 | then we can say gnome is behind the times | 23:48 |
| Unit193 | Enforce one window up at once, and if it's not a full screen application then show the desktop background (not icons, those can be distracting.) | 23:49 |
| ali1234 | android already did it | 23:51 |
| bluesabre | Pretty Maemo also did that, and GNOME did it for a couple releases :) | 23:51 |
| ali1234 | yeah, hildon, that was actually okay for a phone OS | 23:51 |
| ali1234 | well, phone UI, the OS behind it was terrible | 23:52 |
| Unit193 | Win 10 preview did too, didn't it? | 23:52 |
| ali1234 | only metro apps i think | 23:52 |
| ali1234 | but maybe the preview could only run metro apps... i dont remember | 23:52 |
| bluesabre | oh yeah | 23:52 |
| bluesabre | Metro apps in Win8 were fullscreen only, 8.1 added an optional windowed mode, and 10 brought back windows by default | 23:53 |
| ali1234 | ultimately whoever is willing to do the work gets to decide | 23:53 |
| bluesabre | I'm just trying to make sure that there's people left to do the work once the dust clears | 23:54 |
| Unit193 | Yeah, though I have hope that the thunar and xfce4-terminal maintainers aren't game for the idea. :3 | 23:54 |
| ali1234 | what is the benefit of doing it, from maintenance pov? | 23:54 |
| bluesabre | Preps us for Wayland | 23:55 |
| bluesabre | I know video is 100% broken in Parole with GTK_CSD=1, other apps are definitely affected in fun and unknown ways | 23:55 |
| ali1234 | wayland doesn't require CSD - see KDE | 23:56 |
| bluesabre | Right, but the GTK CSD mode I think intentionally breaks X11-specific functionality | 23:57 |
| bluesabre | At least, from when I've run with it on in the past | 23:57 |
| bluesabre | Not sure what else is affected in the backend | 23:57 |
| ali1234 | probably, but why is parole using that in the first place? | 23:57 |
| bluesabre | It's not currently | 23:57 |
| ali1234 | why does it break then? | 23:57 |
| bluesabre | Oh, that being X11 stuff? | 23:58 |
| ali1234 | yes | 23:58 |
| bluesabre | GStreamer video, not crammed through a Clutter actor, seemingly uses X11 | 23:58 |
| ali1234 | how would making it use CSD fix that? | 23:58 |
| bluesabre | And we use the X11 accelerated video bits because the Clutter API changed radically | 23:59 |
| bluesabre | It forces us to identify and resolve those issues | 23:59 |
| bluesabre | I think ochosi had other documented reason for it as well | 23:59 |
| ali1234 | it's fine to support CSDs in individual apps | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
