On Thu, 10 May 2001, Shane Nay wrote:
> > The goal is to have the server intelligently resize and (if necessary)
> > reorient applications when new ones are launched, but this isn't
> > implemented yet
>
> Okay, got it. Smart code for dealing with application window assertion with
> regard to sizing is needed. (Or potentially an option as some architectures
> might discourage multiple programs running simultanously) Maybe this could
> be passed off to a window manager type concept..., not necessarily even out
> of process with the pgserver. Modulized..., something. Should probably fit
> in with some ideas I've seen while looking through the archive to have plugin
> type widgets.
>
So, do you mean compile-time modularization or run-time?
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.
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.
> > It would probably be very difficult to do given PicoGUI's architecture. The
> > entire thing is basically one big layout engine, and everything is done
> > with the metaphor of 'slicing off' rectangles from a pool of available
> > screen space.
> >
> > In general though, even if something isn't useful for everyone, if it
> > doesn't break anything I'll be glad to add it as a compile-time option.
>
> My question was actually about those little dialog boxes. Them locking up
> the drawing of the parent I think is acceptable and maybe even "good/correct
> behaviour". So, it's already in place. Another application able to popup
> and freeze another is maybe a bit sketchy..., but I could see a use for it.
>
Yes, it could be a security risk to allow an app to lock out others. This could be
done with something as simple as an infinite loop of message boxes. Maybe a way out of
this is to implement a hotkey to kill an application?
The ability for an application to create popup boxes is definitely necessary. Though
putting an entire app in a popup box might be of limited use (unless it's something
specialized, like a touchscreen calibrator) this capability is the basis for message
dialogs and popup menus. allowing the apps to call pgNewPopup lets them construct
complex menus, for example with icons on each item, or with text across the edge. (see
the menutest demo or screenshots of it for examples of this)
> > Support for specifying the port number on the command line would need to be
> > added to the server, but this is quite straightforward.
> >
> > The client library would need a lot of modification to support multiple
> > connections, but there's no architectural reason why it's not possible.
>
> Right, just some "more work" :). Not too bad though because it's all just
> built on a TCP/IP stack. I have a new question as well, anyone have any
> bandwidth usage for picogui? I'm interested in what sort of bandwidth an
> application would take up normally. (I'll answer my own question if someone
> else doesn't have this info lying about)
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.
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 PIC.
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.
>
> > > Anyway. My plan is to port some Java implementation to pgui. Why?,
> > > because it makes *perfect* sense really..., the server will be native, so
> > > GUI stuff will be relatively fast. Which is a prime problem in embedded
> > > Java implementations. I'm thinking of porting "kawt" (kawt.de) on top of
> > > KVM. (KVM with the Palm CLDC is pretty shady on this sort of stuff...,
> > > I've already managed to bifurcate kawt from the CLDC calls into my own
> > > twisted set of calls which manupulate the framebuffer directly...,
> > > bringing it up a little higher in level to pgui shouldn't be too ugly)ka
> >
> > Actually, SMARTDATA is already working on something similar to this. It's
> > not Java with all it's class library bloat and AWT, but the language itself
> > is almost exactly the same and the libs are well suited for embedded
> > systems.
>
> SMARTDATA? Well, I dunno if AWT is bloated, surely doing the full set of AWT
> is overboard. Kawt's implementation is only a couple hundred k, but they
> don't sweat the details :), I'm not really planning on sweating the style
> details, etc. either. I'm thinking of doing something like MAWT...,
> minimalistic AWT. Not so many options with regard to widget styles, and
> handing over more control to the native enviro for sizing, dumping custom
> "paint() jobs", except for things that extend Java's Canvas. Of course his
> Swingi-ness is totally out of the pgui question.
Well, I don't know much about Java aside from what I've read in a few Java programming
books a while back. The AWT just seems like overkill for embedded applications
>
> > Olivier Bornet has been porting Waba to PicoGUI. At first, this means
> > porting Waba's drawing functions to work on top of the canvas widget to
> > provide compatibility with existing waba apps. There will also be a class
> > library to allow Waba programs to use the PicoGUI APIs themselves. There's
> > information on the Waba project at http://waba.sourceforge.net and the
> > PicoGUI code is under development in the CVS
>
> 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.
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.
>
> As an asside..., after spending most of the night giving myself a headache
> looking over the kawt code, which is all based on java framebuffer bit
> manipulation, I'm sort of taking a different approach. One is to attack the
> GNUClasspath/japhar monster, and replace all the calls to gtk with calls to
> pgui, which is a much more reasonable port. The downside is that
> GNUClasspath/japhar is quite a bit fatter than kvm/kawt. Ah the tradeoffs in
> life... (I think gutting kawt and re-writing a native toolkit is possible,
> but classpath/japhar starts from a more usable frame of reference, plan is
> work on baseline demo with classpath/japhar and then do "something else"
> that's more appropriate for embedded enviro)
Hmm. Yep, I'm not too familiar with Java.
>
> 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
