XForms: Review and Tutorial
The listings show only the tip of the iceberg of as far as XForms' possibilities are concerned. For the sake of brevity, I did not address subjects such as color definition or font selection.
One thing you will want to try is making resizable forms. Whether a form can be resized is defined in the call to fl_show_form(), which displays the form. How the form is resized is defined in the form definition itself. Again, you should use fdesign to set these options. For example, you might have a form with a button and an input object at the top, and with a browser below thrm. When such a form would be resized, you'd probably want only the browser to expand or shrink, not the button and input object. Such capabilities are set with objects' resizing options and gravities. XForms, and hence the designer, supports “object groups” for this purpose: you can group objects and define the resizing options and gravities to apply to a whole group.
Another useful property of any X program is the ability to let the user overrule settings of the program via command line flags, resources set via xrdb, or resources set via an application defaults file. XForms supports all of these; fl_initialize() can be used in combination with fl_get_resources() to scan for meaningful flags or resource settings. Implementing the resource recognition is not entirely trivial but goes beyond the scope of this article. If you're interested, look at some of the programs built using XForms. The XForms distribution as well as the WWW resources contain pointers to useful and illustrative programs.
Naturally, there are lots of other useful XForms possibilities. I leave it to you to read through the excellent documentation on a quiet evening with a glass of (virtual) beer.
Needless to say, I am very enthusiastic about XForms. The setup of the XForms toolkit (using forms, objects, classes) is very intuitive even when you have no previous experience with X programming at all. You do need good knowledge of C, though.
The range of object classes in XForms is so wide that I haven't (yet) needed to define a free object class. If you plan to write everyday programs, XForms probably has the classes to suit your needs, and the classes have plenty of dedicated functions to make the objects appear the way you like.
As far as the designer is concerned, I have come to cherish this tool, even though I first regarded it as just a flashy extra. The ease with which you can adapt a program to perform an extra task, by expanding an existing form to hold, say, an extra button, is incredible. No more code editing to adjust the coordinates of all widgets!
There are, of course, drawbacks. I think it's a shame that XForms is not distributed with the full sources. The fact that XForms can be used free of charge for non-commercial applications is of course a huge advantage, but still, I'd rather have the sources at hand. This irritation can be overcome if you're willing to pay the price: the authors do sell license agreements that include the source files.
Another drawback is that if you do not use the ELF-based version of XForms, you have to link your programs against a static libforms.a. There is no shared a.out-based library for XForms. Therefore, unless you migrate to the ELF executable format, even the smallest program turns out to be about 130KB. (On the other hand, I also use statically linked Motif programs. The 130KB is, by comparison, trivial.)
The XForms library is “nice” to programmers, which is an advantage when you are a new user or when you're developing a program. For example, when a program tries to remove a form from the screen which is not on-screen in the first place, XForms will pop up a warning window. You are then presented with three choices: to ignore the action, to abort the program, or to suppress such warnings. This feature is very handy when you are testing a program. However, such safety nets add “superfluous” code to a program. Once a program has been tested, such precautions are, in my opinion, no longer necessary and therefore only a burden. Ideally, I'd prefer two flavors of the XForms library: a developer's version with the full safety features and a production version without them. On the authors' part this would require only some #ifdef/#endif compilation directives in the code.
On the whole, I find that there are many more advantages to XForms than there are disadvantages. I use XForms now and I'm planning to continue to do so. I still haven't hit a wall in my X programming efforts that could not be overcome using XForms' own features. And I haven't even explored all possibilities of XForms yet.
Karel Kubat lives in the northern part of the Netherlands and is currently working on his PhD thesis. He is a Linux fanatic and therefore pretends to know everything about the subject, since that's what being a fanatic is all about. He can be reached via e-mail at the University of Groningen at firstname.lastname@example.org.
- Android Candy: Google Keep
- Readers' Choice Awards 2014
- Handling the workloads of the Future
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Synchronize Your Life with ownCloud
- Days Between Dates?
- diff -u: What's New in Kernel Development
- Computing without a Computer
- December 2014 Issue of Linux Journal: Readers' Choice
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane