User Interface of the X Configuration Tool

Matthew Paul Thomas mpt at canonical.com
Tue Jun 5 03:28:16 BST 2007


On Jun 4, 2007, at 11:15 PM, Sebastian Heinlein wrote:
>
> Am Montag, den 04.06.2007, 22:43 +1200 schrieb Matthew Paul Thomas:
> ...
>> So here's what the competition does:
>> <http://think-well.org/articles/2006/12/28/managing-multiple-displays>
>
> How does the MacOS dialog allow to change the resolution of each
> monitor?

(For the benefit of those who weren't in #ubuntu-devel...) Following 
the principle of direct manipulation, it opens a secondary dialog *on 
each display*, for setting the resolution+refresh+colors of that 
display.
<http://www.dummies.com/WileyCDA/DummiesArticle/id-3130.html> The 
secondary dialogs cannot be dismissed by themselves, but presumably 
they disappear as soon as you leave the Displays pane of System 
Preferences. (This works because the whole mechanism is instant-apply.)

If you disconnect a display completely, any windows that were on it are 
automatically moved to the primary display, and resized if necessary. 
However, any desktop icons that were on the secondary display remain 
lost until you either Arrange or Select All then Clean Up the desktop, 
which isn't good.

(This is a correction to what I said in #ubuntu-devel...) If any 
display remains connected but isn't working properly (e.g. you've 
managed to set it to an incompatible refresh rate), both the primary 
Displays window and the secondary display dialogs have a "Gather 
Windows" button. Clicking that button on a display moves *all* windows 
onto that display that are not already on it. (This includes the other 
display window/dialogs. The secondary display dialogs are still 
distinguishable by the name of the display in their title bars.) But if 
your primary display is the one that's hosed, you're still stuck unless 
you have a keyboard combo set up to launch the Displays window in the 
first place (because you can't launch it from an invisible menu bar or 
Dock).

> ...
>> At the top center of the window could be an option menu listing the
>> available displays (defaulting to the primary display), followed by a
>> separator, then items for managing multiple displays. The rest of the
>> window would show settings for the current display. For example:
>>
>>                ________________________________________
>>               |(x)             Displays             (-)|
>>               |         ______________________         |
>>               |        |__LCD (Primary)_____:^|        |
>>               |________________________________________|
>>               |                                        |
>>               |     (display-specific settings here)   |
>>               :                                        :
>>
>> The menu when opened:
>>                ________________________________________
>>               |(x)            Displays              (-)|
>>               |         ______________________         |
>>               |        |/:LCD:(Primary):::::::|        |
>>               |________|  Canon LV-7575       |________|
>>               |        |  Unknown             |        |
>>               |        |----------------------|        |
>>               |        |  Graphics Card...    |        |
>>               |        |  Arrange Displays... |        |
>>               :         """"""""""""""""""""""         :
>>
>> "Graphics Card..." and "Arrange Displays..." would both open separate
>> dialogs, and would not be actual choices.
>>
>> I agree with Corey and Mikko that the arrangement UI should use
>> draggable thumbnails of each display. For accessibility, each 
>> thumbnail could be focusable and movable using the arrow keys.
>
> 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.)

Whether a list of objects should be presented in an option menu, a 
combo box, a listbox, or a text field with compulsory auto-complete 
depends not on the OS, but on the likely number of items and how 
prominent the list should be. For example, word processors (such as 
AbiWord) typically have an option menu or combo box for typeface 
selection in their toolbar, but a listbox for the same set of typefaces 
in their Font dialog.

> I am against using the combobox for such a central element of the
> dialog, since it hides all other information at the first time.

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.)

> 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? Even saying "Primary display" would be better than "Unknown".

> Additionally you have to think of systems with multiple cards.

Sorry, I don't yet understand the ratio of graphics cards to displays 
and why they need to be configured separately. Enlighten me. :-)

> Please see my previous mails about the bad workflow of setting up a 
> dual screen setup if the configuration is scattered on different 
> dialogs or tabs.

As before, since most people will have only one display, I think more 
prominent would be too prominent, and would lead people to press for 
the separate simple+advanced GUIs that neither of us want.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/
-------------- 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 : https://lists.ubuntu.com/archives/ubuntu-desktop/attachments/20070605/5d970766/attachment.pgp 


More information about the ubuntu-desktop mailing list