Le 17/03/2015 20:00, Orchid Win7 v1 a écrit :

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

Well, I do not use gnome anymore on PC. xfce rules now.
I enjoyed gnome2 and its applets. They lost me with unity & gnome3.

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

That's why I now prefer the xfce's run a shell widget (generic monitor):
the output for logo and text is not so fancy, but for periodical
scanning of a resource, it's easy enough to allow me to have want I
wanted (and easy testing), without problem. I could even have the shell
to launch a binary, if I dare to not be portable (and a bit slow for a
double fork)

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

Right. At best: the documentation is in the source code, for doxygen to
extract. But "Source is all you need" is just bad. Code never explains
the concepts.

Post a reply to this message