Re: TODO

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. the core library can be compiled independently of the targets, so there is no essential need for the targets

Re: [Berlin-design] GGI Event forwarding

I found the bug in GGI::Visual that was preventing events from being forwarded; had to fill in the event.any.target field, or it was discarded by ggiEventSend. strange. Why is this needed ? Events are sent to visuals. No. Events are sent to the GII subsystem. You need to set

Re: TODO

Hi Stefan, - 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

Re: TODO

I agree that it would be the most straight forward to include the target drivers into the package containing libgii and libggi. I propose a split into three: * libgii/libggi + basic target drivers (should be considered stable) * kgicon (should be considered stable) * extension libraries such

Re: [Berlin-design] GGIMesa updates

"Jon M. Taylor" wrote: I just committed a bunch of GGIMesa fixes to the Mesa CVS tree. It _should_ all build just fine again, but I have weird libtool and autoconf incompatibilities popping up which are preventing the final library install so I can't test it over here. If someone

Re: is libggi2d still supported?

Hi, On Son, 29 Okt 2000 17:40:28 [EMAIL PROTECTED] wrote: Hello, ... I vaguely recall reading at the mailing list archives that libggi2d was considered more or less obsolete; is this so? I'm afraid this is true: On Mon, 18 Sep 2000 21:22:08 Andreas Beck wrote: ggi2d seems

Re: TODO

In reply to Andreas Beck [EMAIL PROTECTED] I didn't say it can't be done, but it just doesn't make sense. A quick check says that a whole LibGGI tree is around 600k compressed. Now when I pick out the autoconf stuff, which won't split well, but needs to be duplicated for all targets, if you

Re: ggi_malloc and friends [PATCH]

Lee wrote: diff -r degas-old/lib/libggi/default/ramdac/visual.c degas/lib/libggi/default/ramdac/visual.c 51c51,53 vis-palette=_ggi_malloc(256*sizeof(ggi_color)); --- vis-palette=malloc(256*sizeof(ggi_color)); if(vis == NULL) return GGI_ENOMEM; You

Re: TODO

On Mon, Oct 30, 2000 at 09:49:33AM -0800, [EMAIL PROTECTED] wrote: In reply to Andreas Beck [EMAIL PROTECTED] Of course. Though I think it would be best, if someone with a .deb based system would make them. He can test them ... yeah, i'm in a .deb based system and i have no idea on how to

Fwd: Undeliverable Mail

On Mon, 30 Oct 2000, Stefan Seefeld wrote: Lee wrote: diff -r degas-old/lib/libggi/default/ramdac/visual.c degas/lib/libggi/default/ramdac/visual.c 51c51,53 vis-palette=_ggi_malloc(256*sizeof(ggi_color)); --- vis-palette=malloc(256*sizeof(ggi_color)); if(vis

Re: TODO

Hi, even if the size doubles, as with your last suggestion, i don't see a big problem. you will have a bunch of separate files, but -- nothing says you can't have a ggi_all.tar.gz file, which has everything. Yes - but also double size. I don't see how one could easily make a autoconf