On Mon, 26 March 2001, Pascal Bauermeister wrote:
> ...
> Concerning native format for image loading, I had a discussion with our Gnome guru,
>Fred. I'll come back to this topic ASAP, but it seems we can postpone this point.
I have been considering a few options for this.. It seems the Gnome project uses
mostly XPM and PNG? XPM seems flexible, but a bit wasteful in an embedded system
context. PNG is nice, but probably too slow to decompress?
I know the BMP format fits the specs nicely: supports a palette, supports RLE
compression. We could also just make a new format, but it would be nice to have
something the Gimp will export to :)
>
> Fred is also our autoguru (i.e. autoconf and automake), and he said this project is
>a typical case where these tools are very well appropriate. Among other good things,
>this can allow to compile for multiple plateforms/configs by changing .config, but
>without recompiling everything after a config swap. I'd like to let him setup the
>auto{conf|make} environment and commit when done. Micah, what do you think about this
>and giving him a developer access ? his login is "gobry"
Done.
As long as PicoGUI is still very configurable at compile-time, I'd be glad to have a
better build system!
>
> We did not manage cascading the 90� rotations, i.e. 180� and 270�. A hint ?
Well, this is more of a rumor than an actual feature... (I think brandon
misinterpreted me :)
Main reason this isn't possible is that the video library only supports one video
wrapper at a time. Besides, this cascading would make a lot of confusion between
logical/physical coordinates. I just need to make video wrappers for other angles.
This should be pretty simple.
>
> Concerning canvas drawing, let me first announce a cool news:
> ******** WABA port on pgui is ongoing ! *********
> Olivier Bornet, our Waba guru (and SF admin) has started porting waba.ui/waba.fx
>using the canvas widget. He's practically done, but he'd like one option for the
>canvas: just being a simple pixmap, w/o grops. I don'k now what you Micah recommend:
>an option for canvas, or a brand new widget, say 'pixmap' ?
How about a command for the canvas that renders a node immediately without storing it,
like (IIRC) X usually does. I suppose you would still need a way to save what's
onscreen, so it would be nice if it could automatically take a bitmap snapshot of the
canvas before moving it...
I have been planning a pixmap widget, that will let the app use shared memory to go
fast graphics. Problem with something like this is that you can't use the existing set
of primitives.
Does the Waba VM have a way to ask the app to redraw itself?
If not, maybe what's necessary is a better interface to the existing canvas widget, so
it acts like a traditional graphics interface with pr
imitives that render immediately, but it automatically stores what's necessary.
>
> This usage via canvas is a first port for the current Waba object model. It's rather
>a shame with a GUI system such as PGUI, but it will anable compatibility with
>existing apps. The final goal is to let Waba really use the various widgets and take
>advantage of layout management, themes, etc.
>
Yeah.. I'm hoping for a 'compatibility' interface that will emulate Waba's class
libraries with a canvas widget, but also a native PicoGUI interface where it's
appropriate.
--
Only wimps use tape backup: _real_ men just upload
their important stuff on ftp, and let the rest of the
world mirror it ;)
-- Linus Torvalds
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
