GNOME Day 2 (GNOME Shell)

After using GNOME for a little while, I discovered some things that are not how I am used to things working that would probably take a while to get used to if I were to move to GNOME full time (I doubt it though, KWin, KRunner, and general application integration is just too nice in KDE). I’ll be using it until the end of the semester (right before FUDCon) at least since I’ll need Panda3d and therefore the nvidia driver until then.

First, things that got fixed from my last post are that the audio applet showed up after the first upgrade, so I’m guessing the PulseAudio issues that were there caused all of the issues and the upgrade fixed that all up. The nvidia driver works, but it has those issues that I had last time I used it every now and then (waking up, it goes right back to sleep, some jerky animations, screwed up DPI (129 instead of 96), etc.). In response to Adam’s comment on my last post for the driver, the dual booting with another Fedora install makes the kernels a touchy subject and not something I want to deal with. I ended up “rebuilding” the RPMFusion SRPM myself against this kernel. Thanks to the help with getting the “focus follows mouse” setting and the opening terminal entry for the desktop. I did end up getting my keyboard layout settings fixed, but gnome-shell has broken them again (see below).

This morning I had to poke around with some code, so I fired up gedit, played with some settings (mainly tabulators to spaces and 4 spaces for indentation). After some mistakes with typing, I found out what kept causing me to screw up: ctrl+bksp behavior is very different from what I am used to in KatePart. In KatePart, it goes to the beginning of the next <word> and since KatePart is used pretty much anywhere non-trivial text editing is needed, it’s consistent everywhere. In gedit, however, its movement is very different. Going forwards, it goes to the end of a <word>. Numbers are considered a different <word> which adds to the confusion (I’m getting used to looking ahead in vim for command counts, the numbers adding to it throws the counts for key presses off). Going in reverse, the cursor is placed at the beginning of a <word>. This duality is disorienting at times. There is also some odd behavior near the end of newlines. In KatePart, ctrl+bksp will stop at a newline effectively just clearing it. Instead, gedit also deletes the last <word> on the line before which causes me to manually hit Backspace to delete what I want. Word jumping over newlines follows similar patterns and is hard to get used to. For actual coding (pretty much anything beyond what that class requires), I don’t know how well gedit works out, but it’ll take some getting used to. I was pleasantly surprised to see a Kate color scheme in gedit.

I discovered some odd behavior with the volume keys as well. If something is selected, changing the volume with the keys makes it use the “hovered” color while the button is pressed. Another oddity I found was the “desktop effects” configuration selection for Compiz had quick options for “wobbly windows” and “the cube”, two of, what I consider, the useless effects that have been made. I usually use “Present Windows”, “Zoom”, “Desktop Wall”, “Thumbnail Aside”, and “Translucency” in KWin. Other than that, it’s just some visual cues that I could live without like a minimization animation. The rest I see as eye candy (well, the other desktop switchers can be useful, just not my preference) and not really necessary, so why two of the more “useless” effects are front and center befuddles me.

I also found some inconsistency with dialogs. Sometimes Escape works as if I hit “Cancel” and other times it just does nothing. One such dialog is the “Add/Remove Software” window. Visually, it screams “I’m a dialog” to me since it lacks a menubar and toolbars (though these aren’t always applicable) and yet Escape does nothing. Just something I’ve come across and I’m sure there are more around.

How am I supposed to eject flash drives in GNOME? I kept trying to do “Safely Remove” but it kept coming back that “this file could not be stopped” (though it is a funny error message, fairly for those who don’t know about processes holding file descriptors open). Eject works, but it’s not what I’d choose with an option of “Safely Remove” right there.

I also installed GNOME Do and tried it out. Unfortunately it is also not KRunner by a long stretch. I search for “naut”, GNOME Do suggests “Livna Display Configuration” and only that. Why not Nautilus? I know what it’s called, let me launch it. KRunner also searches my bookmarks, contacts, recent documents, path names, Konqueror web shortcuts (very handy), Kate sessions, offers a calculator, and lots more. GNOME Do doesn’t do any of that (as far as I can tell) out of the box. I haven’t searched for plugins yet, so any pointers on good ones for the things I listed would be nice. GNOME Do is also not a standard text entry widget, so ctrl+bksp doesn’t work at all.

