Posted Nov 22, 2012 9:14 UTC (Thu) by ebassi (subscriber, #54855)
[Link]
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.
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 16:09 UTC (Thu) by bronson (subscriber, #4806)
[Link]
By this logic extensions.gnome.org is doomed to failure. Curious if you really believe this.
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 18:33 UTC (Thu) by nix (subscriber, #2304)
[Link]
By this logic Emacs would also have collapsed in a heap about fifteen years ago. It seems not to have, and it's not because it takes great care to keep coupling down, oh no (it's the archetypal 'big ball of mud', after all).
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.
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 18:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
>By this logic Emacs would also have collapsed in a heap about fifteen years ago.
Well, it did. I've been trying to use emacs for about a week every year for the last 15 years of so.
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.
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 19:02 UTC (Thu) by nix (subscriber, #2304)
[Link]
Er, that's not what I meant by 'collapsed in a heap'. I meant 'become too buggy to use'. Speaking as someone who's been using Emacs and/or XEmacs for more than twenty years now, this has never happened.
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 19:07 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
Speaking as someone who tried to integrate a debugger (a REAL debugger, not that #$#@*&$^@#*& gdb command line) into emacs - it IS a stinking mess.
GNOME Shell to support a "classic" mode
Posted Nov 23, 2012 9:23 UTC (Fri) by nix (subscriber, #2304)
[Link]
Ah. Personal prejudice triumphs over the facts again (the facts that Emacs is *still working* and has not imploded into something too buggy for anyone to use, despite the arguments of coupling-is-necessarily-bad mavens such as, er, me). I see. I'll ignore you on this subject from now on, then.
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 22:55 UTC (Thu) by ebassi (subscriber, #54855)
[Link]
the model for extensions.gnome.org is, obviously, Firefox. if you look, Firefox extensions are generally self contained, and do not interact with one another.
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.
GNOME Shell to support a "classic" mode
Posted Nov 23, 2012 9:35 UTC (Fri) by nix (subscriber, #2304)
[Link]
Oh no. Firefox extensions? FF's treatment of its extensions would be the reason I stopped using Firefox after nearly a decade of using nothing else: the extensions became useless because FF repeatedly broke all its extensions every few weeks, nobody could keep up, and eventually all the extensions I relied upon to keep FF usable fell into disrepair (I hear it's better now, but it's too late, I moved away). Chrome, with an actual extension API rather than a big ball of mud, has never broken an extension for me in a year and a half of use with dozens of extensions, despite massive progress in that time.
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.)
GNOME Shell to support a "classic" mode
Posted Nov 23, 2012 9:51 UTC (Fri) by ebassi (subscriber, #54855)
[Link]
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.
GNOME Shell to support a "classic" mode
Posted Nov 23, 2012 19:37 UTC (Fri) by nix (subscriber, #2304)
[Link]
The thing is -- generally there isn't a mess. Not even if you load a dozen weird things that have probably never been loaded simultaneously before in the history of the universe. That's what's odd...
GNOME Shell to support a "classic" mode
Posted Nov 30, 2012 20:20 UTC (Fri) by njs (guest, #40338)
[Link]
And perhaps Gnome 23 will have the same property... ;-)
(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.)
GNOME Shell to support a "classic" mode
Posted Nov 23, 2012 19:39 UTC (Fri) by nix (subscriber, #2304)
[Link]
btw, it is clear from your sarcastic response that you too are not interested in figuring out how it is that some software can be apparently tightly coupled and yet not break all the time, despite working on software with the former property yourself. Curious. Apparently poking inaccurate fun at Emacs is more interesting than thinking about it.
GNOME Shell to support a "classic" mode
Posted Nov 23, 2012 10:18 UTC (Fri) by dlang (✭ supporter ✭, #313)
[Link]
you may want to notice that the chrome extensions API doesn't allow some things to be done that are done in firefox (this is one of the reasons noscript doesn't exist for chrome)
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
GNOME Shell to support a "classic" mode
Posted Nov 22, 2012 22:51 UTC (Thu) by ebassi (subscriber, #54855)
[Link]
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.