Tag: gnome

Categories
linux

Nautilus and Hidden Files

Awhile back I updated Gnome and wasn’t seeing hidden files in nautilus (“Gnome Files”) anymore. I went into dconf-editor and looked around and found the old preference for it set correctly, so I dug around online and found they now use org.gtk.settings.file-chooser.show-hidden instead of the old preference. So I set that and went on, only to find sometime later it wasn’t working again.

Something was changing that setting, but in the meantime I discovered the “Ctrl + h” keyboard shortcut to toggle it, and would just use that. Still, who wants to toggle something like that frequently?

Eventually, I looked at some code of a non-packaged GTK+ application I use. Lo and behold, its file open dialog included a call to gtk_file_chooser_set_show_hidden, which apparently doesn’t just set it for the current file chooser, but sets the preference, too.

I’m not sure if that’s a bug or a feature (in GTK+), but Gnome Bugs: 610925: “GtkFileChooserDialog won’t pick show-hidden setting from a GtkBuilder File”: Comment 4 suggests it’s semi-expected behavior (the idle bug Gnome Bugs: 710258: “File chooser dialog saves show-hidden on closure” suggests others found it as a bug, though). Weird. I even tried replacing the above with something that used g_object_set_property to directly change the ‘show-hidden’ property. No dice, it still persists to the setting (when the dialog is closed, as the second bug suggests).

Anyway, I just commented it out in the end since I don’t care if the application file chooser shows hidden files, but do care if nautilus does. The moral of the story is that sometimes the bug is in some other piece of software for no particular reason.

If you find your file browser sometimes showing and sometimes hiding, it’s likely some application you use is toggling it back on you.

Categories
linux

Thoughts on GNOME 3.6 UX Changes

GNOME 3.6 has entered Debian Experimental, at least to the point where it’s installable save for a few applications. Here are some of my thoughts on the new experience.

Application Menus

In GNOME 3.6 some applications (specifically Files (previously Nautilus)) move their menus to the spot next to Activities. This spot is occupied by the currently-focused application.

The main thing is to be aware of the change. You now have to go there for those applications, and you have to ensure the application is focused before doing so.

On the whole I don’t think this is that bad. Yes, I do happen to keep my Files instances way on the right of a two-monitor setup, and the menu is way on the left. But how often do I need that menu? Pretty much never. Occasionally I’d get somewhere via bookmarks in the old Nautilus. Every now and then I look over my preferences and tweak them. But neither were remotely a daily occurrence for me.

Assuming other applications that drop their menubars for this global menu spot take similar pains to avoid needing the menu very much, it won’t bother me.

In that, this design is a kind of dare to application developers: try to get all the bang out of the UI itself.

Scrollbars

Now that the Gtk+ 2 theme is closer to the Gtk+ 3 theme, all my scrollbars are normalized. That means my scrollbars are now like one bead abacuses. Formerly I had bookends on them letting me press buttons. Now I only have the slider and non-slider areas.

The mouse buttons changed their meanings. Formerly middle-click would jump to the point in the scrollbar. Now that’s left-click.

Provided the scrollbar semantics don’t change every release, this is passable. While I would occasionally use the buttons, I can live without them.

My main complaint with the current generation (and with 3.4) scrollbars is the color of the inactive thumb and blurred thumb. By those I mean the dragged part of the bar that’s not in active use, and the bar that’s part of an inactive window.

I tend to lose my place, as they don’t stand out particularly well. That’s especially true of the blurred bar, where it probably takes me a full second to find the white on light gray thumb.

Why do I need to know that? Often I am going through a scrollable area in a linear fashion, and deciding how far I am is important to time management. But more importantly, switching to that window means evaluating where I need to scroll to. Before, with easily seen bar positions, I could make that decision as I was making the switch. But now I usually have to make the switch, then decide where to scroll.

In time, maybe I’ll learn to ignore the bar and simply try to discover my position based on the content, but more likely I’ll find an alternative to Adwaita (or modify it).

Still scrollbars on the desktop are a far cry better than what I’ve experienced on Android. There, scrollbars are basically vestigial. They only show you where you are. There are a few applications that have functional scrollbars, but even those don’t really allow for jumping to points in the list.