Window management is one thing that I’ve gotten touchy about after getting used to KWin. Metacity and GNOME Shell both have the following issue that bugs me: windows only snap to edges when going towards the edge and not when the two windows previously overlapped. I have high sensitivity on my inputs (but smooth, which is where the Windows drivers start to annoy the hell out of me with their jerky scrolling) so I overshoot placing windows often and “reverse snapping” is nice. KWin also snaps corners to corners and when edges line up (the top will snap to the neighbor’s top line if the two windows “touch”) which Metacity and GNOME Shell are both missing. Resizing windows is also weird with it depending on where the mouse starts within the window. In KWin I don’t really resize things much since I lock windows’ position, desktop, and size for persistent apps (and size for common ones like Konqueror or KWrite). I also set shortcuts for persistent apps (meta+alt+i for Konversation for instance). As far as I can tell, neither Metacity nor GNOME Shell has this ability, so I’m left to manage such things manually and since default sizes are way too small for 129 DPI, I have to resize things.

While on window management, I’ll report my initial findings for GNOME Shell. The first thing I noticed is that its alt+f2 tool is even more featureless than the default GNOME one. It only accepts complete command names, no tab completion, no ctrl+bksp, forces focus, and other things. This mix of things it’s missing makes it pretty much useless in my book since opening up a terminal and letting bash auto-complete for me is much faster. In addition to this, the GNOME Do shortcut gets clobbered somewhere in GNOME Shell so it has to be manually started.

The alt+tab switcher in GNOME Shell is also hard to get used to. If there are two windows for an application, they cannot be separated without the mouse or hitting the down arrow. I was able to get it to display the separate windows with nothing but alt+tab a few times, but it’s not reproducible reliably. Window thumbnails are also hidden in this submenu. Being used to “Present Windows” (with two variants, all desktops and just the current one) which has filtering, this is a step backwards for me anyways, the awkward navigation just adds to it

The list of applications next to the “Activities” menu doesn’t make much sense to me. It only lists the currently focused application so of what use is it? In addition it says “File Manager” for the desktop. How many people know that the desktop in GNOME is just a Nautilus view of a folder with a wallpaper? I didn’t until today. I kept trying to find this “File Manager” that was open so I could close it.

The “Activities” area is weird. There’s no keyboard navigation unless you’re searching (which also does not support ctrl+bksp by the way). You can add and remove desktops here as well. Adding them is no problem. I find issue with the way desktops are removed. You can only remove the last one and the way it works, the position of the last desktop keeps moving. I was also unable to find keyboard access for this. The other issue with these desktops is that the layout with the “Activities” visible is 2d. When back on the actual desktop, it is 1d. On KDE I have my 9 desktops set up in a 3×3 square with shortcuts that treat it as 2d and 1d (if I had 6 more arrow keys and shortcut actions to attach them to, there would be 27 in a 3x3x3 logical layout ;) ). GNOME Shell has no way to treat them as a 2d grid. In addition, I did not find any shortcuts for moving windows between these desktops. You have to get the window menu (alt+f3 with KWin, click in GNOME Shell) and choose to move it right or left. There is also no wrapping, so to get a window from desktop 1 to desktop 9, I have to do this 8 times. There’s also the ability to move windows when in the “Activities” area, but this also requires a mouse and lots more of it.

GNOME Shell also likes to play around with shortcuts. Since the “Activities” area is triggered by the Meta (also known as “Super”) key, my shortcuts to the desktop through VNC are chomped when they use the Meta key. Not fun. If the “Control to show mouse position” is active, the Control key modifier is also impossible over VNC (now using TigerVNC since vinagre is really annoying). My keyboard settings for CapsLock-as-Backspace and RtAlt-is-AltGr, Shift+RtAlt-is-Compose are also completely ignored. Setting them manually with setxkbmap works as expected, but the keyboard settings are completely ignored. The GNOME Do access key (Meta+Space) also seems to have no effect when in its dock mode forcing the mouse to access it there as well.

With GNOME Shell active, GNOME Do defaults to a Macintosh-like dock. It’s nifty and looks nice, but not really my thing. Unfortunately, with what other ways there are to launch applications, it is the least annoying (though I just found the “Sidebar” and it looks a lot better, will report on that tomorrow). Similar to the alt+tab switcher, the dock is hard to use with multiple windows for one application. Right click on the app and then click on the entry you want. No thumbnails to differentiate them if the titles are the same or keyboard navigation.

Reflecting, GNOME Shell gets a “meh” from me so far. I hope that it’s still alpha so that more features can be added (assuming standard alpha and beta definitions). If it isn’t, GNOME Shell’s first release will probably feel like KDE 4.0 did to many. In either case, KWin and Plasma have been much more powerful from my experience and they aren’t as much as a detachment from how things have worked for the past many years.

Experiment for tomorrow: gnome-shell with plasma-desktop. The /proc/acpi/dead_kittens file will probably be reporting numbers in the dozens.

13 Responses to “GNOME Day 2 (GNOME Shell)”

  1. yeah, shell is still alpha, nowhere near finished yet. I just suggested trying it out for fun, really.

    the ‘safely remove’ / ‘eject’ thing is one that’s been baffling me lately. Only one of those used to be present for USB drives, and I’m baffled as to why GNOME these days presents both. I have no idea what the heck the difference between them is supposed to be, if anything. It smells like simply a bug to me.

    for your advanced window managing needs, it smells like you may want to poke at the preferences that are hidden in gconf, and also perhaps play with devil’s pie: (yes, it’s packaged…there’s a graphical frontend called gdevilspie, also).

    I’m going to pass your threads on to the Desktop mailing list to make sure they’re reading them, seems like something they may be interested in.

  2. Fred says:

    Thank you for this “Using GNOME Series”. I’ve been using Gnome since Red Hat 8 and your observations me want to switch to KDE ;-)

    The thing that shouts out at me the loudest is the Gnome Team developing a desktop environment that REQUIRES hardware video acceleration! I just can’t believe it!

    If what ends up being Gnome 3 requires hardware video acceleration… I’m going to have to deal with all those older machines that I installed Fedora on for family and friends. And my own laptops.

    I realize that hardware video acceleration does not necessarily mean a separate video card and also includes IGP graphics chips. But there just isn’t linux drivers ( open or closed ) for many many older ( read a few years old ) IGP’s! and there never will be. Should we all just chuck our 2003 notebooks?

  3. Fred: there’s working open source 3D for all Intel and all pre-r600 AMD Radeon adapters. r600 support is experimental in F12 but works well for many. NVIDIA is the big sticking point, but even there the story is not ‘never’, nouveau is working on it and it will happen, though the timescale may be year(s).

    I’m not sure GNOME 3.0 would go out with gnome-shell not working without 3D acceleration, but I’m not really an insider on that story so it’s just my guess.

  4. Ben Boeckel says:

    I read somewhere that there are no plans for software rendering (read: XRender) for GNOME Shell since it would mean re-implementing all of the drawing routines to not use OpenGL. KWin can do OpenGL and XRender since it gets such for free from Qt. Unfortunately, it’s one of those things that you don’t bookmark after reading the one-off. I think I got to it from Fedora Planet, but I’m not sure.

  5. Nicolas Mailhot says:

    129dpi is not an error it’s the correct things to do. If you want different font sizes change the font size preferences do not pretend your hardware is something else than it is

    People need to get used to change font sizes when they need to change font sizes. dpi is not a font size setting. Resolution is not a font size setting. Font size preferences, are, strangely enough, the correct way to specify your preferred font sizes

    (and before you claim everyone wants 96dpi you can find on the net advice dating from back when someone had the stupid idea to use 96dpi by default. It says: if your fonts have the wrong size under Linux, lower your screen resolution to 1024*768. Like you the writer was convinced changing font sizes should not be done via the font size preferences).

  6. Alexander Larsson says:

    If you want to snap to edges in metacity, hold down shift while moving the window.

  7. twilightomni says:


    Some comments on the gnome-shell-devel list and desktop-devel-list have brought up the 3D support. The developers are clear that Clutter provides many capabilities (for example, animation and transition) that stock GTK doesn’t have, and they’re not interested in developing a crippled version of the interface. [Yes, Qt has this stuff even without 3D. But GNOME is not built on Qt.]

    The general sentiment was that for GNOME to continue to evolve, eventually it must be able to take advantage of new hardware by default, so they are sleeping relatively well over this decision.

    After all, OS X wasn’t designed by focusing on the lowest-denominator hardware platform. [Then again OS X has a -standard- hardware platform, but you can't deny that it's a worthy target for desktop polish comparison.]

    (Note: I don’t necessary agree with all of this, but in general, if GNOME Shell fails, “forcing you to use 3D” will not be the reason why.)

  8. Ben Boeckel says:

    Yes, it is 129 dpi physically. However, the fonts are *bigger* than with 96 dpi and I like small fonts. I usually use size 8, but to get a similar actual size, I have to use size 6 with the 129 dpi. This is the minimum in most places without going to the gconf tool or hand editing files. In any case, things were all right with nouveau and nvidia has much larger fonts. Changing the DPI is easier for me since the font size dialogs don’t go as small as I’d like.

    Ah, thanks, didn’t know that. Still don’t like having to hit a key for that.

  9. Nicolas Mailhot says:

    dpi tells software how many pixels are needed to make an inch (dot per inch, for a computer screen dot=pixel). When pixel density increases, dpi increases, and you need more pixels to make the same inch.

    Since Linux apps use pt as font size unit (even if it is not displayed), and pt is a unit with physical meaning, linked to inches, when dpi increases you need more pixels in a char to make the same pt size.

    You’re very lucky to have eyes good enough to read 6pt text, most people can not be comfortable with it.

    Anyway your problem is not the 129 dpi, your problem is the people that wrote the size selector didn’t think people with such good eyes as yours exist, so you should open a bug so they stop clamping font sizes at 6pt.

    Alternatively if you want a specific pixel size you should open another bug to allow specifying font sizes in pixels and not only in points (a lot of users *really* want them in points so hijacking the pt unit to make it a bastadised pixel unit is no option). Faking dpi to make a pt size translate to a particular pixel value may be what you’re used to, but what you really want is to specify pixel sizes to get pixel sizes (duh)

    And faking dpi has the side-effect of making all sizes in your desktop unreliable.

  10. Ben Boeckel says:

    The reason that it confuses me is that it’s using moreĀ² pixels for that pt size. It needs more pixels to get the same size, but it looks even bigger at the higher dpi, so it has to be using even more pixels to get there. The shock of using 10pt after using 8pt for so long is probably contributing, but everything looks inflated on the laptop (it may be hinting as well).

    As for the 6pt thing, I usually use 8 for normal text and 6 for small (but for some sites, ctrl++ is needed because they *are* just a blur), but it looks the same as 6pt (visually) with the nvidia driver. No matter which way is correct, there is a difference between nvidia and nouveau and I’m just going to blame nvidia since nouveau looks right to me. At DejaVu Sans 8pt ’8′, I used a ruler to compare.

    Intel (GMA X4500HD):
    2.5mm (round about)
    nvidia (NVS Quadro 140M)
    3.0mm (right on the line)

    The odd thing is at 128pt, the bold DejaVu ‘c’ was 1in on the laptop and 1-3/32in on the desktop. Why they switch which is larger, I don’t know.

  11. Malx says:

    Forgive me, but the original post looks like yet another commercial for KDE. Why oh why do users of KDE post onto forums and slate GNOME. We ALL know GNOME is different to KDE. If one is a dedicated / loyal user of GNOME, then one becomes accustomed to the GNOME way.

    I have been using GNOME on Gentoo for a year and I did try KDE4. It was on my system for 1 week, then it was removed. Too bloated, too much eye candy. KDE = bloated with bells and whistles. GNOME = Simple and does what it says on the label. The peeps at GNOME-shell could produce a system that is almost exact to KDE and all the “die hard” KDE users would STILL slate it. AFAIAC it’s a no-win situ for GNOME developers.

    Why are we moaning about the transition to 3D Hardware acceleration?
    Erm….Vista anyone? Erm…..7 anyone? It seems to me this IS the way forward in computing, and there will be NO turning back. Embrace the future like you embraced KDE4 from KDE3.

    What I find totally annoying is the negative posts with regards to GNOME 3 – erm, like you didn’t already know it IS being developed and improved as we speak.

    C’mon guys – give them a break.
    Gentoo + GNOME = Blazing Bliss

  12. Ben Boeckel says:

    I understand that. I don’t believe I said that “KDE was better than GNOME” anywhere, and if I did, it was meant to be from my viewpoint. This series is about GNOME Shell from the viewpoint of a KDE user. When developing, it can be easy to miss something because you didn’t think of it or come across the use case. I’m trying to provide that. Things that I see as missing and things I think many would want: more keyboard accessibility, ability to make the meta key a modifier. I can see people living without lots of KWin’s features I use. I find it annoying on my main machine (I have ratpoison elsewhere, but the machine has a completely different use case) not to have shortcuts to windows that I’ve hidden from the taskbar (which is to help clean it up). That is something that I would put well into “would be nice” category. Keyboard navigation is a lot closer to “essential”.

    Yes, sure, compositing is the future. But when I’m low on power and need the extra 10 minutes (or am on a 6 hour trip and get an extra hour from full battery) I would get from suspending compositing, there is *no way* to do it without dropping out of gnome-shell. That is my main complaint about it. Windows gets it wrong there too I imagine, but I won’t touch that at all to test first hand.

    Yes, it is being heavily developed. What better time to give your thoughts about it? After it’s stable, things won’t change until the next version, bugfix release if you’re lucky.

    I do plan on continuing this, but other things have kept me in my KDE install since the last post (projects that have everything set up there for instance), so I haven’t been able to get more data to post with.

  13. Arran says:

    @Fred: there is software rendering as well if gnome cannot use the hardware it will fall back to software yes this will be slower and more of a hit on the CPU but its there but if it detects the hardware there is no option to switch to software or hardware rendering