-- Note: I just realized that my email servers have been acting very strangely the last couple days, so I apologize if superfluous mail has been getting on the list... I have been trying to send the below mail for a couple days. I switched mail servers, so now it should work. (my address is still the same) -- I am trying to develop a way for applications to store extra data such as bitmaps, icons, text databases, etc. in an easily managed format. (like the resource files utilized on some other OSes...) i want to be able to give each resource attributes, like name, optimum display resolution, and language so that apps can adapt well to changing environments. I don't like the way most UNIXen sprinkle files all over; if the files necessary for a particular version of an app are grouped with the app it would lose a little flexability but it would be easier for users and eliminate the need for a package manager. I see a few ways to do this, and after discussing it a bit with Brandon I got some extra ideas but didn't really reach a conclusion. 1. A directory accompanying the binary (like for pterm, there might be a directory called pterm.res) The resources could be files in this directory, categorized using file name and subdirectories to indicate the name and other characteristics. A 32x32 icon for english systems might be in pterm.res/en/icon/32 Symlinks could be used to provide a default language/resolution/whatever. This would be simple to implement (in fact I've already written a little of it) and it would rely mainly on features already present in the filesystem. Problems are portability (ain't no symlinks in PalmOS or windows...) and hassle of transporting a bunch of tiny files. Files could be mmap'ed into memory so ROM-based platforms like uClinux would not need to recopy. 2. Compile the needed data into the binary. This seems to be the way many X programs do it, with XBM and XPM files. The main problems I see with this are that on non-ROM-based platforms even unused bitmaps and things could be in memory, and it would be unsuitable with large data. (Game cutscenes, audio data... I'm being optimistic :) 3. Develop a simple compiled resource format, similar to what I've done with the themes. Resources will be stored in one file in an organized way, and they can be mmap'ed into memory when needed. More flexibility could be used than directories, because resources could have plenty of properties and methods to find the right resource. It would be harder to customize the resources for a particular platform (for example, a uClinux PicoGUI app might let you install only the low-bpp icons) but I'm sure a filter program could be put together to do the job. 4. Use a compiled resource format, and let it be included in the binary. This would make for monolithic self-contained apps, like usually one might find in MacOS. Only the actual program would be loaded into memory right away, because the resource would be placed after the actual executable. This would be basically the same as #3 but there is only one file to keep track of. Downside of this is that it would basically output a nonstandard binary file that some tools might choke on. I know that in ELF the resources could just be stuck in an additional section, then read in like a normal file. I don't know much about uClinux's flat binary format, but I assume it would be possible. -- Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;) -- Linus Torvalds _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/pgui-devel
