Christoph Egger wrote:
>> yes, indeed. I did work on some GGI code, and Andreas (and
>> others) did know about it. Andreas did mention a couple of times
>> that I should get write permission to commit my work. I did not
>> get any write permission (beside the sourceforge cvs, where
>> almost nothing relevant has been set up so far).
>
>
> We decided some time ago, we need a seperate modul for each
> extension.
>
> Would you like to create those modules and import the libs into cvs,
> please?
I don't understand. I didn't write an extension, but a new target, which
should reside with
all the other targets, i.e. memory, X, Xlib, etc.
>
>> Oh, the work I was doing is a new target ('ipc visual') that lets
>> me use GGI apps which draw directly into the berlin server (using
>> shm, a semaphore and a pipe).
>
>
> Great! Does it support any other servers than the berlin one, too?
it doesn't 'support' berlin. It's simply a GGI target that has to be set
up correctly to be useful.
The idea is basically the same as the 'shm memory visual', that is part
of the 'memory visual'.
Andreas and I discussed a bit about that in November, and we decided
that the shm memory
feature has nothing to do in the memory visual, but rather, that this
should be extended to be
a complete separate target, with support for serialized access
(semaphore) and a 'need redraw'
callback (pipe). That's what I implemented, and I think it would be
pretty useful for a lot of
situations. In fact, the pretty but useless 'cube3d' applet could use
this. Until now, cube3d just
samples the shm visuals, which is neither correct (there is no
read/write lock protecting the
visuals), nor efficient (it does the repair whether the visuals are
damaged or not).
Since my plans were to provide the foundations for some emulators for
berlin (X, gtk, kde, qt, etc.)
I had an interest into an ipc target that does the RightThing...
Regards, Stefan
