Did you ever dream of compiling QT using gcc (or other suspicious perversion)? Well, this binding is perhaps for you. EQT is totally implemented from QT-X11-GPL sources provided by Trolltech. It intend to be a full featured Eiffel ToolKit for the SmallEiffel compiler.

State

EQT is actually BETA code, a consequent part of the QT structure has been implemented but many work has already to be done. Currently, only the X11 window-system is covered via the Eiffel-Xlib library from Stephane Hillion. I did not look by myself if other window-system APIs are available, and should be introduced in the cluster.

• First, all classes have to been updated to a stable state, via complete tests.
• Next, some features are not yet implemented.
• Eiffel assertions has to be written and tested for most of the library features. This has not been done at startup considering that the knowledge of use contextes reclaim the knowledge of the whole library. For now, only basic conditions are specified, and many has not been tested at all.
• Window-specific code (Xlib one) has been separated from common implementation using basic inheritance rule. This clearly determine what have to be done for adding support of another window-system to the cluster.

Features

As a counterpart, EQT provides:

• An Eiffel Toolkit written in Eiffel which will produce C code when compiling. This low-level implementation allow easy integration in Eiffel projects. This also means that defining new widgets will result in only Eiffel work, and nothing else. This may be considered as a detail, but i can say, with some experience of Eiffel GUI libraries that are a layer under a native C/C++ Toolkit, that it is a real and non-neglictible improvement. I already constat that fact when i rewrote some desk tools i did months ago with other languages. This was a real satisfaction and somehow an unattempted validation of this work. Of course, i'm not on about other Eiffel user experiences on this specific scope, but personaly i was considering the GUI specification of Eiffel projects i worked on as something with too much compromises (GUI, native requirements, extensions). EQT provide a real Eiffel framework which allow to have a complete and clear control when defining your own components (a common operation when building GUIs). The Eiffel specification completely describe what you should attempt from all objects you deal with (i'm just looking a widget class from one of the binding libraries, i'm somehow surprised: there are no assertions. Should we call this language as Eif or Fel?).
  
  Of course, this choice of reimplementing QT has the disadvantage that EQT does not automatically integrate QT evolutions and improvements, it will have its own separated evolution. But, as a counterpart, EQT integrates all improvements inherited by the use of Eiffel for maintenance and evolution.
  My first idea was to build a real clone of QT, something that should be used to found real complicated structural bugs in the original library. However, Eiffel allow a more complete specification than C++, it therefore means that EQT cannot be similar to QT unless it does not use all capacities provided by the language. So, i consider now that its finalization (before the non-beta first release) has to be done regardless of the original code, trying to use as more as possible Eiffel concepts.
  
  
  
• The power of QT.



• An interface identical (at a few exceptions) of the QT one. This allow the use of the QT documentation when working with EQT.



• An operative cluster, i currently run some tools written in EQT on my workstation.



• EQT keep the Signal/slot mechanism defined by Trolltech to encapsulate object-to-object communications. All signal connections and signal emissions are expressed with the use of the TUPLE type. This allow the validation of all of these at compile time without any need for dedicated group of assertions. These mechanisms are not frozen, for now, only basic mechanisms are used but more complex ones should be defined in future without any compatibility problem. Signals are really easy to define, slots reclaim an extra little work since they encapsulate a context to call features of a given object. Finally, emissions and connections are simple calls which require no particular attention.



• Properties are not currently defined, but, once the base framework will be defined, it will be somehow trivial to implement them.

The archive which is actually provided cover the base of the cluster. It is distributed for people who should take interest in the evolution toward the first non-beta release, and for usual bug-reports, comments, fixes and ideas. There are many features covered by the actual devel version which are not included in the public archive. This is because, i want these features to be open for discuss. That is, people with ideas about these lacks are welcome for any idea or solution.

Once the kernel features will be clearly defined, i hope that the widget library that came with EQT will grow consequently. I think that the use of Eiffel allow very powerful abstractions in this scope and i currently work on two special widgets (they are actually not included in the archive). My little experience with them seems very positive and make myself thinking to some next generation of toolkits (why not? I'm sure that you'd never think that these concepts are "frozen", or the best available for the rest of eternity).
Sytem and Window-System portability should also evolute depending on people who found EQT as an useful tool and like to spend some of their time and their talent to develop it.

Environment which is known to work is actually the development one:

• BSD OS, the devel platform is FreeBSD
• SmallEiffel-0.75 (beta#16) or later (required for an incompatible change in the STRING class and use of the TUPLE type).
• Xlib, both 3.x and 4.x have been used, but extensions specific to 4.x versions are work in progress (Xinerama, Xft, ...).

No extra library is needed. The X11 binding is based on the X11-Eiffel library from Stephane Hillion and has been included in the archive since it differs significantly from the original version. First, there are major changes in the hierarchy, next, many features that were not covered by the original binding are now present (Input / Output methods, XRM implementation ...), finally, many Xlib extensions are also implemented (MIT-SHM, Shape extension, ...).
Unicode implementation is based on the Unicode Database library from majkel Kretschmar. Regular expressions were taken in the EPCRE (Perl compatible regular expressions) library from Philip Hazel. Note however that Unicode implementation is currently work in progress, i try to make possible easy replacement of the base classes that it use by newly specifications (for example, insertion of Unicode strings in the SmallEiffel Kernel Library?).

Note that apart from the above needs, there is other low-level areas which are not yet covered. As an example, EQT currently work with True-Color displays but has not been tested with others. I did not this work, because i am mainly taken with other parts of the library, but, this has to be considered as a once work.

For any question, comment, information: eiffboss@free.fr