nanogui: Thread: Progress (or lack of it)

I've spent a couple of hours working on the network code today, and I'm
going to try to keep an average of an hour or two two a day set aside for
Nano-X work from now on (weekends will probably vary between no time at
all and most of the weekend depending on where I'm staying and what I'm
doing at the time though). I did promise to have a look at the GGI driver,
but what I'd forgotten was that I've left it on my home machine which is,
surprisingly enough, at home. I'm going home for the weekend to pick some
other stuff up so I'll be able to get it then, or perhaps Greg might be
able to forward it to the list before then (he has a copy of it)...

I'm planning to spend most of the weekend getting the full 0.5 version
done, including the new networking model which is getting quite close to
being ready for release now. On Monday after releasing 0.5 I'll make sure
the latest code is in the CVS, and the CVS is functioning properly again
(I may have to drop anonymous access until I can figure out how to make
it secure though- the only way I seem to be able to let anonymous check
stuff out is to allow it write permission to everything... oh well). When
that is going properly, people are welcome to ask me for a CVS account,
and all development can be done in there from then on, thereby hopefully
solving the problem of multiple developers getting out of sync. If Greg
posts his code over the weekend, I'll try to get it integrated over the
course of next week and maybe get a 0.6 out the following weekend. By that
point, things should be all nicely synced up again, and the full on
development of window managers, GDK ports, etc. can begin...


--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

Alex Holden wrote:
> 
> I've spent a couple of hours working on the network code today, and I'm
> going to try to keep an average of an hour or two two a day set aside for
> Nano-X work from now on (weekends will probably vary between no time at
> all and most of the weekend depending on where I'm staying and what I'm
> doing at the time though). I did promise to have a look at the GGI driver,
> but what I'd forgotten was that I've left it on my home machine which is,
> surprisingly enough, at home. I'm going home for the weekend to pick some
> other stuff up so I'll be able to get it then, or perhaps Greg might be
> able to forward it to the list before then (he has a copy of it)...
> 
> I'm planning to spend most of the weekend getting the full 0.5 version
> done, including the new networking model which is getting quite close to
> being ready for release now. On Monday after releasing 0.5 I'll make sure
> the latest code is in the CVS, and the CVS is functioning properly again
> (I may have to drop anonymous access until I can figure out how to make
> it secure though- the only way I seem to be able to let anonymous check
> stuff out is to allow it write permission to everything... oh well). When
> that is going properly, people are welcome to ask me for a CVS account,
> and all development can be done in there from then on, thereby hopefully
> solving the problem of multiple developers getting out of sync. If Greg
> posts his code over the weekend, I'll try to get it integrated over the
> course of next week and maybe get a 0.6 out the following weekend. By that
> point, things should be all nicely synced up again, and the full on
> development of window managers, GDK ports, etc. can begin...
> 

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 also
make
some attempt at building an imlib esque thing so we can have some funky 
image file loading and drawing

what we basically need to have done is windoamager suppor t be placed
inito
nano-x even if the calls dont work (ie just the prototypes are there) 
it means that the api can be somewhat completely frozen and the tree
tidied
up.

another thing - i think that we should have two different
types of windowmanager.

1) small one that is statically linked into nano-x if nano-x
is built wiothout netowrking, 
2) no windowmanager linked in but operating on the client end of things.

but i have to say that i can't wait to hack up a small window manager =)

cheers

Chris Ross

-- 
======================================================
| Chris Ross - Boris` on efnet, ####@####.#### |
|      Student, C Code Hacker, HTML,  and more...    | 
|           * Web server down - Back Soon *          |
`----------------------------------------------------'

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/ --------------------

: 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.

	That's definitely the right idea.

 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.

	This was the approach I took for the win32 stuff, and the server
is 35k text, 7k data including the sample application.

	As others have mentioned, if the window manager has a known api,
and is implemented in a separate file, then anyone can hack it if they
don't like it, and it doesn't affect anything else.

: 

Greg Haerr wrote:
> 
> : 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.
> 
>         That's definitely the right idea.
> 
>  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.

the baic core idea was one of the ways that is perhaps the best,
have shard libraies that can be loaded with a few callback funtions
scattred about liberally.

well i have to say that what ever happens i will be hacking up my own 
little windowmamager when a basic one has been created i have some
groovy
ideas.

oh on the imlib front we may be able to get away from that for tyhe time
being, i would atleast like to steer clear of it until 2.0 is realesed
which will basically be a major rewrite. imlib has some fundwemantal
flaws 
in that it leaks here there and everywhere - and on our little boxes
we can't afford these memory leaks =)

chris ross

-- 
======================================================
| Chris Ross - Boris` on efnet, ####@####.#### |
|      Student, C Code Hacker, HTML,  and more...    | 
|           * Web server down - Back Soon *          |
`----------------------------------------------------'

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: ####@####.####