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.
> > > > > 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?
> > > > > 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
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Attachment:
signature.asc
Description: This is a digitally signed message part