nanogui: Progress (or lack of it)
Subject:
RE: Progress (or lack of it)
From:
Joe deBlaquiere ####@####.####
Date:
21 Jun 1999 14:20:49 -0000
Message-Id: <80466C8694A9D211A82D0060972BED440E85D4@rebel.wirespeed.com>
I've been following this discussion for a while. I've downloaded a few
snapshots and peeked around, but I hesitate to muck up other peoples code
until I understand how everything works. ;-)
Something I did once sounds like it might give you the flexibility and
performance you want. If you were to develop a 'nano-x-core' shared object
you could let your 'nano-x-winman' run as a linked-in shared object on top
of this core and then your 'nano-x' shared lib could provide message
dispatch, etc and wrap up the two other .so's. I think it would work with a
static libs also but you'd have to re-link (but not re-compile) to change
window managers.
Just an idea...
--Joe deBlaquiere
-----Original Message-----
From: Alex Holden ####@####.####
Sent: Friday, June 18, 1999 3:27 AM
To: Chris Ross (Boris)
Cc: ####@####.####
Subject: Re: Progress (or lack of it)
---CUT!!---
You want to have both? I was hoping we could settle on one or the other
(and I prefer the linked in type myself because that model is both faster
and more efficient, and would still work on very small systems)...
Advantages of "linked in" model:
Low latency between server and window manager.
Lower memory requirements.
No networking needed.
No multiple processes needed.
Disadvantages of "linked in" model:
Uses same address space, so bugs in the window manager can crash the
server and the memory requirement of the server is larger (might be a
problem on machines where address space is limited to 64KB).
Could have licensing problems if we're not careful.
You need to recompile the server to change WMs.
Advantages of "seperate process" model:
Theoretically, if the WM crashes the server should stay up, though how
usable it would be is debatable.
It uses a seperate address space which could be useful if we have a tiny
memory model.
You can keep several WMs around and change them by altering which is
started by your WM startup script (though it's so small anyway, it
probably wouldn't be too impractical to just keep several servers around
in the "linked in" model).
Disadvantages of "seperate process" model:
If you want it to be able to intercept every event (so it can grab key
combinations for it's own use, control focus based on mouse movements,
etc.) it'll use a lot of bandwidth, slowing the whole system down.
You need networking support.
You need more memory than with the "linked in" model.
You need multiple processes.
The server will take longer to start up (if it has to start two processes
instead of one).
I've just had another thought, we might be able to get away with one
configurable, modular, window manager. Ie. all the bells and whistles such
as a screen saver, background image loader, config script parser, focus
policies, window placement policies, etc. are all configurable parts of
one linked in window management engine. There would probably always be
some basic core (probably no more than a few KB) which does nothing with
events except perhaps intercept some key combination which tells the
server to exit, has the most basic window placement and focus policies
possible (might as well shift the focus responsibility to the WM), etc.
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