This is especially annoying when you’ve read to the bottom of a page and need to get to the top. I’ve tried gesturing at it, but it doesn’t seem to understand what that means. So I find myself repeatedly dragging the page until I get to the top (or bottom). Give me a regular scrollbar any day!

New Lock Screen, Shutdown Without Holding Alt, etc.

One of the features people cared about in this release is the new lock screen, which you have to either drag out of the way or press enter to be able to unlock. It doesn’t bother me. I can press enter. The updated lock screen looks nicer.

Same goes for the shutdown with or without alt. I was used to holding alt, but I haven’t accidentally hit suspend so far.

Only things that have really bugged me so far are both in the Activities overview:

Centered Search Field

This just feels like it’s in left field. Like it should belong somewhere, but there wasn’t a spot that was preferred, so it was stuck there. It’s got an unusual sizing, it just feels awkward. Maybe I’ll get used to it.

Show Applications

This is thrown in the iconic application bar in Activities, and it brings up the full listing of applications available to the user. The button is immovable. It doesn’t belong there. Again, it feels like there was a desire to shove this somewhere, but no particularly apt place came forth.

It’s a useful feature. But as any Sesame Street alumnus could tell you, “one of these things is not like the others.” It should be elsewhere.

Conclusions

On the whole this is another solid release of GNOME. While I understand some of the concern by others regarding the direction of the UI, I still think that most of their concern is overreaching.

Specifically, they seem obsessed with the alleged obsession of GNOME developers to make things useful with a tablet. Having never used a tablet, I can’t say how useful the current designs would be.

But I can speak to the usability of a touch-based mobile device. So far it’s a lame experience. Way too many times have I clicked the wrong link. I can’t tell where a link goes, which is important to judging if it’s worth clicking or passing. Typing is difficult to begin with, made worse by ineffective input editing tools (if I misspelled “misspelled” as “nisspelled” then it’s faster for me to erase the whole word than try to get the cursor to the “n” and fix it).

If the GNOME developers are eroding these sorts of problems in a product that will see any tablet/touch device adoption, then they deserve praise, so long as they’re cognizant of the needs of the desktop/laptop platforms as well.

Categories
linux

Criticisms for the GNOME Shell

GNOME Shell gets a lot of flack from people that wish it was more like GNOME 2.x series, ranging from lamenting the difference to disgruntled rants that it’s a ruinous step towards Armageddon.

I’ve been using GNOME Shell since 3.x landed on Debian, and I enjoy it. But there are some things I don’t like about it (very few). Some of them are my own lack of relearning the desktop, failure to install appropriate extensions, etc.

Messaging Tray

This is my least favorite thing about the Shell. The Messaging tray is the area at the bottom of the screen that lets notifications be added, while sometimes acting like the old tray area where applications can add icons.

The problem is that it’s auto-hidden, which wouldn’t be a problem except for the fact that it’s way too shy. I believe in recent versions it’s better, in that it will pop-up and stick around, but it’s still difficult to open if you’re on multiple monitors with the Shell on the left monitor. I run my mouse down, and miss it several times before getting it to show.

There’s supposed to be a kind of hidden bump at the top and bottom right, but those are both ineffective and annoying (ie, they don’t work when I want them to and do work when I don’t want them to).

Snapping Windows

Another feature of the Shell is snapping windows to three places: left-screen and right-screen both take up half of the screen when snapped. This is a kind of easy-tile system where you can have two windows side-by-side. The third snap is maximizing a window on the current screen.

I almost never use any of these on purpose, but do run into them accidentally more often than I’d like. This is especially common with the top-right mouse trap.

Multiple Desktops

My main complaint here is that it’s a pain in the ass to use multiple desktops. I either have to keep a mental map of my desktops, or keep going back to the Shell overview. There’s no normal workflow that automatically makes use of additional desktops. (I have a little more to say about that last sentence, see Workflow below.)

This is partly my fault, as I could probably learn to manually build these into my workflow.

Overview

