nanogui: Progress (or lack of it)
Subject:
Re: Progress (or lack of it)
From:
Alex Holden ####@####.####
Date:
18 Jun 1999 08:27:09 -0000
Message-Id: <Pine.LNX.4.04.9906180847210.27734-100000@www.linuxhacker.org>
On Thu, 17 Jun 1999, Chris Ross (Boris) wrote:
> sounds very good - i think once we have gregs stuff merged with your
> tree i can treult start on the gdk port, i shall also be proting gtk as
> i go along. ( i will call them rgdk and rgtk - reduced = r ) i shall
That sounds great, as long as it'll be able to run standard GTK+ apps
without too much porting effort. Perhaps the bits you cut out could be
(as a debugging option) stubs which do:
sprintf(stderr, "Application called unimplemented function foo()\n");
So most applications could be straight away linked against the debugging
version of RGTK+, and then we could use the combination of the error log
and what parts fail to work as a guide as to exactly what needs to be
altered...
> also make some attempt at building an imlib esque thing so we can have
> some funky image file loading and drawing
Heh, I was about to say, "does anything need doing to get imlib working?"
(I thought it just loaded images and converted them into different
formats in memory), then I decided to have a look at the source ;) It
looks like it could be quite a bit of work to port, but very useful all
the same.
> another thing - i think that we should have two different
> types of windowmanager.
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/ --------------------
