How one arrives at these answers can have profound impact on the financial and political health of a company, not to mention the mental health of the developers. Concerns include the overall architecture, which tools to use (and how they ought to be used), which languages to use where, and, of course, the ever-looming pipe-dream of cross-platform portability.
In this article, your bubble may be burst since there will be no magic bullet offered. No such bullet exists. What will be offered is an analysis of the concerns that are faced in developing large Motif applications. The author will not (and should not!) presume to make architectural decisions for the reader, but, rather, will help the reader to make their own decisions in the most informed manner possible.
It seems sometimes that there are more tools than user applications in the Motif market. There are two factors that have made this so: the unwillingness of other developers to make products for anyone other than their own kind (who wants to understand the end user?), and the notion that developers must simply have more and more tools. Surely the task will be utterly impossible without some high-level tool, won't it?
In the minds of many managers, the "tool" does all the real work while the developer merely turns the cranks and levers. Thus, investing in the "tool" is more important than investing in the people using the tools. Several problems arise here: rather than making the developers more expert, the tools often insulate developers from learning processes which would have otherwise occurred, stunting the growth of developer skills. Also, methodologies built into the tool by the tools' vendor are often imposed on the developer, not because it was the right thing to do, but just because the tool is being used. So the user is not only prevented from learning the underlying technology they use, but also restricted in having any say in methodology, since this is often dictated by the tool. The end result: a high degree of productvity in making mediocre software.
C++ wrappers: while it is quite desirable to move ones development from C into C++, it does no good unless C++ is used well. Thus, it may not be of much benefit to wrap Motif widgets into C++ wrappers, since widgets have a good object oriented design already. Novice C++ programmers might not improve much upon what Motif already offers. Wrapping Motif in C++ is worthwhile only when it clearly improves the object oriented model of the overall product.
Cross-platform: it is very popular now to make cross-platform portability a paramount goal. This often leads to skewed priorities; being "portable" over Motif, Windows, Mac, and whatever often overshadows the overall quality of the product. Many "cross-platform toolkits" limit the ability to use the robust features of a given windowing system, and also intoruce more overhead. Cross platform portability, in the truest sense, cannot be fully achieved without sacrificing quality of user interface designand performance. Idiosyncracies of the toolkit often complicate development, thus stealing away any alleged "saving" in development time. The moral of the story: being platform portable is not a virtue if the end product is poor; you just have lousy software on more different machines.
The priority of being cross-platform, how to become cross-platform, and where one ought to be cross-platform, must all be carefully considered. Cross-platform portability especially is not a magic bullet, it is often a can of worms.
Market value of a platform: this often overshadows the User Interface value of the platform. Often marketing decisions are made such that a product should be moved to a certain platform, but no attempt is made to fit the product into the style guide of that platform. Moving software from XYZ to Motif is of limited value unless the features of Motif are used well. User Interface quality is not the place for technological shortcuts. The end user should not be short changed.
Cross-platform toolkits: often show glowing prospects in small demonstration programs. But when used in a large complicated product, the Style Guide for any given platform tends to be compromised more and more. The end result: rampant compromising of Style Guide makes the larger application unbearable to use. Windowing systems were supposed to make thngs easier, remember?
Archaic data models: When porting old non-graphical software to Motif, archaic data models are often carried over. The entire user interface design can end up being driven by this data model (or a command line syntax). The resulting product is often no better than the original. This older architecture is typically very modal and must be overhauled in order to use the full features of Motif.
Often a personal favorite language, design, or tool will be used at the expense of future maintainability. A prima-donna employee or a closed-handed consultant can steer a group towards a technology that they alone understand. While this is very good for that individual, it can be disastrous for the group if that individual leaves. Only consider technologies that the existing staff can assimilate. Secret skills do not make a good foundation for software.
Advanced software designs are often used, not so much because they will make a better product, but as an interesting intellectual exercise. "Wouldn't it be cool to use C++? Doesn't everybody else?" If the existing staff is not yet ready for C++, then using C++ will most definitely not be cool. This is not to diminish the likes of C++; advanced software techniques are great, but only after the staff is trained to use them.
Failure to overhaul old character based products is a favorite shortcut, but the loss in user interface quality is tragic. Once again, the end user is short-changed in an inexcusable way.
A body of code can also be written in a language other that C++ (probably C), but it may already posess a level of modularity and design quality such that converting to C++ will not yield much benefit. One might be better off to leave the code in it's current language, or, perhaps, to mix languages. For example, an old core of functionality written in C could be simply cleaned up and made as modeless as possible, but new code for a Motif user interface might be written in C++.
When a GUI builders' data files are incorporated directly into version control it makes automatic builds more difficult. This is due to the fact that the GUI builder output will almost always require some manual change, no matter how small, in order to build the product to satisfaction. Each new update of version control undoes those changes. Automatic builds become agonizingly manual.
Some GUI builders introduce new layers of API, as an "improvement". These new layers impose more overhead, require more learning of non-standard technology, entangle the product to the GUI builder vendor, and seldom introduce benefits the developers could not have made themselves.
The best GUI builder, in the humble opinion of the author, is the least intrusive. It allows rapid prototyping without trying to control other aspects of development. It spits out code which can be cleaned up and rolled into the development process, leaving the GUI builder behind.
The underlying engine should have strong encapsulation of it's data and be accessed by a well-defined API. Also, no data types or references to the windowing system should occur in the engine, these should only be in the User Interface. This makes porting to another platform easier, one must simply reimplement the User Interface layer, and that can be done using the full rich features of the windowing system in question. While this is more work than using a watered down "cross-platform virtual toolkit", the opportunities for User Interface quality are greater.
Multiple Instance models: if an adequate object-oriented design is used, then more than one instance of some data can be supported. This can offer vast new power to a user over an older non-graphical user interface. For example, rather than loading one image, document, chart, or whatever, at a time, the user could be allowed to load as many different images, documents, etc. as they wish, each in a separate window. To achieve this, the underlying engine must be smart enough to support an unlimited number of sets of data. Many engines can only focus on one set of data at a time, thus only one image or document could be displayed at a time with any meaningful engine support. A more robust engine would use some sort of "handle" to identify what set of data it was working on, and the User Interface would reuse it's presentation functionality once for each set of data, with each instance presenting a different set of data.
Document-View models: there are several variations of this object-oriented model, but they all have the same theme - allow many diverse "views" of a given set of data ("document") to all exist at once, typically, each in a separate window. For example, a "document" might be a set of data describing some numeric data collected from an instrument; there could be several "views" that could simultaneously support different presentations of the data. One "view" might be a graph window, another might be a spreadsheet window, and so on. Each view would give some sort of presentation of the data, and some views might change the data. the document and all views would send and recieve messages between themselves so they all could have updated knowledge of the data. This model requires some work, but it allows excellent functionality for the user and extensibility for the developer.
Assuming you wish to have an applciation framework, what should it contain? First of all, it should provide strong support for your chosen architectural model(s). For example, if you are using the document/view model, than a useful application framework might contain functions that help to manage the creation and deletion of documents and views, no matter what kind they are. Also, document/view messages could be facilitated by such functions.
Enforcement of Style Guide is another important feature in an application framework. Suppose your application framework has utility functions to help build popup dialogs. The functions might automate the construction of certain repeatable parts of the dialogs, like the Motif-compliant action area at the bottom of the dialog.
Encapsulation of tedium is an essential part of an application framework. For example, widgets whose state control the sensitivity of other widgets can have this behavior automated by clever utility functions that install context-independant callback functions.
All these can save much coding. One can purchase existing application frameworks, some of which offer excellent object-oriented models, or one can create their own, customizing it to their exact needs. It is not an excessive or difficult task to make an application framework of your own, and you can then have greater control over your own destiny since it is your own.
Does that old code need an overhaul? Almost always, the answer is yes. Just prior to porting into a GUI is an excellent time to do such an overhaul, since the GUI requirements will help to correctly guide you in your overhaul strategy. You can pay the price now or later. Do the overhaul now.
Managers who lack technological savvy are sometimes mislead by advertised promises of GUI development tools. The message the manager gets is this: "I use to take five man-months to write an application. Now I just take five hours - well, I'm off to the beach now..." The guy in the picture looks happy enough. Did the ad make inflated claims. Perhaps, or perhaps not. The point is that the manager got this message for whatever reason. And, hungry for easy answers and technological shortcuts, this message is exactly what the manager wanted to hear.
Add to that the managers reluctance to train the developers since that would impact their schedule, cost more money, and, heaven forbid, make the person more viable in the job market. The end result: a manager who invests in tools, not people.
Clearly not all managers do not fit this bleak picture. But the author has seen some who have, and it is a problem the software industry must reckon with.
This author believes that investing in the skills of the developers should be the first priority. It is better for both the company and the employees.
When a novice is given a tool, the tool may allow the novice an artificial boost in productivity, but the workmanship of the novice will very likely not be enhanced by the tool. The novice will simply create mediocre results faster. Further, the tool will tend to insulate the novice from having to learn anything, so they are actually held back in their learning process. The tool can end up having a disturbing crutch-like quality.
In contrast, the expert with a tool can use the tool for some benefit, but often the expert finds some deficiency in the tool, unnoticed by the novice, that impedes their work. The expert is thus frustrated by the tool in their effort to achieve their greater level of workmanship.
Furthermore, the expert often gets little gains in speed from the tool, since their deeper knowledge of the underlying technology makes them more efficient in the first place. The classic example is the expert who, by virtue of their well-tuned convenience functions, can make a menu more rapidly in code than with the tedious interactive process of the GUI builder.
By offering interactive techniques, tools are not always faster than expert people. They are only easier for a novice to conceptualize. The real problem, therefore, is the novice level of the developer. And the solution recommended by the author is clear: invest in the person first. Train them well. Let them become an expert. Then, if they see value in a tool, get the tool.
Look for real-world cases where a given tool or approach worked, or even better, where they failed. Understand the reasons why, and then determine if the other organization is similar enough to your own to expect the same results in your own.
Don't believe everything the ads promise. Also don't believe what the magazines say, not even this one! Scrutinize the views and recommendations set forth, incuding my own. Remember, we may offer expert opinions, but they are still opinions.
Finally, your most valued assets are clear goals and expert people. These should be your first priorities. Clear goals will help you stay focused on what really matters as you go through the myriad of techno-hype that is out there. Expert people will make better decisions and products, often just as quickly as a novice with a tool.