>> Since OpenSUSE 13.1, gsettings likes to randomly revert certain settings
>> every 103 reboots, for no defined reason. This is extremely unhelpful.
>
> Could be a bug.  Have you asked in the openSUSE forums for some help, and/
> or reported a bug?

Given how excruciatingly hard it is to get access to the OpenSUSE bug 
tracker... no, I haven't.

Besides, they'll just report it upstream and then go back to doing 
nothing. That's what they did with the Zypper bug I spent ages 
diagnosing and reporting.

>> But the *most* unhelpful thing is that half the things you want to
>> change DON'T HAVE SETTINGS! For example, there is no setting to bring
>> back the minimise and maximise buttons; you have to install an
>> extension.
>
> No, you don't. gnome-tweak-tool ->  Windows.

Perhaps it was the "show task list" option then. I remember spending 
weeks trying to configure the shell the way we want it, and in the end I 
couldn't do it.

>> But I guess that's a symptom of another worryingly common problem: GNOME
>> 3 is *clearly* designed to run on a tablet or a phone. Because nobody
>> uses desktop PCs anymore, right? Right??>_<
>
> I use GNOME3 every day, and not on a tablet or touchscreen.  Works fine
> here.

I'm not saying it doesn't *work*. I'm saying it's clearly not optimal. 
The way they try to stop you arranging multiple windows visible at once, 
the way they try to steer you away from multitasking. Heck, the latest 
revision even removed a scrollbar and replaced it with a sequence of 
buttons, so it'll work better with a touchscreen.

>> Riiiight. Because I haven't already read that page 65,536 times. :-P
>
> You said it wasn't documented.  It is.

How you write a minimal Hello World type thing is documented. The vast, 
sprawling mass of code you need to interact with to do anything 
nontrivial is utterly undocumented.

How do I respond to window open/close events? Not documented. How do I 
determine what tray icons are defined? Not documented. How do I resize 
an existing window? Not documented. Would you like me to continue?

>> Basically, you write a shell extension by writing a JavaScript file that
>> contains [at least] three functions with specific names. These functions
>> work by MONKEY-PATCHING THE LIVE RUNNING CODE to make it do something
>> different. The extension itself is responsible for reverting these
>> changes when you disable the extension. (In particular, there are
>> extensions that cannot be disabled, or don't disable properly.) Leaving
>> this critical detail up to people who don't really know what they're
>> doing and have no documentation to go by is... not optimal.
>
> Got a better idea about how to do it?

How about, I don't know, the system generating a reverse diff as you 
change stuff, and then applying that diff when you turn the extension 
off? It's more work for the framework, but then less work for the 
extension author. And I'd *hope* the framework is rather better tested 
than your typical extension...

>> This, then, is how you write a shell extension. And how do you work out
>> which part of THE ENTIRE SHELL CODEBASE you need to monkey-patch to make
>> the changes you want?
>>
>> You read the source code.
>>
>> For the entire shell.
>
> No.  What you do is you identify what it is you want to do, and you find
> that part of the code, if that's the way it's actually done (I don't for
> a moment pretend to have written an extension, however given your track
> record in overstating things, you don't really think I'm going to take
> your word for it, do you? ;) )

You realise I got *paid money* to write several shell extensions and 
modify some existing ones, right?

Indeed, it seems the only "documentation" for how to do anything is to 
read the source code for extensions that other people have already written.

(How THE HELL these other people wrote this stuff utterly baffles me... 
I guess one or two people might have too much free time, but given the 
vast number of extensions available [most of which add back 
functionality that GNOME 2 had built-in], it screams that somebody 
somewhere must have some real documentation...)

>> Because there's no documentation. Indeed, one Stack Overflow commenter
>> helpfully commented that "there SHOULD be no documentation, because the
>> source code is the documentation". No, random Internet user, the source
>> code is not and will never be the documentation. Because the source code
>> gives you the *implementation* not the *interface*.
>>
>> Then again, when your entire extensibility platform is fundamentally
>> based on purposely breaking encapsulation to start with...
>
> Um, no, it's based on extending encapsulation in an OO way, as I
> understand it.  It's somewhat like using DITA specializations, or
> extending an object class in a directory service.

In an OO language, you don't generally modify a huge, complex framework 
by deleting code from the running system and replacing it with your own.

Then again, JavaScript isn't completely OO, so...

Post a reply to this message