This blog post will not be picked up by the usual news sites. News sites don’t care about positive things, it is much more interesting to talk about impending doom. Don’t get me wrong, it is quite healthy and necessary to talk about these things, but it is also an opportunity for haters to come out in full force. From the comments section of Benjamin’s post, I just got the same vibe as usual (note: take the following as an introduction with a bit of tongue-in-cheek humor):
- People don’t like change. “YOU MORONIC FREEDOM HATING NAZIS, WE TOLD YOU, WE TOLD YOU SO! How dare you!”
- People like change. The silent, happy userbase just doesn’t spend time fighting the haters in the comment sections of Slashdot, “OMG! Ubuntu” and of the various blog posts who slam the GNOME3 vision or user experience. Admittedly, Benjamin’s post is more on a “platform healthiness vision” level, not on the UX level.
The desktop is dead. Mobile is the way to go. We have driven the ammo tug to the railgun and built the gun controls. FIRE ZE RAILGUN!- Mobile is dead. We’re too late. Fall back! Focus on the desktop! Protect ze fuel depot!
- People find installing an extension or using the Alt key to suspend way too hard and insulting. For those people, with GNOME 3.6, it will be the year of GNOME on the Linux desktop, obviously. On a philosophical level (see further below) I am not sure I agree completely with backing away from that bold decision, but oh well.
There, that’s the jist of it. Now you don’t really need to read through the remaining 200 comments of angry geeks venting their frustrations. You shouldn’t read that kind of stuff unless you already have a strong, flame-retardant psyche and a transatlantic flight.
The next few paragraphs are going to be walls of text of a more philosophical nature. Worry not, there is an optimistic, “here’s what we can fix” plan just a little further below, so jump to the “Let’s fix this” section (right after the Doom poster) if you just want something concrete.
I’d like to take a minute to talk about the myth of “powering off”. Personally, I always agreed with the core idea behind the “suspend only by default” design decision (even though it’s a really bold move): when people say they want to power off, what they actually mean 99% of the time is “I want my computer to stop using power”. Suspend to RAM achieves exactly that. Yes, I actually have measured power consumption, on multiple machines.
- Suspend eats no more power than a full poweroff on a desktop, let’s say 5 watts instead of 4 watts. You heard that right: your desktop computer’s power supply constantly draws a few watts even when fully turned off, and the difference between that and suspend to RAM is insignificant (if you care about 500 miliwatts and such things, please seek professional help).
- For a laptop, maybe you should, you know, try plugging it sometimes. I do that everyday when I’m not on the move. Or rather, maybe we need a label on the packaging of laptops that says “I’m not a power vampire that eats more than 50 miliwatts while asleep”, or a “This laptop has a 5 weeks standby capacity” standard labelling like cellphones. Someone needs to lobby the FCC or some electronics standards committee about this. If not for me, do it for Matthew Garrett and the polar bears.
Second, I want to point out that the tabloids will think that GNOME is somehow “dying” because “the majority of people are massively boycotting it”, both of which are quite untrue.
- What is worrying the GNOME community lately is that serious corporate investments in the platform have diminished a great deal; however, the concerted economic difficulties and strategic reorientations of various corporate patrons we relied upon (Nokia, Novell, Sun, to name only a few) are a better explanation of the impact we see on “plumbing maintainers”. You think these guys would stop caring about GNOME just because of GNOME Shell? Think again.
- The current “monoculture” (of sorts) that Benjamin warns about is a consequence of a serie of unfortunate events, of which Redhat is one of the very few strongholders left. Redhat does have more influence now, because we are letting them have it. While I am very happy with the work that is being spearheaded by Redhat, I have to say that the idea of a monoculture does worry me too, at least from a theoretical standpoint.
If the above depressed you, perhaps you could watch this year’s GUADEC keynote on the history of GNOME to regain some perspective. Against impossible odds, we’ve been doomed since 1997; somehow we’re still alive and kicking. Keep calm and carry on (but let’s not blind ourselves regarding the situation we are in either).
Let’s fix this.
On the bright side, from the comments on Benjamin’s post, I was able to see recurring patterns of things that need fixing. Here’s a list of actionable recommendations, concrete stuff that we can start tackling right now to make GNOME Shell more accomodating and to make GNOME a better platform to contribute to:
- Extensions are good. We need more extensions, and better integrated.
- Perhaps have an “idea storm” page on the extensions website, where people can submit requests for extensions and vote on ideas.
- Usually, the biggest criticism is the fact that some people really, really, really don’t want to use the overview mode for task switching and they can’t stand the idea of the topbar “wasting space”. Well then, let’s have someone write an extension that provides a copy of the dash onto the topbar and aligns the clock to the right. There you go, most of the hate will go away.
- Oh wait a second… there are already extensions that do all of that! autohiding the panel, configuring the visibility of the dash, showing a window list, not missing chat notifications anymore, moving the clock, traditionnal alt+tabbing (and its duplicate)… the list goes on.
- We should definitely have a “ihatechange” tag for these extensions made to address the biggest recurring complaints (yes, I’m serious).
- Then maybe the problem is awareness: we need to make extensions an obvious part of the core GNOME experience, not hidden away on a website whose existence you have to guess.
- The extensions website is not even linked from the main GNOME website or the GNOME3 page. Extensions should be in the top list of features, part of our marketing efforts.
- Integrate the extensions website into the upcoming GNOME software center design, even if it’s a silly embedded webkit window pointing to the extensions website in the beginning. Provide a fast filtering search with local caching, replace the page numbers by a “show more as you scroll” workflow, use the “categories” (tagging) system, have a way of grouping similar extensions together, etc.
- Perhaps consider making gnome-tweak-tool a core component that should be installed by default. Maybe (gasp!) it could even be merged with the “Details” (née “System”) panel from the control center, unless the point of the tweak tool is really to escape the legislative power of Freedom Haters.
- Our excellent documentation might need to be more in-your-face.
- Show it on the first startup of a new GNOME version (afterwards, disable it in the gnome session autostart; “OEMs” like me can re-enable it before shipping the computer to someone else), in a similar vein to Fedora 17’s new welcome dialog on its liveCD image.
- Ensure the keyboard shortcuts, the right clicks, the middle clicks, the hot corners, the drag and drop UX, etc, are fully documented (as far as I know, the docs are already pretty good). Not everyone bothers to look up an obscure wiki page, and handholding people a little bit by providing a cheatsheet can’t hurt.
- Identify confusion points for your users in your own application and either redesign them or provide more contextual help. For example:
- One might think of adding a button that triggers the relevant Yelp page in the display settings where setting the primary monitor is far from obvious (arguably, there’s got to be a better design for this one, adding a help button would take just as much space as a “Make primary” button in this case…).
- Link the keyboard shortcuts Yelp page from the control center’s keyboard settings. Rinse, repeat for other areas. Don’t assume that people are intrinsically attracted to Yelp, or that it is even among the items in the dash.
- Fix our keyboard shortcuts. Make the keyboard shortcuts standard all across the board and make the standard in-your-face. If possible, consider making changes like these configurable in the gnome keyboard settings. Make it a well-documented GNOME Goal that apps should use those shortcuts from the user system settings instead of hardcoding them.
- Desktop development is harder than it should be.
- Make the new contributors & programming documentation first-class. Appeal to 16 years old tinkerers. I haven’t thoroughly checked their work, but as far as I know we have interns making progress on that front, and I commend them for that. This is a very strategic asset you are working on. We need to push this much further.
- Beyond the fact that they’re quite obviously a very different ecosystem, look at what the Android and Apple (especially Mac and iOS) platforms are doing in terms of contributor experience. See what they do wrong and what they do right in terms of documentation and in terms of making it attractive to just “jump in, hack something together and publish it for the [GNOME] platform”. Analyze the competition, match and surpass them.
- Dogfood our platform from a newcomer’s point of view:
- The “Get involved” page on the official website mentions the GNOME Love initative (which is great), but there are no direct links to actual tutorials and full-fledged documentation, or marketing about the awesomeness of our platform (see our competitors).
- You have to crawl through the semi-obscure wiki or know about the existence of library.gnome.org (not linked from anywhere?), open a dozen tabs, and I’m still unsure whether or not I really found what there was to find, and if what I found was up to date and complete. Potential contributors should not have to do more than 3 clicks before finding something relevant.
- The wiki might not be a full replacement for putting things upfront on the website. Wikis are sometimes quite bad at revealing their structure or guiding you properly (but maybe this is just a cleanup issue). It’s like a maze with no clear sense of scale. Take this with a grain of salt, as my mind probably works in strange ways, but here’s what my trajectory looked like: 1→ 2 → 3 → 4 (ooh, a wiki?) → 3 → 5 → 6 → 7 (hmm, maybe I should have found this earlier). Unless you’re actively looking for a tiny gray link in the website footer, you probably won’t stumble naturally onto the wiki home page.
- Generally speaking, spreading our content across many different sites with different designs, structures and navigation systems sucks.
- There’s a ton of cruft and dead pages. We might need a patrol team. At least, some system to easily find and tag old pages for update or phasing out. Example on pitiwiki: old pages, orphan pages, obsoleted pages.
- Make Python (+ GTK3) the “official” language for our ecosystem. We need to pick one and only one default proposed language for newbie contributors.
- Unless you’re making a performance-critical application, you should never have to touch gobject C. The C language is a chainsaw with no safety switch, armed and dangerous unless handled by capable hands. A desktop application written in C will consistently have 1) an exponential learning curve 2) three to six times more lines of code, files, infrastructure, boilerplate, headaches 3) more bugs and vulnerabilities. Coding in C without excellent reasons to do so is malpractice and is a disservice to your users.
- If a new contributor already knows what he/she’s doing and plans to use Vala/Java/Fortran for whatever reasons, that’s fine, and we can have docs for that; but don’t waste time suggesting anything but our official high-level language for those who “just want to get something done”.
- http://python-gtk-3-tutorial.readthedocs.org should certainly be linked or officially integrated in the GNOME developer docs.
- How about providing a “GNOME SDK”? The development testing ISOs we already had once in a while could actually become an official, strategic tool to encourage development instead of just being “one off snapshot testing tools”. Just make a Fedora spin that includes a complete set of offline documentation packages, debugging packages, IDEs, devhelp, code samples, an IRC client preconfigured to some specific channels, and perhaps an optional (opt-in) “nightly gnome builds” package repository instead of requiring jhbuild.
- Make the new contributors & programming documentation first-class. Appeal to 16 years old tinkerers. I haven’t thoroughly checked their work, but as far as I know we have interns making progress on that front, and I commend them for that. This is a very strategic asset you are working on. We need to push this much further.
- Make GTK3 a “compelling” sell. From experience, besides integrating with the new UI themes and getting some fixes, to the average app developer, GTK3 has no prominent “killer features” or “highly visible bug fixes”, just potential “risks”.
- The GTK+ website does not have a “why you should port your app from GTK2 to GTK3” page. It should.
- Some think that the lack of fulltime GTK+ maintainers is not really a problem. I’m a little bit unconvinced by that argument. Personally, I would like to see funding to have more people working fulltime on GTK+. We might want to consider this for a minute: GTK+ is a fundamental, core asset of our platform, and it’s quite a beast to maintain (by the way, want to help out as a volunteer? see this page). We have way too many longstanding bugs, regressions and missing features/polish (hello, GTK FileChooser [1][2][3][4][5][6], to name just my favorite component). How will we ever get to such enhancement requests before fading into obsoleteness, if we barely have enough manpower for sustained core maintenance?
- GTK+ is infamous for being the GNOME product with the most bug reports (still 3400 of them!), and this must be quite a crushing weight. Perhaps we could organize a special “bug triage fest” with the bugsquad, GTK+ hackers and community members, at the Boston Summit or the next GUADEC? This would certainly help cleaning up ten years’ worth of accumulated bug reports, many of which are probably obsolete or duplicates. This is probably going to require a full week of concerted work between multiple triagers and GTK+ developers, but it has to be done.
Documentation, infrastructure and “initial UX” folks: now you’ve got a map with mission objectives. Make it happen!
Related readings:
- The Future of GNOME, by Christian Schaller
- The Queen’s Rebuke, by Emmanuelle Bassi
- Thoughts on “Staring into the Abyss”, by Taryn Fox
Business management consultant, branding strategist, free & open-source software contributor and experienced community manager. Has unlimited hi-HP potions to keep teammates alive.
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
Latest posts by Jeff (see all)
Comments
37 responses to “Staring into the Axis' Abyss: the Railgun map”
Turning off my computer works like this:
(1) Shut it down
(2) Switch the hardware plug that disables power for all my electric devices in my computer room.
Step 2 saves about 25W. And no, burning 25W just so you can keep suspend-to-ram is not a good idea.
Also, shutting down the computer gets rid of all memory leaks, memory corruption and other brokenness in the system.
Also, your whole posts screams “work hard on making GNOME more configurable”. Extensions, binging back tweak-tool, making keyboard shortcuts changeable, …
I’m not sure this is a direction the GNOME project wants to take? 🙂
Having extensions is nice, but they shouldn’t be seen as a substitute for doing things right by default. If a significant proportion of the user base are installing the same extensions because they don’t like the out-of-the-box experience, developers *do* need to consider that they should change the defaults.
And that’s especially true in the case where you end up telling the users that what they want is wrong. Your argument about power management is all very well, but as Benjamin Otte points out, it sometimes misses the point – and the amount of resistance developers have shown towards supporting a simple power-off function is an absurd waste of both time and goodwill.
The GNOME Shell extensions system is a clear indication of the designers and maintainers’ willingness to give some freedom beyond the uniform “core experience”. If they didn’t want that to be possible, they wouldn’t have made it, would they? Let’s not turn them into demons for sticking to their guns and keeping the core “simple and solid” 🙂
Tweak tool: I’m just conjecturing the wild idea that maybe we could make the “Details” pane actually useful by merging the tweak tool into it. I doubt the design team will be thrilled by that idea though.
Configurable keyboard shortcuts: well this has persisted into the GNOME 3 control center, so I suspect they’re not going away. Might as well make the most of it: to me the problem is not that they are not present, it’s that apps might not necessarily be using them (unless I’m mistaken).
Except that I would venture a guess that this is not the majority of the user base, as ludicrous as it may sound. I argue that angry geeks are a minority (maybe 10-30%, who knows), but to prove it you would need a “true”, statistically sound referendum on that matter. And just like distro statistics, it is pretty much impossible to get something truly accurate and representative of the totality of the GNOME population. Just as the Fedora statistics page says on the validity of opt-in or arbitrarily sampled statistics, “Anyone who tells you otherwise may be misinformed, dishonest, or trying to sell you something” 😉
Gnome project needs to understand that computer must behave in a way that fits people physiological thinking.
Even if shutdown saves no amount of energy, it gives closure for your work. Let me explain, I start the day with a fresh desktop, I do a daily routine to make me fully functional in a few minutes and in the end of the day I shutdown the system with a felling of mission accomplished. The next morning it will all start again. I will put my laptop on standby if my work needs to be interrupted and taken back a few moment later.
Most people thinks this way, that’s why almost all book have chapters, people need to interrupt an activity on an organized way. Sure, you can close a book in the middle of a chapter, but you will fell comfortable if you stop on the end of the chapter, as the author intended you to do.
Pedro, your argument is interesting (in a socio-philosophical way), I can’t resist replying to it. Personally, I hate shutting down my computer. I don’t like having to remember which applications I had running the last time, launching all of them, reloading my dozens of browser tabs, remembering which conversations I was having before running to catch the bus, etc. I like that applications start instantly because they are still warm in the kernel’s RAM cache. Booting a computer and setting things up to their previous state is just wasting my time.
I only restart to apply kernel/major upgrades, which is why my laptop has an average uptime of only one week. People from my family (parents, uncles/aunts who run GNOME 3…) have uptimes that are counted in *months*. I kid you not. To them, the computer is just a self-managed appliance. It autosuspends after 30 mins and it Just Works.
If you’ve ever used a modern cellphone, you don’t shut it down every day, do you? Same for computers. I don’t shut down: I close apps to free memory or to unclutter my view as needed. Selectively quitting apps does the same thing as shutting down, without the disadvantages. There are many ways to debate your “bookmark vs chapters” analogy, but I won’t get into that because that’s really not the point of this blog post.
To future commenters: please focus on the topic of improving the GNOME ecosystem at large 😉
I am curious whether you tested the situation where you abruptly lose power when the machine is suspended. I wonder what are the chances of the filesystems getting corrupted. Power cuts are quite common in summer in parts of the world and that was one of the concerns about trying to discourage powering off.
I agree with many of your points. Personally, I have adored Gnome 3 from the moment I first used it, particulalry because it has the facility to be modified to meet my needs, even if this is not as easy as it might be at times.
However,
There are numerous examples in the design discussions of ´core designers´ stating categorically that extensions/themes etc are not considered part of the intended design and should be kept at arms length.
There has been a proposal to integrate gnome-tweak-tool into the main settings for over a year which has been roundly criticisied for these reasons and ignored.
The extensions website has always been second rate at best, whilst new method of adding preference dialogs is a mess.
One does not get the impression that user customisation is at the fore-front of gnome designers´ minds. Quite the opposite, with every option being systematically removed from the core software such as Nautilus.
As with your suggested changes to the Gnome website, these problems are more a matter of perception than reality, but perception is often more important than reality. The suspend-as-default is a perfect example – it cost the developers nothing to offer an alternative, and the refusal to do so for so long just read as ´we know better, you plebs´.
p.s. Python is a terrible choice!
I must confess I was initially among the people a bit horrified by Gnome 3, partly for some reasons given in this post (e.g., the extensions, which made my personal experience much better when I discovered them and which could have been more advertised). Now I find it really cool (except for gdm, but I have a computer shared by people who use different languages and keymaps…), but it is quite a change which, I guess, should be “accompanied” as much as possible (I like the idea of showing some doc at first startup: a desktop upgrade is not the occasion I would spontaneously RTFM, yet for such a different approach it’s more than useful).
“Make Python (+ GTK3) the “official” language for our ecosystem. We need to pick one and only one default proposed language for newbie contributors”
I think it would also be interesting to have some visibility on the languages used by different projects. Either when choosing which language to pick (where I think it could be reassuring to know that it’s possible to write real projects in this language and that it’s not just an obscure binding that might disappear from next release) or for people who might want to contribute code to gnome (if you only learned python+gtk, it might be easier fixing bugs in Python than in C). Maybe such a page exists, but I have the impression this information is quite disseminated (e.g, there is a list of project using Vala on the Vala page and I guess it might be the same for other languages).
Extensions break when you upgrade Gnome 3 (that happens every 3 months), so you need to start over looking for the same extensions to be updated. In fact, I’m not using the same extensions I was using in the previous Gnome release.
Another weak point to the extension aproach is that “let’s have someone write an extension that …”. Sometimes it won’t happen. I won’t do it, and lots of people can’t do it. I understand some people are angry when a feature is removed and the answer is “let’s have someone write an extension that …”.
So I agree extensions may work, but “to extend”, not to implement features that should be there by default.
About Python: I’d love to see Python in a better shape in Gnome, but I don’t think it can happen. Have you see the Python docs? Have you read the arguments against Python? Looks like it is too slow to be used in the desktop (BS), and that’s why some people is pushing Vala forward. Who’s using Vala ouside Gnome anyway? I don’t understand why an unknown experimental language is so important for Gnome when the motivation to use Javascript in the shell is because it’s a widely used language that can attract developers (specially from the web world).
Finally I agree that a Gnome SDK would be a great!
Thanks for your post. You exposed some great ideas!
I’m an ex-Gnome user since Gnome 3 was out, but I still browse Planet Gnome from time to time, curious to see what’s going on. Posts like yours are quite a treat: what a wonderful black-and-white world you live in! On the one side, the smart developers, provided with a vision and knowing what’s best for the user (even if the user doesn’t know … yet!), surrounded by happy, praise-singing Gnome 3 users. On the other side, an angry rabble of “haters”, people who bash Gnome 3 and that oh so wonderful vision just because they’re … evil, misguided, frightening people! All that hate! No good criticism to reply to!
Really, while I disagree with a good number of your points, I think that any kind of arguing against them is ultimately impossible: I doubt I could pierce your delusional state and discuss actual issues with you. You guys have been living and copying so much in Jobs’ shadow that you’ve sort of inherited his reality distortion field. Let’s say a “distorted reality distortion field”, a bad copy … again.
I’ve said your post is “a treat”, but that was actually bitter irony: it is just sad to see what’s becoming of a great desktop environment. I used Gnome since the beginning, enjoyed the transition to Gnome 2 (see? it’s just that change for good is good, change for the sake of change is bad, what’s the part you don’t understand?) and helped many friends installing it and using it instead of Windows. No more of that.
The most ironic fact (again) is that you’ve screwed up a good desktop environment to create a franken-touch-enabled one: and how many tablets or smartphones have been shipped with Gnome 3? how many this year? how many are available now, or will be shortly? in 2013? Yeah, I thought so.
I’ve few complaints about the whole situation
apart from that some linked whining of mine: https://gist.github.com/3272421
Python, GTK and documentation
A few weeks ago, I tried to make a little map application. Similar to what is described on https://live.gnome.org/Design/Apps/Maps. I’m sure my choice of language, my “prototype” like coding flavour will not ever make my attempt to be an official part of Gnome, but I got the core functionality working.
Libchamplain and the code introspection was kind of amazing, and I made huge steps in a short amount of time.
But, the documentation sometimes make it unnecessary hard, by having you to guess what a C function will be named in Python. Is it capital letters, underscores, but worst is to “find out where the dots should be”, i.e. how to convert to an object oriented language. And with the conversion to GTK3 some functions have moved from Gdk to Clutter or elsewhere, and easy stuff has been make very hard.
The documentation looks auto-generated from C code, and there is little effort in trying to make it usable in Python. You have to use the Python Gtk tutorial for all it is worth, knowing it will not cover what you need.
If I would know that there is room for an experienced Python programmer (and a Gnome user and planet reader for about 10 years), I would be glad to help. But I don’t know: Which python programs are there, and which of these needs help, and what kind of help do they need? Has somebody written a guide to how to read C documentation and (humanly) interpret it as Python? Would such a guide be appreciated, should it be part of the tutorial or what? Would it be possible that a core Gnome application, like the Maps, could be a Python program?
1. You seem like a cool guy. I’d like to have a beer with you.
2. Every update of gnome has, for me, broken every single extension used in previous versions. It’s part of the design. Sometimes just telling the extension “Frack you, you will now accept the number 3.2.4” will make it work again. Broken by design?
3. Otte’s most important comment was ignored. Name one touch device currently using gnome. If it was redesigned for touch, did it even support touch in it’s 3.0 release?
4. I’m not a programmer, but it must be, it just must be, harder to remove a feature entirely than to just change it’s default setting. For example, it has to be harder to completely remove the ability to split screen nautilus than to just create a default keybinding on f3 in nautilus that disables it from working. Gnome is literally going out of its way in the name of design zealotry, as opposed to some other goal, like touch focus. It harms the purity of the vision to even enable the ability to split the screen.
5. The people who are the brainchilds of this vision, can’t even be bothered to add logging to their irc channels. Why? Because frack you that’s why. Add an extension if you want to know what we’re up to.
6. Seriously though, if you’re ever in Canada, let me know. I’d love to buy you a beer.
How about doing things in the right order? Far too often I see in GNOME the following chain of reasoning:
Examples would for instance be the removal of the homepage and customisable toolbars in Epiphany, the removal of the support for compact view and extra pane in Nautilus, the release of GNOME 3 before it had A11Y support, the lack of world clock, weather and calendar notifications in the first GNOME 3 release (calendar is there now, but world clock is still being worked on, I dunno if weather is on the way yet?), etc.
Extensions are great, but not all GNOME components have extension support, and not all missing (read removed) functionality can be reimplemented using extensions. I’ve found myself using Epiphany less and less since the homepage and support for a toolbar where I could place bookmark folders and search boxes were dropped.
@Derisann:
Sure you can. I’m a very agreable guy and you might find that I have a very flexible mind, although it loves to argue and has strong opinions on some matters (such as patents, interpretation of statistics, etc). Grab me at one of the many open source conferences or in the Montréal area for a chat.
Now, I did satyrize a bit the portrayal of the situation here in my long introduction, that’s part of what makes my posts a little bit more interesting, motivating, and let’s say “uplifting” to the community rather than just focusing on the criticism at face value. Perhaps you have not noticed that my post is quite a bit more empathic towards power users than many… so don’t shoot your own messenger!
@justSumHayta: I do happen to live in the Montréal area, if that matters 😉
I agree on the “no mobile devices actually ship with GNOME Shell” point. This is also something that needs to be fixed, but it’s not part of my “easy” list of concrete, “actionable” items. It’s a longterm goal, and I’m afraid to think that GNOME might already be a bit too late on that one. Kind of like any desktop Linux being shipped by mainstream OEMs, actually.
About the Nautilus split view being removed: people are all up in arms about this and, to be honest, I’m not so sure why it’s a loss. The splitview was buggy as hell and I don’t see how it is any better than just pressing Ctrl+N to get a new window to put side by side. I have yet to see concrete, convincing arguments of anything that “splitview” does that two actual windows couldn’t do better!
@sigurdga: I feel your pain. I don’t quite like reading the C API documentation to guess function names either. Surely someone has a plan to clean this up in a programmatic way.
I would add another point to this list:
Try to find out the number 5 top hates about GNOME Shell (and I’m definitely not talking about a “catch all” like “lack of options”) and see if you can satisfy them without extensions.
Even if you have to add options for them. Having options most definitely has a cost, but GNOME should be able to afford the top 5.
My guesses (but at least a semi-real survey should be done) for the top three would be
1. Being able to make the dock “always visible”. Auto-hide can stay the default.
2. Being able to set the font size without installing GNOME tweak tool.
3. Give up and make “shut down” a first class citizen. It’s just not worth it.
The point is that F3 is just quicker and it does not eat up more screen estate. CTRL+N sprawls a window next to the existing one, F3 just splits the existing one, so anything that was visible on the screen before pressing F3 is still visible. It is also esier to close. And, it is quicker, as I just said.
I actually triggered this by accident and was surprised and had to google what happened. But when I learnt what it was I fell in love with it pretty quickly. I actually love nautilus – its extensions, scripts, extendable context menu, bookmarks (are they not removing those too?), samba and other network places integration, overall integration into the system. It is powerful but yet simple if you do not want to use advanced features. I do not see why they need to make it simple but not powerful if it already is simple.
Luckily I can provide easy steps to help you understand why the split view is superior to dual windows:
1. Open nautilus
2. Switch to fullscreen (for some reason it doesn’t seem to support F11, so press maximise instead)
3. Open a new window
4. ???
5. Gaze and behold as the new window (of course) opens up maximised over the other window
You may argue that fullscreen mode is not natural for nautilus anyway. Fair enough, so alternate flow:
1. Open nautilus
2. Press ctrl + n
3. ??
4. Gaze and behold as the new window opens *almost* on top of the old one with both windows having, by default, 1/5 of their width taken up by the sidebar. To get to a usable state from here you thus have to go through moving and resizing both windows
The sidebar does not contain any dynamic information (TTBOMK), so having two sidebars is superfluous (but cannot be avoided when having two separate windows, since that’d be illogical).
A typical usecase:
1. Open nautilus on my oggplayer
2. Open extra pane with my music collection
3. Copy various directories with oggs to my oggplayer
4. Press safely remove device (btw, it seems that nautilus — or possibly some other component — doesn’t quite know how to handle that operation when performing it on an SD-card, it always display an error message)
This workflow works perfectly, and I’ve a hard time seeing how the multi-window approach could in any way improve upon this (well, I admit that having it know a priori which music I feel in the mood for and copying it automagically would be better, but I doubt that’s realistic :P)
To turn your argument around: I still haven’t seen any examples of how multiple windows would perform this usecase better. Sure, there are contrived situations where a multi window approach works better (I’m not arguing for removing it), such as when copying things back and forth between multiple different sources (say, 2-3 different remote servers, local memory cards, etc.), but the basic usecase of a file manager is 1:1 (one source, one destination), or M:1 (multiple sources, one destination).
BTW, pardon my ignorance, but is there any extension yet that allows static, preconfigured workspaces in a 2-dimensional grid, with a workspace picker visible on the top menu (or, possibly as a weak workaround, on the bottom statusbar)?
The only solution I’ve seen so far seems to be a horrible 1-dimensional kludge where you have to first use dynamic workspaces to choose your desktop size, a kludge that also seems terribly buggy wrt session saving.
Thanks for the link to the “primary window” bug. Here I was giving xrandr –primary commands on the CLI every time Gnome got the primary window wrong.
@Jeff François Fortin Tam, aka Nekohayo:
Thanks for your reply. I re-read your post more carefully and I have to apologize for my overreaction: at first glance it looked like another one of those “everything is well and good!” posts that have filled PGO after Guadec, you’re actually trying to help improving things instead of doing PR (or simple ego reassurance), so indeed I don’t want to shoot the messenger.
That said, I do not envy your task, because at the present moment there’s no easy way to make Gnome Shell interesting and usable again for those who left: I’ve tried to use extensions, and have been burned by instability and breakage (also the fact that you have to go and find the right extension to reinstate basic functionality is quite annoying); there’s just so much you can gain by making gnome-tweak-tool a standard part of Gnome 3, more configurability options should be added; most important: the new behaviors required by the dash, alt-tab etc., the amount of clicks you need to do something that was as close as a panel menu are just a show stopper for me and, judging from what I read online, quite a lot of people; finally, the new decisions/tendencies that one can gather from PGO or other news (i.e. the continuos removal of features to make Nautilus more touch-friendly, the split menus for application windows, the “new application” design etc.) are step in the *wrong* direction, as far as we oldies are concerned.
At some point in time I dreamed of Gnome 3 available in two variants: a “traditional desktop” and a “tablet enabled” one; after all I’m quite happy with Cinnamon, which is just a more traditional approach on top of the same Gnome environment. But if I’m right about the devs’ intentions, the Gnome Shell will diverge further and further from a traditional desktop, to the point of no return.
Hope I’m wrong, good luck with your message 🙂
You are absolutely right about gnome’s documentation: I just tried finding it in my Debian testing gnome3 installation and couldn’t. I tried the search terms “help”, “doc” and “yelp” as well as their german equivalents (I’m using german as configured language in gnome) in the activities overview and couldn’t find anything. So I fired up “yelp” from a terminal and found a really nice documentation. Yeah! This documentation really needs to be a _lot_ more in my face!
Sorry, but users don’t want their computer “to stop using power”. They either want to turn it off or suspend it – as others have explained, it’s not the same thing at all, regardless of power consumption. The OS GUI should provide an obvious way to do both things. The same applies to pretty much everything else. Some people feel more confortable with “focus follows mouse”, others with “rise to focus”, etc. Developers should not try to push their (often strange) opinions on how things must be done onto the users, or they will alienate them. Flexibility is the key, coupled with good default settings. Also, by calling everyone who disagrees with you a “hater” the only thing you do is come across as someone who is not mature enough to accept criticism. Good luck.
I wrote “rise to focus” in my previous comment, which doesn’t make any sense. That should be “click to focus”, sorry.
I actually really like Gnome 3 (much much more than Unity, which drives me nuts).
I did have an issue with suspend not working properly on my previous computer. It works much better on my current installation, but I was one of the people who was furious when “Power Off” disappeared, because suspend was simply not reliable for me.
I’m still kind of annoyed that I can’t have applets or application shortcuts at the top of my screen any more. I’ve gotten used to them not being there, but that’s not the same as being happy about it.
The underlying issue, though, remains. Trying to encourage a usage pattern that you think users will like better is all well and good, but deliberately making things people really want to do difficult just pisses people off. It’s one thing for a power user like me to have to google a little to figure out that the alt key makes “power off” visible, but imagine explaining this to a regular user: “the designers of Gnome 3 thought that it would be easier for you if they made the ‘power off’ menu impossible to find on your own”. It’s a basic feature that everybody expects to be easy to locate, and it’s nowhere to be found.
Anyway, I do actually like Gnome 3 overall, so these nits aren’t showstoppers for me. I agree that there really seems to be no goal anymore, now that the basic desktop is “done” and actually working really well, and nobody has identified any realistic way to build market share beyond developers (like me).
Maybe the way forward is to identify an interesting niche (or several) where you think Gnome could do really well, and work towards conquering it. Perhaps hard-core gamers, now that Valve seems interested in porting their games? Just don’t do it at the expense of your current user community (mostly developers and system administrators).
Split screen in Nautilus is just an example. Its not about which one way is the best for everyone. Its the mentality that there is only one way to do it and all others be damned. And its not about refusing to implement a wishlist item but actively removing the already implemented ability to do things in different ways. If gnome just changed the default but left the code that would enable some feature you wouldn’t see all the griping. Having these decisions taking place among a choice few in unlogged channels means people can’t see the discussions that led to decisions. Attempts to bring up the issues are then dismissed as hating… not getting it… etc. Its just a poisonous development model that you would have a hard tike finding outside of propriety closed development community. IMHO.
It was on Planet GNOME. At least I think you are referring to the C migration plan post.
I think it’s wrong to demonise people who dislike changes in the way their computers operate. (It’s fine to hate people who whine on the internet all day, but these aren’t all the same people). Many people use a PC to write letters and read their email, and maybe play Minesweeper occasionally. If suddenly the taskbar disappears and they can’t shut down their computer any more then it’s hugely frustrating, in the same way that they would be if one day they took their car to the garage and without asking, they replaced the steering wheel with a D-pad.
GNOME never explicitly said whether we want to support or ignore these sorts of users. The choice of distro helps a lot: I’m guessing that there aren’t any users of Debian stable complaining about GNOME 3 and there won’t be for a while. But the structure of our platforms are such that at the moment it’s impossible to hold out forever, because application X needs GLib version Y, which is only available in distro release N+1 …
I’m hopeful that in the future I can install a distro running XFCE, Cinnamon, MATE or some such on a relative’s computer and be sure they’ll receive security and platform updates without having UI functionality disappear and rearrange every 6 months. I certainly can’t do that with any GNOME-based distributions any more.
@Stefan: thank you so much for the link to Andy’s article! I have now updated the blog post accordingly.
Seems like you’re missing one point in your ‘fix it’ plan: get more companies to back GNOME development again. Obviously I don’t speak for RH officially, but personally I’d be really happy to see other companies supporting GNOME more strongly and I’d be surprised if anyone at RH said otherwise. I agree that a monoculture has intrinsic dangers – it doesn’t matter how good or evil RH is, really, it’d still be better to have other stakeholders. I’ve no idea how to go about this, to be honest, but it seems like something GNOME should make an effort to achieve.
@Adam: of course, I didn’t miss that one. Everyone is talking about it (or at least thinking about it). I didn’t put it in my blog post because 1) that goal is already on everybody’s mind 2) it is not “actionable”.
I only wanted to make a list of things to tackle *concretely*, in the short term. “Getting more corporate sponsors” or “conquering the mobile ecosystem” are just broad goals that we aim for in the long term, for which nobody has a very clear answer (or if so, that person would be filthy rich already).
nekohayo: aha, understood: that makes sense. Thanks for the clarification.
To be fair, a feature being “buggy as hell” doesn’t mean it should be removed. If people are using it, then they were using a “buggy as hell” feature – and if you wanted to make them happy, you would fix it. By removing it, you make them even more upset.
The problem is that users shouldn’t have to install extensions just to get desktop usability back. There are hundreds of extensions on e.g.o and some of them has problems, doesn’t work with your specific version of gnome or even causes the shell to crash. Users shouldn’t have to browse that site and try out various extensions just to get back the functionallity they’ve come to expect from a DE but that’s missing from gnome-shell.
It seems to me that gnome-shell doesn’t know whether it wants to be a touch/tablet UX or a desktop UX. It doesn’t work very well on a tablet, in fact it’s just as bad as windows 7 IMO. But then it also sacrifices desktop usabilty to work better with touch. Hence it doesn’t do a good job at either.
@nekohayo: I wrote a little post about the split view here. It also covers your ‘buggy as hell’ claim.
@nekohayo: will it be possible to create a “extension-sync”, somewhat like Firefox’s Add-on sync. I think this would make it much easier to handle and would give a consistent experience accross different computers or after an upgrade.
Is G-S extension API going to become stable at some point?
I cannot answer questions regarding the GNOME Shell extensions API, I’m not the one developing it… that question should probably be directed to the G-S mailing list. I suppose that nobody would be against an extension syncing system if someone is willing to provide a patch for it.