One aspect that I always found very appealing about gnome-shell is that you could just go in /usr/share/gnome-shell/js, make a few changes, hit Alt-F2 r and try them out. This was a very low barrier to entry – no development environment needed, no days of jhbuilding dependencies. This is at least part of the explanation why shell extensions exist in large numbers. Sure, you still have to make yourself familiar with the internal and external APIs that are used in gnome-shell, and if you are unlucky, then Alt-F2 r will show you not your cool hack, but the fail whale.
I was a bit sad to see that we’ve lost a bit of this newcomer friendliness in 3.12, when all the JavaScript and css files were wrapped up in resources and included in the gnome-shell binary (to be exact, they are located in /usr/lib64/gnome-shell/libgnome-shell.so, not in /usr/bin/gnome-shell itself). Why was this done ? I guess having everything in one file and not spread across the file system makes gnome-shell start up a tiny bit faster (although I’m not sure if anybody has measured this).
But how do I now try gnome-shell changes quickly ? Let see…
For some background, gnome-shell is using the GResource mechanism for embedding the js files in the binary. Under the covers, this puts the files in a separate ELF section and makes their content available in a filesystem-like structure. The application itself can get at the resources e.g. by constructing GFiles from resource:// URIs, like this:
file = g_file_new_for_uri ("resource:///org/gnome/software/gtk-style.css");
To access the embedded resources from the outside, you can use the gresource utility that is shipped with GLib. It can list the resources and also extract their content. Sadly, there is currently no easy way to replace existing resources with newer versions, since that requires recreating the ELF section and relinking the application.
gnome-shell has quite a few resources; the list looks like this:
gresource list /usr/lib64/gnome-shell/libgnome-shell.so /org/gnome/shell/extensionPrefs/main.js /org/gnome/shell/gdm/authPrompt.js /org/gnome/shell/gdm/batch.js /org/gnome/shell/gdm/fingerprint.js /org/gnome/shell/gdm/loginDialog.js /org/gnome/shell/gdm/oVirt.js /org/gnome/shell/gdm/realmd.js /org/gnome/shell/gdm/util.js ...
Here is how I used the gresource tool to get back to gnome-shell tweakability. Since the gresource commandline is not very versatile, I wrote this little script:
#! /bin/sh
gs=/usr/lib64/gnome-shell/libgnome-shell.so
cd $HOME/gnome-shell-js
mkdir -p ui/components ui/status misc perf extensionPrefs gdm
for r in `gresource list $gs`; do
gresource extract $gs $r > ${r/#\/org\/gnome\/shell/.}
done
After running this script, all the js files that make up the gnome-shell UI can be found in $HOME/gnome-shell. Now I can point gnome-shell at these files with the (undocumented) GNOME_SHELL_JS variable:
GNOME_SHELL_JS=$HOME/gnome-shell-js gnome-shell
And – voila! – gnome-shell is as hackable as it always was.
Welcome to the FOSS version of Apple and Microsoft in terms of user accessibility and customization.
Sadly, Gnome, once the desktop of choice, has become the desktop that causes choice.
A small and vocal clique of OCD “designers,” no doubt based out of a mojito bar in South Beach, allowed their control issues and Ubuntu envy to supersede rationality and the result is a desktop where form cripples function at every turn.
Somewhere along the way to creating an interface that could be run precisely they way they run their ears and nostrils the Gnome “designers” became obsessed with making it difficult or impossible for those pesky users to mess up their perfect “design” decisions.
In the pursuit of an imaginary user base running desktops with their fingers Gnome took a decent Swiss Army Knife and turned it into a plastic picnic spoon while alienating the majority of the real user base–including the man who invented the OS.
Gnome will remain inaccessible and become more so, as you have just experienced, as long as the arrogant crew of control freaks who hijacked the project remains at the wheel.
They are driving the bus and don’t you forget it. They know what you need and you don’t. They have “designed” a modal interface any idiot can use with just one grubby finger and in doing so they have demanded that everyone else get lobotomised..
Now eat your rutabaga and kale pie with your plastic picnic spoon or you won’t get any borscht for dessert kid. Sure it tastes awful, but just look at the colors and the presentation.
Stop picking your nose! You need that finger to run your computer.
What a fine rant. Naturally, I see things differently, because I’m one of the freaks at the wheel myself 🙂
I am just a normal user, not a developer. I LOVE Gnome Shell and what the Gnome developers are doing… I donate to the Gnome Foundation because I so support what they are developing. I get sick of people bashing Gnome because ‘oh poor me, I can’t make some customization’ that 99% of users have no need for. Rather than complain, provide useful feedback that the Gnome developers can use to improve this marvellous piece of software.
Just to clarify:
I’ve approved this comment because I wanted to show the over-the-top feedback we have to deal with every day when doing design and development work out in the open. And the language here is so over the top as to be almost comical.
I don’t condone that language, and I apologize to my friends and co-workers in the GNOME community who may feel insulted by it. I’ll share a mojito with you the next time we meet !
Wallace Gromit, I love the colourful language, but try checking your facts next time. You obviously have no idea how GNOME actually works, and you’re doing a disservice to all the awesome contributors we have by saying that a few designers run the show. I can tell you for a fact: we don’t.
Allan
Getting slight more off-topic to the root post, but appropriate to the comment…
The inclusion of an explicitly supported extension mechanism in gnome-shell is amazing and makes it acceptable and good to reduce the core feature-set and buttons and exposed buttons and knobs out of box.
I say this both as someone who has been frustrated when features have been removed and someone who has hacked on an open source product with waaaaay too many core features (Thunderbird).
Configuration permutations make it hard for developers to support and test a product and hard for designers to create a smooth flow among the many resulting usage variations. There is no silver bullet for this, but I think extensibility is as close as we can get to this.
And in the case of extensibility, the people doing the extending greatly benefit from the app in question having a simpler core. Because they too are human and it’s much easier to document and reason about a simple system than a complex system.
In summary: bravo gnome-shell developers! And props on this post to try and help keep things eminently hackable. (And also props to those trying to help keep startup-time down/reducing I/O. There is a tension there between hackability and performance and I know there will always be a random walk around the ideal balance line.)
Can I partially agree with Wallace? I found bugs in Gnome, and where I would have tweaked Gnome to resolve them, the details I need to find what is where have hampered me in that chore.
Ergo, the only way to resolve bugs is to file a bugzilla notice.
But for what I do with Gnome, the amount of twiddling to fix something is as much as the fingers in my left hand. Ergo, Gnome and MC, hope you clear out bugzilla.
One of the make modern things I did was to «permenantly» add the EuroSign and the yen to the keyboard layouts that I use.
And to hope that the physical depiction of the layouts is one day updated (I’ve been waiting Fedora versions and nothing yet) Hint, many layouts follow pc105 (extra key between z and left shift) Check out wikipaedia or Gnome 2 from way back or Debian Wheezy to see the correct layout. –try it with CA and latam layouts.
> I found bugs in Gnome, and where I would have tweaked Gnome to resolve them
That’s the wrong approach.
Tweaking something ensures that the bug is worked around for you, and only you.
That’s not “fixing” a bug by any definition of the word.
The way to fix a bug is to report it, and if you can submit a patch, and nag the developers until it is properly fixed.
Hm,
Having it able to still use the files probably would be better … however ..
Nice utility – if you added the ability for it to watch the source files, then repack them into the resource as they change (possibly even restart gnome shell too) – you would be onto a winner.
The only feature missing then would be a backup/rollback facility for when it goes tits up.
So why was it compiled into a single binary file in the first place? I would assume that somebody did some performance testing before proposing this, no? And I would assume that other developers considered the numbers are decided they are worth it, no?
If this wasn’t measured at all, if this was just a spontaneous idea from a particular person (e.g. GNOME designers are very good with spontaneous ideas which are not based on user requests at all – i.e. full-screen app hiding), please consider reverting this back. Because I have tweaked some gnome-shell’s javascript files before, simply because it was that easy to do so. And I was very happy about it. Now it’s just a blob and without proper documentation one can’t do anything. We will see smaller number of new extensions, that’s for sure.
kparal, watching your online footprint, somehow you’ve managed to promote yourself into the same group as Wallace Gromit. Feel free to add the invasion of Ukraine to the things designers are responsible for.
Design is decisions and not all pan out. You seem to be a fan of generalizations and public shaming that really make it hard for me to engage in discussions with you.
The last time we talked, I was trying to patiently explain and you were completely dismissive, at least in my view. So maybe it’s a vicious circle. I’ll try to hold myself back more next time. Still, some approaches amaze me – like the ‘show password when typing’ feature that was fortunately reverted after a few weeks – where it seems like somebody has committed something quite essential without any public discussion traces. I was wondering if this was the case as well. As a general theme, it would be really nice to see more blogposts explaining “why”. On a positive note, I have been quite pleasantly surprised lately (the last release or two), so I think things are moving in the right direction.
When first hearing about the blobbified shell, I was afraid my highly customised GDM theme would need all kinds of hackery. After trying out the Live Image, I am relieved to see /usr/share/gnome-shell/theme is still exposed. Yippee!
Any way to use this as default launcher or just in the terminal?GNOME_SHELL_JS=$HOME/gnome-shell-js gnome-shell