On Wed, 2006-04-26 at 16:12 +0200, Cesc wrote: > I agree on all the advice you are given here ... > My experience is that it is not piece of cake, but it can be done. > Test often and plan compatibility since the very beginning. > Then, i would recommend you take a look at other projects which are > cross-platform and you borrow from there ... for example, i am > involved with MiniSIP (www.minisip.org), which is builds on linux, > win32 and wince. The approach is to isolate OS dependent calls in > compatibility layers (in minisips case, libmutil and libmnetutil), so > you have a stable API which compiles the appropriate code depending on > the platform.
Definitely doing your own this abstractions is very important. This doesn't always mean making lots of #ifdefs and #defines, or wrapper functions either. In many cases this means you've completely separated your backend code from your frontend (the UI). If you completely modularized the backend to the point that OS-specific things can be compartmentalized into their own modules which can be selected at compile time, you will be much more successful. I believe this is a better approach than trying to limit yourself to the most common denominator c library calls. For example I have written one program that uses asynchronous socket i/o. Because of the design of the backend code, I can move my state machine engine to threaded-i/o without a lot of problem for platforms where that may be better (just an example that's not necessarily relevant). One thing I find that helps make the backend more portable is heavy use of glib (the underlying utility library from gtk). This can allow you to do file i/o on a variety of OSes and file systems and not worry about things like path separators. For areas where glib doesn't cover directly, like socket i/o, having an OS-specific module would be needed. On the frontend, GTK does provide some portability and abstraction that works well on Windows and Linux, but not so much on OS X yet. For this reason I have been using Qt a lot lately, since Qt 4.1 is now very native on Windows and OS X. But if your target is X11 and Win32, gtk works very well. However it is not always a good idea to tie your UI (gtk) so closely to the backend that it would not be possible to change out the GUI down the road and use something else (something native for example, like, heaven forbid, win32). Abiword chose this route. The backend code is shared between platforms but the UI is, to my knowledge, specific to the OS. I have written several programs recently in Qtk (and Qt) with the intention to run them on several platforms and, having planned for this from the beginning, have been quite successful. For just a little bit of effort up front (which turns out to be good practice anyway), you'll find the transition from platform to platform to be relatively simple. Makes me wonder why any application developer would ever intentionally tie himself to one platform regardless of that platform's market share. Michael > > Good luck! > > Cesc _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
