Code generation is the core operation of every GUI builder. Though X-Designer's friendly interface leads you through the GUI design, code generation is the reason you bought it. I think the Motif/C combination for Unix/X workstations is the native configuration. I tried to create a few small GUIs; they all worked and compiled without warnings. All I had to do was manually set the location of the Motif libraries and headers in the Makefile, since I keep them in the /client/lesstif directory. The same applies for the C++/Motif combination, which also worked flawlessly.
Portability is an important issue today, so I set out to explore the Java and Microsoft Windows code generation options. I had a design targeted for a Motif/C combination, and I tried to change it to Java code. Of course, the callback code was useless; I didn't expect X-Designer to translate my C code into Java code, but links also work in Java. The prerequisite for Java designs is to include the path to a set of Java classes, which are provided with X-Designer, in the CLASSPATH variable. The classes are put into the package called uk.co.ist.mwt. They provide components which have counterparts in Motif but are missing in Java. There are also some widgets which are added to the standard Motif set to implement some Java components not present in Motif. They are container widgets, such as the Card Widget, Flow Widget, Border Widget, Grid Widget and GridBag Widget. This enables the WYSIWYG development of Java applications.
Changing my test design for Java required toggling the Java compliance toggle-button under the Module menu. X-Designer then checks the current design, giving you messages about any non-compliant parts. Sometimes the “Fix” button will be enabled, allowing you to trigger the automatic fix for Java Compliance; otherwise, you have to do it yourself. If you know about Java and Motif, the messages generated by X-Designer are more than enough to give you a clue about what is happening. I don't know much about Java, but I know enough to make the design Java compliant within minutes. The Java code generation dialog is different than the C/Motif one in that you must specify which file to create. A file for every class, the top-most application class file and separate sources for string, color, font and other objects are included. Using JDK 1.0.2, I compiled and ran the application without any problems as a Java application. I could have built a Java applet, in which case additional constraints might have popped up.
All of X-Designer's dialogs use the same convention of marking the resources and settings which are relevant for Java. Whenever there is a steaming coffee cup icon next to the resource, it means that it will be honoured in Java code. A very good feature, since at the time you make a change you can note immediately whether or not the change code remains Java compliant.
Using X-Designer for building Microsoft Windows applications is another prime feature. X-Designer must be started in Windows mode to enable this cross-platform development. It can be done via resource, or via running it by typing xdesigner<\!s>-windows. In this case, an additional button is added to the tool bar, to toggle the Windows compliance. The procedure is similar to the one used for Java. If you read an already created Motif design into Windows-aware X-Designer, it prompts you with a dialog containing all the warnings and reasons for Windows non-compliant design. Sometimes it can fix the problems, other times it cannot.
Code for Windows is always generated as C++, in three flavours: Motif, MFC or Motif XP. Motif XP is a set of provided classes similar to Motif, but named to match the Microsoft Foundation Classes. Since Motif is much more flexible and allows more freedom than MFC, the basic task X-Designer must perform is to apply additional constraints on the design to force Windows compliance. This is the only method of MFC code generation. In all the dialogs, a convention is used for the MFC-honoured resources; if the entry field or button is painted pink, it means that the resource is honoured only by Motif and not by MFC.
X-Designer contains very advanced tools for C++ class structure and hierarchy maintenance. A subset of a design can be created as a C++ class, and access control can be applied for any widget member. One can use methods such as callbacks and even create custom preludes into the source code to add additional class members. An interesting feature is definition creation, which can be put on the widget palette as a reusable group of widgets. C++ programmers will find the abundance of features extremely useful, as the class structure becomes the property of the design and can be maintained in cross-platform applications.
All the code-generation options are well beyond the scope of this review, but I am convinced that even though Motif is the native toolkit of X-Designer, Java and MFC support are advanced, and most importantly, they work. For any design information that can be ported to Java or MFC, X-Designer keeps track of it and properly implements it. Every issue is considered, including font inconsistencies, color incompatibilities, different native pixmap formats and problems with long filenames under Windows platforms.
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
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