On Tue, 17 Mar 2015 19:00:21 +0000, Orchid Win7 v1 wrote:

> On 16/03/2015 11:55 PM, Jim Henderson wrote:
>>> GNOME3 has plenty of configuration options, set using dconf-editor.
> 
> GNOME 3 uses the gsettings system to hold its configuration settings.
> It's something like the Windows Registry, but harder to use. (E.g., it
> seems to be impossible to access when X11 isn't running. It's
> nightmarishly hard to configure settings for a user who isn't you. It's
> really hard to navigate without a GUI tool. And so on.)
> 
> 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?

> 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.

> 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.

>> Oh, and for creating gnome-shell extensions?
>>
>> https://wiki.gnome.org/Projects/GnomeShell/Extensions
>>
>> Google with search terms "writing gnome 3 shell extensions".
>>
>> First hit.
> 
> Riiiight. Because I haven't already read that page 65,536 times. :-P

You said it wasn't documented.  It is.

> 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?

> 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? ;) )

> 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.

Jim
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message