Bailey O.H.Embedded systems.Desktop integration.2005
.pdf
110 |
Chapter 4 / Designing Cross-Platform User Applications |
|
|
compilers. I have not worked with the product so I cannot compare it to the Emacs and Borland products.
A Final Word about Free Software
During the course of writing this chapter I had some issues regarding cross-platform development using the GCC compiler suite. I wound up contacting the Free Software Foundation office because my emails were being bounced back undeliverable to the addresses on their web page. There was no acknowledgment of the problem, only a statement that the addresses should work. I was also informed that all of the developers donate their time and it is common for two to three weeks to elapse between a question being asked and a response being sent.
This is a very serious consideration when choosing a commercial product versus a free product. This caused me to go back a second time and take a closer look at the email address problems. When I took a closer look at some of the web pages, I noticed that some had not been updated in several years. I also noticed that some of the links from those pages were no longer active.
The Cost of Free
Taking the above experience into consideration, anyone using free software has to determine the real cost. While the software may be obtained free of charge, a three-week delay in a commercial project does not go without cost. Anytime a problem is encountered time is at stake. The time to research the problem has costs, the time to attempt a fix has costs, and even the time spent searching for the right person to contact has a cost. When you acquire a commercial product, the company that sells that product promises its support. While support may not be free, at
Chapter 4 / Designing Cross-Platform User Applications |
111 |
|
|
least there is a single point of contact. It is very important to understand these hidden costs.
Shareware — The Middle Ground
While on the subject of commercial versus free software I want to mention the middle ground — shareware. With shareware you can acquire a free demo or trial product to use. If you like the product, you can purchase it; this also includes developer support. Over the last 10 or so years I have purchased several shareware developer tools (mostly libraries) for use in commercial products. I might add that the products I have purchased have come from all over the world including Russia and Japan.
My experiences have never been negative. I have found that support for these products rivals, and in many cases exceeds, the support of commercial software vendors. I would not hesitate to use or purchase a shareware product for commercial use.
Chapter Summary
In this chapter we have explored the options and concerns with developing cross-platform compatible applications. As we’ve seen, there are several approaches that can be taken for developing applications from a single-source code base that can run on Windows, UNIX, Linux, and other operating systems as well. In the end a developer will probably choose one of the following techniques:
Cross-platform languages that support developing consistent user interfaces and code base for multiple platforms (Kylix/Delphi, Kylix/C++BuilderX, GNU tools, etc.)
Developer libraries that provide consistent functions, methods, and user interface components on multiple platforms (Qt, wxWindows, etc.)
Chapter 4
112 |
Chapter 4 / Designing Cross-Platform User Applications |
|
|
A combination of developer libraries and visual designers (Zinc interface library)
There are options available even in cross-platform development compilers, tools, and libraries.
Chapter 5
Developing the
Desktop User
Application
Overview
In the previous chapter we explored the concerns and design considerations of designing cross-platform user applications. In this chapter, we will design the end user application. When we have completed this chapter, we will have a completed design specification. Remember that we are still in the design phase, so the implementation details have not yet been introduced.
Functional Requirements
Now that we’ve reached the traditional information technology layer, we need to stick to the rules of the road for a user application. That means we need to have functional requirements that are well documented. There are two reasons for this. First, there may be distributors who wish to either develop their own user
113
114 |
Chapter 5 / Developing the Desktop User Application |
|
|
applications or assist the end users in developing those applications. As a result, the documentation will serve not only for operating the system but also as a road map to developing a user application from scratch.
The function calls needed to communicate with, monitor, and control the thermostat are already defined, so our task now is to take that information and put it into a functional visual package that can be easily operated by the end user. We still have a few choices to make regarding the user interface.
Multi-Language Support
No, I don’t mean C and C++. English, Spanish, and other languages are routinely used in software development these days. If the interface will be available only in English, the text for the user interface components can be hard-coded during the visual design phase. If other languages will be supported, then we need to use a separate file that can be easily translated.
Chinese, Japanese, and Korean Language
Support
The Chinese, Japanese, and Korean languages differ from English in more than just phonetics and visual design. For instance, the Japanese language can have up to 13,000 different characters. There are several special considerations to support these various languages. First, the U.S. character set is relatively small when compared to the Far Eastern sets. To allow for the display of all foreign characters, a two-byte or Unicode character set is used. This allows up to 65,536 different text characters to be displayed, which is more than will be needed. To support the entry of these characters from an English-type keyboard, a software component known as an input method editor (or IME) is invoked. The function of the IME is to display character options and allow the user
Chapter 5 / Developing the Desktop User Application |
115 |
|
|
to select the proper character based on the context of the sentence.
Far Eastern languages require twice as much memory for storing messages that are displayed, and the screen metrics change because the number of characters in the message increase. To deal with this challenge, smaller characters should be used to display user messages. Help files also need to be translated, again keeping in mind the changes in message size and required storage.
Graphic or Text Mode Based Application
As we’ve already learned, all of the supported platforms provide both textand graphical-based interfaces. Since that is the case, what are the deciding factors? Let’s compare the text and graphical interfaces.
Text Mode Interfaces
It may appear that implementing a text mode interface is easier than using a graphic interface. After all, using block graphics has to be easier than graphic text fields, right? In the past that may have been true, but with today’s high-resolution monitors and fast processors, implementing a graphic user interface is just as easy. Text mode displays were used for years because graphic displays were expensive and processor speeds were not able to handle the processing load. Text mode interfaces were also popular because they limited the amount of data needed to draw a screen of data on a remote terminal.
Several things have changed since those days. First, try to purchase a text mode (or monochrome) monitor for less than a color display. Today, even if you could find a green, amber, or white text mode monitor, they are considerably more expensive than high-resolution color. Second, compare the average speed of
Chapter 5
116 |
Chapter 5 / Developing the Desktop User Application |
|
|
a computer today to one 10 years ago. 66 MHz Pentiums were common 10 years ago; today, 2+ GHz are standard. In short, today’s computers are roughly 40 times faster than systems of just 10 years ago. Finally, operating systems today have the necessary developer tools that make writing graphic-based event-driven applications much easier. In fact, the developer tools available today in most cases have no text mode counterpart.
The Modern Graphic Desktop
Okay, so using a desktop manager or graphical user interface is the method of choice. What products are available to developers that support cross-platform development and work on multiple platforms?
There are many ways of developing graphic user applications on one or more platforms. In the previous chapter we examined cross-platform-specific options and considerations. The following sections look in detail at choices applicable to our specific project.
The Microsoft Windows Operating
Systems
By limiting our development support to Windows NT kernelbased systems, we have the ability to retain a high degree of control over not only the application but the operating system as well. Windows NT, 2000, XP, and Server 2003 all allow the developer access to the pre-emptive task scheduler. This was not available in Windows 95, 98, and ME. Because of this, task scheduler applications are much less likely to crash the operating system should an error occur. Even if we use a desktop manager that is available on Windowsand UNIX-based systems, all API calls on Windows will eventually be processed by the Win32 API. With that in mind, the remaining considerations are the amount
Chapter 5 / Developing the Desktop User Application |
117 |
|
|
of memory consumed and how much processor overhead will be incurred.
Memory Usage
Microsoft Windows loves eating memory. If memory were junk food, Microsoft would win the award for the world’s most obese operating system. It seems that every time I add another 512 MB of RAM, Windows consumes it on power-up, burps, and asks for another helping. The fact is pretty graphics come at a hefty cost in memory usage. With this in mind, let’s compare the levels of application code using a graphic framework, a desktop manager, and native executable program.
Developer Libraries and Tools
As we’ve already learned, a graphic framework allows a developer to provide a consistent user interface on multiple platforms by translating native API calls into a uniform set of calls accessible on all supported platforms. Some of the more popular graphic frameworks available on Windows are the following:
Qt library
wxWindows library
Zinc interface library
GTK+
Qt Library
The Qt library from Trolltech has been around for several years. In fact, the Qt library is what provides the cross-platform visual components their foundation in Borland Delphi, C++, and Kylix products. The Qt libraries provide consistent interface components on Windows, UNIX, and Linux platforms, offering one solution to single-source cross-platform application development. The application is linked to these libraries statically when compiled. When the application is executed, the Qt library calls are
Chapter 5
118 |
Chapter 5 / Developing the Desktop User Application |
|
|
translated into native calls for the operating system on which the application is being run. A separate binary image of the application and libraries is required for each platform the application is distributed on.
The following illustration shows how the Qt libraries fit into the memory management of Windows.
Figure 5-1
By looking at how the Qt libraries use Windows memory, we can see they reside in user memory, which is shared with the application and interface directly to the Windows API. You will also notice that the Windows API resides partially in user memory and partially in kernel memory.
Figure 5-2
Chapter 5 / Developing the Desktop User Application |
119 |
|
|
This image is a screen shot of a program developed using the Qt library that is running on Windows XP.
wxWindows
Like Qt, wxWindows is a library that provides a consistent “look and feel” wrapper for the end user and also provides a consistent API that translates native API calls for the developer.
Figure 5-3
The memory model of wxWindows is identical to the Qt library. The main difference in these products is how they are licensed. The Qt libraries support both the GPL and commercial licensing schemes. This can be complicated for developers and can lead to a license violation by simply selling a single product. The Qt libraries also include a graphic designer, where wxWindows is supported by several third-party products, both commercial and free. wxWindows is a free product, so selling your first copy will not put you in license violation. There is also one more big difference: wxWindows supports the C++ language exclusively, while Qt can be used with a variety of languages including C, C++, and Pascal.
So how do applications developed using wxWindows look? Figures 5-4 and 5-5 are screen shots of Windows and UNIX versions of an application developed using wxWindows.
Chapter 5