Micah Dowty wrote:
>
> 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.
I would not invest time on and around ui&fx because, due to their design,
the do not encourage to design portable GUIs. Remember that they were
originally aimed at the Palm with 160x160x1 screens. However, this is
currently the only Waba kind of standard, and the only ready and working
API for now. As the Waba community slowly continues to enrich ui&fx, I
would just port any new widgets on top of PicoGUI, with minimum effort,
like till now.
If somebody wants to take full advantage of PicoGUI, why not write in C ?
Waba + PicoGUI, unfortunalely, will unlikely run on several platforms, e.g
PalmOS (no multitasking => no client/server). Sorry Micah !
On the other hand, AWT can be implemented (and is found) on various VMs
with less requirements to the OS.
AWT, even if not taking full advantage of PicoGUI, will give very nice
results on top of it. We could add some Java library (the application could
check for its presence at run-time) to control some PGUI-specific features
like themes, provided the application could also run (ok, less nicely !)
without.
Pascal.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
