On Wed, 09 May 2001, Shane Nay wrote:
>
> Pgui-ers..,
>
> Okay, I've taken a somewhat close look at pgui from a purely user perspective
> now, and looked at some of the underlying video frambuffer code. I was told
> about this project from Jay Carlson, and I must say that I'm intrigued with
> the idea of a server side widget implementation. (The idea has always
> intrigued me actually, but I always thought of it in more traditional terms,
> my idea was to have a "normal" server, and a sprite language where you
> install animations and the like into the server) In terms of the embedded
> industry, it makes a *ton* of sense, but whether or not the limitations are
> "work-around-able" is a big question.
>
> (BTW: I think this has a lot more potential than just embedded, in a way,
> it's like a render farm implementation. I don't think it's really good for
> desktops, but for embedded and other cool/wacky stuff)
I'm glad you like it :)
It's definitely non-traditional, but also seems to have a lot of potential.
>
> Okay, questions/comments:
> 1) I noticed that when I had two applications running, while they both
> appeared on the screen, it appeared that only one at a time (the "focus"
> window) was getting CPU time. Like you run the canvas animation, and then
> pop up "some other" program, like the video settings program, and the
> animation ceased. Is this a design goal, or a temporary situation that patch
> fixing it would be accepted into the core of pgui?
Well, there seems to be a bit of confusion surrounding this. Most applications reside
in 'panels' that never overlap but can be resized. I coded the little video mode
switcher as a 'popup', the same container used for message boxes and menus. It just
seemed like a good idea at the time, i suppose... As the vidpopup app is in the
'demos' directory not the 'apps' directory, it's not in it's final form. I'll probably
integrate it later as some sort of applet in a general-purpose control panel.
(Another use for Pascal's idea for named public containers that apps can attach to)
Anyway, this popup creates a new layer, stacked on top of whatever popups/apps were
there before. When a layer is added, the things underneath it are locked, hence
PicoGUI's support only for modal dialog boxes. The canvastst is still drawing (or at
least sending drawing commands to the server) but it has been locked out by the popup.
The reason for this locking is that allowing the layers under the current one to draw
would require supporting complex (non-rectangular) clipping. One of the reasons to use
the application panels was to prevent having to add the complexity of complex clipping
to the video engine.
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.
> 2) Perl bindings..., all I have to say is.., Cool. :)
> 3) I noticed that that applications weren't always asserting themselves over
> apps that were already running. Like when I had some bar running, and the
> canvas animation, then tried to launch the calculator, nothing appeared to
> happen. Although the calculator was running, so either it was waiting for
> realestate, or didn't "assert" itself. (The video program asserted itself
> *over* the canvas in the same situation, which seems to be a negative trait
> given the "no overlapping windows" design goal)
Yes, this is what most apps (that create toolbars or panels instead of popups) will
do. It's actually running, but wedged into the non-existant space between the canvas
app and the edge of the screen. If you resize the canvas app with it's panelbar
(assuming you have panel resizing compiled in) the calculator will appear.
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
> 4) Overlapping windows are generally not usefull in the embedded world except
> for dialog windows..., I think I saw some note for this, but I'm not sure. I
> need it :), if it's not already in, would a patch be accepted for it?
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.
> 5) Given the present architecture, would the following be legal: Can a
> application have access to N numbers of servers, where N is an arbitrary
> number running on distinct machines? Now, same question, but multiple
> servers running on the *same* machine? Now, if it's not possible currently,
> what are the issues with doing it, and would a patch be excepted that "fixed"
> this? (You know, does pgui specify a numbered port for operations, what
> issues within the c connection library would have to be fixed in order to do
> it, etc.)
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.
>
> 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.
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
>
> Thanks,
> Shane Nay.
> (Known limitations: Of course when I say would a patch be accepted, I mean
> if it was written well, my prime question is would the extensions I'm asking
> about be acceptable into the design goals of the pgui team at this time.)
>
> _______________________________________________
> Pgui-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/pgui-devel
--
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
