User Interface of the X Configuration Tool

[Sebastian Heinlein]

Hello Desktopers,

the new and shiny GTK frontend to displayconfig (the x configuration
part of the KDE admin suite named guidance) has got some usability
issues. I would like to start a discussion about this to get your input
and comments.

Currently the dialog is separated into three tabs:

- Display mode (allows to change the resolution, rate of each screen)
- Dual head (allows to configure a dual screen setup)
- Devices (allows to choose drivers and monitor models)

You can get a recent feisty package of displayconfig-gtk here:

http://glatzor.de/filesink/displayconfig-gtk_0.2
+20070523ubuntu2_i386.deb

Furthermore some older screenshots can be found on the Internet:

https://wiki.ubuntu.com/DisplayConfigGTK

The problem is that this layout behaves quite bad in the current use
case: Setting up a new monitor for dual screen use.

At first you have to go to the devices chooser and select another model,
then back to the dual head tab and choose the right mode. Most times you
will forget to go back to the first tab and change the resolution before
clicking ok ang logging off and in.

Furthermore it is quite hard to identify monitors on the first tab if
you have got more than one graphics card. 

So the a solution could be to merge the display mode and devices tab to
single tabs of which each would represent a single graphics card:

http://glatzor.de/filesink/dcg-gfxbase.png

****
If you want to the new/other user interface on your computer
(displayconfig-gtk needs to be installed before):
bzr branch http://glatzor.de/bzr/displayconfig-gtk/gfxbase/
cd gfxbase
./displayconfig-gtk --data-dir=data
****

There is the objection that identifying screens by graphics cards is
quite geeky, since most users only know of the screens that they see and
not internal cards.

Hopefully most systems would only have got one device. And the people
that bought a second card for dual screen are used to the technical
terms.

If there would be only one device and one output the user would only get
one device tab and the screen selector on the left would not show up. So
the new interface could scale well.

http://glatzor.de/filesink/gfxbase-single.png

I am unsure if we should remove the dual head configuration tab at all
or only make it insensitive in single screen mode. On the one hand users
that connect a second screen later on another computer would know where
to search for, but on the other hand users that perhaps for all time
will only sit in front of one monitor will be bothered with more
technical and complex issues. If the second tab is invisible we could
even hide the borders of the notebook or perhaps exchanged them by a
separator:

http://glatzor.de/filesink/gfxbase-stripped-down.png

Although I designed the dialog I am still a little bit confused by the
multiple screens layout and I heard this from others too.
 
This could be related to the screen selector. But improving it can be
quite hard, since we are limited in space that can be used by the main
window and therefor the screen selector: the dialog has to fit on a
640x480 screen. 

Currently the model name of the screen is available twice: one time in
the selector and one time on the device/model chooser. Currently the
device chooser label uses ellipsis and therefor does not consume too
much space. It would be nice if would not to duplicate this text.

Would using numbers for the outputs make more sense? Moving the selector
to the top seems to get us into space troubles.

By the way the driver name on the lowest selector will be replaced by a
human readable and longer name in the future.

In the near future I plan to add location/profiles support to the
window. That would allow you to manage different X configurations and
easily switch between e.g. your home and work setup.

See this and the previous screenshot:

http://glatzor.de/filesink/gfxbase-profiles.png

I would be appreciate your input, comments and suggestions.

Regards,

Sebastian

P.S.: To avoid any XRandR 1.2 questions: Primarily we will use the
traditional approach by xorg.conf modifications. But we plan to
implement an instant apply function using XRandR 1.2 as far as possible.