Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
I must say, their answer isn't very convincing... It reads something like, "Clem doesn't like the new Nautilus so we can't use any part of Cinnamon." It would be nice to hear more.
GNOME Shell to support a "classic" mode
Posted Nov 21, 2012 16:40 UTC (Wed) by ebassi (subscriber, #54855)
Posted Nov 21, 2012 17:30 UTC (Wed) by tjc (subscriber, #137)
Of course Gnome has a better chance of pulling it off, since they can tweak the Gnome code to work better with extensions if they have to.
Posted Nov 21, 2012 19:20 UTC (Wed) by ebassi (subscriber, #54855)
Of course Gnome has a better chance of pulling it off, since they can tweak the Gnome code to work better with extensions if they have to.
well, it's not a problem of access to the code - it's all open, after all, and we still respond well to patches from contributors. it's more an issue of constraint: Mint wants to be able to provide a specific user experience that includes being able to completely change itself in ways that are not under the original author's intents and designs. the GNOME shell extension team can achieve that because it has a smaller surface area, and can make decisions; obviously, this will lead to a series of shitstorms on web forums and mailing lists, with people saying that we "disenfranchise" users (whatever that may mean in the context of a free and open source project), but it's not like we aren't used to it by now.
Posted Nov 21, 2012 19:30 UTC (Wed) by Zizzle (guest, #67739)
The precious GNOME brand. It's not important that users do what they want, we need to maintain the brand!
Posted Nov 21, 2012 19:41 UTC (Wed) by ovitters (subscriber, #27950)
Posted Nov 21, 2012 20:01 UTC (Wed) by tjc (subscriber, #137)
Which is better than the alternative.
I find quite a lot of what I read on the Internet (including most of your posts) not worth reading in hindsight, but I value freedom of speech, so I'm willing to put up with it.
Posted Nov 21, 2012 20:15 UTC (Wed) by ovitters (subscriber, #27950)
Posted Nov 21, 2012 20:29 UTC (Wed) by tjc (subscriber, #137)
Posted Nov 21, 2012 20:37 UTC (Wed) by ovitters (subscriber, #27950)
There was nothing that could be rude as the only thing you said is that you don't find most of my post worth reading. In my impression I think I have more or less the same discussion, usually with the same people in pretty much every LWN article. It gets to the point that even if I am just interested in something other than GNOME, it turns in the same discussion anyway. I sometimes wonder if the repeating the same discussion is not against the spirit of the GNOME Code of Conduct ("try to be concise", see https://live.gnome.org/CodeOfConduct).
Saying "not worth reading in hindsight": I actually wondered why only in hindsight ;)
Posted Nov 22, 2012 3:37 UTC (Thu) by tjc (subscriber, #137)
I'm not really sure what you mean by this, but if you mean "why do I read things that I think I might disagree with," it's because I've learned things from people with whom I disagree with on almost everything. I admit not often, but it has happened.
Posted Nov 22, 2012 8:21 UTC (Thu) by ovitters (subscriber, #27950)
Posted Nov 21, 2012 21:45 UTC (Wed) by AndreE (subscriber, #60148)
And communities are free to enforce standards of discourse to encourage the sort of participation they like.
Posted Nov 21, 2012 22:16 UTC (Wed) by Company (guest, #57006)
This is why I value moderated places like GNOME IRC channels or mailing lists over Facebook or Twitter for GNOME development discussion or Google News over Tumblr.
Posted Nov 21, 2012 21:01 UTC (Wed) by Zizzle (guest, #67739)
This guy must be the ultimate troll in your eyes.
"The point is that it decreases our brand presence. We’ve always argued that if it is anything, GNOME is a UX. There might be a case for letting people tweak things here and there, but I really think that every GNOME install should have the same core look and feel. Otherwise, what is it that we are doing in the first place?" -- Allan Day
"Let’s say that we are trying to define either a product or a product platform. I don’t think it is possible to do this without some “brand” coherence." -- William Jon McCann
Posted Nov 22, 2012 5:23 UTC (Thu) by Trelane (subscriber, #56877)
Posted Nov 22, 2012 5:24 UTC (Thu) by Trelane (subscriber, #56877)
Posted Nov 22, 2012 8:25 UTC (Thu) by ovitters (subscriber, #27950)
Posted Nov 22, 2012 12:18 UTC (Thu) by Trelane (subscriber, #56877)
Posted Nov 22, 2012 13:18 UTC (Thu) by ovitters (subscriber, #27950)
Posted Nov 22, 2012 15:09 UTC (Thu) by clump (subscriber, #27801)
I do wish comments on these articles would stay away from hyperbole. Every time GNOME is mentioned people immediately jump to making assumptions about people and intent. There are gifted coders and contributors on LWN. Surely the time would be better spent contributing.
Posted Nov 22, 2012 16:03 UTC (Thu) by bronson (subscriber, #4806)
Posted Nov 22, 2012 20:49 UTC (Thu) by clump (subscriber, #27801)
Posted Nov 22, 2012 20:14 UTC (Thu) by Trelane (subscriber, #56877)
So don't filter posts with your account? Personally, it helps me deal with stressful persons who're likely to just draw me into yet another unproductive debate.
The "Someone is Wrong on the Internet" thing. It makes life suck just a bit less.
Posted Nov 22, 2012 20:47 UTC (Thu) by ovitters (subscriber, #27950)
Posted Nov 21, 2012 19:57 UTC (Wed) by el_presidente (subscriber, #87621)
Isn't this a good thing? Assuming that the original author isn't perfect.
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.
Posted Nov 21, 2012 20:21 UTC (Wed) by tjc (subscriber, #137)
My impression (which could be wrong) is that the Gnome project does not want to accept patches from outside contributors, which is why Cinnamon was forked in the first place. Are you saying that Cinnamon could be integrated with Gnome Shell and Mutter if the Mint project submitted patches?
Posted Nov 21, 2012 21:05 UTC (Wed) by sorpigal (subscriber, #36106)
So "If you want that maintain it yourself," which they're doing.
Posted Nov 22, 2012 2:20 UTC (Thu) by jbicha (subscriber, #75043)
I believe that whatever muffin does could be done in mutter. Even Cinnamon could probably be implemented in extensions and I think GNOME Shell developers would be interested in accepting a few patches to make that possible (if it isn't already).
But the Linux Mint devs would rather keep their GNOME 3.2 forks of GNOME Shell, Mutter, and Nautilus.
Posted Nov 22, 2012 8:51 UTC (Thu) by ebassi (subscriber, #54855)
My impression (which could be wrong) is that the Gnome project does not want to accept patches from outside contributors
I guess that's why we don't have a public bug tracking system, or integrated patch review on said bug tracking system, or even a public, distributed revision control system to store all our code.</sarcasm>
seriously: we accept patches and contributions from everyone; there are constraints: if the maintainer does not think your patch should be integrated, then he won't integrate it. the reasons for that depend on the product's direction, long term maintainability, style issues, design issues, or implementation issues. any failure to match to the per-product criteria will be communicated and there can even be a back and forth until the patch is either dropped or pushed to the repository.
I have just described the process of submitting a patch to any open source/free software project; it shouldn't be surprising anyone that things work this way for GNOME too.
Posted Nov 22, 2012 8:57 UTC (Thu) by dlang (✭ supporter ✭, #313)
are you really surprised that people don't "work with them" to submit patches?
Posted Nov 22, 2012 9:25 UTC (Thu) by kigurai (guest, #85475)
While I noticed some regressions in the first versions of GNOME 3.x (most notably bookmarks in nautilus), I think it's a healthy sign of a project that features are not applied blindly.
Posted Nov 22, 2012 9:27 UTC (Thu) by ebassi (subscriber, #54855)
but when the project leaders make such a point of saying that they don't want features, they don't want flexibility, they don't want...
this is something you have inferred by yourself, or extrapolated by single data points. yes, it has been said by the members of the design theme that extensions and themes are potentially dangerous; they have any right to say so, and from their perspective (and from others as well) they are absolutely right. on the other hand, you're replying to an article that says that the GNOME project has decided to use extensions to bring the 2.x user experience back for the users that feel so inclined. I think an announcement from the release team, which is direct emanation of the GNOME Foundation board of directors, should have more weight on any judgement of the direction of the GNOME project than individual emails extrapolated out of their context.
another data point for you to consider: I accept patches, I accept features, and I accept bug reports - and so do all the other maintainers in the GNOME project, otherwise we would have closed Bugzilla down. if you think I (or any other maintainer) will commit any and all patches you send my way without a review, then you're obviously deluding yourself: I will reject patches that are sub-par, or conflict with my vision of the modules I maintain. it's not something unprecedented or weird or wrong. if you think you know better, then the licensing and development model allows you to fork my code and do whatever; I'd obviously prefer to discuss things before adopting the nuclear option, but that's just how things works in free software, don't they? try sending a patch for a kernel module written in C++, or using the GNU coding style, or using the wrong interface, to lkml, and see what happens.
tho, I have to agree: we have a marketing/communication issue. every time GNOME does $SOMETHING, people immediately accuse us of being irrational, wrong, stupid, and be on the payroll of Microsoft or Apple or Google or Satan himself. this, repeated over the course of years tends to create a siege mentality - it is (sadly) natural, and we (luckily) lack the personalities to just tell people to fuck off and die in a ditch, like some other project does.
Posted Nov 22, 2012 9:59 UTC (Thu) by dlang (✭ supporter ✭, #313)
actually, I think you (as a project) are doing a pretty good job of getting that exact message out.
This article is one of the very few items that goes the other way.
Not accepting patches because they don't agree with your vision for the project is within your right (and your responsibilities for that matter), but you can't do that and then complain "why don't they just send patches" when they fork your project.
Preventing a fork is at least as much the responsibility of the people running the project (thorugh the process of accepting outside viewpoints and expanding the scope of the project when patches are supplied) as it is the responsibility of the people who start the new fork
Posted Nov 22, 2012 15:12 UTC (Thu) by jbicha (subscriber, #75043)
If you're talking about the MATE and Cinnamon projects, I don't think that those developers even tried submitting patches. If they didn't, then I believe the GNOME developers are fully justified in saying "why don't they just send patches."
Posted Nov 22, 2012 20:40 UTC (Thu) by ovitters (subscriber, #27950)
Now this is not needed anymore (everyone has their own infra).
Posted Nov 22, 2012 22:43 UTC (Thu) by ebassi (subscriber, #54855)
If you're talking about the MATE and Cinnamon projects, I don't think that those developers even tried submitting patches.
correct, as far as I know after talking with the maintainers of the involved projects.
Posted Nov 24, 2012 2:15 UTC (Sat) by tytso (subscriber, #9993)
For that reason, I'm not going to be willing to waste time trying to bend GNOME 3 in "Classic mode" to my will (if that's even possible, given that you don't believe in giving customization options to users). It's clear it will always be a second class citizen, because it's not consistent with your "vision". Which is fine. Fortunately, the XFCE developers are willing to support my desired use case --- which is why I'd encourage all desktop developers who are interested in contributing to GNOME 3 "classic mode extensions", to consider instead contributing to XFCE. At least that way they will be contributing to a project where their contributions will be valued, instead of being at best tolerated since they don't match up with the GNOME project's "vision".
Posted Nov 24, 2012 2:27 UTC (Sat) by jbicha (subscriber, #75043)
I understand you're upset at GNOME 3 to date. Hopefully you can see that the GNOME developers actually do appreciate extensions that add customizability. (I mean that's kind of what this whole news topic is about.)
I'm glad that XFCE seems to be working out well for you. Maybe you should take a look at GNOME 3.8 or 3.10 to see how well the classic mode lives up to your expectations next year.
Posted Nov 24, 2012 3:09 UTC (Sat) by Trelane (subscriber, #56877)
Specifically, I'm using https://extensions.gnome.org/extension/484/workspace-grid/ which has satisfied my need for a 7x7 grid quite admirably.
Posted Nov 24, 2012 19:35 UTC (Sat) by tytso (subscriber, #9993)
The problem is that the GNOME developers have a very bad reputation about not caring about preserving their existing userbase's usage patterns, and instead of developed Steve Jobs arrogance of trying to tell me that "I'm using it wrong". I haven't seen any evidence they've repented of their arrogance. Until then, why should I risk my productivity?
Better to try to encourage more people to use the competition such as XFCE, and make it be a better desktop environment than GNOME 2.x ever was (and certainly better than GNOME 3.x is by my lights).
Posted Nov 24, 2012 21:57 UTC (Sat) by paulj (subscriber, #341)
Posted Nov 24, 2012 22:13 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
XFCE, on the other hand, is not married to GTK2 - there are plans to migrate to GTK3 (it's actually slowly happening right now). And XFCE community is nice enough to minimize breaking UI changes.
Posted Nov 26, 2012 17:07 UTC (Mon) by tytso (subscriber, #9993)
But in any case, that's why I've been recommending XFCE; that and the fact that it's available on all of the major distributions, which is not necessarily true for the Gnome 2 forks.
Posted Nov 22, 2012 17:56 UTC (Thu) by tjc (subscriber, #137)
If you read from the top of this thread down to here you'll notice that we're going around in a big circle, with a lot of context being left behind along the way.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds