Micah Dowty wrote:
>
> Quoting Pascal Bauermeister <[EMAIL PROTECTED]>:
>
> ...
> >
> > May I just add this:
> >
> > - currently the Waba port using PicoGUI mimics the Waba Palm port,
> > i.e.
> > the object model is the ui and fx classes. Widgets are drawn by the VM
> > directly in a pgui canvas. Layout is extremely simple, mostly by placing
> > widgets at absolute coordinates; rendering does not therefore benefit
> > from the theme system. The whole looks very Palm-ish.
>
> Right. This is good for compatibility... Actually, once there is a way of
> calling PicoGUI APIs from Waba, we could theoretically rewrite the 'ui' code to
> use PicoGUI's theme rendering to draw the buttons. They wouldn't be real PicoGUI
> buttons, but they would look like them :)
> Just a thought.
Difficult, since ui&fx and pgui have a radically different orientation, the first with
absolute placement and the second with container hierarchy with dynamic sizing.
Also, ui&fx being by essence themeless, everything is adjusted by the waba app at the
pixel level, so themes would give bad results.
> >
> > - having an object model that better uses the features of the
> > underlaying
> > GUI system is slightly more complex, as one should either invent an
> > appropriate object model, or better, implement a standard one. Shane
> > Nay has done a port of AWT for another VM (not WABA). Let me also
> > mention the MIDp object model from Sun Microsystems, which has
> > currently no known port on Waba.
>
> Why implement another layer? PicoGUI's API is already basically object-oriented
> C. I'm rusty on the syntax of Java/C++, but you could easily make
> object-oriented bindings for the PicoGUI API:
>
> b = new pgWidget(PG_WIDGET_BUTTON);
> b->Set(PG_WP_TEXT,new pgString("foo"));
> b->Bind(PG_WP_ACTIVATE, myHandler);
yes and no.
Yes: it could be technically possible.
No: because we would have yet another object model. Java's goal is to
provide a virtual platform, with virtual resources, and you don't care
how these are implemented. As a result you cannot access all features
of the underlaying platform.
[ For example, AWT is the common denominator of what was easily
available on Windows, X11, Mac, etc. An AWT applet has a Window-ish
look on a Windows platform, etc. After some years, people where
unhappy with the limitations, so Swing was born, reimplementing
everything and only using canvasses on the host platform; Swing is
therefore huge, memory+cpu hungry, and looks Swing-ish on any platform
(ok, it has themes so you can mimic the look of a couple of OSs). ]
If we want to be compatible with other VMs, we must stick to existing
standard, currently:
- AWT originally for web applets
- Swing not reasonable for small platforms
- MIDp for tiny portable platforms
- ui&fx for waba platforms
You may run waba applets (using ui&fx) on other vms, provided you pack
them with bridge classes implementing the ui&fx classes (above, say,
AWT). Currently, you cannot run AWT applets on Waba. By introducing a
PGUI model, you would have many problems with all platforms, except
the few Waba ones especially equipped with the PGUI classes.
> ... or something like that ...
> PicoGUI's architecture is different from any existing standards, or the whole
> interface would have probably been designed to conform to an existing standard.
> Forcing the API to use a standard designed for a different type of GUI would be
> like using a compatibility layer. Waba already has that, it needs an interface
> to the native PicoGUI API.
Right, so here is my opinion:
- for the time being, start developping with ui&fx; your waba applets
will also run on Palm, Newton, PocketPC, Netscape, Explorer, etc. w/o
source modification.
- Waba may be opened to an existing standard in the future such as AWT
or MIDp, sitting on PGUI or whatever depending on the platform, but
this is currently unavailable.
Regards,
Pascal
--
Pascal Bauermeister
Head of Software Development
SMARTDATA
PSE-A / EPFL
CH-1015 Lausanne
http://www.smartdata.ch
mailto:[EMAIL PROTECTED]
Phone: +41 (21) 693 84 98
fax: +41 (21) 693 84 91
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
