The Importance of the GUI in Cross Platform Development
OSF/Motif is a set of commercial libraries and widgets built on top of X Toolkit Intrinsics (Xt) which in turn is built on top of Xlib, the lowest layer of X. Motif, in my opinion, is just adequate. Creating applications with Motif is tedious, and from the user's point of view Motif is also just passable, nothing to get excited about. Unfortunately, it is Motif, rather than something technically excellent like Fresco, that the commercial UNIX vendors have declared the official UNIX GUI standard (along with the Common Desktop Environment, CDE, which is built upon Motif) under the auspices of the Open Group.
However, just being declared a standard doesn't make it so. Many people dislike the mediocre quality of Motif and use other solutions for programming X applications. And since Motif is not free, it is not very widespread among Linux users. The vast majority of X applications included in Linux distributions do not use Motif. So, regardless of the Open Group's decree, Motif cannot really be considered the obvious native UNIX GUI library the way Win32 is for Windows and QuickDraw and the Toolbox is for Macintosh. The best that can be said is that most toolkits for X tend to provide a look that is somewhat similar to Motif.
Motif does have one advantage, though; it does provide the ability to create much of what you will ever need in a GUI for your program, even if it takes a lot of time and effort. Motif has much of the functionality of that last 10%, such as full keyboard control, a resource system to customize widgets, support for internationalized input methods and fonts and for threaded programs.
There is a free implementation of Motif available, called Lesstif, that is just becoming usable for some applications. It still needs work to provide the coverage that the latest version of Motif (2.1) has, however. There are commercial versions of Motif for NT, although they are expensive, so it is possible to use Motif in a cross-platform application. I believe Xlib and Xt have already been ported to NT, and theoretically I suppose Lesstif could be ported, which, again theoretically, could provide a free solution on NT.
GTK is the GIMP ToolKit (see LJ Issue 47), the widget library used in the free image manipulation program the GIMP. (See LJ, Issues 43, 44, 45 and 46.) The most interesting thing about it is that it seems to be gaining some momentum in the Linux free software world, as more and more projects are using it. Perhaps most notable is GNOME, a project to create a unified, consistent graphical desktop environment built entirely on free software.
In the software world, momentum is often more important than technical design, so GTK is worth investigating for that reason alone. Not that GTK is technically bad. It is a fairly low-level toolkit, written in C, so it doesn't provide a lot of high-level support. The attempt to use object-oriented design implemented in C creates a lot of busy work in the code that is somewhat distracting. However, because it is written in C, it can be used by almost any language, and there are already bindings for C++, Guile, Scheme, Objective C, Perl and probably others. This is no doubt one of the reasons for GTK's popularity.
The design seems reasonable. It is not as flexible as Fresco, but at least it gets some of the basics right, like having a button contain a widget rather than a character string. It also provides layout using horizontal and vertical boxes, which although I found the methods not as intuitive as the TeX inspired boxes and glue of Fresco, they still provide a reasonably straightforward interface.
For handling events, GTK uses a system of signals and slots, like Qt. The C++ interface to GTK, known as GTK--, also provides a nice implementation of the signal/slot methods using templates, an improvement over Qt's macros.
GTK is still immature. It lacks support for full keyboard control, a resource system, unified printing interface and internationalized input and display. It also is currently only for X. It is implemented on top of a low-level, thin wrapper around some Xlib functions, called GDK. This may make porting to other systems easier, although if the wrapper is so thin it requires Xlib semantics, it may be harder. I include it here because ideally the best Linux GUI toolkit will also be a cross-platform GUI toolkit. I hope that as GTK matures into a more obvious choice for a Linux GUI toolkit it will also become a more obvious choice for a cross-platform solution, and we won't have so much fragmentation and duplication of effort.
In short, I have found no obvious winner among the various toolkits. I'm using Java and the Swing package now, while investigating GTK and others in more detail. Ah, yes, I am still dreaming that Fresco will rise again, Phoenix-like, from the ashes.
Michael Babcock has been using Linux since 1992. His programming interests include multi-lingual software (especially Chinese and Japanese), parsing techniques, graphics and anything that will help improve and promote Linux. He enjoys playing basketball, playing the guitar and listening to The Fall. He expects to graduate from the University of Montana in May 1998 with a bachelor's degree in computer science. He can be reached via e-mail at firstname.lastname@example.org.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide