GNOME Day 3 (Nitpicks and plasma-desktop test)

So, another day with GNOME on the laptop. First, I’ll go over the things brought up in the comments of yesterday’s post. I also replied in the comments to most, but I know going to posts to read comments is something I do rarely, so I’ll make it convenient for others to get the discussion.

To Adam, I mentioned that I would be trying out GNOME Shell anyways, so no need to worry that I was trying alpha software at the whim of a comment ;) . I tried gdevilspie, but couldn’t get it to actually do anything. The options indicate it can do what I want, but it just doesn’t do it. The GUI says the service is running, but neither Metacity nor GNOME Shell picked up on the rules at all.

To Nicolas, I know that the screen is actually 129 dpi, but the fonts are too big then. To get them to the size I want them to be, I have to set it to 6pt and 4pt for regular and small text, respectively. The font selections go to 6pt as a minimum, so anything meant to be smaller is just the same size. I’m sure I can edit it in gconf, but meddling in there is after I try doing it all through a GUI. The fonts getting bigger with higher dpi seems backwards to me since you should be able to show the same size with smaller physical size, but maybe I’m missing some key detail as to why the opposite is true. So the only way to get the font sizes I want is to set the dpi to a lower value, probably 96 dpi since I know the font sizes at that dpi.

To Alexander, pressing Shift while moving a window gets the effect I want, but only snapping is jarring and not really what I expect.

To twilightomni, the animations are something that I find dispensable. They aren’t necessary for things to work. The main reason I find fault in requiring 3d acceleration is that nvidia users are left out in the cold or forced to go for the blob. One of the reasons for this install was so that my KDE install with nouveau isn’t screwed up when I no longer need the nvidia driver. I have more on this issue today.

Second, the nitpicks that I’ve found with usage. First, I tried to use Guake which is supposed to be similar to YaKuake. Upon trying to start it, it just crashed (yes, a bug has been filed). I’ll look into it once the issue is fixed. This crash triggered abrt to report the crash. Now this is an issue that I’ve been finding all over the place, but dialogs are not given focus when they are created. I need to manually move the mouse (or alt+tab, but i have issues with GNOME Shell’s way of doing this as I went over yesterday) to give the dialog focus. In abrt’s case, it also put the dialogs underneath other windows or dialogs making me wonder why the application had become unresponsive. Having translucent windows as I normally do would help avoid the discovery that there is a modal dialog hiding among the others, but it would only ease the issue, not solve it. I also spotted a spelling error in the dialog that requests for credentials. The word “below” is misspelled as “bellow”. If this post isn’t enough to be considered a bug report, I’ll file a formal one.

There are also some migration pains with Nautilus. In Dolphin, F10 creates a new directory and prompts for a name. In Nautilus (and elsewhere), F10 gives the menubar focus (just like in the latest incarnations of Windows). Both KDE and GNOME also allow alt+<letter> to access the menubar, but in GNOME, F10 is a wasted key. This also conflicts with htop when inside of a gnome-terminal, but at least ‘q’ still works to quit as well. The screensaver also automatically locks the screen. I want it to lock, but I want some time to catch it and prevent it from forcing me to put my password in if I’m reading something (like my notes for these posts). I also found a quirk in PackageKit. After selecting and installing a set of packages, they are still checked in the interface, but the “Clear” action does nothing to change these selections which is a little odd, I thought.

For GNOME Shell, I do have issue with it not supporting a low-end setup without 3d acceleration. First, nvidia users are left to either stick with Metacity or use non-Free drivers which require some additional repositories to be enabled. Other chipsets have similar issues, but nvidia is the most noted one. Personally, I have found that the only thing that is used that really requires acceleration is the “Activities” view. Everything else is just animations and other effects that don’t really add any useful features to the experience (maybe I’m missing things, let me know). It is sort of necessary since there is no other way to easily launch applications that I can approve of for general use. With no other option to fall back to, there is no way to lower power consumption. KWin suspends its (well, PowerDevil triggers it, but it’s there) compositing when low on power to help prolong battery life. GNOME Shell has nowhere to drop to other than Metacity which loses essential and key features of GNOME Shell.

While on this subject, there is some lack of interoperability between Metacity and GNOME Shell. The activity count for GNOME Shell is not turned into a desktop count in Metacity and when going back to GNOME Shell, there is again only one activity. This was irritating as I had to reorganize my windows after each switch (though KWin would be able to pick up my rules and put important things where they belong). I know that window manager to window manager switching usually collapses all applications to one desktop anyways, but if GNOME Shell does have a power-save mode, Metacity would probably be it and they should work better together in that case.

The “lg” command that GNOME Shell has is nifty, but I don’t know what objects are available. If there was something like Python’s dir() function, discoverability of things I could do with it would be greatly improved[1]. The history output also seems to not keep the output scrolled to the bottom if it is there forcing manual intervention to see output.

Third, and probably the most interesting part of this post, is my test to try GNOME Shell and plasma-desktop at the same time. All I did was install kdebase-workspace and launched plasma-desktop. To my surprise, it worked and there were no dead_kittens. Plasma picked up GNOME Shell’s activity count and pager happily displayed them all. However, the workspace switcher in GNOME Shell was confused and only saw one workspace (with the ctrl+alt+left/right keys, going back to 1 worked, but you were locked in once there) even after plasma was killed (switching to Metacity and back fixed it). Plasma also stole the notification area (status bar) and GNOME Shell didn’t get it back until the Metacity switch as well. After finished with plasma-desktop (and KRunner), killing them brought back the nautilus desktop as one would expect. The only thing that didn’t really fit was GNOME Do which still stuck to the bottom edge behind the plasma panel, but it still worked despite being there. I also removed kdebase-workspace (with yum history undo) to prevent future temptation to just use them instead.

Tomorrow, I’ll have some RAM usage statistics I gathered last night.

[1] As a note, I just figured out what the “Evaluator”, “Heirarchy”, and “Properties” labels do, but that is, again, more mousing than I like.

5 Responses to “GNOME Day 3 (Nitpicks and plasma-desktop test)”

  1. On DPI – imagine a 5,000 DPI screen, something like a 20″ monitor with 80000×60000 resolution or something. if you drew each character with the same number of pixels vertically as you would on a 100 DPI screen…they’d be microscopic and impossible to read. (You can see a real-world example of this if you can find a Sony Vaio P running its stock Windows install – the screen is over 160 DPI but Sony, inexplicably, left Windows set to 96 DPI. You can barely read the text on the default desktop.

    what using the ‘correct’ DPI setting does is means that the characters are the officially-correct physical size. there’s actually a standard that defines how big, in real-world physical units, any font point size should be, it’s not an arbitrary number. If you use the correct DPI setting for your monitor, fonts are those sizes. Many people tend to find those sizes ‘too big’, because people have been used to using the Windows-alike 96dpi on screens which are actually higher resolution than that for a while. No-one’s going to arrest you if you use the ‘wrong’ DPI setting, but there is a method behind the madness.

    the abrt dialog bug has been fixed, I think at least.

    Personally I suspect gnome-shell won’t go out to the world at large if it requires a closed source driver on NVIDIA. I guess some kind of software implementation will be done. That’s just me guessing, though. I may be entirely wrong.

  2. Dave Airlie says:

    You guys seem to missing the fact that RH is funding nouveau development to create an open source nvidia driver capable of running gnome-shell.

    This is quite a high priority before g-s can be shipped.

  3. airlied: well, I know that, but the last estimate I got from Ben on working 3D in nouveau was measured in months-to-years. That seems quite a discrepancy from the GNOME 3.0 plan, though I may be misreading something there.

  4. s/working/actually usable for real people/

  5. Tomasz says:

    As for fonts and DPI, people often forget that “pt” (point) is physical size, just like millimeters, inches and so on. For example, setting your fonts to be “10pt” is the same as setting them to be about 3.5mm. It is completely natural, that when you have higher DPI, letters have to have more horizontal pixels to come at requested, real world size.