Am Dienstag, den 05.06.2007, 14:28 +1200 schrieb Matthew Paul Thomas: > 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>
> 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). Small side note: There is going to be a x keeps crashing session, that will start displayconfig. But I don't know if it will enable multiple monitors by default. > > ... > >> 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.) 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. Your widget would contain different entry types. The graphics card entry would not even refer to another object type but also launch a sub dialog, instead of modifying the current dialog. Before you could reuse the locations from the network admin you would have to introduce a meta concept of locations. > 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.) In GTK terms the widget would be an entry combobox. The term options menu refers to a deprecated GTK widget. 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 think that the widget even on the Windows dialog looks very strange. > > 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. So at first we get the information from the xorg.conf. And only the parts that are not defined there will be auto detected and completed. Since we face a lot of crappy hardware we have to allow the user to override the auto detected configuration easily. > 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. Think of the following to situations: Display #1 => Primary Display #2 Display #1 Display #2 => Primary The use case are laptop users who want to use a larger external screen as the default when being at home. > > 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. :-) 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. :) > > 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. Most people are perhaps not the ones who use the app at most. The automatic configuration should work on most systems. But laptop users that use external display devices will use this app quite often. If we get the locations chooser there would be two comboboxes. That would result in a quite nested dialog. I think the best solution would be to combine the arrangement widget and the screen selector. The only problem would be how to represent disabled screens. :/ The "lucky" only XRandR based configuration tool would have not to care about this and a lot of other stuff. Cheers, Sebastian -- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
