Well, if a good method of uniquely identifying the widgets (converting a name or ID to
registration function pointer) can be worked out, dynamically-loaded widgets would be
a good compile-time option. It could be a lot like compiling modules for Linux.
As far as the Java goes, throughout this project I've been focusing on doing things in
new ways rather than on compatibility. Hence the unusual API. I think Waba's a good
compromise that gives even the low-end hardware I'm primarily targeting some measure
of compatibility.
Still, I think compatibility with the Java AWT is a Good Thing. It's not something
that had been high on my priority list, but if you have a use for it we can always use
more compatibility.
On Fri, 11 May 2001, Shane Nay wrote:
>
>
> > So, do you mean compile-time modularization or run-time?
>
> Both :). Like apache.
>
> > Compile time options would be great, a lot like the optional panelbars are
> > now. Changing application managers at runtime wouldn't be too hard to
> > implement, but I don't see how this is useful. As far as moving this
> > functionality to the client side, I'm against that. One of PicoGUI's goals
> > is to have as much functionality as possible in the server. This is why
> > widgets and themes can be so tightly integrated with the server.
>
> You'll not hear complaints from me on that.
>
> > What do you mean by plugin type widgets? I assume you mean widgets that can
> > be loaded from shared libraries? This would be a nice compile-time option.
> > I want to make sure it's still possible to compile widgets into the server,
> > though, because some architectures like uClinux don't support shared
> > libraries. There are also other issues. Right now a widget is created by
> > referring to a numerical constant, and calling widget method functions
> > looked up using a function pointer table. Loading widgets dynamically would
> > need some way of referring to them by name, or by assigning unique IDs to
> > widgets somehow.
>
> What I mean is that, you compile up picogui, and you can add widget libraries
> via shared libs later. I.e. install them in the server. Without that, it's
> unlikely that picogui would ever be cast in ROM. (And ROM is much less
> expensive that Flash, although picogui is small enough that it could be
> tucked in a flash area..., but better is extendable)
>
> As far as shared libraries go, I agree, they should not be necessary for
> PicoGUI. It should be something that is optional, and can extend the
> funcationality of the application. You mention that uClinux doesn't have
> shared lib support, but another argument against forcing it to be part of the
> architecture is that some flavors of linux have support for sharedlibs, but
> they are *exceptionally* slow. For instance MIPS has real issues with PIC
> code when it comes to performance, and PIC is a requisite for dlopen() and
> friends. (Well, you could get around it with a maddening scheme, but...)
>
> > Don't know when I'll get around to doing it, but PicoGUI's IPC will
> > eventually become modularized, so the server can support many protocols and
> > the client can pick the best one. This will allow connection using TCP/IP
> > for network transparency, domain sockets for communication within the same
> > machine, shared memory for transferring blocks of data, or even linking the
> > server and client into one binary.
>
> Well, server & client in one binary is a dead end road I think. Having the
> ability is nice, but there are other things that do this pretty well.
> (Microwindows for instance) PicoGui's strength is in it's implementation of
> that seperation.
>
> > I also envision an 'IPC' method that would allow the server and client to
> > communicate over a serial port. This would let you use an embedded box with
> > similar CPU power as a Palm Pilot (like a chipslice, ucSimm, or even an
> > actual Palm pilot) run pgserver, and connect to embedded controllers
> > through the serial port. Because the PicoGUI client is fundamentally very
> > simple and so much memory requirement can be offloaded to the server, I bet
> > a client could run nicely on a very cheap microcontroller like the P C.
> > Embedded systems with very low-end CPUs could still have GUI interfaces by
> > making a serial connection to a more powerful system with an LCD or CRT.
>
> Yes, that is what I've been thinking about of late.
>
> > > Right, but using the canvas sort of gives up the benefits of using
> > > picogui over "something else". Then again, in many peoples eyes using
> > > native widgets gives up a lot of benefits of Java..., but those people
> > > tend not to be working on 50Mhz and below hardware :).
> >
> > Well, that's mainly for compatibility with Waba. I bet that with a little
> > hacking of the Waba class libraries and some method in pgserver of
> > embedding widgets within a canvas, it would be possible to make Waba
> > applications use PicoGUI-native widgets when possible.
>
> Right, creation of peers for native widgets.
>
> > The main reason Waba is good for SMARTDATA's Dragonball-based Chipslice
> > (and many other platforms PicoGUI might end up on) is that Waba apps are
> > already written with low-end hardware in mind. Waba mostly targets PalmOS
> > and WinCE, with emphasis on PalmOS. This means that by porting Waba to
> > PicoGUI, they can have a huge base of available applications written in
> > Waba in addition to PicoGUI-specific apps.
> >
> > The same thing could be said about Java, but given the target hardware and
> > existing apps, Waba seems like a good choice for what SMARTDATA (and
> > everybody else working on a linux-based handheld) is doing.
>
> Maybe. But you are also taking away one of the main benefits of Java, and
> that is programmer familiarity. Waba does not implement many things that
> Java programmers expect. It cannot use much of the large body of code that
> is already out there (GUI wise). So, everything must be written from
> scratch, or much of it re-implemented. Some would argue this is eventual
> because of the platform, but that is not really true. (Okay, with a
> dragonball, it is, but with a higher power handheld, no)
>
> > Hmm. Yep, I'm not too familiar with Java.
>
> Heh, well, if I had my choice, I wouldn't be either.
>
> Thanks,
> Shane Nay.
--
To the systems programmer, users and applications server only to provide a
test load.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
