ZooLib is not quite complete. What's provided works very well, and it is extensively debugged and I think ZooLib author Andy Green architected it brilliantly. But there is room for improvement and completion.
Among the work needed is:
The menu bars provided by ZooLib on Mac OS, BeOS and Windows are wrappers around the menu bar provided by the OS GUI toolbox. XWindows does not provide such a menu bar built-in, and one remains to be written.
I'm sorry, but that's the bad news - you can't have menus on Linux yet. You'll have to stick with buttons for your Linux UI for now.
There are a couple ways one could do this - one way, perhaps quickest but least desirable would be to create a similar wrapper around the menu bars provided by Gnome or KDE. This would get some people working soonest and would suit some developers but would cause undesirable library dependencies and the licenses may not be suitable for some developers.
The other way would be to implement a menu bar from scratch. It is thought that this could be done without doing naked XWindows programming, but by having the menus that are created be ZWindows populated by lists of ZSubPanes.
This would have the added benefit that the menu bar could be used on other platforms, particularly new platforms that also did not provide a menu bar, and we could tune the appearance and performance of the menus to suit our needs.
Resource files are used in ZooLib to provide application UI data, such as graphics for buttons (usually stored in BMP resources). You can also store your UI text in resources to make localization easier.
Resource files are used here in the sense that they are on the Mac OS, BeOS, and in Windows programs - a chunky file format containing arbitrary slabs of binary data which you can fetch via type and ID. Please don't confuse this meaning of a resource file with the meanings it may have in other contexts.
Resource files are a highly platform-dependent thing and POSIX just doesn't provide them. The Mac OS provides resource files in a rich way.
This is clearly needed for full functionality on POSIX platforms but it's not clear how to implement it. While we can certainly append data to the executable file (or store data in the ELF format on platforms that use ELF, and similarly for other platforms with extensible executable formats), there is the problem of finding the executable file to be able to read it in.
It would be easiest if we just had a file descriptor for the executable file, but we don't. In fact, with POSIX file permissions it is possible to be able to execute a file while not having permission to read from it. There are ways to figure out the pathname a program is executing from, and this is one of the ways we are investigating to solve this problem.
Of course, we will also need an actual file format to use for our resource files and code to implement reading from them, and building them on POSIX. We don't expect to support writing to resource files from ZooLib at all.
So far ZooLib really only works properly with plain-ASCII text. This is already a problem for an application that needs to display text with diacritic characters, and of course non-latin characters like Russian and multibyte characters as used in the national languages of Japan, China or Korea don't work at all.
We're well aware of this limitation and are starting to architect a solution to it. It is hoped that the solution will be able to draw on libraries available from other sources in a flexible way, that is, it may be possible to plug-in different character set transcoders.
ZooLib as it stands works very well for the core functionality needed by an application, network server, or database server. It would be very helpful is carefully architected classes were contributed by ZooLib users to make it easier to do higher level things.
For example, using the ZPaneLocator class to layout the widgets in your window is a very powerful and flexible concept. But it would be very helpful if certain common kinds of layout policies could be codified into reusable classes so they could be tossed into the program wherever necessary.
It takes some thought and extra effort to create a class that can be fully useful both in the original program it was created for and for other programs written by other people. It is helpful to think in terms of creating reusable components from the very start, not just when you start writing a ZooLib application, but when you write any program - in this way you can gradually build up a technology base, which you may keep for your own use or share with the community as open source.