On Friday, October 19, 2001, at 01:50 AM, Pascal Bauermeister wrote:
> 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.
>
Well, I know it wouldn't make sense to use sizing from the themes. But
it could use the theme's fillstyle code to make the Waba buttons look
similar to 'real' picogui buttons.
>>>
>>> - 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.
I know this is Java's goal, but we're talking about Waba :)
Seriously though, I know it would be nice to be able to use Java to
provide compatibility with other systems. But, it would also be nice to
be able to use Waba as an interpreted language for writing apps designed
for PicoGUI. For legal reasons (not wanting to statically link with LGPL
code) and for portability reasons, Waba with a native PicoGUI API would
be a great language for distributing 3rd party apps for PicoGUI.
>
> [ 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
I agree that compatibility with standard object models would be nice,
but I really don't see how these could be used well in PicoGUI. Still, I
think it would be good to have a native PicoGUI API if not for any other
reason than to make it easier to write other object models. The classes
to interface with PicoGUI could be built into the Waba interpreter, and
the compatibility APIs could be written in Waba bytecode. This means
that the Waba interpreter itself could be very small and ui&fx, AWT, etc
could be distributed separately.
>
> 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.
>
Well, my hope is that Waba + PicoGUI will become a more common
platform :)
But if compatibility really is that much of an issue, maybe there could
be classes to allow PicoGUI Waba apps to run on top of the AWT?
>
>
>
>> ... 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.
I don't think it would be that difficult to take the ui.fx support out
of the Waba interpreter and add support for making PicoGUI API calls.
Then, the ui.fx classes could be written in Waba using the PicoGUI APIs.
Other standards like AWT could be implemented in the same way if
necessary.
>
>
> 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
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