The fact I’m avoiding the overview in dealing with multiple desktops points to the fact that I almost never touch the overview. In the course of a day, 90% of my overview use is in the first minutes of starting my computer. That’s usually to open a terminal, browser, and mail client. Maybe a few other things get opened/closed during the day (eg, wireshark), but these are rare.

I could have my common processes open on login, but then I’d really neglect the overview.

But this is less a criticism of the Overview/Shell, than the way I’m using it and that it’s meant to stay out of the way.

Things I Don’t Care About

I press Alt when I’m going to shut down. It doesn’t bother me. I understand that it would be trouble for discoverability reasons, and would see it fixed (I believe there’s some further work on changing it already?).

I open new windows from the application itself. As said above, I tend to avoid the Overview anyway, so making it easier to launch multiple windows for apps wouldn’t buy me anything.

Workflow

I mentioned not using multiple desktops due to workflow problems. That’s the same reason I only sparingly use Panorama in Iceweasel/Firefox.

In general, I’m conservative in my computing. I keep the number of visible tabs in Iceweasel below 10. But that’s based on experiencing frustration when I have too much around. There are people who regularly speak of having hundreds of tabs open.

My guess is that they would rather find the tab they want than navigate to a new tab.

But the point is, there’s an opportunity to have things like Panorama and multiple desktops automated into the workflow. If I could open 50 tabs without managing them (building and pruning the set), it would be entirely common.

For Panorama, that would probably involve some sort of on-screen/non-dedicated group mechanism.

For multiple desktops, seeing the other desktops might be part of it, but that would add clutter to the desktop. Better might be to do away with the concept and instead have some other way of managing what windows are on the screen(s) at once.

In any case, having features that aren’t part of the workflow requires the user to build their own extra steps into their work.

Summary

If you look, you’ll see all my (minor) complaints are regarding places where GNOME Shell gets in my way. It doesn’t do it very much.

I’m rather happy with what’s here. It can be better, but for all of the grief it receives, it’s a stable desktop experience. I honestly believe that the complaints tend more to the feelings of betrayal at the loss of GNOME 2 than any deep complaints at the state of Shell.

Categories
linux

Tips for Python Gtk2 to Gtk3

Today I’ll look at some tips for making a port of a python application using GTK+ 2 to use GTK+ 3.

The first thing you’ll want to do is read over GNOME: Live: PyGObject/IntrospectionPorting. That resource includes a link to pygi-convert.sh, which is a shell script that tries to do a bulk of the menial replacements in your code automatically.

I found that script to do a pretty good job.  It misses some things, such as import lines that include multiple modules, but the only place it made a mistake when I used it was with Gtk.Label, trying to add extra parameters unnecessarily. One thing it did miss was calls to Gtk.pack_{start,end} which now requires padding to be specified.

But this got things to a near-working state.

You’ll want to open a Python shell so you can do some manual inspection of GTK objects. For that you’ll almost definitely want something similar to:

import re
def grep(obj, string=None, insensitive=False):
    obj_dir = dir(obj)
    if string is None:
        print(obj_dir)
    else:
        if insensitive:
            expr = re.compile(string, re.IGNORECASE)
        else:
            expr = re.compile(string)
        for text in obj_dir:
            match = expr.search(text)
            if match is not None:
                print(match.string)
>>> from gi.repository import Gtk
>>> grep(Gtk, 'bar')
HScrollbar
HScrollbarClass
Scrollbar
ScrollbarClass
Statusbar
StatusbarClass
StatusbarPrivate
Toolbar
ToolbarClass
ToolbarPrivate
ToolbarSpaceStyle
ToolbarStyle
VScrollbar
VScrollbarClass
>>> grep(Gtk, 'bar', True)
HScrollbar
HScrollbarClass
InfoBar
InfoBarClass
InfoBarPrivate
MenuBar
MenuBarClass
MenuBarPrivate
ProgressBar
ProgressBarClass
ProgressBarPrivate
STYLE_CLASS_INLINE_TOOLBAR
STYLE_CLASS_MENUBAR
STYLE_CLASS_PRIMARY_TOOLBAR
STYLE_CLASS_PROGRESSBAR
STYLE_CLASS_SCROLLBAR
STYLE_CLASS_SIDEBAR
STYLE_CLASS_TOOLBAR
Scrollbar
ScrollbarClass
Statusbar
StatusbarClass
StatusbarPrivate
Toolbar
ToolbarClass
ToolbarPrivate
ToolbarSpaceStyle
ToolbarStyle
VScrollbar
VScrollbarClass

