Thanks Micah,
> I'm glad you like it :)
> It's definitely non-traditional, but also seems to have a lot of potential.
Agreed.
> So, for the (long-winded) answer to your question, it's not a good thing,
> but if the vidpopup was implemented properly in the first place it wouldn't
> matter much, and the solution to it would add unnecessary complexity to the
> server.
Okay, that makes sense. I saw that the app was of type popup later, and
noticed that it seemed to have quite different behaviour as the other
applications.
> 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.
> 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.
> 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)
> > 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.
> 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 :).
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)
Thanks,
Shane Nay.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
