That's a good question, especially since I'm sure many people would be prone to ask
"Why another GUI?"
When I started PicoGUI last March I knew about Microwindows. (isn't NanoGUI part of
Microwindows now?) Microwindows is great at what it does: it provides a familiar API
and flexible graphics engine with a small footprint, suitable for many embedded
devices. At the time I started PicoGUI it was only for the Kiwi project, so I had
slightly different goals. I wanted the entire GUI to be keyboard-based (because Kiwi
has no touchscreen) and basically just a way to run a word processor and a game or
two. The low specs on Kiwi's 'ez328 CPU ruled out Microwindows, but as my goals for
PicoGUI changed and matured I realized there were several things about current GUIs
that were unsuitable for constrained computing environments:
--- Widgets vs Graphics
In X-style GUIs like XFree86 and Nano-X, the server focuses on providing graphical
operations to the client. The client can use a shared library to create and manipulate
widgets, but everything is converted to pure graphical primitives for the server. I
wanted PicoGUI to focus on providing widgets. As you might have seen from that
'architectural diagram' on the website, PicoGUI provides widgets in the server, and
virtually everything centers around the widgets. This simplifies the API a bit, but
the most significant thing for me is it makes the client library _much_ more simple as
it only has to bother with networking code and a few support functions. This means
that PicoGUI will run well even on platforms that don't support shared libraries, such
as uClinux. Because of the client library's relative simplicity, it is also possible
to completely rewrite the client interface in another language. You could write a
PicoGUI client in 100% pure Java for instance. Since so much information can be
stored on the server-side, it might be possible for extremely limited computers like
the PIC microcontrollers (where memory is measured in tens of bytes) to act as PicoGUI
clients.
This method makes the whole thing smaller and faster, and provides for better
integration with themes. There are two fairly large downsides to it though. Because
widgets are in the server, clients can't create a true widget themselves. Clients can
still create widgets, but they can't use the same programming interface that internal
widgets use. To create their own widget, they must use graphical operations, which
brings me to the next downside. Because the GUI is so widget-centric, the graphical
core of the PicoGUI server is accessed through a widget, the canvas widget. This is
probably as it should be, but because the graphical capabilities of PicoGUI were
designed with the built-in widgets in mind, they are a bit limiting.
The graphical capabilities of PicoGUI are improving though. I just started making some
major changes to the server that will fix this by adding support for rendering to
offscreen bitmaps, more methods of combining primitives with existing data
(XOR,OR,AND,INVERT,MULTIPLY,ADD,SUBTRACT, and a few more) Another major difference
between PicoGUI's graphics and other GUIs is that primitives are (optionally) stored
instead of rendered immediately. This allows the server to redraw the app without
client-side intervention in most cases, and as soon as I finish a few of these
server-side improvements it will
even be able to scale, translate, and otherwise munge the graphics with little to no
client intervention.
--- Compatibility
A large 'selling point' for many GUIs is compatibility with existing apps. Because I
wanted to try something new with PicoGUI, I almost completely disregarded this.
However, because of Smartdata's port of Waba to PicoGUI this is changing.
--- Window management
PicoGUI has support for modal dialog boxes and menus, but in general it does not
support overlapping windows. Instead, applications live in resizable and
repositionable 'panels' (yep, panels are just another widget) that allow multitasking
but conserve screen space. If desired, panels can be turned off at compile time so the
apps can place themselves statically on the screen, or one app can be run at a time
without resizing. The lack of overlapping windows greatly simplifies PicoGUI's
graphics library.
In fact, PicoGUI's entire layout system all the way from positioning apps to laying
out words in a paragraph is built by slicing rectangles in two to form smaller
rectangles. The entire screen can be represented by a tree of these layout elements--
divnodes-- some of which have an attatched list of rendering instructions. Widgets
simply stake a claim to part of the divtree and insert their own nodes.
---
Well, I must be in documentation mode :)
That will come after i finish these video library changes. (maybe this weekend? no
guarantees though, as I will be busy with a few other things)
Hope that answered your questions! (If not, feel free to ask more)
It's definitely unconventional, but it seems to be working well so far.
On Thu, 19 April 2001, John Utz wrote:
> could you tell me what you perceive the differences are between picogui,
> microwindows and nanogui?
>
> if you dona have any opinion, that's fine too, but if you do have one i
> would really like to learn about it.
>
> tnx!
>
> johnu
>
>
> _______________________________________________
> vhl-tools-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/vhl-tools-devel
--
perl -e'socket S,2,1,tcp;connect S,pack(H16,"0200029a80692d32").\0x8;print
grep!/=/,<S>'
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
