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
