gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Display server and window interaction


From: Pascal Bourguignon
Subject: Re: Display server and window interaction
Date: Fri, 12 Apr 2002 07:15:45 +0200 (CEST)

> Date: Thu, 11 Apr 2002 16:40:12 -0600
> From: Adam Fedor <address@hidden>
> 
> Fred Kiefer wrote:
> > With the new split of the back end functionality a new class 
> > GSDisplayServer was introduced. As we may in principle have a lot of 
> > those, we must find the correct one for a given window, before we send 
> > it any window operation. This happens mostly in the NSWindow.m file and 
> 
> 
> I'd actually argue to opposite. There are very few, if any, reasons to 
> have more than one display server per application. Perhaps a groupware 
> application might find this useful (although having a non-graphic server 
> talking to separate GUI frontends via DO would probably work better).
> OSX and OpenStep don't even have a provision for this.
> 
> I think I should just make GSDisplayServer a singleton and have a static 
> variable "GSApplicationDisplayServer" hold the id to it.
 

Quite  on the  contrary, there  are all  the reasons  to  have several
displays and more than on for any application.  I currently have three
computers on my  desk, and with all X applications,  I can put various
windows on any and all of  their displays. Actually, with emacs, I can
even do it dynamically, and open a new window with :

     M-x make-frame-on-display RET triton:0.0 RET

and  then   use  the  screen  of   my  laptop  while   working  on  my
workstation. Why would you want to  prevent me to do that with GNUstep
applications?

It's even so  well designed that there are as  many insertion point as
there are  displays (input devices),  and therefore I can  easily type
with my QWERTY  keyboard of my workstation text in  English and at the
same time,  type with  my AZERTY  keyboard of my  laptop same  text in
French. Yes, I have two  hands, and two hemispheres... ;-) Ok, perhaps
I don't  do it at the  same time, but I  don't see any  reason why one
could  not  configure his  software  to  run  and interface  with  any
hardware one happen to have  on his network.  Let's avoid "The network
is the computer." be only dead words.



The GNUstep API allow for  several screens.  Why not allow the passing
of several  -display host:D.S options  to any GNUstep  application and
thus  have the  possibility to  map NSWindows  onto X  windows  on any
screen  whatever the  X  server.  We  already  have a  "pointer" to  a
window, just make it a little bigger and point to a X server too.




For OPENSTEP,  while it  did not handle  several -NXHost, at  least it
accepted one  like -display of  simple X applications, and  while this
was not  a feature directly implemented  by the AppKit,  it would have
been trivial for any Application to connect to several DPS servers and
have windows on them. As trivial as it is with X.





And  if  it  really was  VERY  few  reasons,  if  there was  only  ONE
application  that would  profit of  it,  say, like  an application  to
display flights departures and arrival on fifty screens in an airport,
I think it  would be a great improvement over the  actual state of the
art  and BSOD  generaly  displayed  on these  screens.   Think of  the
millions of travelers who would thank you to allow us to know when and
where their planes will leave or arrive!


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------





reply via email to

[Prev in Thread] Current Thread [Next in Thread]