Hi Stefan,
> ok, here are some things I consider important, i.e. which I would like
> to see in GGI (eventually). Please tell me whether you agree and whether
> you think it might be possible to include it in the next release.
TNX.
> * visual update feedback (through named pipe or unix socket)
> add a fifo to the shm visual structure, and implement the ggiFlush
> functions such that the repaired region is reported back through the
> channel, if desired.
> The initializer string could simply be completed by a token "-p:<name>"
> or "-s:<unix sockaddr>" indicating whether the client wants feedback
> and if so, what transport.
> If nobody else is working on that one, I'm probably putting my hands on
> it myself shortly. This would be essential if we want to provide a low
> level emulator for porting X applications to berlin.
O.K. - please reconsider this one closely, if you really think it is a
good idea. Doing so would induce a bunch of possible problems:
- stalling the attached application when the pipe gets full
- handling of signals
- many apps are pretty dumb about updates and flush often or are SYNC. You
would need to pre-optimize drawing from multiple entries in the pipe
in many cases.
- it doesn't solve the locking problem - i.e. you can have a "half baked"
picture in the shmvisual, as taskswitching may occur at any time.
- it adds an extra dependency to the underlying OS.
Considering these points - do you still think this is the best idea ?
If yes, I'll implement it for you.
I will think about an alternative in the meantime. I'm considering something
that goes inband through the shm area, just like the events do.
I am thinking along the lines of a struct that gets updated with a
"changed region rectangle" and that has a spinlock that gets released in
ggiFlush() only. That would allow to run the parent only while ggiFlush()
is active.
I got to look into SYSV-IPC message queues as well - maybe one can use them.
The idea there is, to at least avoid the extra dependency. If we have SYSV-
SHM we very probably also have the messages ...
> * physical size of a visual
> as I once proposed, it might be desirable to know the visual's physical
> dimensions. Lots of applications need such information, so it would be
> best to provide that info at a low level instead of requiring every
> application to provide a calibration tool. Some devices provide that
> information, in which case you could simply use that to fill in the
> visual.size part. Else provide some means to read that information from
> a central configuration file (probably together with other necessary
> data
Yes. 120% agreed.
> This requires some thought / design, so I'm not going to do anything
> without your suggestions / feedback.
O.K. - what do you need to know ?
> > > >> * Remove _ggi_malloc and friends, use true error handling.
> > --- Pending. If someone with insight
> > --- into the LibGGI internals has some free time - get at it.
> what would you like to be done ? replace _ggi_malloc with std malloc ?
_ggi_malloc() is basically "malloc or panic". This should be avoided and
replaced by using malloc, checking the returncode and bailing out cleanly.
This is nontrivial in some places, as you got to undo other stuff in
some places, then.
> on a more administrative note: I'd like (as I pointed out) a distribution
> to contain multiple packages, at least a separation between the basic
> parts (libGII and libGGI plus target plugins) and the extensions.
I have started this. Hope ibiblio liked my new scripts. We'll see that
somewhen this morning ...
I haven't separated out the targets for source distributions (doesn't
make much sense IMHO), but we will for binary ones. I'll see if I can
make a build system for RH rpm packages.
> May be they could even get independent version numbers. In fact, some
> of the extensions are rather new (XMI, for example), so it would only
> confuse people to find them in a package with version number 2.1...
Yes. Releases have always been that way. I am working on making the snaps
a bit similar.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
