Re: Portability (was: Compiler status)
- Posted by "Cuny, David at DSS" <David.Cuny at DSS.CA.GOV> Jul 11, 2000
- 415 views
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? -- David Cuny