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. 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. 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. > > > > > > > > > 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 > Usability gnome org > http://mail.gnome.org/mailman/listinfo/usability -- __C U R T I S C. H O V E Y_______ sinzui is verizon net Guilty of stealing everything I am.
Attachment:
signature.asc
Description: This is a digitally signed message part