Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing
> Hi Everybody, > [...] Hi, just don't forget something like : > --8<-- > - picogui > - src (clean source tree) >- tools > - wt compiler > -->8-- To better integrate the widget template compiler as a picogui tool what is currently not obvious. > This new source tree layout emphasizes PicoGUI as a complete system. It [...] > resolve what vidlibs those drivers need, and what libraries those > applications need. Woaw! Good luck! -philippe --- 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
Re: [Pgui-devel] a stupid question on speed on 68VZ328
> Hi all, >There is a stupid question about picogui's speed. >We had head there are many people had use picogui on uClinux based on >68VZ328 in 33MHZ processor. > >We had develop a board that based 68VZ328, and uClinux 2.4.17 kernel, >run in ROM. And build the picogui, modify little codes for support > chinese(GB2312).when run in PC, it's ok, but when run on our board it > seem too slow. there are /proc/cpuinfo of uClinux, Does anybody tell me > the speed of picogui run on other board ?? > CPU:MC68VZ328 > MMU:none > FPU:none > Clocking: 18.2MHz > BogoMips: 2.28 > Calibration:1142400 loops Hi sanit, We have ran PicoGUI on the EZ and the VZ but it's also a long time ago, still with the 2.0.38 kernel... As said Micah, what video driver are you using? Don't try something deeper than 2 bpp... (I think we used 1 bpp) To have an idea about what will be the behavior of the programs on our platform, we used the XCopilot emulator on pc. Is this also what you spoke about when you said "... when run in PC, it's ..."? Unfortunately, I don't have one that works here... but if my memories are right, it wasn't possible to have such informations with the 2.0.x kernel. (or maybe it was something else that wasn't accessible...) Anyway, if I could get some info, I'll tell you. -philippe --- 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
Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing
On Tue, 2003-01-21 at 19:37, Micah Dowty wrote: > Hi Everybody, > > I just wanted to give an outline of the source tree reorganization I'm planning after > the 0.44 release. This is necessary in my opinion for several reasons: > > - The current build system is hard to port to non-linux platforms > - A lot of the code in CVS is arranged in a less than logical way > - The configuration system is hard to cross-compile with for people who >aren't familiar with all the GNUisms involved > - The configuration system doesn't handle dependencies > - The configuration system only configures pgserver > > The reorganization I have planned would involve two major changes: moving the source > tree to a Subversion server outside of sourceforge, and switching the build system, > probably to something based on SCons. This subversion server has about 40GB of >redundant > storage, a 256kbps internet connection, and I'll be able to make offsite backups > regularly. Releases will still be done through sourceforge. > > The big concepts I want to emphasize with the new system are portability, and > configuration of picogui as a complete system. The directory tree will look something > like this: > > --8<-- > - picogui > - README, COPYING, INSTALL... > - build (Intermediate files in compilation) >- x86-dev >- arm-zaurus >- ppc-dev > ... > - bin (final compiled binaries) >- theme >- x86-dev >- arm-zaurus >- ppc-dev > ... > - config (files for the configuration system) > - fonts > - src (clean source tree) >- pgserver >- appserver >- lib > - c > - client > - media > - python > - PicoGUI > - cpp > ... >- tools > - themec > - themedc > - future app packaging tools >- apps > - Only relatively usable apps (pgedit, pterm, scribble, working games...) >- devapps > - Apps that are only useful for developers >- themes > - Relatively usable themes, in their own directories >- devthemes > - Themes only interesting to developers > -->8-- > > This new source tree layout emphasizes PicoGUI as a complete system. It removes a lot > of the confusing things about the old tree: > > - the cli_* naming convention for libraries will be gone, since it can be >confusing. > The new source tree uses directories to organize libraries by language, and the > library should be called the "C client" rather than "cli_c" > > - Clean up the awful mess in themetools/examples. Themes will separated into >generally > useful and developers-only, and each theme's source will be in a separate >directory. > Since svn allows moving source trees easily, themes could be very simply migrated > between the categories. > > - Separate applications into mostly usable, and for developers only > > The new configuration system will still be similar to the current one, but with a few > key differences: > > - It will configure the entire source tree, not just pgserver. Every component will > be conditionally compiled depending on this configuration > > - Dependencies will be managed for the whole system. Outside libraries (libpng, >zlib, > SDL, etc.) will be represented as targets in the config system, as will 'tasks' > that select common options for different situations. The operating environment > (OS and available libraries) for the target platform will be automatically >detected. > > - Cross compilation can be managed by selecting a different target platform in the > config system. It would still support specifying the compiler and paths manually, > but this would remove the pain from cross-compiling to common platforms. > > - Once picogui has app packaging, it will integrate with the config system to >provide > automatic installation of the completed picogui system into a distro. > > - There will be many frontends. If you're only selecting a task or two, you could >use > the command line. There could be graphical configuration frontends for ncurses, >gtk, > or PicoGUI. You could even have frontends that would glue this system to other > config systems, like the ones OpenZaurus or Smartdata use. > > - The config system will make it clear which options you selected manually, and >which > are implicitly selected by a dependency. This will make it easy to avoid using > compile-time options that aren't necessary, so you can make the smallest binary > possible. > > For example, you could start with a blank configuration, then add a "OpenGL game UI" > task, which would include all the widgets, drivers, and vidlibs you would need for >that. > Or you could include a "Zaurus" task that would build the drivers the Zaurus needs, >plus > a "PD
Re: [Pgui-devel] picogui demo applications?
On Tue, 2003-01-21 at 17:45, Micah Dowty wrote: > I just wrote that demo in python because I was in a hurry, it would actually > be very easy to do the same thing in C. The program that loads the pages and > flips between them would need rewriting in C, and you would want to precompile > the .xwt files to .wt files using xwtcompiler.py. After that, the C binary and > the .wt files are self-contained. I have to admit that the xml templating mechanism is not so clear to me. Yes I know about the wiki pages but they made me think it was tied to the python api... Any fast clues? -- Daniele Pizzoni --- Ascensit Linux Solutions email: <[EMAIL PROTECTED]> - <[EMAIL PROTECTED]> --- 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
Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing
On Tue, Jan 21, 2003 at 11:37:56AM -0700, Micah Dowty wrote: >- apps > - Only relatively usable apps (pgedit, pterm, scribble, working games...) >- devapps > - Apps that are only useful for developers >- themes > - Relatively usable themes, in their own directories >- devthemes > - Themes only interesting to developers - demos - apps - apps that are absolutely useless except as a demo - themes - glcube, etc The demos subtree isn't built by default (neither is dev*) []s, |alo + -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ --- 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
Re: [Pgui-devel] picogui demo applications?
On Tue, Jan 21, 2003 at 02:02:40PM +0100, Daniele Pizzoni wrote: > > Thanks for the info, I just missed to check the latest CVS. Anyway I > think python will just not fit into the few megabytes we have. That depends on how much is your "few". I run python and picogui in my PDA with a 10Mb flashdisk. My project could be summarized as "a PDA environment that allows me to write programs in the pda itself", and this is why I wrote the picogui python client library for. My python binary (for the pda) has 1.9Mb; you can make it smaller by not compiling the optionals. (My pda platform does't support dlopen, so I had to build a lot of things built-in; a typical desktop python binary is below 800k.) The only compiled module you *really* need for pgui is _socket (and _expat if you want to work with xml, but as Micah, I advise against it). The (full) library is at 5.4M here; I include only the optimized bytecode files (*.pyo). By selecting just the stuff you need, which requires about one day of experimenting, you can bring this below 500k. That depends on what you want to demonstrate; IMO showing a very readable script, modifying it in-place with pgedit, and then running it, is absolutely impressing ;-) []s, |alo + -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ --- 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
Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micah Just to let you know, I've been using a source control tool called 'larch'. I've found it stable and a better alternative to CVS and also subversion. It's also GPL'ed (for license bigots like me). [link] http://freshmeat.net/projects/archrevctl/?topic_id=52 [/link] - -- Thanks, Aidan Delaney - -- If anyone has both the right and the need to study the code and be assured of its correct functioning, it is users. Whitfield Diffie gpg key: http://tass.cs.may.ie/~balor/public_key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+LnmPJqM6BHYo7esRAlhfAJ95pWNKDHdsOeIgZLDw0nQ1aRHORQCdE4wH HMH7SJbndReM/6wN3Jqj7Q4= =0JCY -END PGP SIGNATURE- --- 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
Re: [Pgui-devel] picogui demo applications?
On Wed, Jan 22, 2003 at 11:02:48AM +0100, Daniele Pizzoni wrote: > On Tue, 2003-01-21 at 17:45, Micah Dowty wrote: > > I just wrote that demo in python because I was in a hurry, it would actually > > be very easy to do the same thing in C. The program that loads the pages and > > flips between them would need rewriting in C, and you would want to precompile > > the .xwt files to .wt files using xwtcompiler.py. After that, the C binary and > > the .wt files are self-contained. > > I have to admit that the xml templating mechanism is not so clear to me. > Yes I know about the wiki pages but they made me think it was tied to > the python api... Any fast clues? The xwt compiler is a module, part of the python client library. However, once you compile the widget template, the .wt file is self-contained and it can be used easily from any language. There are some apps that use this. A simple one written in C is 'picosm'. > > -- > Daniele Pizzoni --- Ascensit Linux Solutions > email: <[EMAIL PROTECTED]> - <[EMAIL PROTECTED]> > > > > > --- > 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
Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing
On Wed, Jan 22, 2003 at 09:33:24AM +0100, Pascal Bauermeister wrote: ... > > It is a good idea to rearrang a bit the whole project. A few remarks: > > * Some projects people live from (I do not speak only about us...) > rely on the current structure, so we must first meet a consensus > on the transition deadline. For instance, switching from CVS to > Subversion is not a blocker, but would have certainly an impact > on our schedules. Right. This is the only reason I've hesitated to do the reorganization this long. > * We also have a dependency system (reason why we bother everybody > with our mdl files ;-) ) which is one layer above autoconf and > co. Our dependency system deals with a lot of various components > (kernel, drivers, libs, 3rd party software, etc. etc.) and > pgserver and some pg apps are among. Your proposed dependency > system should be an alternative parallel system. I advise to > build it also on top of autoconf, so that one still can access > the autoconf level, like before (which may be just sufficient > for some people). I will keep the autoconf system in place until the new system is built and tested plus some transition period, but the autoconf system can't coexist with it indefinitely. It would negate a lot of the benefits of going to a new system if you had to maintain the old one also. > * We can give a lot of hints about difficult > ^H^H^H^H^H^H^H^H^Hinteresting points we faced when dealing with > dependency issues. We for instance separated the platform from > the product aspects. I was thinking the configuration system would have separate settings for CPU, operating system, video, and input hardware- then those could be wrapped with more tasks for each platform. > * The new dependency/platform/product management system should > certainly not only deal with dependencies, but hide some > platform-specific options related to cross-compilation. One > would have to bother about these options only when introducing a > new platform. All this above autoconf ! Yep, the largest part of this will probably be building libraries on all the supported platforms. It will need to support at least Linux, IRIX, MacOS X, win32, and SNOW binaries eventually. I won't be using autoconf, automake, libtool, or even the shell. It will all be pure python built on SCons, for maximum portability and ease of integration. > * I find very good to be able to quickly build a (nearly) complete > system, e.g. for several embedded platforms, or for demo > purpose. We should however still be able to just pick necessary > pieces separately. right. There will be 'tasks' for these complete systems, which through dependencies will select all the necessary options. I envision that when you browse those individual options, it would be clear that they are being selected or deselected via the dependency process. You could override those selections. > * You said: > > - The current build system is hard to port to non-linux platforms > Do you mean target platforms or build platforms ? Build platforms. I've got PicoGUI running on MacOS X and IRIX, and others have run it under win32. It always requires a lot of hacking on the build system. The largest piece of this is the dependency on bash, and all the other linuxisms in the current config scripts. > > Regards, > > Pascal > > > -- > Pascal Bauermeister > Head of Software Development > > SMARTDATA > PSE-B / EPFL > CH-1015 Lausanne > > http://www.smartdata.ch > mailto:[EMAIL PROTECTED] > Phone: +41 (21) 693 84 98 > fax: +41 (21) 693 84 91 > mobile:+41 (79) 456 82 05 > > > --- > 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
Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing
I just spent some more time reading the documentation for svn and for arch. It looks like arch's main advantage over svn is its handling of branches, according to the docs. However, it also says arch is a collection of shell scripts and C code, which seems like it would be flimsy and unportable. On this page, it says that arch is very slow on cygwin, and doesn't work on OS X or 64-bit platforms: http://www.fifthvision.net/open/bin/view/Arch/BitKeeper That is counter to my goal of making picogui as portable as possible, so it looks like arch isn't an option for us. Thanks for the suggestion. On Wed, Jan 22, 2003 at 10:59:27AM +, Aidan Delaney wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Micah > Just to let you know, I've been using a source control tool called 'larch'. > I've found it stable and a better alternative to CVS and also subversion. > It's also GPL'ed (for license bigots like me). > > [link] > http://freshmeat.net/projects/archrevctl/?topic_id=52 > [/link] > - -- > Thanks, > Aidan Delaney > - -- > If anyone has both the right and the need to study the code and be assured of > its correct functioning, it is users. > Whitfield Diffie > gpg key: http://tass.cs.may.ie/~balor/public_key.asc > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE+LnmPJqM6BHYo7esRAlhfAJ95pWNKDHdsOeIgZLDw0nQ1aRHORQCdE4wH > HMH7SJbndReM/6wN3Jqj7Q4= > =0JCY > -END PGP SIGNATURE- > > > > --- > 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
Arch (Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing)
On Wed, Jan 22, 2003 at 11:37:58AM -0700, Micah Dowty wrote: > I just spent some more time reading the documentation for svn and for arch. > It looks like arch's main advantage over svn is its handling of branches, > according to the docs. However, it also says arch is a collection of shell > scripts and C code, which seems like it would be flimsy and unportable. > > On this page, it says that arch is very slow on cygwin, and doesn't work on > OS X or 64-bit platforms: > http://www.fifthvision.net/open/bin/view/Arch/BitKeeper Arch is actually very good (I tried it this morning and will probably adopt it internally); I wouldn't call it "flimsy". However, it *is* unportable; absolutely no-go on any platform that doesn't have a bourne shell. That said the site is outdated, I read in the list archives that it works on OSX already. If you have one or two free hours and want a good laugh, I recommend going over the archives for January, it's better than Will&Grace. Arch has IMHO one *major* advantage: you don't have to use it at all. The repository is structured on two different kinds of versions: a release and a revision. Releases are stored as regular tarballs (therefore you can use the Arch repository as your main download location; it is also easily mirrorable). Revisions are stored as patchsets (essentially a diff file on steroids). So if you're an end-user you just use the tarballs. If you want to track development revisions, all you need is GNU patch and one single script from Arch (dopatch). If you want do do your own development, you could get Arch, but if it doesn't work on your system you could get away with GNU diff and one single script from Arch (mkpatch). So, I'm not sure portability is an issue. What I think could hurt us is that Arch is pretty much a moving target, with two different leaders developing in different directions. But if this turns out to be an issue, we could fix it by sticking to the latest known-working version of Arch (and perhaps storing it ourselves for users to download). I'm still evaluating it, but I *really* like its design and hackability. I recommend installing and evaluating it before you discard it. As an excercise, import the whole pgui source tree and try to move stuff around to the new layout. One bad thing is that there isn't yet a way to import the existing cvs repository (with past history) into arch, while I heard there is something named cvs2svn that does this for svn, albeit imperfectly (potentially). []s, |alo + -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ --- 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
Re: Arch (Re: [Pgui-devel] Subversion, SCons, and reorganizationalizing)
On Wed, Jan 22, 2003 at 07:09:57PM -0200, Lalo Martins wrote: > > One bad thing is that there isn't yet a way to import the existing cvs > repository (with past history) into arch, while I heard there is something > named cvs2svn that does this for svn, albeit imperfectly (potentially). I take that back, there is already such a beast. Go to http://www.fifthvision.net/open/bin/view/Arch/ArchDownloads and search for cvs2larch. []s, |alo + -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ --- 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
[Pgui-devel] Evolution past PicoGUI
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 _
Re: [Pgui-devel] Evolution past PicoGUI
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 pr
[Pgui-devel] Future layout engine
Hi Everybody, After chatting with Stefan on #fresco (and having more chances to feel inferior to Fresco..) about layout engines, I thought I should bring up the topic here. I like the simplicity of picogui's divtree for widget layout. With a little tweaking it should be able to handle whatever apps need, and it results in a tree that's very easy to render and traverse. But what about alternatives? A constraint solver would be nice, and a good step in the direction of UIs that can be defined very abstractly. -- 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
[Pgui-devel] New name.. or not?
Hi Everybody, Not sure why I didn't realize this earlier, but the name PicoGUI could still fit with this new design. PicoGUI's always been a GUI that's coded more like an OS- the new design would be like moving from a monolithic kernel to a microkernel. We'd use an interconnect between the servers that's smaller than your usual microkernel, and it's a GUI, hence.. PicoGUI I still wouldn't mind changing the name if we came up with something really good, but this is a good excuse to avoid the effort of changing everything ;) --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
[Pgui-devel] PicoGUI v0.44 "Polygons of the Apocalypse" released
Hi Everybody, Well, I got tired of waiting on myself to fix all the bugs on my list, so I released 0.44 anyway :) It still includes numerous bugfixes, enhanced OpenGL support, pgserver embedding, and VNC server support. You can find the download and the release notes on picogui.org. --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
