Weekly Edition
Return to the Development page
| |||||||||||||||||||
extensions.gnome.org launches
We're happy to announce that extensions.gnome.org is now in public alpha testing at: https://extensions.gnome.org If you have GNOME Shell 3.2 on your system, you should be able to install extensions from the website via your browser. This uses the "GNOME Shell Integration" browser plugin which is likely already installed on your system if you have GNOME 3.2. The plugin only works with Firefox currently - see "Known Bugs" below. We've seeded the site with a small set of extensions, including the extensions from gnome-shell-extensions. If you are the author of an extension that has been uploaded, and you want to take over uploading future releases, please contact us, and we'll get you access. The set of extensions on the site is still small compared to the total number of extensions available. We expect more extensions to be available over the next few weeks as authors upload them and they are reviewed. About GNOME Shell Extensions ============================ GNOME Shell extensions are small pieces of code written by third party developers that modify the way GNOME works. (If you are familiar with Chrome Extensions or Firefox Addons, GNOME Shell extensions are similar to them.) Since extensions are created outside of the normal GNOME design and development process, they are are supported by their authors, rather than by the GNOME community. Extensions provide a way to prototype out new possible features for future versions of GNOME, and for advanced users to make customizations in ways that aren't necessarily compatible with the overall design vision of GNOME, but are still cool and useful to a subset of users. Since extensions become part of the core operating system, they need to be checked for potential security problems. Extensions uploaded to extensions.gnome.org go through code review before they are made available for download. More information can be found at https://extensions.gnome.org/about/. Known Bugs and Problems ======================= * There are some bugs that currently cause the browser plugin to not work correctly in WebKit-based browsers like Epiphany or Chrome. We will fix these bugs in subsequent releases of GNOME Shell, but for now using Firefox to access extensions.gnome.org is advised. * Extensions that use GSettings to store user settings cannot be currently installed as a user; this limitation will be fixed for GNOME 3.4. In the mean time, extension authors should avoid the use of GSettings if they want to make their extension available via extensions.gnome.org. * Due to a bug in GNOME Shell 3.2.1 code, the uninstall button will not work for some extensions. Disabling extensions still works, but if you want to remove an extension entirely, you'll need to manually delete it from ~/.local/share/gnome-shell/extensions. Reporting Problems ================== If you find problems with the site, please file them in bugzilla.gnome.org against the 'extensions.gnome.org' component of the website product. Problems with individual extensions should be reported using the "Help! It didn't work!" link on the extension's page. Thanks to everybody that made this happen! -- Jasper St. Pierre _______________________________________________ gnome-announce-list mailing list gnome-announce-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-announce-list (Log in to post comments)
extensions.gnome.org launches Posted Dec 1, 2011 22:52 UTC (Thu) by ovitters (subscriber, #27950) [Link]
I've added the required patches on Mageia Cauldron to ensure uninstall works (as of gnome-shell-3.3.2-2.mga2). I've heard someone already submitted a new extension (battery indicator), it is still being reviewed.
extensions.gnome.org launches Posted Dec 1, 2011 23:42 UTC (Thu) by paravoid (subscriber, #32869) [Link] That would be me :-) Battery percentage indicator was already reviewed and accepted! The website is nice and the submission process was a piece of cake¹. Writing the extension, not so much, since the whole API is largely undocumented and I had to inspect the Shell's source to understand several things about how things work. Still, it didn't take me more than a few hours, and that's for a Javascript and GNOME beginner. I'm not sure exactly how I feel about the whole approach to the problem though I'd probably prefer having an official tree where people could contribute their ¹: With a bit of a worry about the copyright & license, for which I promptly filed a bug for.
extensions.gnome.org launches Posted Dec 1, 2011 23:58 UTC (Thu) by ovitters (subscriber, #27950) [Link]
There are some cool hidden stuff, like e.g.: ALT-F2, then lg
starts looking glass. Some sort of built in debugger. I think more documentation is of course helpful, no matter if API is stable or not.
extensions.gnome.org launches Posted Dec 2, 2011 15:27 UTC (Fri) by robinst (subscriber, #61173) [Link]
> I'd probably prefer having an official tree where people could contribute their crap extensions and these would be reviewed, maintained and forward-ported by the GNOME team
You could aim for inclusion in the gnome-shell-extensions repository, which is kind of what you want:
extensions.gnome.org launches Posted Dec 2, 2011 15:30 UTC (Fri) by paravoid (subscriber, #32869) [Link]
I did, before the website launched. I was informed that this repository was temporary, and will be deprecated after the website launches (i.e. right about now).
extensions.gnome.org launches Posted Dec 3, 2011 10:30 UTC (Sat) by robinst (subscriber, #61173) [Link]
Ok, didn't know that.
I hope it's secure Posted Dec 2, 2011 1:47 UTC (Fri) by flammon (guest, #807) [Link]
It's a little scary to go to https://extensions.gnome.org/local/ and disable or enable extensions from within the browser.
I hope it's secure Posted Dec 2, 2011 6:37 UTC (Fri) by Alterego (subscriber, #55989) [Link]
Is it mandatory to have https to some random gnome site to install extension ?
And privacy ? i really don't like to use web browser to do install...
How does it work for disonnected-from-the-net sites ?
I hope it's secure Posted Dec 2, 2011 8:13 UTC (Fri) by ovitters (subscriber, #27950) [Link]
Not mandatory to use extensions.gnome.org, you can install it manually as well.
Note that GNOME shell does not allow a random website. It only allows the site extensions.gnome.org via https. LWN already covered all the security tradeoffs before.
Regarding privacy, this is setup by the same people who made GNOME shell. So maybe we are like your phone and we already track everything. Or perhaps we can be trusted. :P But you can still install manually.
The installation is not done by the browser btw, it is handled by GNOME shell (site->plugin->shell; shell making the decision + taking action in the end).
I hope it's secure Posted Dec 2, 2011 10:37 UTC (Fri) by cortana (subscriber, #24596) [Link]
Are the downloaded data themselves signed? I don't like the idea that someone in charge of my DNS could cause their own extensions to be installed. Just requiring https is _not_ enough, as the DigiNotar debacle demonstrated...
I hope it's secure Posted Dec 2, 2011 12:21 UTC (Fri) by ovitters (subscriber, #27950) [Link]
No idea, there is a whole writeup at https://lwn.net/Articles/459786/. Installation is not automatic btw, you have to confirm it, that is handled locally. Website cannot automatically install, nor automatically update extensions.
I hope it's secure Posted Dec 2, 2011 13:01 UTC (Fri) by flammon (guest, #807) [Link]
This plugin, like any other plugin I suppose, needs to be bullet proof then. Adobe has had a heck of a time keeping their plugins secure.
http://www.adobe.com/support/security/#flashplayer
I'm sure the developers have seen The Matrix so they're familiar with what happens when a door to the Real World opens.
I hope it's secure Posted Dec 5, 2011 13:22 UTC (Mon) by hnsr (guest, #78227) [Link]
Well.. the Adobe Flash plugin can be used on any website. If I understand correctly this plugin only works for extensions.gnome.org over https. While that is still not bulletproof (considering false certificates can be issued by compromised CAs), it seems much different than the position the flash plugin is in.
Can the extensions system be disabled? Posted Dec 3, 2011 1:00 UTC (Sat) by coriordan (guest, #7544) [Link]
For people who are wary of this, is there a way to simply disable the installation and running of extensions?
(Having extensions as packages in distros would be great.)
Can the extensions system be disabled? Posted Dec 3, 2011 3:00 UTC (Sat) by ovitters (subscriber, #27950) [Link]
At least Firefox allows you to disable it. One of the first things the extension does is to check if the site is extensions.gnome.org using https btw.
Can the extensions system be disabled? Posted Dec 4, 2011 20:09 UTC (Sun) by coriordan (guest, #7544) [Link]
Installing software via my web-browser is is one worry, but maybe my bigger worry is actually in cutting the distros out of the system.
Package maintainers are the reason I trust software to do things such as playing nice with my other software, that the licence has been verified, that the uninstall option will do what it should.
In "non-distro-ised" operating systems (which are all proprietary), the lack of these things leaves systems in a mess. I hope free software doesn't migrate to non-distro-ised ways of distributing software. The ability to add a layer of verification is one of the advantages we have over proprietary software.
It would be great if the extensions could be put into the distros. They could be grouped into a number of bundles if the number is too large. At times they might be months out of date, but that's still clearly preferable in my book.
Can the extensions system be disabled? Posted Dec 5, 2011 8:47 UTC (Mon) by ovitters (subscriber, #27950) [Link]
Distributions can still package them. It is pretty much the same as Firefox. If you don't want to use this site then don't.
Can the extensions system be disabled? Posted Dec 5, 2011 13:10 UTC (Mon) by coriordan (guest, #7544) [Link]
But if the distros don't package them, then users have to either do without that functionality, or have a non-distro system with the problems I mentioned.
But that's just "if". Hopefully they will get packaged, just like Firefox extensions are packaged in Debian.
Can the extensions system be disabled? Posted Dec 5, 2011 14:48 UTC (Mon) by ovitters (subscriber, #27950) [Link]
So if you want your distro to package them, ask your distro to package them. There is not much difference between extensions.gnome.org and 'ftp.gnome.org' in that. It is provided on a site, but it is up to the distributions to package it and keep it up to date.
The difference in this case is that extensions.gnome.org provides an easy way to avoid the distro and see what has not packaged.
I get the impression you think providing a easier non-distro method is somehow a bad thing done by GNOME?
Can the extensions system be disabled? Posted Dec 5, 2011 19:56 UTC (Mon) by coriordan (guest, #7544) [Link]
"Bad" sounds malicious. I hope my comments don't sound like an attack. I'm more wondering if this direction is unwise.
If most/many users are installing stuff directly, then distros have less motivation to package and maintain that software. It seems likely that less software will go through the distro systems, and if that happens then I think free software will be undermining one of its big advantages.
By ftp, there's a power-sharing system. The GNOME devs decide the direction of the software, and the distros can exercise decisions such as when to migrate to the newest version, how it should be configured, what apps should own what mime types, etc.
The distros might seem to hold a lot of power there, but because there are many distros and they have to keep their users happy or lose them, the distros are kept in check too. The same isn't true for GNOME. There's only one set of developers I can get GNOME directly from.
With direct-install, there's no more power-sharing, no more review, no more testing to see if it plays nice with my non-GNOME software, no more need to worry about users going elsewhere etc.
(These issues would disappear if GNOME starts getting forked or if the direct-install repositories get forked, but such forks don't exist today, and we already have the distros which provide these services, so I'd rather support the distros than encourage multiple forks of GNOME.)
Could be a step in the wrong direction.
extensions.gnome.org launches Posted Dec 2, 2011 3:01 UTC (Fri) by MisterIO (guest, #36192) [Link]
At first my main problems with the gnome-shell were basically about usability. I found it (and still do) to be much worse than gnome2, but I could somehow even leave it on my desktop as a secondary choice if those were the only problems. Then I noticed how orrendously bad it performs, in particular for my case, that is someone who leaves many windows open all the time (like 100 windows of a browser like chromium). I couldn't use the system at all anymore, so I completely removed gnome from my system! Unfortunately currently xfce is buggy on debian unstable+experimental (like the window manager doesn't work, I don't know, I just noticed that the maintainer thought it was a good idea to close the bug report about this(reported by someone else)), so I'm currently using KDE. Without the semantic-blablabla which eats your cpu and hd space, it isn't bad!
extensions.gnome.org launches Posted Dec 2, 2011 6:45 UTC (Fri) by luya (subscriber, #50741) [Link] Then I noticed how orrendously bad it performs, in particular for my case, that is someone who leaves many windows open all the time (like 100 windows of a browser like chromium).100 opened windows from Chronium? Was each of them running heavy cpu intensive application like Flash? On which system?
extensions.gnome.org launches Posted Dec 2, 2011 14:47 UTC (Fri) by MisterIO (guest, #36192) [Link]
> 100 opened windows from Chronium?
Yes. > Was each of them running heavy cpu intensive application like Flash? No, _they_ weren't taking any cpu time at all (nor anything external like flash). > On which system? Debian Unstable/Experimental x86_64. Chromium v14, the last one working on Debian. v15 just goes "Aw, Snap" and dies an horrible death!
extensions.gnome.org launches Posted Dec 2, 2011 15:12 UTC (Fri) by Cato (subscriber, #7643) [Link]
Chromium uses a lot of RAM with many tabs in my experience - since GNOME 3 is no doubt more RAM intensive than GNOME 2, you may simply be running out of RAM with that many tabs loaded.
extensions.gnome.org launches Posted Dec 2, 2011 16:59 UTC (Fri) by Frej (subscriber, #4165) [Link]
No doubt? Are you sure? I *think* that 3.0 uses less ram (if 'intensive' ~ amount).... But i have no proof.
But neither do you ;)
extensions.gnome.org launches Posted Dec 2, 2011 18:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Hmm? My x86_64 CentOS 5 VM runs GNOME 2 in ~300MB. My Rawhide machine is close to ~200MB after booting runlevel 3. My F16 netbook is close to 150MB in the same state. Running X on top of that puts it over the VM's usage and I'm just running xmonad and xmobar. The lowest I've seen with Fedora (13 or 14 FWIW) is ~60MB on an i686 and pretty stripped down (no sendmail, sshd, iptables, etc.).
Now, of course, that's nothing compared to my FreeBSD box which boots in 30MB and rises to 40MB after running its jails which include nginx, postgres, a few fastcgi instances, git-daemon, and musicpd.
extensions.gnome.org launches Posted Dec 4, 2011 9:15 UTC (Sun) by Pawlerson (guest, #74136) [Link]
I wouldn't compare Fedora which is full of features to some minimalistic system. I bet you could have even less memory usage with Arch Linux.
extensions.gnome.org launches Posted Dec 2, 2011 17:41 UTC (Fri) by MisterIO (guest, #36192) [Link]
I have 12Gb of ram, so ram is definitely not the problem here.
extensions.gnome.org launches Posted Dec 5, 2011 10:42 UTC (Mon) by jezuch (subscriber, #52988) [Link]
> Debian Unstable/Experimental x86_64. Chromium v14, the last one working on Debian. v15 just goes "Aw, Snap" and dies an horrible death!
It's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647992 and looks like it's stalled.
extensions.gnome.org launches Posted Dec 2, 2011 8:17 UTC (Fri) by ovitters (subscriber, #27950) [Link]
Did you file a bug about the gnome-shell performance? Could you still test with GNOME 3.2 and file it (at https://bugzilla.gnome.org/)?
Even if you do not use it, I am still interested in ensuring it works for you :)
Make sure to mention your graphics card + driver as well.
extensions.gnome.org launches Posted Dec 2, 2011 14:53 UTC (Fri) by MisterIO (guest, #36192) [Link]
No, I didn't file a bug because my guess is that it's a design problem, that is not something that you can fix in any simple way. The problem is that every time that you select a virtual desktop, the windows in it are displayed in real time and that IMO eats huge quantities of cpu when you have many windows open, even if they're dormant (I may be wrong obviously, it's just a guess). Couldn't they take snapshots of the windows at some interval and display them? They could have been even cached that way. Is that impractical or maybe I'm missing something obvious for some reason? Even better, why not just show a little part of the title and nothing graphical at all? Not enough fancy stuff?
extensions.gnome.org launches Posted Dec 2, 2011 15:16 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
The scaling is done on the GPU, not the CPU. It's just displaying another copy of the texture that's aready in video memory.
extensions.gnome.org launches Posted Dec 2, 2011 17:45 UTC (Fri) by MisterIO (guest, #36192) [Link]
It does everything on the GPU? I guess that at least the management of the data structures to use those windows, to move them from the background to the foreground and anything else which isn't just showing an image is still done on the CPU, or maybe not?
extensions.gnome.org launches Posted Dec 2, 2011 18:20 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
I'm not quite clear on what you mean. The CPU certainly has to tell the GPU where to draw the textures, but that's not a significant amount of work.
extensions.gnome.org launches Posted Dec 3, 2011 15:07 UTC (Sat) by MisterIO (guest, #36192) [Link]
I was thinking about dropping this, since I doubt this can be interesting to anyone else other than myself, but, since I answered to another comment, here I am again. What I meant is that probably there is some other work done in the background by the gnome-shell which takes too much cpu time, not directly related to the simple act of just drawing textures.
extensions.gnome.org launches Posted Dec 3, 2011 21:20 UTC (Sat) by ovitters (subscriber, #27950) [Link]
Could be. We have a shell performance stats website at http://shell-perf.gnome.org/home. I guess we should check how it behaves with 100+ windows. Of course in a benchmark 100+ windows might be a few ms slower, but it should not be noticeable for a user (which is a 30% slowdown from what I heard).
extensions.gnome.org launches Posted Dec 5, 2011 8:55 UTC (Mon) by dgm (subscriber, #49227) [Link]
Maybe you mean it's done with OpenGL, so _hopefully_, _if_ you happen to have the right graphics card with the right driver, it _may_ be done in the GPU.
But how can this be related? Are you, MisterIO, showing all the 100 windows at the same time? Or maybe is GNOME Shell so dumb as to try to show all those scaled-down windows at the same time? Or worse, is it drawing them even if they are not shown?
extensions.gnome.org launches Posted Dec 5, 2011 12:06 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
If you don't have the right graphics driver with the right gpu, then right now you're not running Gnome Shell.
extensions.gnome.org launches Posted Dec 7, 2011 4:21 UTC (Wed) by k8to (subscriber, #15413) [Link]
That's the intent or the fact?
It seems like you could have a videocard and correct opengl driver that offers to do the operations but doesn't offer the performance. How is the capability tested?
extensions.gnome.org launches Posted Dec 7, 2011 4:28 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
How many opengl drivers do you think exist without the ability to scale textures?
extensions.gnome.org launches Posted Dec 7, 2011 20:24 UTC (Wed) by k8to (subscriber, #15413) [Link]
For what size textures?
extensions.gnome.org launches Posted Dec 7, 2011 20:38 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
2048x2048 on Intel <965 and Radeon <r500, 4096x4096 on everything else as far as I know.
extensions.gnome.org launches Posted Dec 7, 2011 20:48 UTC (Wed) by k8to (subscriber, #15413) [Link]
There exists a whole range of hardware that never could handle textures over 256x256.
extensions.gnome.org launches Posted Dec 7, 2011 20:53 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
I'm sure. I'm also sure that you're not running Gnome Shell on it.
extensions.gnome.org launches Posted Dec 3, 2011 12:45 UTC (Sat) by deepfire (subscriber, #26138) [Link]
I think you simply run out of VRAM on your GPU, which causes texture thrashing.
I have the same problem, with a relatively small (~20) windows on a 1920x1200 screen on a 128MB Radeon x800.
extensions.gnome.org launches Posted Dec 3, 2011 12:52 UTC (Sat) by deepfire (subscriber, #26138) [Link]
..just to put things into perspective:
1920x1200x4 = 9216000 bytes (all my windows are full-screen)
You can imagine how quickly my GPU runs out of its 128M VRAM..
extensions.gnome.org launches Posted Dec 3, 2011 15:00 UTC (Sat) by MisterIO (guest, #36192) [Link]
My GPU has 512 Mb of VRAM. I doubt that's the problem, but, if it is, then that's another example of bad design! I can't have 100 windows opened because they are all kept in VRAM memory to show them in realtime? Frankly, this doesn't make it look any better to me.
extensions.gnome.org launches Posted Dec 7, 2011 23:49 UTC (Wed) by tuna (guest, #44480) [Link]
Making a system that is optimized for having 10 windows instead of 100 windows open seems like a wise design decision. I am sure you have good reasons for having so many windows open, and if that is your requirement, maybe you should investigate a different DE.
extensions.gnome.org launches Posted Dec 8, 2011 0:09 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
at work we provide services for a couple thousand customers, a few years ago the company decided to re-write the application to be more modern, slick, etc.
During the development they repeatedly made decisions based on "90%+ of our customers don't need this feature". After a year and a half of development they announced that the new version was complete with great fanfare and got ready to roll the result out, only to discover that only 30 of our 2000 customers could use the new version of the product, because every other customer used one of those features that "90%+ of the customers don't need"
the fact that the statement "if you need that feature you should use a different DE" (or equivalent) is being said so frequently should be setting off alarms for people
This sort of thing is one of the big reasons why the simpler Microsoft Office competitors have not taken off, 90% of the people may not use 80% of the features, but the trouble is that it's not the same features that they don't need.
extensions.gnome.org launches Posted Dec 8, 2011 20:50 UTC (Thu) by sgros (subscriber, #36440) [Link]
So, you provided one (ok, two/three) examples of (supposedly) bad designs and that's OK, but the question is what does it prove except that there exist designs that are arguably flawed? How does that extends to Gnome Shell? Certainly there could be positive examples too, and we could end up enumerating both without any purpose.
In this particular case, two things are very interesting here, at least for me:
1. If you have a problem, then you fill a bug! In the end, if it is really a bug, bad design decision, or just a specific case not taken into account on purpose (but otherwise good design decision) is not known in advance and certainly not based on a single case.
2. To claim something is bad design simply based on a fact that _you_ have a problem, and repeat it every time you say something, is a bit too stretched and offensive (at least it sounds so to me)!
And I'm having open 12 Firefox windows and 107 tabs, which is now a lower value of the usual state, but I don't notice any slowdown. Could it be that the original poster really has 100 separate windows? But what is the purpose of such a large number of windows? BTW, I like gnome shell. There are problems and annoyances, but I believe that things will be better with each new release.
extensions.gnome.org launches Posted Dec 2, 2011 13:08 UTC (Fri) by svena (guest, #20177) [Link]
There are some bugs that currently cause the browser plugin to not work correctly in WebKit-based browsers like Epiphany or Chrome"
Yikes! No love at all for Epiphany :(
extensions.gnome.org launches Posted Dec 3, 2011 21:23 UTC (Sat) by ovitters (subscriber, #27950) [Link]
The fixes to make it work from Webkit seem pretty low-impact. I can ask them to do another gnome-shell 3.2.x. release with that fix. The Epiphany people weren't amused by the lack of support (though nothing more than a bug). No guarantees, etc.
|
|||||||||||||||||||