KWWidgets/Projects/UIDesigner/Application/GraphicalUserInterfaceToolkitChoice

From KitwarePublic
Jump to: navigation, search

Determining which graphical user interface tool-kit/library to use

    A preliminary, brief and private study with the purpose of determining which is the graphical user interface that best fits to implemente the 'KWWidgets UI-Designer'’s frame-work was undertook. Even-though the first impulse is to use the KWWidgets library, rigorousness was proved necessary before taking such important decisions, for instance the comparison study of existing user interface designers and its results will certainly provide our application with a firm and solid base and robust,well-designed features.

    Just like the study comparing existing user interface designers, this study could not --and did certainly not ;)-- focus on every single existing graphical interface out there, it restricted to the following tool-kits: gtk+, qt, java, tk and obviously KWWidgets. Besides the results obtained from this study, the arguments listed in the FAQ of the main KWWidgets site were taken into account.

Evaluation criteria

    Among the criteria to evaluate were these arguments:

  • Portability: Does the tool-kit run on different platforms?
  • Licence limitations/restrictions: Is it open source, free of cost, under which restrictions?
  • Integration of KWWidgets widgets: Possibility to integrate widgets as per-se?
  • Extra library dependencies: Is the tool-kit dependent on other libraries?
  • Extra system charge: Using the tool-kit results on memory and CPU usage overloads?

    At the end of the study the balance honored the first decision of using KWWidgets to implement the designer's frame-work. But, as any decision taken for this project the last word is said by the KWWidgets team, so the results were submitted for approval.

Results

Portability
The tool-kits evaluated are all portable over all major platforms: *nix, Windows, Mac OS/X, Solaris.

License limitations/restrictions
They are all free software. But license restrictions apply to Qt if you want to develop proprietary software.

Integration of KWWidgets widgets
This was the major issue which influenced the choice of KWWidgets.

There would be just way too much effort to "wrap" the integrity of all KWWidgets widgets, which are C++ wrapper of tcl/tk widgets, into any of those tool-kits. Wrapping the wrapped that smells bad as a two-layer used dipper ;).

Besides that, two important points come up:
  • having the real look of the KWWidgets every where in the frame-work makes the user most 'cozy'. It would be weird to have, let's say, a gtk+ theme all around the frame-work, while the KWWidgets forms/widgets, the user is working on, will have another one. This could be quite disturbing/frustrating for the end user and it doesn't seem IMHO to be an ergonomics compliance.
  • if we are thinking about developing an user interface designer for the KWWidgets library, it is more than reasonable to use the KWWidgets library and let the both projects grow hand in hand: Glade was conceived to build gtk applications, as Qt Designer for the Qt library, and they have evolved over the year as "sibling" projects. It would have been *hilarious* to see Qt Designer developed in gtk+ ;)
It is certain that as of today's date KWWidgets is not as "robust" as gtk+, Qt or Swing/AWT, which could be a potential draw-back, but one must recognized that it is already quite a powerful and well-defined-targeted library and over the years it will hopefully/certainly grow as(or more) powerful as the other libraries.

All that being said why start off with a Qt, gtk+, or any other 'alien' library based designer, which will over the years need to be ported to the KWWidgets library? Why not make it right from the first try?

Extra library dependencies
This is another important point to take into account. If decision is made to use another library than KWWidgets, there would be more dependencies to fulfill in order to compile and run the application, while on the other hand using just KWWidgets will not cause this trouble.
Think about this: why do one always chop off fat from meat? Same principle applies to software, use only what's useful, meaningful and strictly necessary. That is the beauty of simplicity.

Extra system charge
Conceiving an application not exclusively running with KWWidgets will need extra memory for the runtime of other libraries, like gtk+, or for the VM of Java and extra CPU for the Java VM interpreter. This might not apply directly to Tk though.

Even though today computers are getting more powerful over the years, a good conceived and implemented application should not be gluttonous in any way, this is an argument taking more and more prominence in the software market. --To my mind comes the 'eternal' duel between Gnome and KDE, which as today's date Gnome leads with is incredible memory management improvements for their 2.14 version.--

The faster and smoother our application runs the better end-users will like it. Besides this the less resources are allocated to our main frame-work the more we have spare for adding a vast range of KWWidgets widgets, which is IMHO a key point.

Conclusions

It is true that KWWidgets is in its early ages, but it is already a well-targeted and powerful library, which presents many, if not all and more, of the key elements for conceiving a firm frame-work for our designer.

Using the KWWidgets is necessary to keep consistency and coherence: the library and the designer will 'grow hand in hand'. The designer will grow to the needs of the library, but it is also possible that needs in the designer might source needs in the library.

Concerning the 'lacks' that KWWidgets might have today over other more mature libraries, they can be 'overpassed' by using the underlying Tk layer, which is a frequently omitted/forgotten yet a powerful aspect of the KWWidgets library.

So KWWidgets is the chosen library to develop the frame-work of the designer, the KWWidgets team having the last word on this matter.




KWWidgets: [Welcome | Site Map]