Short Review of GNOME Shell

It feels a bit weird to be part of KDE land and be a bit of the conservative guy these days. We had our first Plasma Desktop release three years ago and the first fully user-targeted 4.2 release two years ago. Since then things improved on a steady but not revolutionary pace. Well, that’s not entirely true for our back-ends as I feel that eg. QML is a very revolutionary move for developers but the desktop experience from a user’s POV stayed largely the same.

As I have an open mind, I of course gave GNOME and lately GNOME Shell a try and today I upgraded my GNOME installation to 3.0 beta 2.

Startup

What I noticed immediately was the lack of a splash screen. Since I upgraded from an older release and the settings were kept, I stared at a entirely black screen for a few seconds because in the meantime I deleted the wallpaper I had selected before. I honestly didn’t know at that time what if anything went wrong. While some say progress bars are evil from a usability standpoint, I at least like it when something is moving to ensure me that nothing is hanging. With clean settings you stare at blue stripes for a while but you still can’t be 100% sure anything is loading at all. I find our smoothly fading Plasma splash screen way better.

Launching Applications

Starting applications is a bit weird. First you have to open the Activities screen (so far OK). Then you can either run them from the Dock-like bar on the left side which in my case only held Firefox and Nautilus or (and this is the weird part) switch from the current ‘Windows’ view to the ‘Applications’ view. Initially I didn’t even understand that the two Windows and Applications “buttons” are clickable. They follow no convention known to me to indicate that they are clickable instead of being mere titles of some sort.

And even if they indicated that: As the default ‘Windows’ view shows a Exposé-like view of all open windows (in the current Activity), I’d expect the ‘Applications’ view to show all running applications regardless how many windows are open. (Yeah, I know. Knowing about applications and which windows they spawn is considered geeky these days.)

Alt-F2 also works but it’s a simple command prompt. IMO the Shell crew should adopt something akin to our Runner for a future release.

Maximize and Minimize

There is quite a big fuss going on about the decision to drop Maximize and Minimize buttons by default. I don’t think it’s much of an issue. The new concept behind GNOME Shell is clear: Less window management but instead Activities management.

Switching between maximized and windowed state all the time seems so 1990s to me. These days you either have a rather high resolution screen with which running maximized windows makes no sense at all or you have a portable device like a netbook or small laptop where windows should open maximized by default anyway. Windows nevertheless can still be maximized or windowed by double-clicking the title bar or via Aero Snap-like gestures (dragging the window to the top of the screen – other Aero Snap gestures are also available).

The missing Minimize button is another story. While it’s clear that Minimize is no longer needed, provided that good activity management is in place, it currently is not.

Neither do new windows spawn in new Activities by default (which IMO would make sense given the paradigm), nor is moving windows between Activities easily accessible just as the Activity switcher is not.

Better Activity accessibility is something likely to be in line for 3.2 in fall.

The Little Things

It’s little but I fell in love with it: The way startup feedback of applications work. Here in KDE land we have the jumping cursor which I also love. In GNOME Shell a roundish progress writes the title of the application into the task bar.

One aspect I found a but weird was Firefox: For some reason under GNOME Shell placing the mouse cursor somewhere inside the Firefox window makes it completely change its appearance. In FF the cursor is back with white outline while outside of FF it has inverted colours. WTF? It can’t be Firefox’ fault because under Plasma the cursor doesn’t change to something completely different.

A rather big usability fuckup is the introduction of a new switch widget to replace checkboxes. I have the same on my touchscreen phone where they work because I have to use my thick fingers to activate options but on cursor-driven GUIs they just look clumsy.

The “Is that a clickable button?” question also hit me when fiddling in GNOME Control Center. The “Back to All Settings” button doesn’t look like a button at all.

The title bars of windows are a bit too big. I don’t mind them to be bigger than before (after all the average screen resolution increased) but in 3.0 it’s a bit too much.

Conclusion

The most important question is: Is it good? And yes, it is. There are quirks here and there but it’s just a dot-0 release. In time they’ll be ironed out. I’m sure.

Is GNOME Shell something to imitate for Plasma? No. Like often there is no objectively right way to approach users. There are a few concepts that can be adapted however. The application startup notification may be worth trying out adopting in an alternative task bar Plasma widget but my guess it that it won’t look good in a cramped task bar.

Shell’s Acitvity approach is IMO also no something that works well with the existing Plasma Desktop but I think something along Shell’s lines would work well for Plasma Netbook and Plasma Mobile.

Will I switch? No, definitely not. GNOME Shell is good but from my point of view it’s also fundamentally flawed.

  1. Shell is a plugin to the Mutter window manager. Crashing the window manager means crashing everything. While typing this review I switched back and forth from my other session and at some point I had just a back screen with a mouse cursor and locked input – meaning I couldn’t even switch back to my main session running Plasma. I had to forcefully turn off my PC (luckily Blogilo saves automatically every few minutes).
    Not only that but being a window manager plugin also means I can’t choose to use a different WM with Shell. KWin allows me to on the fly turn off compositing. It’s nice because my GPU is too old to handle compositing and GPU-accelerated HD video decoding at the same time. Mutter does not and KWin can’t be used with Shell.
  2. It’s still GNOME. By default GNOME shows only a handful of options in GUIs. GNOME has many hidden settings but it’s my opinion that settings should be organized well instead of being hidden. While it’s true that our own past releases tended to have options simply thrown together, we changed our approach since 4.0 and the results are great, usable, configurable but not crippled applications like Gwenview, Dolphin, Marble, etc.
    In GNOME 3.0 I couldn’t even find a way to change Shell, Mutter, and GTK themes. Maybe I am missing some pref pane package but so far it looks like everything moved into hidden settings.

Rating: B+

Did you read Planet GNOME lately?

Planet GNOME is a good read lately. After Canonical found it to be a great idea to take 75% of revenue away from GNOME Foundation for an application Canonical didn’t even develop, discussions about older experiences of Canonical’s “interaction” with the GNOME community.

It basically goes on like this: Mark Shuttleworth blames GNOME for allegedly being close-minded for not adopting app indicators and GNOME people are arguing that the rejection was solely based on bad timing (feature freeze too close) and disagreement about the implementation on a purely technological level.

Whatever the truth is (read the posts and decide yourself), the aspect I find most amusing is the irony that Shuttleworth on one hand portrays himself as a victim of GNOME’s alleged high entry barrier for contributions and on the other hand requires contributors to Canonical projects (incl. the indicator library) to assign all copyrights to Canonical and rejects patches because Ubuntu is not a democracy and all design decisions are made solely by Canonical.
Either Shuttleworth is a great comedian or he really does not get the disconnection between his acts and what he preaches.

Nokia’s risk with Microsoft and the “Mobile computer” loophole

You heard by now that Nokia chose to use Windows Phone 7 as main smartphone OS.

I certainly won’t buy any WP phone ever. I’d rather buy some Android phone as long as it doesn’t depend on Windows (like Samsung’s AFAIK do).

As you may recall, Palm went a similar route before: PalmSource developed PalmOS 6 based on many technologies from BeOS. They had a superior OS but Palm never used it in any devices. Instead they sticked with PalmOS 5: Outdated technology but binary compatible to existing applications.
As PalmOS 5 was gradually replaced with Symbian as dominant OS, Palm partnered with Microsoft and shipped Windows Mobile on its devices. In the short term it helped Palm gain back some market share. In the meantime PalmSource was bought by ACCESS and Palm worked on webOS.
webOS seems to be a very nice OS but clinging to PalmOS 5 first and later partnering with Microsoft distracted Palm. The result: webOS came too late. Palm was bought by HP.

Change some nouns above and you’ll pretty much get Nokia’s recent history.

However, Nokia at least was wise enough to have two loopholes: The first is that Qt stays for lower end phones which means Nokia won’t stop developing it. The second is – and that one seems underrepresented in the news coverage – Nokia still plans to develop MeeGo “computers”.
You may not know it but by Nokia’s official terminology the Maemo-based N900 is not a smartphone. It’s not a phone at all. It’s a “mobile computer” that happens to be usable as phone.

If Nokia continues those “mobile computers”, the situation is not so grim. However if Nokia really bets on MS – and history showed us that doing that is a safe bet for doom – I’ll say Lenovo will buy them.

Quick look at Firefox 4 for Qt4

A while ago I blogged that I left Firefox for Rekonq. Sadly that didn’t last long because Flash keeps causing crashes.

So for a while I used Konqueror in KHTML mode. While Flash didn’t crash there, it did other weird stuff such as painting over the toolbar when during scrolling.

So I tried Chromium… gosh, that GUI is really unbearable when using under a KDE environment.

Then I went back to Firefox but being so fed up with FF3, I tried FF4. To my surprise at least its performance was immensely improved. The GUI however was not. Well, at least I could restore most functionality (status bar via an extension, real stop/reload button via rearranging). Thanks to SUSE’s KMozillaHelper application I also have some Plasma Workspace integration but FF3 had that as well, so no news there.

When I’ve read yesterday that a Qt version of Firefox is now available, I decided to try it. After all, the screenshots on that website didn’t look so bad, right?

Well, time to put them into a KDE perspective:


Default window after first launch.


Accessing a menu (context menus don’t work at all, bzw)


Firefox-Qt’s Open/Save window

There you have it: Don’t bee too exited, yet. FF-Qt still has a long way to go.

EDIT:
I just made the mistake to scroll in one web site. Half the page turned white.

So Canonical ported Unity to Qt…

In case you haven’t heard already: Canonical ported Unity to Qt.
So far it’s only advertised as option for people without 3D drivers (like the EFL port of UNR before Unity) and no plan to make this default at some point has been announced.

To me it seems very weird, though. All that replacing and porting over and over again (UNR port to EFL, later a rewrite of UNR as Unity for Clutter/Mutter, then porting Unity from Vala/Mutter to C++/Compiz and now from Clutter to Qt with whatever window manager) makes me wonder if there are people in charge at Canonical who don’t change their mind every few months…

From a KDE perspective the increased adoption of Qt is certainly a plus but OTOH losing (or at least cutting down) Aurélien Gâteau’s paid work on KDE software is sad (he’s now part of the Unity porting team). He already announced his plans to work more on KDE software in his free time, so we won’t lose him as a community member but I fear his Unity work will go to waste in a similar way as EFL UNR just because some manager decides that everything has to be ported to Moonlight/Java/FLTK/Android/… six months from now……

What do you think is the overall picture? Will Unity-Qt help KDE due increased Qt adoption or will the work force transfer hurt KDE? Or will nothing change for us at all?

What’s Nokia doing in MeeGo?

EDIT 2: Damn, I’m so dump. I had the answers already but I totally forgot about them. I posted something similar to this blog post in the comments section of that article but being a bit ill (not surprising in November..) I completely forgot about it and never checked back.
Due weird circumstances my websearching brought me back to that article where I found a reply by Nokia’s Quim Gil. He wrote:

The apps included in the MeeGo Handset UX are the top of a complex iceberg. Nokia is contributing heavily to Core OS and Handset UX, from Kernel to MeeGo Touch Framework. The Handset application/services layer in MeeGo products from Nokia will be heavily tied to Ovi and Nokia proprietary apps. It would be quite schizophrenic to also develop the open alternatives. Still you can see Nokia’s involvement in Mozilla, KOffice and essential application back-ends like Kcal or Buteo.

Now we have it: Nokia won’t open source the actual front-ends. The code for the Handset UX front-ends is just meant to be a reference implementation and nothing to ever become a usable product on its own.

Apart from MeeGo Touch Framework (a component I wasn’t really aware of at that time, even though I had heard the name before but it never caught my attention) Nokia is involved with upstream projects for back-end services.
A misconception (likely due my unclear use of words because I’m not a native English speaker) in said comments section was that I accused Nokia to be not involved in FOSS except Qt. That is not what I meant. Both my comment and this blog post were solely about MeeGo-specific projects and not multi-purpose upstream projects like Mozilla where Nokia is developing a Qt port of Firefox Mobile.

With my regained memory about the VisionMobile article, let me say a few words about the comparison of MeeGo Handset and Android. If the MeeGo Handset front-ends stay a mere reference implementation, cheap smartphone manufacturers will more likely opt for Android because even stock Android is a polished product. The development may occur behind closed doors but a complete end to end stack is released with each development cycle.

This however may serve as opportunity for us KDE people. If Plasma Mobile + our apps turn out as polished product bundle, we “only” have to make potential MeeGo adopters aware of it as in “Just take it all for free. You only need to set a branded wallpaper and you’re set. If you do encounter bugs, our development is open – just submit a patch.”

Now that it’s all settled, I can go to bed again. 😉 For reference I keep my original blog post below:

Continue reading “What’s Nokia doing in MeeGo?”

Follow us at the new digg.com

So digg.com has been completely redesigned and KDE now has an account, too.

http://digg.com/KDE will automatically publish KDE.News stories and Planet KDE posts.

Let’s see how/if that works.

[EDIT] It works! \o/
So in case you don’t use Akregator (shame on you!), you can now also follow KDE in digg to get Planet KDE posts. KDE.News stories will take a bit longer but they’ll come.

Now don’t forget to digg (=vote up) your posts. 😀