Re: Portability (was: Compiler status)

new topic     » topic index » view thread      » older message » newer message

OK, here's a follow-up to my already overly long first posting.

I had a number of questions about exactly how feasible it would be to use
wxWindows; if anyone cares, here they are, along with some answers, in case
anyone other than me cares:

[Comparison to Other Toolkits]

I got a chance to look at wxPython (http://wxpython.org) a bit more closely.
If the testimonials are to be believed, wxWindows is the best thing since
sliced bread. There's a comparison between tkinter (based on Tcl/Tk),
PythonWin (based on MFC) and wxPython (based on wxWindows) here:
http://www.ora.com/catalog/pythonwin32/chapter/ch20.html; in my book,
wxPython looks the best.

For those pointing out that this is a Euphoria, not Python page, I'll borrow
this quote: "wxPython is close enough to the C++ version that the majority
of the wxPython documentation is actually annotations to the C++
documentation that describe the places where wxPython is different. "


[Converting C to C++]

I wasn't sure how difficult it is to convert C++ routines back into plain
old C. A good example of a library that does just that is QtC, which creates
C routines for the C++ Qt toolkit. Here's an example routine,
QDateToTime::toString:

qt_QString * qt_QDateTime_toString( qt_QDateTime *instPointer){
        return (qt_QString *)new QString(((QDateTime
*)instPointer)->toString());
}

Pretty ugly, but not really that much magic involved. More importantly, it
shows that a C++ library can be effectively wrapped without having to resort
to any OOP. This is a lot like how GTK+ is coded; classes are made explicit
by writing:

   class_routine()

instead of:

   class.routine

In the unlikely event that anyone wants to see the source for QtC, it's at:

  ftp://ftp.tux.org/pub/sites/ftp.kde.org/devel/qt-bindings/QtC-0.0.2.tar.gz


[Derived Classes]

One of the other problems with using a C++ library is that, in order to have
objects respond to events, you have to derive new classes that redefine
empty methods, like onMouseClick, and so on. This is the approach that's
taken by V (http://www.objectcentral.com/) It's possible to wrap such a
library, but it means having to derive a version of each class ahead of
time, and place a callback into each method, then write tools to connect the
callbacks to methods - a real pain.

Fortunately, wxWindows already has helper functions that allow callbacks to
be associated with objects. This means you add functionality to controls
without having to derive a new class. For example:

   EVT_MENU( self, menu_id, menu_callback )

attaches a callback to a menu for when a particular menu item is selected.


[Size and Speed of Code]

The 'minimal' wxWindows application is about 300K; I suspect that the
solitaire program (773K) is more typical. (It compresses to 205K under UPX).
I assume that with the entire library, it could be quite a bit larger, but I
suspect that it shouldn't be enormous.

Finally, the speed of the application seems good (much better that Tcl/Tk),
because wxWindows uses native controls where possible. This also means that
it will have a native look and feel on each platform - without the speed
issues of Java's Swing. That also means that when a new version of
Windows/GTK/etc. comes out, it will be able to use the new look and feel of
the widgets.

All in all, I'm pretty impressed with wxWindows, and I'm even more convinced
that it would make a good match with Euphoria. So Robert, could you finish
up that compiler, and start working on the portable GUI? blink

-- David Cuny

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu