[lug] Pushing Back Against Gnome CSD/Headerbars

[Internet Privacy Advocate]

You are correct.  It's best to keep it simple, and given that the Window manager is so important, it should not be overridden.   I've always used Mate, because Gnome proper seemed confusing.  When KDE changed it took about 5 years to get the wrinkles out, and actually I've never gone back to it, but I liked it originally.  Some people say the new Gnome is good, but I've never been drawn to it.  As for Unity, I never liked it from the beginning and even less after mark Shuttleworth deleted my comment saying "it had no place in my future."

 

 

 

-----Original Message-----
From: stimits <stimits at comcast.net>
To: Boulder (Colorado) Linux Users Group -- General Mailing List <lug at lug.boulder.co.us>
Sent: Sun, Jan 28, 2018 11:08 am
Subject: Re: [lug] Pushing Back Against Gnome CSD/Headerbars



I'd rather keep an area at the top where the window system can interact regardless of whether the application did something wrong or not. Example: What happens to the ability to manipulate the app (or the window containing the app) if the content of that bar is partially or fully locked up?
 
In the spirit of modular coding, why would he want to move what could be a single well-debugged set of code into every single individual application?
 
I wouldn't mind if there were an alternate library which an application could link to and would provide this behavior...so long as the application can work with either library interchangeably (and if the "barless" version, when missing the library, would revert to the "withbar" version). This would more likely be a change to the window manager, and not to individual applications...this would preserve the ability to control look and feel and make a choice.
 
As soon as you start putting part of the window manager into every single application I start thinking of guaranteed grief instead of quality. Then again, I use KDE...but there are plenty of Gnome applications in use here. It scares me to think of trusting all applications to work...especially applications demanding we look at advertisements and commercials. Want the end user to be forced to see your advertisement? Just code this little piece of the window manager to go away. This would be a whole new era of exploits if every single application must be trusted to do it right. I hope firefox has no means to remove/alter/edit/modify this part of the window based on web content.
 
----- Original Message -----
From: Jed S. Baer <blug at jbaer.cotse.net>
To: lug at lug.boulder.co.us
Sent: Sun, 28 Jan 2018 19:05:40 -0000 (UTC)
Subject: [lug] Pushing Back Against Gnome CSD/Headerbars

Hmmph. Just read the Slashdot discussion regarding the Gnome CSD
initiative.
https://wiki.gnome.org/Initiatives/CSD
https://tech.slashdot.org/story/18/01/27/2245240/should-apps-replace-title-bars-with-header-bars

And my initial reaction is to agree with all the negative remarks in
the /. discussion, if not in tone, then certainly in substance. In
essence, I'm asking, "What in the Wide Wide World of Sports is a goin' on
here?"

As an end user, I'm not privy to whatever discussions proceed deep in the
bowels of the Gnome/GTK developer community. And, really, I don't think I
should have to be. But, I also suspect that since I don't agree with
what appears to be the end result, I wouldn't support whatever arguments
are being used to justify it anyway.

Does anyone here know why it is the Gnome people feel the need to foist
this upon us? Is there some good reason why window management functions
somehow now need to be managed by applications? I seriously don't get it.
_______________________________________________
Web Page: http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety

_______________________________________________Web Page:  http://lug.boulder.co.usMailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lugJoin us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20180128/1a5725a9/attachment.html>