On Monday 23 April 2007 10:15:57 am Curtis Hovey wrote: > On Mon, 2007-04-23 at 09:25 -0400, Jacob Beauregard wrote: > > On Monday 23 April 2007 08:48:56 am you wrote: > > > On Mon, 2007-04-23 at 08:23 -0400, Jacob Beauregard wrote: > > > > > > The question is, what is the familiarity of most GNOME users? Is > > > > > > it in Windows or in GNOME itself? Do GNOME users even utilize the > > > > > > right-click context menu, and would adding such an element to > > > > > > that context menu be a constraint to the GNOME population? > > > > > > > > > > Adding items which the majority of people would never use would be > > > > > a bad move, imho. > > > > > > > > Users would stop complaining if they could change their context menus > > > > from the default configuration. > > > > > > > > Also, you're assuming that the majority of people would never use > > > > this item. PROVE IT. You lack reason not to investigate a user's > > > > input if you're going to declare a decision as final. > > > > > > I have to prove that the majority of users don't have the desire to > > > change the resolution of their screen sufficiently frequently to > > > justify a desktop context menu item explicitly to change resolution? > > > I've yet to hear a decent reason *for* it. Why would someone want to > > > change resolution so frequently that they'd need rapid access for it? > > > And why would the xrandr-applet not suffice in this case? > > > > > > > > What are we talking about now? The ability to add arbitrary > > > > > entries to the desktop context menu? That is possible by adding an > > > > > entry to the Nautilus scripts folder, but note how they are in a > > > > > submenu so that they don't take over the context menu. > > > > > > > > Submenus bury functionality, making it harder for users to access it. > > > > In addition, submenus that open to the side as opposed to unfolding > > > > add extra work for the user. > > > > > > Yes, that is true. > > > > > > Burying functionality isn't an issue for the Scripts menu, as the user > > > has to put stuff in there. The choices were a) submenu or b) > > > potentially huge desktop context menu. I think the right choice was > > > made. > > > > In the context you speak of, it's great the way it is. It's great for the > > default, too, but giving people the ability to directly modify the > > context menu makes no contest for all use cases. > > In this scenario I disagree. Accessing the screen* option from the > desktop leads to additional choices that the user must consider (waste > time). We have a control center so that the user knows there is one > place to configure the desktop work environment. Once configure, the > computer should 'Just Work'. If users need to visit the control center > often, that is another problem that must be understood and addressed.
I never said this should be done. These are the constraints I inquired for someone to state. > > Adding additional items to the context menus will also waste time the > users time if these items are rarely needed & available elsewhere, or > the item is not exactly related to the context. > > Ross is correct in that we offer the panel launchers as a convenience > (and time saver) to allow users to access _distant_ features quickly. > Allowing user to adding items to a Context menu is already a feature, > making it as easy as adding a panel applet is work that can be done. I'm > not convinced that work should be done, but I'm willing to see a working > concept. It doesn't necessarily have to be done, I just see how people can be frustrated by it at times. Has anyone thought of using click-activated folding/unfolding submenus (lengthening the context menu when a submenu is clicked) rather than a hovering side-menu? This would help the user save time by not having to reorient direction of hand motions, and therefore the features in submenus would feel less "buried." > > As for this particular example that you bring up, I added the Change > Screensaver feature to my desktop menu in a minute and a half--then > removed it. I don't see any nautilus scripts for changing screensavers > or screen resolution in any of sites that host nautilus scripts. Yet it > is simple for moderately experience GNOME users to create the two line > script. I don't this there is a _want_ for these features in the context > menu. So I don't think this is a Windows or a Mac issue, and I see no > evidence that this is a community issue. It isn't a particular example that I brought up. > > > > > > > > > The modesetting display capplet in notification tray, the > > > > > > > > whole of display properties so one can change things on the > > > > > > > > fly, seeing a movie, seeing a .pdf etc. hence atleast to me > > > > > > > > it makes sense. > > > > > > > > > > > > > > Why would you change resolution manually when you want a movie, > > > > > > > or read a PDF? I'm still struggling to see a use-case for > > > > > > > frequent resolution changes. I change resolution relatively > > > > > > > frequently (when I connect my external monitor), but I have a > > > > > > > tool which changes resolution, font size, wallpaper and so on > > > > > > > in a single keypress. > > > > > > > > > > > > Yea, I've got that external monitor case, too. There are also a > > > > > > few games that like to add constraints to the resolution you can > > > > > > use. > > > > > > > > > > Every game I've used changes resolution itself. Interesting that > > > > > there are some which don't. That's a bug in the game of course, > > > > > should GNOME add an extra menu item to the desktop context menu > > > > > because there are some buggy games? > > > > > > > > Once again you have no idea what you're talking about... No, there is > > > > no bug with the game, and please don't make assumptions on my use > > > > cases. > > > > > > So why does a game enforce particular resolutions on the user, but not > > > change the resolution itself? How does this considered a feature and > > > not a bug? > > > > The game in question isn't enforcing the resolution, it's simply > > suggesting you use a lower resolution so not to have an unfair advantage, > > and otherwise be limited to watching (which a higher resolution would be > > better for as well). This game does provide a means to set resolution. > > However, it can also be set to adapt to the current resolution. This > > means it can be a choice of the player on whether they would want to > > change their resolution via in the game or in the computer's resolution > > settings. > > > > > > > > > > I find it extremely challenging to traverse through 3 menus > > > > > > > > in order to get a simple thing done, hence if the display > > > > > > > > capplet is there which has everything from brightness, > > > > > > > > contrast, resolution-modesetting, themes etc. it would be > > > > > > > > pretty cool > > > > > > > > > > > > > > Brightness and contrast are monitor settings, GNOME can't > > > > > > > control those. > > > > > > > > > > > > Would a device driver possibly have control over these? > > > > > > > > > > No idea, I don't have the EDID specification to hand. If it were > > > > > possible and if X exposed it, then it could be added to the Display > > > > > capplet. > > > > > > > > Who's the GNOME dev who's going to ask an X dev? > > > > > > Whoever wants to code the functionality. If you want to code this, you > > > can read the EDID (and so on) specifications, come up with a nice way > > > of integrating this into X (using the controllers available on the > > > XRANDR 1.2 CRTCs is probably a good idea), propose that to the Xorg > > > list and if it's agreed up, add it to XRANDR> Then you can add two > > > sliders to the currently-non-existant Display capplet. > > > > > > > > > > That leaves resolution and theme. Thomas Wood is working on an > > > > > > > Appearance capplet which covers themes, colours, and fonts. > > > > > > > I've been planning on adding ICC profile selection to the > > > > > > > Resolution capplet which would make it a Display capplet. > > > > > > > > > > > > If I wanted to switch my res from 1680x1050 to 1280x1024, would > > > > > > GNOME be responsible for handling when my screen gets stretched > > > > > > rather than certain parts getting ignored (I really doubt it, but > > > > > > such a thing could probably be hacked anyway). > > > > > > > > > > I've never had the screen be ignored when expanded: nautilus > > > > > notices the resize and draws the wallpaper there, the panel expands > > > > > to fill the extra space, and metacity will place windows. If you > > > > > can replicate GNOME refusing to use space, then you've found a bug > > > > > in X. > > > > > > > > What are you talking about? I'm talking about refusing to use space > > > > for the sake of not distorting the monitor based on default > > > > resolution, and I meant hacking through whatever bug or work-around I > > > > could throw in my X source code. > > > > > > Sorry, I misunderstood you. > > > > > > My laptop panel is 4:3, my external display is 16:9. In the new XRANDR > > > implementation (available in xorg-server 1.3) I don't end up with a > > > distorted screen but black bars on the sides, so I presume this is > > > either a) fixed in xorg-server 1.3 or b) a driver bug (I'm using > > > -intel). Anyway, yes, this is nothing to do with GNOME. > > > > > > Ross > > > > _______________________________________________ > > Usability mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/usability _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
