On Sun, 2002-02-10 at 03:22, Micah Dowty wrote: > Hi Everybody, > > The requirements for this system > - non-overlapping application windows > - minimal screen space usage (for example, it would be a waste to > have resizing handles on each edge of a window) > - intuitive user interface! > - customizability > > I found a couple other systems with the same goal as PicoGUI- to > eliminate the extra time and screen space associated with moving around > windows by forcing them to occupy non-overlapping 'panels' or 'frames'. > The user needs to be able to move apps between frames, resize the > frames, and create/destroy them. > > -- emacs > > The most obvious example of this type of system is emacs. You can split > the window, resize, and load buffers using keyboard commands. > > -- ion >
If PicoGUI is targeting embedded devices, the majority of them use smaller screens. I think UI's that try to target this area could be decent "role models" for a UI. There are several examples of these that exist, Microsoft (CE/PocketPC), Palm, and symbian are environments design for smaller embedded devices. We can all name things we like or dislike about each environment but they mostly contain a common theme. When you are dealing with small real estate (160x160 was given as an example) the task you are currently doing should be given the most screen real estate. Take Palm for instance. There is no "menu bar", scroll bars are limited, and they have some custom hard keys to navigate. When you are running an app, it runs full-screen. This is true of the PocketPC and Symbian environments as well, because with countless dollars spent on usability research, the majority of the population gravites towards being able to use and comprehend this model. So I am in favor of a UI that allows being able to focus single applications in a fullscreen environment. The current UI allows for that, although it could be made more straight forward. I believe the tiling that currently occurs is difficult to navigate, as suggested by Phil, but at the same time I don't think that use-model is going to be a common occurence. In general, tiling is useful (IMHO) where you have multiple pieces of information that you want to give about one active screen. Or put another way, you might want to display a clock, current weather, and a stock ticker, while having your "current application" in the foreground. For the most part this will be controlled by the programmer. Of the usable solutions that exist, obviously Palm's model has been the most successful in the handheld PDA market. It represents a good model for hand held devices. Qt has made a similar UI on top of Linux in an attempt to enter that market share. I think PicoGUI has to decide if in fact it's a PDA-style GUI, or smaller embedded device GUI? The reason for this, is because you can't optimize for all solutions. (Look at Windows for an example of how it doesn't scale well across devices.) If in fact PicoGUI is trying to be everything-to-everyone, it won't make it mainstream. Qt took a narrow approach, and one could argue it's been one of the most successful linux gui's to date in embedded systems. I think by Micah putting a stake in the ground there will not be "overlapping" windows, it's not designed for a web-tablet or similar device. I think this is a great choice, as there are numerous gui's that satisfy that space already. (NanoX, tiny X, Qt, etc.) Whatever GUI architecture that is decided on for the "default" environment, currently represented by the pgl-stuff, I suspect that many devices won't fall under that usage model. Take for instance digital cameras, cell phones, camcorders, etc. None of these even have a pointing device, and they represent a huge portion of the embedded space. I just hope whatever solution is picked as sort of the "general use" model, that the gui can be tailored to fit almost any situation in the small embedded device space. (Ranging from PDA's down to watches and perhaps smaller.) I believe this is currently supported by the current architecture as well. (You can have no-height panel bars, you can hide/show apps by changing the height of windows, and the best part of all, this can be decided at run time throug the theme support provided.) After all this is said, the most powerful aspect of PicoGUI is it's theme support. This continues to be one of it's best strengths in the embedded gui space. Whatever architecture is decided upon should continue to put the themeabilty of the gui as it's highest priority. I think the current design does this as well. PicoGUI has been going for close to two years no (from the inception) and one of the most important aspects I see it needs to work on is moving towards stability. In the embedded environment one can't readily download the new version. :) Anyways.. just throwing in my two cents about general directions without giving any specifics. I like Palm's model, as it lends itself to many types of devices. I like the ability to hide bars, but to have them there if required. I also don't see a problem with PicoGUI's actual UI design in it's current form. I think what is more being talked about is the "pgl-environment" in it's current form. Eric _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
