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)
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?
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)
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?
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.)
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)
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
