User Interface of the X Configuration Tool

Matthew Paul Thomas mpt at
Tue Jun 5 13:16:59 BST 2007

On Jun 5, 2007, at 7:01 PM, Sebastian Heinlein wrote:
> Am Dienstag, den 05.06.2007, 14:28 +1200 schrieb Matthew Paul Thomas:
>> On Jun 4, 2007, at 11:15 PM, Sebastian Heinlein wrote:
> ...
>>> In GNOME we use a notebook with tabs or a left sided list view. It
>>> would not be consistent.
>> That's a strange thing to say, because you've already added an option
>> menu for locations that works much the same way, like the one in
>> network-admin. (I hope it's sharing the list of locations with
>> network-admin.)
> Not really. It has got a label that gives a "clear" idea of what you
> could find inside of the combobox menu: Locations. It only has got one
> purpose.

So perhaps the menu needs a "Display:" label. I didn't include this in 
my proposal, because the "Displays" title bar was only 20 pixels or so 
above the menu, with nothing between the title and the menu. But if you 
are adding a location menu between them, perhaps a separate label is 

> Your widget would contain different entry types.

I think the location menu should eventually behave the same way. (The 
current scheme, of three unlabelled buttons to the right of the menu, 
is unattractive and unreasonably difficult to understand.) It is not 
common in Windows for dropdown listboxes to contain commands for 
managing the list they contain, but that's because they're drawn as 
listboxes rather than as menus, and it is much more obvious that a menu 
item will perform a command than that a listbox item will. But this GUI 
pattern is quite common for option menus in Mac OS, and I think the 
only reason it's not common in Gnome is that there isn't nearly as much 
Gnome software yet.

> The graphics card entry would not even refer to another object type but
> also launch a sub dialog, instead of modifying the current dialog.

You might be right, the graphics card item might need to be a separate 
button. I can't tell that until I understand how graphics cards relate 
to displays.

> Before you could reuse the locations from the network admin you would
> have to introduce a meta concept of locations.

That's what I'm suggesting. :-) I doubt there needs to be a separate 
Location Manager, though. Probably it would be enough to have an 
unobtrusive management interface in each tool that uses the locations.

> ...
>> Since -- as you pointed out -- most people will have only one display,
>> I think it is quite prominent enough as an option menu, the same as in
>> Windows. (And I know my Ascii art is dodgy, but I did intend it to be
>> an option menu, not a combo box.)
> In GTK terms the widget would be an entry combobox.

If GTK calls it an "entry combo box", that is an error in GTK. A combo 
box is a control that *combines* a text field and an option menu, hence 
the name. (In Windows, a combo box combines a text field and a dropdown 
listbox, with much the same effect.) But the displays menu should not 
be a combo box, it should be just an option menu.

Windows programmers often mistakenly refer to dropdown listboxes as 
"combo boxes" because, in Windows versions up to XP, the two types of 
control looked exactly the same despite behaving very differently. 
(That bug is fixed in the default theme for Windows Vista.) So if GTK 
really does refer to option menus as "combo boxes", it may be because 
the GTK developers were mistakenly copying the Windows developer 

> The term options menu refers to a deprecated GTK widget.

I doubt that. Option menus are used in much of Gnome, including the 
location menu in network-admin, as well as gnome-background-properties, 
gnome-language-selector, Seahorse, Epiphany, Evolution, and GTK's own 
file pickers. Perhaps GTK uses a weird name for them too?

> Like the name already suggests, why should we allow the user to put 
> any text into the chooser? The set of available options is really 
> small.

I agree entirely. That's why it should be an option menu, not a combo 
box. :-)

> I think that the widget even on the Windows dialog looks very strange.

You may be looking at screenshots and thinking that the Windows dialog 
uses a combo box, but it doesn't. You've been misled by the Windows bug 
I described above, where dropdown listboxes and combo boxes look 
exactly the same. In Windows Vista, the default theme makes it much 
more obvious that the monitor selector is a dropdown listbox that you 
cannot type into. <>

>>> Especially there is no indication to find the arrangement and 
>>> graphics card action in the combobox. At the first time it will only 
>>> show the name of a display - in the worst case even "Unknown".
>> Can you not even determine whether the primary display is an LCD or a
>> CRT?
> At first there is a technical limitation: auto-detecting only works for
> the first display correctly. And if it fails we won't have got not any
> idea at all.
> But there is also the problem that we have got two information sources:
> on the one hand the configuration from the config file and on the other
> hand some run time auto detected facts. It is sometimes hard to make a
> decision on which we should base.

If either of them return "Unknown", use the other. If neither of them 
do, toss a coin. ;-)

Anyway, I don't think it's any worse to have an "Unknown" option menu 
item than it is to have an "Unknown" listbox item.

> ...
>> Even saying "Primary display" would be better than "Unknown".
> Generally there is a difference between the role of the screen and it 
> is index number. The role can change, so I am against using the role 
> as an identifier.

Fair enough.

> ...
>> Sorry, I don't yet understand the ratio of graphics cards to displays
>> and why they need to be configured separately. Enlighten me. :-)
> A visual connection between the card and the screens would make it
> easier to identify "Unkown" devices on multiple card setups. But I
> skipped this in my latest approach too.
> Some time ago I posted a mockup that used the graphics card as the main
> object.
> You suggested to separate the graphics cards configuration by
> introducing a sub dialog. :)

Is there somewhere I can read about the relationship between cards and 
displays? Is it 1:1? Is it 1:n? How friendly, and how long, are typical 
detected names for cards? Approximately what proportion of people have 
1 card, what proportion have 2, and what proportion have 3?

> ...
> If we get the locations chooser there would be two comboboxes. That
> would result in a quite nested dialog.
> ...

That's a good point. But perhaps you don't actually need locations 
after all. Instead, store all the detected identifying information for 
up to (say) the 50 most recent unique displays the user configured, 
together with how they configured each of them the last time they used 
them. (This information wouldn't be shown anywhere in the GUI, it would 
be used solely for making things Just Work.) Then the next time a 
display is detected, compare it against the list of previous displays. 
If there's a match, automatically set the display to the configuration 
the user used for that display last time.

Even if that approach requires better auto-detection of displays, maybe 
you could hold off on including a locations menu, instead of adding it 
now only to remove it later when auto-detection makes it unnecessary.

Matthew Paul Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : 

More information about the ubuntu-desktop mailing list