Hi again. I thought i might mention some ideas that came up talking with Yann on IRC today:
I'm starting to get pretty excited about implementing the abstract networking interface for PicoGUI. For those that have been fortunate enough to not hear me blabber about it yet, i'd like to replace the TCP/IP layer in PicoGUI with something more modular that would allow several different media to be used for connecting clients and servers. One of these that may be quite useful for embedded systems is the ability to directly link the client and server into one binary. This could even be done with shared libraries much like Qt/Embedded currently does, loading each application into a separate thread. This of course would toss security and stability out the window, but provide an option for systems where stability isn't as important as speed. I've been too busy with theme, textbox, and panel code lately to implement this, but it's cool, so i might do it anyway :) It would be neat to write a library with all the core functionality to implement a grid-based board game for PicoGUI. It would have all the UI functionality for multiplayer, keeping high scores, starting a new game, etc. Given a definition of the various states each square on the board may take on, the library would provide functions for changing the state of each board square and updating the display. This could be accomplished very cleanly using a canvas widget and the PG_MAP_SCALE mode. We could even use theme fillstyles to draw the grid squares, so that games could easily use themes to define their entire look complete with vector graphics. Yann suggested two nifty little games we could port, overflow and ataxx. Here are linux implementations of both if you're not familiar with the games: http://freshmeat.net/projects/overflow-thegame/ http://pressibus.org/ataxx/unix/gbgataxx.html Another interesting idea that came up when talking about the web browser implementation: (Eric, you here? ;) I had previously been planning on having the web browser app handle higher level HTML tags like images, links, and forms. It would convert them to low-level commands before sending them to the textbox. For example, to process the <img> tag it would load the bitmap from the internet, then create a bitmap widget and insert it into the textbox. The new idea that came up was to have the textbox process the tags and use events to signal the client to perform tasks the server cannot. For example, to process an <img> tag, the textbox widget would insert an empty bitmap widget and store the <img> tag's contents temporarily. It would then send an event to the client with a handle to the empty bitmap widget and the tag. The client could start downloading the image, and when it's finished, load it and display it in the bitmap widget. Scripting like Javascript would still be implemented on the client side, but all HTML formatting including objects that require extra loading could be implemented on the server side. Another advantage to this method would be that HTML with images could be used by any applciation, not just the web browser. An app could use HTML on its about box or help page, for example, and load images from a local file or even from a theme property. The possibilities are exciting :) Well, that's enough rambling for now... -- Micah _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
