Robert's wxXt and FADE Homepage

This local page is a snapshot of Robert's on-line Web page, which is here.


Note: For the new project FADE see below.

News

  • 22th September ī97: Plans to create wxGTK have been discussed, letīs see
  • 14th September ī97: Screenshots and project plans made available
  • 1th September ī97: wxWidgets 1.67 available (thatīs when I noticed..)
  • 26th July '97: ALPHAs available for two demos: TextMaker and FileMaker
  • 26th July '97: wxWidgets 1.67 will soon be released, wxXt 1.67 will follow
  • 20th July '97: Well, the DnD code in 1.66d was't perfect yet..
  • 14th July '97: wxXt 1.66d released
  • The German SuSE GmbH packages wxXt in its recently released Linux distribution 5.0.

  • Description and copyright

    wxXt is a C++ GUI toolkit derived from and source-code-compatible with Julian Smart's wxWidgets GUI. More information about wxWidgets can be found at the wxWidgets Homepage. wxWidgets works under Linux, too, but it uses either the Motif library or the ugly and outdated XView (aka OpenLook) libs. Remember the fire and frying pan..

    wxXt provides a rich set of classes which help to make GUI programming under Linux, and probably most other unices, very easy. There are certain similarities to a commercial product called Qt which, sadly enough, has been chosen to be the base library for the KDE desktop project.

    There are classes for the following categories

  • Window classes: wxWindow, wxFrame, wxDialogBox, wxPanel, wxCanvas etc.
  • Widget classes: wxButton, wxCheckbox, wxChoice, wxListBox, wxListCtrl, wxText, wxGauge etc.
  • Data structures: wxList, wxString, wxHashTable, wxDate etc.
  • Layout/constraint system
  • GDI classes: wxPen, wxBrush, wxFont, wxBitmap etc.
  • Events: wxCommandEvent, wxMouseEvent, wxKeyEvent etc.
  • Devices contexts: wxCanvasDC, wxPostScriptDC, wxMemoryDC, wxPrinterDC
  • Base class for runtime-type information: wxObject
  • Interprocess communication: wxClient, wxConnection, wxSocket, wxServer etc.
  • Document-view architecture: wxDocument, wxView, wxDocManager etc.
  • Printing framework: wxPreviewFrame, wxPrintDialog, wxPrinter etc.
  • Many helper classes, wxApplication, wxTypeTree, wxPathList etc.
  • A multitude of functions and macros
  • The main author is Markus Holzem. But several people have contributed to wxXt. In contrast to most, if not all, GUI libraries of that quality, wxXt is under the L-GPL.


    What can I do with it?

    Quite a lot. Let's give three examples:

    Create a new Desktop Environment like KDE. It would be free, in contrast to the Qt based KDE. See below under FADE.

    Let's assume, there is a Linux Distribution called Debian, which wants to write a GUI configuration tool, which I will call Deity. Deity could then use wxXt to be a truely free (i.e. GPLed) program to configure it's distribution. But for companies, who would die for Motif-apps, the same source code can be used to build a Motif app (using wxWidgets 1.66 from Julian's site.), which would make Debian more attractive for companies.

    Let's assume, there is a network server system for Unix and Windows called Samba. Writing a GUI configuration tool for Samba would be very useful. Using wxXt there can be free version for the UNIX site; for the Windows side, there can be an even freer version using the Windows version of Julian's wxWidgets.


    Screenshot

    What would a home page of a GUI be without a screenshot? It is here.

    The screenshot is not totally uptodate.


    Download

    Go to the FTP section directly.

    You can download the sources from here. That's 1.2 Mb. This is the first release using the GNU autoconfigure mechanism instead of Imake. Not everything is entirely tested yet. You are warned.

    There is also documentation in html available. You can download this from Julian Smart's site. It is the documentation for wxWidgets 1.66. As your programs written in wxXt will be source-code compatible (except for the way to include header files - and even there exists an extra compatibility mechanism) you can use this (excellent) documentation for wxXt 1.66 and wxWidgets alike. Download it here. That too is a Meg of data.

    As I will soon move to Debian GNU/Linux, I will make a .deb version of the shared library for that OS available. If there is someone, who wants to help me to make that happen faster, mail me using the address stated below. As I don't have RedHat, I will not produce .rpm files. So get the source, compile it as shared and send it to me, if you want to have an .rpm here.


    Installation

    Installation is not very simple. It even took me quite a while to install it on my new Debian 1.3.1. But if you follow this mini-cookbook, you should get where you want. There is also an INSTALL file in the source distribution. But that is not for the faint of hearted. Here we go, step by step
  • Well, download the source.
  • Unpack it to a suitable subdirectory, let's say ~/wxxt-1.66.
  • Type "tar xvfz wxxt166d.tgz" if you don't know how to unpack.
  • Type "cd wxxt-1.66"
  • Type "configure --with-shared"
  • Type "make makefiles"
  • Type "make depend"
  • Type "make src"
  • Log in as root, type "su" and the password that is.
  • Copy the contents of ~/wxxt-1.66/lib/Linux to /usr/lib or anywhere, where your dynamic linker will find the libraries.
  • Type "make samples" if you want to compile _all_ demos.
  • Type "cd samples/demo"
  • Type "Linux/demo" - That's all.

  • My add-ons

    Is is planned, to replace all widgets from the Free Widget Foundation with generic widgets. As the current widgets work, this hasnīt got the top priority.

    wxText and wxTextWindow

    So far, wxXt is dependent on the dreaded Xaw library for the wxText widget, which is a simple inputline and the wxTextWindow class, which is a multi-line editor. I have written replacements for both, which will soon become part of the official distribution.

    wxDragCanvas

    I already implemented support for the OffiX Dnd protocol on the Drop side. There is already working code for dragging, but it isn't very good-looking yet.

    wxListCtrl

    What wxXt didn't have so far, but badly needed, was a wxListCtrl-class, which can display data like Windows' "Explorer" program: icons, simple lists, tables (aka report view) and small icons.

    You can find these classes (and a few more) here. Untar it into wxxt-1.66/other/AddOns. Feel free to ask me for the newest sources.

    My add-on-demos

    FileMaker

    To demonstrate a real-world program, I'm writing a file manager, called FileMaker, for wxXt. For this, I have already written a wxListCtrl which acts like a ListCtrl item under Windows. A few dialogs work already, other will be working very soon, Drag and Drop of files does already work. What remains is to draw more icons and to actually implement the various copying, moving etc funtions, possibly using wxXt's thread support. Get it here and untar it into wxxt-1.66/other/FileMaker.

    Here are two screenshots that show FileMaker (including wxListCtrl and the new ToolBar class) in different view modes. First in tree view and then in commander view . Just click..

    TextMaker

    When writing wxTextWindow, I realized, that it would be usefull to actually implement an editor, which uses the class. In fact, the html page, you are just looking at, has been created using TextMaker. Get it here and untar it into wxxt-1.66/other/TextMaker.

    Here is a screenshot that shows TextMaker (including wxTextWindow and the new ToolBar class).

    HelpMaker

    I have plans to further write wrappers for the data classes in Qt, such as QList and QString, so that porting applications from Qt will become easy. Once, FileMaker is ready, I will myself port the KDE help program, which can read html, info and man-pages, to wxXt. Rumours have it, that there is even support for Java-Script.


    FADE

    This is a new projects which needs participants. Anybody interested in joining may mail the author of the page.

    FADE stands for Freely Available Desktop Environment. I got the idea for it, when I looked at the KDE project, which tries to make Linux more attractive to end-users by giving it a common user interface. But because it is based on a commercial toolkit for its GUI, it has no chance of getting the blessing of the many GPL dogmatics, spearheaded by the Debian group, which will probably gain in importance. The idea, to do the same or something similar with wxXt was obvious. So I propose this new project, on which I only will work, if somebody joins the effort. What has to be done is:

  • Streamline wxXt, no compile options, only shared (not very difficult).
  • Write a set of KDE compatible classes, so that switching from KDE to FADE will become easy.
  • Finish FileMaker...
  • Write a replacement (DeskMaker?) for kPanel (kind of Windoze95 Taskbar).
  • Either make DeskMaker work (for Desktop switching) with FVWM, kwm or WindowMaker :-)
  • or write a new window manager (quite a bit of work..).
  • Write HelpMaker (see above on how..).
  • Replace FWF widgets to make wxXt look even nicer (can be done gradually.)
  • Create a full blown www-site with mailing lists etc.
  • Among the classes needed for KDE compatibility are
  • wxURL for decoding of URLs. (Easy).
  • wxMimeBinding for binding filetypes to actions (not difficult).
  • wxConfig for reading Acsii config files (not diff.)
  • wxSocket for obvious reasons (on the way).
  • maybe the above mentioned Qt compatibility classes (?).
  • There are plans to replace the FWF widgets with either a front end to the GTK (Gimp Tool Kit) or to replace them with generic ones (i.e. writing them using wxXt itself).

    Writing new widgets directly in wxXt would have the implication, that porting wxXt to a new system, including first of all LinuxGGI (and/or Berlin), would require only a few steps:

  • porting the central event system (exists in GGI)
  • creating one or two base windows, which can scroll and contain other windows (not simple, not at all)
  • creating a frame and a dialog (simple, once the above is done)
  • porting the GDI including bitmaps, fonts, cursors..
  • The fact that Java is undergoing a very similar change right now, i.e. moving from using native widgets on every platform to using generic ones (you could say native Java widgets) may hint at that this idea maybe isnīt so stupid.



    This page is maintained by Robert Roebling. Comments, in contrast to junk and flames, welcome.

    Last changed 22th September '97.