Reply to post: Re: This is grim

Companies toiling away the most on LibreOffice code complain ecosystem is 'beyond utterly broken'

ovation1357

Re: This is grim

The GNOME team even ran a little crusade (and I use that word precisely because they're almost religious in their belief that CSD is the one true way) to pressure developers into changing their applications to ditch the title bar. It seems to have been moderately successful...

https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

But so blinkered were they in their own little world view that the idea of end-user choice went out of the window and I don't they they gave a moment's thought that this poison was going to spread to any environments that use GTK3 (even the latest Firefox on Windows suffers from this abomination, nor to the backlash that it starting to happen by furious XFCE, MATE users plus other many other desktops too.

There's actually a security argument against the CSD as well - there's a very deliberate reason that the title bar is controlled by the window manager and not by the application and that is to guarantee clear containment and separation between applications. In 'labelled' security environments such as Solaris with TX (Trusted eXtensions) the title bar is used to denote the classification of the application such as Secret or Restricted. Letting the applications decide on the decoration isn't going to roll in those environments.

A neutral party could look at my argument and accuse me if being similarly religious in my belief that GNOME has got this seriously wrong. But my stand point isn't that CSD is wrong necessarily, but that it's far better suited to touch screens and I want to see users given a choice in the matter. There's no way it's that difficult to create a menu system which can be written once and then rendered as either title bar plus classic menu bar or as a CSD based on a user's preference. This solution would please everybody, and I think it would stand a better chance of achieving wider adoption as developers and users would be less likely to push back against it.

I like the idea of the STLWRT project but I think it's ambitious and might prove almost impossible to reliably take a CSD menu structure and reformat it into a classic menu without per-application templates to help. It'll be very interesting to see how it turns out as it's so alpha right now that the author says it doesn't even compile right now.

I've not yet had a chance to look at XFCE Classic but I guess that's going to be dependent upon forking and thus maintaining a small subset of applications which still may not cover those needed/wanted by other desktops. This also creates yet more fragmentation in the Linux space which isn't really desirable.

Both of the above solutions are really just the proverbial sticking plaster (bandaid).

The only real way out of this is for GNOME to have a change of heart and agree to support a configurable choice of Classic or CSD mode and to ensure that all GTK applications are encouraged to include the necessary support for both modes - something that will really piss some developers off who have already spent a load of time rewriting their app and throwing away the legacy menus to become CSD-only.

This is why it's genuinely such a major problem and why it's such a shitty problem. The only way out is four GNOME to change their policy and that seems an extremely unlikely outcome.

Or the whole application ecosystem could rebel and use a GTK fork or other alternative but that's even less likely!

So sadly, CSD isn't likely to be going away any time soon although I'm not going to give up fighting just yet. There's time yet for me to become a KDE convert however there seems to be a distinct absence of decent Qt based web browsers so I'd still be stuck using Firefox or Chrome on GTK :'(

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon