As the post about wx progress in 2008 seemed to generate quite some interest, here is the promised update for the things we did in the first month of 2009.
The main new addition was probably the long-discussed support for persistent controls. This is not completely done yet but initial implementation of the basic support for persistence was checked in and now persistent adapters for more wxWidgets classes (currently only wxTopLevelWindow and wxBookCtrls are covered) can be added one by one.
Another important change was the integration of the type-safe events patch from Peter Most. Not only it makes the events safer but it also allows connecting anything as an event handler, not necessarily a method of wxEvtHandler-derived class. Unfortunately we hit some problems with building this code with all but the very latest compilers (we didn't even try to use it with VC6, but it was a bad surprise that VC7 template deduction was not smart enough for it neither) so currently it is still disabled but we plan to re-enable it a.s.a.p.
Speaking of the improvements to compile-time safety, Francesco has modified wxWindow::ProcessEvent to be protected at wxWindow level as it should never be called directly but only as win->GetEventHandler()->ProcessEvent() or, with the latest trunk, as win->ProcessWindowEvent() which does the same thing, to avoid skipping any event handlers pushed onto the window. Doing this allowed to find several places in wxWidgets itself where GetEventHandler() call was forgotten and there are certainly a lot of similar omissions in code outside of wx itself which this change will now allow to find during compile-time.
There was also more work done on the native headers (with nice support of sorting and column reordering) in wxDataViewCtrl and wxGrid (special thanks to Zen Fire for sponsoring this work!) and on wxDataViewCtrl in general. In particular the simple wxDataViewListCtrl wrapper was added and event-based API for drag-and-drop was implemented.
The last problems with support for custom controls in native file dialogs under Windows were solved thanks to Marcin so now only Mac support for this feature is missing. Speaking of Mac, the new OS X port kept progressing in leaps and bounds and I'm especially glad that several people have contributed to it recently -- thanks!
Then there were some improvements to MDI stuff. This code was not updated for a long time so I started reviewing and correcting it in last November and continued to do so, while adding some new features, now.
And finally some useless statistics: so far (the month is not quite over yet...) there were 850 check ins in January. 138 new tickets were created, 211 ones were closed (at least we're moving in the right direction!) and Trac records 365 ticket modifications in total from 93 different people (with Robin and me doing most of the damage with about 70 changes each).
On a completely unrelated note, I've installed, out of curiosity, beta of Windows 7 and tested some wx samples under it. They have no special support of Windows 7 (nor even Vista yet) but they still appear to be quite fine, only small details (e.g. owner drawn menu items) look out of place. I'm not sure if this can really be seen as our merit though, it's probably more a compliment to Microsoft for maintaining backwards compatibility. Although it also clearly shows the advantage of using native controls -- I doubt that the programs written using Qt, especially using its version from a few years ago, look as good as the ones written even very old wx versions under the new system. Other than that, my main impression of Windows 7 is that it's amazing that it still needs to restart when changing the workgroup name. I guess they didn't want to remove all old and familiar features at once...
And to end this post, some less technical news: we made a brief roadmap for 3.0 release. This is not much in itself but it does help to concentrate thoughts on it and hopefully gives a bit more visibility into the project future for people not reading this blog.
And I was extremely glad to learn that wxWidgets now has a new maintainer in Debian as I almost lost hope to ever see them there as the old maintainer spent his time only sabotaging the efforts by others to bring wx to Debian and spreading FUD about it in his spare time whereas the new maintainer has already released the updated packages which is great news for me both from a wx developer and a Debian user viewpoint. We also had a discussion with Dan Horák, Fedora packager of wxGTK, about supporting multiarch (mostly x86/amd64) packages and making RPMs for wxWidgets 3.0 (interested people can already try these experimental pre-2.9 versions).
Saturday, January 31, 2009
Wednesday, January 14, 2009
Qt switch to LGPL
Qt switch to LGPL has triggered a thread with subject "Bad thing for wxWidgets Qt will be in LGPL" on wx-users mailing list which clearly implies that this is indeed a bad thing. But is it one really?
First, let's not be egoistic: even if this were bad for wx, it's surely excellent news for just about everybody [else]. I do applaud Nokia for doing the right thing and I'm personally very glad that even people in big multinational companies such as Nokia understand the benefits of open source.
Second, this certainly will bring more users to Qt. But I'm not sure it's going to happen at the expense of wxWidgets users. I rather think more people thinking to use Java or C# or C (with GTK) could reconsider their choice and use C++ with Qt. The reason for this cautious optimism is that the cost of Qt has never been the only reason for choosing wxWidgets over it. Of course, this hasn't ever been important for GPL applications anyhow. And, surprisingly, it often wasn't very important for commercial applications neither as companies often choose to pay for wxWidgets support anyhow even if the library itself is free. So I think that relatively few of people who had chosen wxWidgets in the past would change their mind now, as the other two main reasons for this choice -- the use of native widgets by wxWidgets and the absence of any preprocessor -- remain as valid as ever.
Finally, if more people use C++ for developing cross-platform applications this is good for wxWidgets even if they use Qt because the whole idea of writing portable programs is unfortunately still not as entrenched in mass conscience as it should be in our opinion. So this could yet turn out to be positive for wxWidgets, although more likely it's not going to change much for us one way or the other.
But this remains great news for the open source community (of which we are part) so I just can't bring myself to regret it. I can dream about wxTNG which would combine the best features of wx and Qt but this still remains a dream for now...
First, let's not be egoistic: even if this were bad for wx, it's surely excellent news for just about everybody [else]. I do applaud Nokia for doing the right thing and I'm personally very glad that even people in big multinational companies such as Nokia understand the benefits of open source.
Second, this certainly will bring more users to Qt. But I'm not sure it's going to happen at the expense of wxWidgets users. I rather think more people thinking to use Java or C# or C (with GTK) could reconsider their choice and use C++ with Qt. The reason for this cautious optimism is that the cost of Qt has never been the only reason for choosing wxWidgets over it. Of course, this hasn't ever been important for GPL applications anyhow. And, surprisingly, it often wasn't very important for commercial applications neither as companies often choose to pay for wxWidgets support anyhow even if the library itself is free. So I think that relatively few of people who had chosen wxWidgets in the past would change their mind now, as the other two main reasons for this choice -- the use of native widgets by wxWidgets and the absence of any preprocessor -- remain as valid as ever.
Finally, if more people use C++ for developing cross-platform applications this is good for wxWidgets even if they use Qt because the whole idea of writing portable programs is unfortunately still not as entrenched in mass conscience as it should be in our opinion. So this could yet turn out to be positive for wxWidgets, although more likely it's not going to change much for us one way or the other.
But this remains great news for the open source community (of which we are part) so I just can't bring myself to regret it. I can dream about wxTNG which would combine the best features of wx and Qt but this still remains a dream for now...
Tuesday, January 06, 2009
Another Year of WX
I wanted to write this summary of the work done on wx in 2008 before the end of the year but, as it unfortunately often happens, ran out of time and couldn't do it. Still, better late than never -- again this is a very familiar principle -- and so here is a brief summary of important things which happened to wx in 2008. It liberally reuses the material from Robert's Wonderful World of WX write up, read it for more details.
So, what have we done in the almost 7000 revisions checked in during 2008? Maybe surprisingly, the most important changes haven't been about writing code at all but rather about improving the project infrastructure. This may not seem like a big deal but the old SourceForge-based bug tracker was completely unusable and basically was unused because of this and literally hundreds of bugs could have been triaged and closed since the switch to using Trac. We also finally have a working BuildBot which allows to detect breaking the build (and assigning the blame) quickly and automatically and this is very useful for a project such as wx where it's not always possible to test the compilation of the new code in all configurations under all platforms. Finally, the documentation now is in a new Doxygen-based format which makes it easier to maintain and contribute to it, as well as producing nicer results.
By the way, you might have noticed that one of the goals of these changes was to make it easier to contribute to wxWidgets:
But while waiting for the success of our diabolic plans to make wxWidgets users work on improving the library themselves we still found time to do quite a few things ourselves. From the strategical perspective the most important change of 2008 was certainly the decision to start merging the old Carbon-based wxMac port and the alpha-quality wxCocoa into the new, one and only, wxOSX port which will run on both 32 and 64 bit platforms and also iPods and iPhones and not just the boring desktops. And as a side note, wxOSX can now also be built as a framework and not just as plain old Unix-style dynamic library.
Another strategic decision was to concentrate more on the quality of the library than on the quantity of the things it may do. This has led to dropping of ODBC library which was embarrassingly buggy and unmaintained since a very long time and spending a lot of effort on bug fixing, including the inconsistencies in behaviour between different ports (and while this post intentionally doesn't cite any names to avoid accidentally omitting somebody, I do have to thank once again Google for organizing, once again, the Summer of Code which allowed us to spend more resources than would have otherwise been possible on this task -- let's give credit where it is due). In the same category, we have finally cleaned up wxSocket and wxURL code which became an acute embarrassment to all of us after a decade of bit-rotting and also fixed some, although by far not all, problems with wxGrid which also suffered from chronic lack of attention.
Of course, all this doesn't mean that there were no new features added so let me list the most important ones:
And I probably forget quite a few more.
But while things have progressed quite a lot, we didn't manage to do everything we'd have liked to, of course (otherwise what would be doing this year?). My main regret is that we didn't manage to release 2.9.0 development branch preview release as I'd really like to do this a.s.a.p. to get more feedback about the Unicode-related changes. Among the features we hoped to add this year but didn't one really stands out: a lot of people are asking for images support in wxButton and we really should support this as it's not even difficult to do so this will definitely be something to do in 2009.
The two other small things we hope to see in this new year are the wxOSX completion and hopefully the 3.0 release. Let's see if this happens...
That's all for 2008 and see you in a year time (unless people find this post really interesting, in which case I might try to write monthly summaries of wx development)!
P.S. Edited to correct the date on 2009-01-09.
So, what have we done in the almost 7000 revisions checked in during 2008? Maybe surprisingly, the most important changes haven't been about writing code at all but rather about improving the project infrastructure. This may not seem like a big deal but the old SourceForge-based bug tracker was completely unusable and basically was unused because of this and literally hundreds of bugs could have been triaged and closed since the switch to using Trac. We also finally have a working BuildBot which allows to detect breaking the build (and assigning the blame) quickly and automatically and this is very useful for a project such as wx where it's not always possible to test the compilation of the new code in all configurations under all platforms. Finally, the documentation now is in a new Doxygen-based format which makes it easier to maintain and contribute to it, as well as producing nicer results.
By the way, you might have noticed that one of the goals of these changes was to make it easier to contribute to wxWidgets:
- Trac not only allows us to process bugs more efficiently but will hopefully also encourage others to to help with weeding out the duplicates (something we really couldn't expect the others to do with the SourceForge tracker as we couldn't even do it ourselves). And it allows for better bug categorizations, for instance you can see all easy to fix bugs at a glance and hopefully this can encourage more people to try fixing them (the list is short right now but will probably become longer with time).
- The BuildBot allows to verify that the svn trunk version at least builds which is supposed to encourage people trying it out. We also hope to get more volunteers setting up their own build slaves to help us test even more configurations.
- And the new documentation format has already allowed many more people to submit contributions to the manual than before and we hope that this trend is going to continue. And using Doxygen further lowers the barrier to entry to wxWidgets development as no LaTeX knowledge is needed any more.
But while waiting for the success of our diabolic plans to make wxWidgets users work on improving the library themselves we still found time to do quite a few things ourselves. From the strategical perspective the most important change of 2008 was certainly the decision to start merging the old Carbon-based wxMac port and the alpha-quality wxCocoa into the new, one and only, wxOSX port which will run on both 32 and 64 bit platforms and also iPods and iPhones and not just the boring desktops. And as a side note, wxOSX can now also be built as a framework and not just as plain old Unix-style dynamic library.
Another strategic decision was to concentrate more on the quality of the library than on the quantity of the things it may do. This has led to dropping of ODBC library which was embarrassingly buggy and unmaintained since a very long time and spending a lot of effort on bug fixing, including the inconsistencies in behaviour between different ports (and while this post intentionally doesn't cite any names to avoid accidentally omitting somebody, I do have to thank once again Google for organizing, once again, the Summer of Code which allowed us to spend more resources than would have otherwise been possible on this task -- let's give credit where it is due). In the same category, we have finally cleaned up wxSocket and wxURL code which became an acute embarrassment to all of us after a decade of bit-rotting and also fixed some, although by far not all, problems with wxGrid which also suffered from chronic lack of attention.
Of course, all this doesn't mean that there were no new features added so let me list the most important ones:
- The first among them was the long-awaited inclusion of wxPropertyGrid in wxWidgets itself.
- wxDataViewCtrl and related classes continued to be significantly enhanced.
- wxRichTextCtrl has benefited from many small but cumulatively important improvements as well.
- As part of improving wxGrid/wxListCtrl columns display support, a new wxHeaderCtrl class was added and a handy wxRearrangeList and related classes were added and column reordering was implemented.
- A convenient new sizer class, wxWrapSizer, was added.
- wxCalendarCtrl now has a native implementation.
- The humble wxMessageDialog got a much needed face lift as well, in particular you can finally use custom labels for its buttons
- We even found something to improve in wxStaticText which now supports "ellipsization" of its contents.
- wxGLCanvas gained anti-aliasing (multi-sampling) support.
- The main -- but far from only -- change to AUI library was the addition of wxAuiToolBar.
- Events (and hence timers and asynchronous sockets) support was finally added to wxBase, after years of planning to do it.
And I probably forget quite a few more.
But while things have progressed quite a lot, we didn't manage to do everything we'd have liked to, of course (otherwise what would be doing this year?). My main regret is that we didn't manage to release 2.9.0 development branch preview release as I'd really like to do this a.s.a.p. to get more feedback about the Unicode-related changes. Among the features we hoped to add this year but didn't one really stands out: a lot of people are asking for images support in wxButton and we really should support this as it's not even difficult to do so this will definitely be something to do in 2009.
The two other small things we hope to see in this new year are the wxOSX completion and hopefully the 3.0 release. Let's see if this happens...
That's all for 2008 and see you in a year time (unless people find this post really interesting, in which case I might try to write monthly summaries of wx development)!
P.S. Edited to correct the date on 2009-01-09.
Sunday, January 04, 2009
Pretty printing wxStuff in gdb
I've recently stumbled upon a highly informative series of articles by Tom Tromey, one of gdb developers (among other things), about embedded Python in new gdb. The one immediately useful consequence of this is that you can now write pretty printers for custom data structures as explained here. Unlike the custom gdb commands, the custom pretty-printers apply to all occurrences of the objects, including as fields in the other data structures and even in the backtraces printed by gdb itself so they are much more useful.
So without further ado here is a pretty printer for wxString from svn trunk (it can also be trivially adapted for 2.8 version by using m_impl.m_pchData) shamelessly stolen from the examples above:
This is supposed to be put into a file sourced with source -p gdb command (there is apparently a better way to load this than simply inserting the command in .gdbinit but for now this is good enough for me).
And then:
Of course, you do need a Python-enabled gdb for this to work. The easiest way is probably to get the package from Debian Experimental as I did. Otherwise you can always follow the instructions on Tom's blog and get gdb sources from git and built them yourself.
But this is really incredibly useful and will be even more so when we add pretty-printers for the other wxWidgets types (e.g. wxDateTime could definitely benefit). Any contributions to our custom pretty-printers would be welcome!
So without further ado here is a pretty printer for wxString from svn trunk (it can also be trivially adapted for 2.8 version by using m_impl.m_pchData) shamelessly stolen from the examples above:
class wxStringPrinter:
def __init__(self, val):
self.val = val
def to_string(self):
return '"' + self.val['m_impl']['_M_dataplus']['_M_p'].string() + '"'
gdb.pretty_printers['^wxString$'] = wxStringPrinter
This is supposed to be put into a file sourced with source -p gdb command (there is apparently a better way to load this than simply inserting the command in .gdbinit but for now this is good enough for me).
And then:
[sunset:../src/build/wx-gtkud/samples/minimal]% gdb minimal
(gdb) b 149
Breakpoint 1 at 0x40cc65: file /usr/local/src/wx/HEAD/samples/minimal/minimal.cpp, line 149. (2 locations)
(gdb) r
Starting program: /usr/local/src/build/wx-gtkud/samples/minimal/minimal
[Thread debugging using libthread_db enabled]
Breakpoint 1, MyFrame (this=0x5751a0,title="Minimal wxWidgets App") at /usr/local/src/wx/HEAD/samples/minimal/minimal.cpp:149
149 SetIcon(wxICON(sample));
(gdb) bt 1
#0 MyFrame (this=0x5751a0, title="Minimal wxWidgets App") at /usr/local/src/wx/HEAD/samples/minimal/minimal.cpp:149
(gdb) p title
$1 = "Minimal wxWidgets App"
Of course, you do need a Python-enabled gdb for this to work. The easiest way is probably to get the package from Debian Experimental as I did. Otherwise you can always follow the instructions on Tom's blog and get gdb sources from git and built them yourself.
But this is really incredibly useful and will be even more so when we add pretty-printers for the other wxWidgets types (e.g. wxDateTime could definitely benefit). Any contributions to our custom pretty-printers would be welcome!
Subscribe to:
Posts (Atom)