Design: rethinking the style preferences

Back in the Acessibility: Contrast, colors, and fonts post, I explained how the color/style preferences changed depending on "contrast mode" being on or off:

Following a suggestion by Matthew Paul Thomas, I now merged the two versions into a single one, using a GtkComboBox.

This new version allows both modes to share all possible options. It also reduces interface complexity by eliminating the need for checkboxes in non-contrast mode.

I'm still wondering whether I will make a list of suggested colors available. I have no idea what they would be. :)

Coding: Aligning Widgets with GtkCheckButton Labels

As I mentioned in the previous post, I think I found a way to accurately align widgets with GtkCheckButton labels, though I have no idea if it's the easier way.

Basically, these are the GtkCheckButton style properties that define the left distance:

So all you need to do is set the margin-left of child widgets to:

focus-line-width + focus-padding + indicator-size + 3 * indicator-spacing

If you want to adapt immediately when the GTK theme changes, then you also need to connect to the style-updated signal appropriately. Here is a custom widget that gets the job done.

from gi.repository import GObject, Gtk

class CheckGroup(Gtk.VBox):
    def _on_checkbutton_style_updated(self, widget):
        value = GObject.Value()
        value.init(GObject.TYPE_INT)

        widget.style_get_property('focus-line-width', value)
        margin = value.get_int()

        widget.style_get_property('focus-padding', value)
        margin += value.get_int()

        widget.style_get_property('indicator-size', value)
        margin += value.get_int()

        widget.style_get_property('indicator-spacing', value)
        margin += 3 * value.get_int()

        self.group.set_margin_left(margin)

    def __init__(self, checkbutton):
        checkbutton.connect('style-updated', self._on_checkbutton_style_updated)

        self.group = Gtk.VBox(homogeneous=False, spacing=6)
        self.group.show()

        super(CheckGroup, self).__init__(homogeneous=False, spacing=6)
        self.pack_start(checkbutton, False, False, 0)
        self.pack_start(self.group, False, False, 0)
        self.show()

Design: To Label or Not To Label?

So, after Lars pointed me to the right direction, I think I managed to perfectly align widgets with checkbox labels. The next blog post will give the full details, but before that I have a small design question... Is it just me or the group labels are now visually redundant?

Compare

with

What do you think? Should I eliminate the labels or keep them for consistency with other windows?

By the way, I am aware that the entire authentication group should technically be inside the general group, but I couldn't figure out how to do this without making the layout look very unbalanced. Specially now that I'm aligning the widgets with the checkbox labels. Suggestions are welcome.

Design: Dialogs and error messages (2)

Following feedback from our favorite crazily-smiling designer and that great orange psychopath artist (I'm assuming the avatar is a self-portrait), here's the current state of the proxy dialog.

The italics were a personal touch.

Design: Dialogs and error messages

Following up a comment by Matthew Paul Thomas on the Design: Dialogs, long operations, and error messages post, I'm experimenting with ways to show the error message in dialogs directly, without the need of hover or keyboard focus.

The hard part is inserting an error message inside the dialog layout in a way that's not aesthetically horrible. In particular, catering to the alignment issues of both short and long messages is complicated.

For now, I'm thinking about placing the message on the top.

This looks intrusive, as it moves the entire content downwards, but keep in mind that the dialog becomes insensitive during a long operation that can fail. So the user will not be trying to click anything in the moment the error appears.

What do you think? Suggestions?

Heads Up: Drag 'n' Drop bug with PyGObject 3.0.0 (Ubuntu 11.10)

The GTK handling of drag 'n' drop looks a little bit convoluted at first, but can be quite handy once you get the hang of it. Unfortunately, there is a bug in PyGObject versions below 3.0.3 that makes things a little bit harder than they should.

Long story short, when using PyGObject in Ubuntu 11.10 Oneiric Ocelot, you can't pass detailed parameters to widget.drag_dest_set and expect GTK to take care of everything. You need to handle the drag-motion, drag-leave, and drag-drop signals yourself.

Acessibility: Contrast, colors, and fonts

As part of the goals for the current rewritings and refactorings of Polly, I'm trying to neglect accessibility a little less than I did until now. Because GTK offers great a11y support by default, this basically means taking some extra care when I edit widgets on my own instead of relying on the theme. One such care involves playing well with high-contrast themes.

Instead of a one-size-fits-all design, that would inevitably lead to some lowest common denominator aesthetic choices, the next versions of Polly will allow a --contrast command-line parameter that causes some subtle changes in the interface.

One of those changes involves the color of the error bar. In normal mode, it simply has our good old universal error color, red.

In contrast mode, the red is replaced by a color taken directly from the theme, ensuring readability while still drawing attention. Below you can see what how contrast mode looks when using the HighContrast and HighContrastInverse themes.

The other change I have implemented involves a new feature: I am going to introduce optional background color coding for unread items and mentions.

In contrast mode, where the choices of color are much more limited, I offer an alternative: marking unread items with bold and marking mentions with italic. This wasn't a very hard choice, since bold is a very common way of showing unread items in mail clients.

So when contrast mode is enabled, this is how the preferences window looks like.

What do you think? I'm not an accessibility expert, so I would love some feedback.