Just remembered another few design ideas I had: Right now PicoGUI's widgets are almost completely based on setting/getting properties. I'd like to remove that almost- get rid of pgWriteCmd as used in the terminal, textbox, and canvas.
The whole reason for this inhomogeneity in the current design is that the properties are very simplistic- a single integer or a handle, representing another fairly simple data type. If properties were extended to include lists and observers, the widgets could be made much simpler. For example- the canvas widget could have property you set to a list of primitives. When you modify this list, the canvas automatically updates. The terminal widget would have a data source property that you could set to a stream object, then write data to that stream. Also, right now memory management for picogui clients can be a pain, since you have to keep things like strings and bitmaps around when a widget refers to them. This could be much cleaner if all handles in picogui were reference counted. You could set up a whole tree of widgets and other objects that the widgets refer to, immediately unreferencing the objects you create. Then, as soon as you unattach the head widget, it and all the others would be deleted. On Wed, Jan 22, 2003 at 05:35:26PM -0700, Micah Dowty wrote: > Hi Everybody, > > Lalo might be posting a more detailed mail on this later, but I wanted to get > the idea out into the open. > > For a while now I've been wanting to do a complete rewrite of PicoGUI's > networking, layout, and rendering systems. A quick outline of what I wanted > to do in each, and why: > > Networking: > - Separate the protocol from the underlying requests, so that one > PicoGUI server could respond to clients from multiple protocols. > - Write a new protocol with much lower network latency > - Separate the socket code into the OS abstraction layer > > Layout: > - The current engine uses a 32-bit bitfield to store layout settings, > and it's full! Instead of one massive flags variable, each divnode should > have a function pointer for the layout algorithm it uses, then parameters > defined by that algorithm. > - If there was a thin compile-time abstraction over the coordinates and > vectors used by the layout engine, it would make the code much cleaner > plus allow very easy switching from integer to floating point and/or from > 2D to 3D at compile time. > - Definition of translucent/transparent/opaque regions, for the S2 engine > > Rendering: > - New rendering algorithm based on portal rendering (S2 engine) > - The same coordinate abstraction used in layout > > So, this would amount to a pretty big chunk of code. As we discussed this on > IRC, it turns out there are a few other things that would be good to do: > > - Lalo and I are both interested in refactoring pgserver into modules that > would act more like a microkernel. You would have a widget server, layout > server, output server, etc. All communication between these modules and > between clients would be managed through a thin RPC interface. This RPC > interface could be configured as a straight pass-through to efficiently > link all these modules into one binary, it could be a dynamic library > interface, or a protocol similar to the one we're using now. This would > make code more maintainable, plus allow a lot of really cool things to > happen, such as running the same app on multiple layout engines > concurrently, so one app could appear at different resolutions or using > different themes at the same time. You could create a gecko widget as > a separate module, that could either be linked in with the rest, as a > dynamic library, or as a separate process. > > - I've been idly thinking about changing the name of PicoGUI for a while. > The current name has the connotation of a tiny GUI that's only good for > little embedded systems with very limited memory. This was PicoGUI's > original goal, but for a while now the main focus has been scalability > to very different platforms. After this microkernelization, there will > also be a focus on modularity. We brainstormed a little on IRC and some > names like "uiGui" and "transGUI" emerged, but nothing that's obviously > the right name. > > - The current video driver interface is wonderful in it's generality- > the primitives it defines work well on framebuffer devices, in X, in > OpenGL, or in text mode. However, it isn't nearly sophisticated enough to > handle Postscript or SVG natively. It would be nice to extend PicoGUI's > concept of a layered video architecture into something that would still > handle simple primitives in a portable and easy way, but support SVG and > Postscript on platforms where it's feasable. This could mean providing > optional support for libart in the renderer. > > So, all these changes add up to a pretty big overhaul of PicoGUI. So big an > overhaul in fact, that it would make sense just to start a new project that > borrows a lot of ideas and code from PicoGUI. I'm not abandoning the tiny > embedded systems- features like floating point layout, postscript, and RPC > will all be optional. It will still be possible to compile a GUI server into > a little static binary that only uses integer math and does all the rendering > without external libraries. But the fact that the same architecture can also > handle overlapping, translucent windows, postscript, and a microkernel-like > design will provide far wider scalability for applications. > > Assuming we go ahead with this, the new project will start on new servers, > developed in parallel with PicoGUI. This will cancel the build system and > version control overhaul for PicoGUI. PicoGUI will still recieve bugfixes and > new features. > > Once the new project reaches the same level of usability as PicoGUI, the > PicoGUI CVS will be abandoned (but not put offline) and the PicoGUI web site > will be replaced with a redirector to the new project. > > --Micah > > -- > Only you can prevent creeping featurism! > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
