Not logged in
Log in now
Create an account
Subscribe to LWN
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
LWN.net Weekly Edition for June 6, 2013
Isn't this a good thing? Assuming that the original author isn't perfect.
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 9:14 UTC (Thu) by ebassi (subscriber, #54855)
Isn't this a good thing? Assuming that the original author isn't perfect.
one thing that has been learned over the past 15 years of GNOME is that there are limits as to what you can make your environment do, assuming you still want to provide a coherent experience that doesn't break horribly if something goes ever so slightly wrong. it has nothing to do with perfection (which we know is the enemy of "good"), but more with surface area and interaction between different parts of the system. complexity increases exponentially with the number of moving parts, after all.
if you have, for instance, 2 extensions then you need to handle four cases: only (a) is loaded, only (b) is loaded, both (a) and (b) are loaded, both (a) and (b) are unloaded. on top of that, dependencies and ordering may be issues (and one of the things that Clem found is that yes, they are): now you have to handle the case where (a) is loaded before (b), and the case where (b) is loaded before (a). total: six cases, for two extensions; if you look at the list of extensions needed to implement a "classic" UX, you can start to extrapolate how many failure conditions have to be checked to avoid breaking your UI. now a solution is to make it a single extension, or at least a set of independent extensions that do not interact between them and do not rely on ordering, and eliminate all of this in one fell swoop - but this falls outside the constraints on Cinnamon, which allows you to control individual extensions, and has different extensions depending on each other. again, fair enough: I cannot even remotely pretend to dictate what Clem should or should not do, and I don't begrudge him the necessity to fork, given his constraints.
it's really not something that should be so surprising, but I guess it needs to be experienced as a developer to be truly believed. I posit that this is why a lot of people here, and elsewhere, think that GNOME developers are morons that like to remove third party extension points just because the want to impose misery on their users, as opposed to the people that have been dealing with the user-reported bugs and requests for the past 15 years - which is insulting and wrong, but mostly insulting.
Posted Nov 22, 2012 16:09 UTC (Thu) by bronson (subscriber, #4806)
Posted Nov 22, 2012 18:33 UTC (Thu) by nix (subscriber, #2304)
Coupling *is* bad, and it *does* push up the test matrix, but clearly it's not as bad as all that. It might be worth seeing what ball-of-mud projects like Emacs are semi-accidentally doing right in this area, and copying it.
Posted Nov 22, 2012 18:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
It looks like there's no real progress there. Other projects had moved from simple text editors to full-scale semantically-aware IDEs during this time.
Posted Nov 22, 2012 19:02 UTC (Thu) by nix (subscriber, #2304)
Posted Nov 22, 2012 19:07 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Posted Nov 23, 2012 9:23 UTC (Fri) by nix (subscriber, #2304)
Posted Nov 22, 2012 22:55 UTC (Thu) by ebassi (subscriber, #54855)
stuff that we are copying, or we can copy, from Firefox: communication with extension authors; a certain grace period for letting the most successful extensions be updated before the actual release; integration of part of the functionality of the extensions into core.
it's been two cycles: it will take a bit of time to get to the point where Firefox is now.
Posted Nov 23, 2012 9:35 UTC (Fri) by nix (subscriber, #2304)
So if GNOME is modelling its extension API on FF's, it's not a good sign. If it models it on FF's except treats it like an API and doesn't break it at the drop of a hat, that might work better.
(Again, I don't really know how Emacs has avoided implosion despite using the same 'big ball of mud, everything is available' approach as FF extensions do. I suspect it is simply treating its interfaces like a programming language designer would, i.e. extremely conservatively, taking *decades* to deprecate *anything*, so by the time your extension moves from using deprecated interfaces to breaking because they're removed, the app itself is too obsolete for anyone to care about it anymore. It only just broke old-style backquote, for instance, and that started emitting deprecation warnings something like fifteen years ago.
Perhaps if people would consider that they are kicking all their users every time they deprecate a stable interface it might help. I understand that Emacs developers ritually cut off and sacrifice a body part to the cons gods every time they intentionally break anything that external Lisp is relying on :P That attitude might help too, but it seems to be almost unique in the 'just break it dammit' free software community right now.)
Posted Nov 23, 2012 9:51 UTC (Fri) by ebassi (subscriber, #54855)
Again, I don't really know how Emacs has avoided implosion despite using the same 'big ball of mud, everything is available' approach as FF extensions do.
because you're obviously ignoring the fact that the emacs users are putting up with a big ball of elisp with obscure commands that require three keyboards to actually be used successfully, which means that they are capable of getting out of the mess by themselves, and they'll probably enjoy doing so - whereas people installing Firefox and GNOME extensions are much more likely not to be software developers or humungous geeks.
Posted Nov 23, 2012 19:37 UTC (Fri) by nix (subscriber, #2304)
Posted Nov 30, 2012 20:20 UTC (Fri) by njs (guest, #40338)
(Also emacs' UI is pretty flat and decoupled to start with, since it consists mostly of keybindings. It's much easier to merge 10 extensions' keybindings than it is to merge 10 extensions' arbitrary fiddlings with status bars, menus, etc., and those things change from release to release too.)
Posted Nov 23, 2012 19:39 UTC (Fri) by nix (subscriber, #2304)
Posted Nov 23, 2012 10:18 UTC (Fri) by dlang (✭ supporter ✭, #313)
Firefox also has an extensions API, and things that use that are very stable. But Firefox didn't start with an explicit API, instead extensions are allowed to muck with anything in the browser, and ones that do are extremely sensitive to any changes in the browser (potentially including compile options)
as in everything, there are tradeoffs
Posted Nov 22, 2012 22:51 UTC (Thu) by ebassi (subscriber, #54855)
By this logic extensions.gnome.org is doomed to failure. Curious if you really believe this.
you're extrapolating from something I didn't say.
I said that it's extremely hard to create a system that can be QA'd (and documented) effectively - not impossible, because there are few things that are outright impossible.
it's also true that everyone can set up their own system using extensions, evaluate what breaks, and learn to avoid it - locally; end users, especially enthusiasts, have a fairly high threshold for pain, otherwise you wouldn't be able to explain vim, emacs, or enlightenment. I'd rather not expose non-enthusiasts to this mess, though.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds