linux-admin.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stewart <bdlists@snerk.org>
To: Glynn Clements <glynn.clements@virgin.net>
Cc: Barry Gamblin <bgamblin@hao.ucar.edu>, linux-admin@vger.kernel.org
Subject: Re: changing color depth in XFree86
Date: Sat, 19 Apr 2003 11:55:02 -0400	[thread overview]
Message-ID: <3EA17156.3070009@snerk.org> (raw)
In-Reply-To: <16033.21074.906637.184724@cerise.nosuchdomain.co.uk>

Glynn Clements wrote:

> : Support for the RandR extension has been partially integrated into
> : the XFree86 server, providing support for resizing the root window at
> : run-time.
> 
> The problem with changing the depth is that the depth is guaranteed to
> remain constant. That has been part of the interface since X'
> inception, and no amount of code can change that.
> 
> Once an application queries the screen depth, it can safely assume
> that the information remains valid for its lifetime. Changing the
> depth of a running X server would cause existing applications to
> either stop functioning correctly or crash outright.

Then the applications will have to remove their legacy code and catch up 
with the needs of the users, rather than the programmers.

Moreover, if an application were to crash because it finds itself 
outside of the bounds of the screen, that application was poorly written 
to begin with. There's just no excuse for being *that* dependant on 
geometry with no protections in place.

Further, if and when the screen is resized, it's up to the 
window|desktop manager to align the windows according to a pre-defined 
set of guidelines (static or configurable), much like Windows Explorer 
and the Mac GUI.

For the sake of productivity, I should be able to seamlessly en/disable 
any of my monitors, alter any of their resolutions and/or colour depth, 
reposition their virtual layout, all without restarting my entire 
graphical environment and having to play with scripting, command-line 
switches and convoluted config files.

Don't get me wrong, I'm a long-time Linux admin and I find that textual 
config files are some of the most powerful means of managing daemons and 
system components, but realistically there has to be a front-end method 
that will allow me to perform any/all of these actions withOUT 
interrupting my train of thought.

>>Frontends are forthcoming from your friendly neighborhood window|desktop 
>>management centres.
>>
>>Upgrade and behold the goodness of a drop-shadowed mouse cursor (worth 
>>the price of admission, IMHO. ;> )
> 
> I'll choose compatibility over gimmicks any day.

"Gimmicks"? Changing resolution on the fly has come to be expected from 
any modern desktop environment. It's taken far too long, IMO, for 
XFree86.Org to catch up and implement such functionality in their 
server. I only hope they don't leave the job half complete.

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."


  reply	other threads:[~2003-04-19 15:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17 17:48 changing color depth in XFree86 Barry Gamblin
2003-04-17 20:23 ` Glynn Clements
2003-04-19  4:10   ` Stewart
2003-04-19 13:42     ` Glynn Clements
2003-04-19 15:55       ` Stewart [this message]
2003-04-19 23:19         ` Rant [Was: Re: changing color depth in XFree86] Glynn Clements
2003-04-19 23:42           ` Bill Sneed
2003-04-20 15:21           ` Stewart
2003-04-20 14:17         ` changing color depth in XFree86 terry white
2003-04-20 15:11           ` Stewart
2003-04-20 15:52             ` terry white
2003-04-20 23:24               ` Stewart
2003-04-21  1:36                 ` terry white
2003-04-21  4:44                   ` Stewart
2003-04-21  7:04                     ` terry white
2003-04-21 16:34                       ` Milan P. Stanic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EA17156.3070009@snerk.org \
    --to=bdlists@snerk.org \
    --cc=bgamblin@hao.ucar.edu \
    --cc=glynn.clements@virgin.net \
    --cc=linux-admin@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).