[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Mon, 08 Jan 2007 17:16:24 +0000 Simon Williams <systemparadox@xxxxxxxxxxxxxx> wrote: > Hello everyone. > > Virtually any program I write I will want to work anywhere regardless of > OS or architecture. Architecture: Easy - anything supported in Debian. OS: Gtk and glib. Take a look at Fink/OSX and Cygwin - two environments that have successfully ported *native* Gtk applications to the two main alternative operating systems. Design your Gtk/GLib program with portability in mind and it can be trivial to port the program to these other environments. Don't omit SMALL architectures from your list either - embedded devices are increasingly important and large interpreted languages like Java or Perl simply won't fit, neither will C#. > Does anyone have any recommendations for libraries to use for portable > programs? libglib2.0-0 libgtk2.0-0 Lots of simple documentation - install dwww on Debian or devhelp elsewhere and then the relevant -doc packages. Use a sensible IDE (Anjuta) and learn the autotools *well* because therein lies the secret of portability. The GNU autotools can seem daunting but if you use autotools to show you where the code is problematic, you'll end up writing portable code by default. Use -Wall and -Werror at ALL times and in all projects. Hunt down every error and warning and fix them, don't work around them. Workarounds are the Number1 reason why applications fail when ported. This method puts more of the portability burden on you at the very time when it is easiest to fix portability issues - before the first release. If 'make distcheck' completes successfully and you implement sensible test case programs for common problems, you can be reasonably confident that the code will compile on any POSIX system - whether it works is up to you. Do NOT attempt to cut corners now to get the first release done quickly - it is always harder to make code portable AFTER release than before. Portable programming is not a race, there are no shortcuts nor is it a trivial task. It needs to be in your mind throughout design and implementation. > The main thing I am looking at for now is a widget set- should I use > gtk, qt or something else? Qt is incredibly difficult to handle in small programs, gnome is bad enough but Qt makes gnome dependencies look simple. Leave libgnomeui out of the equation and you really can't get much simpler than Gtk/GLib. > What about sound? file I/O? Networking? Sound is always tricky - you'll need different libraries for that but they aren't particularly large. Configuration is the hard part. (GConf). I/O? GLib has almost everything you could need, including simple XML and KeyFiles or there's sqlite. Don't use libxml2 as the sole I/O, it limits your portability due to the ever increasing size, keep it as an option for more capable devices. Networking? GnomeVFS - not weighed down with the rest of the Gnome UI libs, it's a small addition to Gtk/GObject/GLib but provides transparent I/O for local and virtual filesystems. What kind of networking did you have in mind? Use as much existing code as possible - most tasks can be done with very little new code, all you need to do is remix it. You can expect to fit all that in a 60kb binary. Take a look at GPE. If you want a query interface with that, I'm inevitably going to recommend QOF which is based on GLib and brings SQL-type object handling along with transparent libxml2 and SQLite backends. (gpe-expenses) Also, keep in mind that it is the DATA that needs to be portable, not just the application. Do not lock the data into a custom backend, do not lock the logic into a custom frontend. Keep the backend generic, keep the logic with the objects wherever possible and keep the frontend simple and flexible. Aaron did a good talk at a past meeting that touched on Model:View:Controller - keep the data in the model, the frontend in the view and the object logic as controller. That way you can easily add a new View and a new Model without losing compatibility with the controller: the data objects. See data-freedom.org for more on data-lockin. I can guarantee that as soon as others start using your program, they are going to want a slightly different view of the data or to export/import data that is currently held in a different model. Live with it, design it in at the start. Expect to handle export and import, no matter what the application, expect to have requests for modified views or systems that can provide alternative views, like XSL/HTML. The worst possible thing you can do in terms of a portability, IMHO, is to require every user to enter all data using the sole frontend and expect them to be happy with a custom backend. (e.g. gnucash). ;-) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpyQPADlyNig.pgp
Description: PGP signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html