Re: [Usability] desktop lacks "Display properties" or " Screensaver - Power" options on right-click context menu

[Jacob Beauregard <jake13jake comcast net>]

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.

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