[Fresco-devel] [[email protected]: [Pgui-devel] Evolution past PicoGUI]
Micah Dowty <[email protected]>
| Newsgroups | gmane.comp.video.fresco.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, it's Mr. PicoGUI again :) I was talking about my plans for a new GUI that borrows ideas from picogui and improves them on #fresco, and apparently forwarding this to the list is a good idea. ----- Forwarded message from Micah Dowty <[email protected]> ----- To: [email protected] From: Micah Dowty <[email protected]> Subject: [Pgui-devel] Evolution past PicoGUI X-BeenThere: [email protected] X-Mailman-Version: 2.0.9-sf.net List-Help: <mailto:[email protected]?subject=help> List-Post: <mailto:[email protected]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pgui-devel>, <mailto:[email protected]?subject=subscribe> List-Id: <pgui-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pgui-devel>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pgui-devel> X-Original-Date: Wed, 22 Jan 2003 17:35:26 -0700 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 ----- End forwarded message ----- -- Only you can prevent creeping featurism!