This will make your life easier, as often looking in the same object, the name of a function has changed, and it can be faster than consulting the online documentation (though you will probably still have to follow up with that, if the signature has changed).

For the online documentation, the main resource you’ll use is the GNOME Developers: GTK+ 3 Reference Manual, as Google Search and other search engines tend to have a lot of GTK+ 2 cruft sitting there to waste your time. But there’s also a promising bit of work at ReadTheDocs.org: The Python GTK+ 3 Tutorial. While it’s brief as of this writing, it’s a decent, hardworking resource, very clean, etc.

You’ll also want to do a grep -rn 'except:' [path] or possible a more sophisticated alternative to find out where in the code you are working with are exceptions being handled. This is especially useful if what you’ll find is:

try:
    foo()
except:
    pass

Those are the worst, you’re wondering why something isn’t working, when it turns out that foo() isn’t being allowed to tattle. Censorship sucks, even in code. Python needs whistleblower protection! Don’t let them silence your flaws, it will come back to bite you in the ass.

One place where things have changed and maybe are still changing that I noticed was GdkPixbuf and other graphics-related things. These are moving toward cairo. In those cases you’ll need to dig into the pycairo docs as well, but chances are you won’t have to go too deep or the component you’re working with would’ve been written calling cairo from the start.

Another thing to remember is that the way the original developers did it may have been due to earlier versions of GTK+ not supporting something it now supports. In those cases, you can save yourself some trouble if you can realize that and make the change.

Categories
linux

Canonical and GNOME

Removing the minimize button?  Not giving a preference to turn off the display and not suspend when you close your laptop?  Moving the window controls to the other side of the window? Making the tabs square instead of round? Not allowing the editbox to be manually resized? Hiding the RSS icon? Moving the link preview to the URL bar? Removing the status bar?

And those are just the ones I can recall at the moment.

The computer is so central to peoples’ activities, that there is a certain fear that someone will break it for them.  That’s one of the major motivations behind Free Software in the first place: if I can build it myself, then you can’t force me to use the broken one.  If I can’t, then MicrosoftAppleSonyPaypalMastercard can up and decide to force their will upon me, and my recourse is simply to stop using them.  No stabbing big corporations with a fork.

Canonical Limited (the main driver for Ubuntu Linux) and the GNOME project couldn’t work together so they are each moving forward with their own, reinvented desktop interfaces. GNOME is going for gnome-shell and Canonical/Ubuntu will get Unity.

I don’t think this is a bad thing, excepting the bickering.  The larger community of desktop Linux users will get to see two different approaches in the wild for at least a year, which will inform the next iteration of the Linux desktop landscape.  There’s also an open-ended possibility for reunion later.

The dispute is territorial, which is not uncommon in open source.  The uncommon part of this is simply that it’s between two big players rather than between one big player and the users.  Though, the latter has occurred for both reinventions as well (see a few of the questions posed in the first paragraph).

Project governance is hard.  Cooperation is hard.  Finding the best way is hard.

If it weren’t for the bickering, nothing would be wrong.  There’s too much distrust and fear, because that’s what we’ve been taught by the proprietary realm.  When we used proprietary software, we could be stuck with a bug indefinitely.  Or things could change with no warning.

So we’re edgy.  But when the source is open, we shouldn’t be.  And if we weren’t, it would make project governance easier, it would make progress easier.  We should be willing to give the code an honest run.

At the end of the day any shift in any system will require a new equilibrium to be reached.  In open source that means some users will switch, forks might be created, etc.  But it also means that most users will find a slightly better workflow, will be a little (or a lot) happier and more productive.

I just wish that the developers weren’t so quick to assign blame, because they’re both building the foundation for the future, and they should be proud of their efforts even if they fail.