Goals of wxWidgets

A comment attached to the last post asked the question about what wxWidgets goals are. I was initially quite surprized because the answer was so obvious to me, but thinking a bit more about this I realized that we don't clearly answer this question anywhere in the public documentation and so for someone not following wx-dev mailing list the direction of wxWidgets development may indeed seem mysterious. To help with understanding it, I'd like to briefly explain where wxWidgets is coming from, what are the guiding principles for its development today and what I hope it is going to be tomorrow. Please note that, as anyone who does follow wx-dev would know, we don't always agree about everything and so what follows is just my personal point of view and while it hopefully does overlap with that of the others -- at least for the past and present parts -- I don't pretend to speak for everybody.

This disclaimer aside, let's start by looking at the current state of wxWidgets and how did we get there. On the negative, and often mentioned, side, it's an accretion of almost 15 years of development, by different people, some of which have stopped contributing to the project since a long time. So it is not surprising that there are some inconsistencies in the API (although we work hard on ironing them out) and some components (notably those whose maintainers have left) are not as good as one'd expect them to be. It is also true that compatibility with MFC seemed much more important in the nineties than now and this explains why wxWidgets has some superficial similarities to it, although it has never been nor designed to be, an MFC clone. So it's true that this long history resulted in some problems and we had to change quite a few things to fix them -- even the original name of the library turned out to be a bad idea.

However, on the bright side, not everything we did during these 15 years was a complete waste of time and, in addition to the accumulated historical luggage, everything that we did right is in the wxWidgets codebase too. And this is quite enough to allow people to create real life, professional complicated graphical cross-platform applications -- which is, to answer the initial question, what wxWidgets is about. To be more precise, the main goal is to allow the developers to do everything they need to do without resorting to writing platform-specific code: the "Write once, compile anywhere" principle. Of course, this goal is a moving target which can never be quite achieved because developers discover more and more things that they need to do with time as the new graphical environments introduce new standards (use of gradients and animations in the GUI was not exactly common when wxWidgets was started) but, still, I believe we're pretty close to it -- and getting closer with every new release.

So wxWidgets primary goal is to allow creating sophisticated portable applications without writing platform-specific code. This is not the only goal, of course, but it's the most important one and so trumps all the others. For example, wxWidgets could be more size efficient but this would be mostly important for toy applications and not for the programs which are themselves of reasonably important size. And so, while we'd be as glad to make wxWidgets smaller as anybody else, this currently has a relatively low priority because it's not very important from the main goal perspective. On a perhaps more constructive note, this also explains why do we consider the differences in behaviour of wxWidgets on different platforms important bugs: it's useless to have the code which compiles on all platforms if it doesn't behave the same everywhere during run-time.

But, to repeat, as important as this goal is, I think we're quite close to it and have been there since a long time. However other things could really be improved. Chief among them is the ease of use of wxWidgets: things have changed a lot since its creation and, in particular, modern C++ doesn't have much to do with C++ of the nineties. So it would be great to make wxWidgets evolve with the language and other standard C++ libraries. This would mean providing a more modern API, removing the need for memory management completely (this is very rarely a problem in wxWidgets even now, as most of the objects are owned by the library anyhow, but it would be nice to make this more explicit) and improve error handling by using exceptions. We should also rely more on the standard C++ library and Boost instead of implementing all various useful but not directly GUI-related classes on our own as we had to do in the past (as not implementing them would have conflicted with our primary goal whereas now, when such classes are available from elsewhere, it doesn't any more). This, and much more, is in our plans for wxWidgets 3.

There are certainly a lot of other tactical goals. The fact that I didn't mention at all fixing the bugs or improving the documentation doesn't mean that these goals are not important but just that they are obvious and I don't want to make this article even longer than it already is by stating the obvious. The point of this post was to just say that strategically, our main goal always was and remains making wxWidgets suitable for real-life portable applications development and, in addition, creating a new, modern, API for wxWidgets 3 in (hopefully near) future.

How to Contribute to wxWidgets Guide

We often have the impression that wxWidgets could be so much better if only we had more time to fix the known problems with it, to implement all these exciting new features it still lacks or even just to fix the numerous old bugs. But unfortunately the time is always lacking (isn't it funny that you can regularly find jokes about 48 hour days in wx-related email since the beginning of the nineties?) and so many things remain undone. So the next idea, after failing to change the duration of the day, is to encourage more people to work on wxWidgets -- and it seems especially actual now that programming is becoming all about parallelization to take advantage of new multi-processor machines. And attracting new contributors does work rather nicely (better than trying to construct time dilatation machine, anyhow), for instance several new developers joined us relatively recently and brought us great things like AUI, custom comboboxes and almost all other new controls in the upcoming 2.8.0 release.


But we'd still like to attract even more! And maybe it's our own fault, after all, if people don't flock to wxWidgets development. We don't do much advertisement (real programmers hate marketing) and we don't even explain clearly how to become a wxWidgets contributor anywhere. Personally, as I want to keep my real programmer badge, I can't really address the former issue but at least I tried to help with the latter and so wrote this guide to explain how you can help with wxWidgets development. It is probably not as useful as it could be as it's hard for me to understand what questions and problems can a newcomer to wxWidgets (and/or open source development in general) have. But hopefully this guide is better than nothing at all and I'm looking forward to improving it in the future with feedback from the people it is really addressed to.

So thanks in advance for any comments about this guide! As for me, I'm finally going to log off and have a few hours of sleep after my 40 hours wxWidgets working day, safe in the knowledge that hundreds of new developers are going to join the project tomorrow ;-)

wxWidgets at Firebird Conference 2006

The fourth worldwide Firebird Conference will convene at Andels Hotel in Prague, Czech Republic, on Sunday November 12. Notice one of the talks: "Developing Cross-Platform Applications with Firebird and wxWidgets" by Milan Babuskov. Be there!

wxwidgets.org website issues

As mentioned in a comment on a previous post, the http://www.wxwidgets.org website is currently blank and has been so for a few hours now. Robin Dunn mentioned on the users mailing list that the likely cause is that vhost.sourceforge.net is currently down; alternate addresses such as

http://wxwindows.sourceforge.net/

Still appear to work.

Recently in the past there were also issues with speed of the site as well, possibly concerning sourceforge hosting; specifically image loading. Sometimes images would only load half the time. Images were shifted to and from an alternate server (run by Kevin Olliver) in an attempt to provide a temporary fix for the issue.

Right-To-Left layout (RTL) support in wxWidgets

Here is some information about the support for locales with right-to-left (RTL) layout out in wxWidgets. As you probably know, RTL-support is required mostly of Hebrew, Arabic and Farsi. It has been decided that wxWidgets should follow mostly the Windows API and Windows approach for displaying RTL text and layout in applications. This approach is described in a document at MSDN here. In short, all coordinates for drawing and for window positioning are mirrored horizontally which means that (apart from bitmap mirroring) little has to be done at the user level. Also, the various native Win32 controls are modified to support RTL design.

This is different from what is done under GTK+, where no coordinates are mirrored. Instead, every app needs to mirror everything itself, even if the job of mirroring controls is mostly done within GTK+'s layout container automatically. As far as drawing within wxWidgets is concerned, coordinates are mirrored at the wxDC level in the GTK+ port. Some more information about GTK's RTL support can be found here.

I have added two screenshots from the popular FileZilla application running in the "ar_EG" (Egyptian variant of Arab) locale (screenshots in parts thanks to Tim Kosse). Since the tree control in the Linux screenshot is using generic wxWidgets code, this also demonstrates how drawing and scrolling is mirrored for user windows.

Below is a screenshot using wxWidgets and GTK 2.4.9.














Here is roughly the same screenshot using Windows 2000.

wxWidgets 2.7.1 released

12th October 2006: wxWidgets 2.7.1 (a development release) is now available for download via http://www.wxwidgets.org/downloads.

The main changes since 2.7.0 are detailed below. We would be grateful for testing as we work towards 2.8.0 release within the next few weeks. However please be aware that 2.7.1 is not production quality.

wxMac defaults to using the more advanced Core Graphics implementation - this is a work in progress, and we would like to hear of any problems. You can edit include/wx/mac/carbon/chkconf.h to switch Core Graphics off.

Thanks,

The wxWidgets Team


Changes in 2.7.1
=================================================

All:

- Added wxDir::FindFirst() (Francesco Montorsi).
- Added wxPlatformInfo class (Francesco Montorsi).
- Added wxLocale::IsAvailable() (Creighton).
- Added Malay translations (Mahrazi Mohd Kamal)
- Added reference counting for wxVariant
- For consistency, all classes having Ok() method now also have IsOk() one, use
of the latter form is preferred although the former hasn't been deprecated yet

All (GUI):

- Support for right-to-left text layout (started by Diaa Sami during Google Summer of
Code, with a lot of help from Tim Kosse and others).
- wxAnimationCtrl added (Francesco Montorsi)
- Added wxAboutBox() function for displaying the standard about dialog
- Added wxID_PAGE_SETUP standard id.
- Added wxSize::IncBy() and DecBy() methods.
- Added wxTextCtrl::IsEmpty()
- Added file type parameter to wxTextCtrl::LoadFile, wxTextCtrl::SaveFile for
consistency with wxRichTextCtrl.
- wxRichTextCtrl: fixed range out-by-one bug to be consistent with wxTextCtrl API,
fixed some attribute bugs and added wxRichTextStyleComboCtrl.
- Added wxWindow::IsDoubleBuffered()

wxMSW:

- Implemented wxComboBox::SetEditable().
- wxSemaphore::Post() returns wxSEMA_OVERFLOW as documented (Christian Walther)
- Fixed a bug whereby static controls didn't use the correct text colour if the
parent's background colour had been set (most noticeable when switching to a
high-contrast theme).
- Respect wxBU_EXACTFIT style in wxToggleButton (Alexander Borovsky)

wxMac:

- Add parameter to the --enable-universal_binary configure option for the path
to the SDK.

wxGTK:

- Automatically use stock items for menu items with standard ids.
- Setting cursor now works for all controls.
- Implemented right-to-left support
- Implemented left indentation and tab stops support in wxTextCtrl (Tim Kosse).

wxUniv:

- Added wxTLW::UseNativeDecorations() and UseNativeDecorationsByDefault()

Towards quality in wxWinCE 2.8

The most mature ports of our toolkit (wxGTK, wxMSW and wxMac) are nearly equally advanced in terms of features. The development on them is "easy" - they all have the same screen sizes, keyboards, pointing devices, and sounds so once a wrapper around their native API is in place, the ports can share a common wxWidgets infrastructure for events, placement of controls etc.

A few releases earlier we started work on a new family of ports that are increasingly demanded by the market: handhelds, phones and PDAS. See more about it at http://wxwidgets.org/docs/embedded.htm

wxWinCE is the name given to wxMSW when compiled on Windows CE devices. We have a dedicated section in our manual about this port, see: http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_wxmswport.html#wxmswport

Are you a wxWinCE user? What do you miss most? When and how do you use #ifdef __WXWINCE__ in your code? Do you have some own improvements to this port? Please share any opinions and findings about the current state of the wxWinCE port on wx-dev and (for bugs and patches) the SourceForge trackers, and let's make it better together for future releases.

Google Summer of Code 2006: wxWidgets projects summary

Google Summer of Code 2006 is over, and it's time to take stock of what's been achieved. We had nearly 20 proposals, and in the end three projects went ahead. All of the three have contributed useful code, and needless to say we're in awe of Google's programme that gave so much and asked for so little in return. Open source in general, and wxWidgets in particular, just took another big leap this forward this summer. Thank you Google! And of course a big thank you to the three students, and to others who submitted applications - perhaps they will be working on GSoC 2007. Meanwhile, there's still the page of project suggestions for people looking for contribution ideas.

Here then are summaries of the projects.

wxWidgets Package Manager

This project promises to make it easy for people to use the many available third-party wxWidgets components, which often have unique installation methods that take time to understand. What started off as one application has become a suite of three: wxPackageManager, wxPackager and wxp.

wxPackageManager is a GUI application that lets you browse local and remote package repositories, view a summary and details of the packages, and then download, compile, install, and uninstall them.

wxPackager is another GUI application that helps you create and edit a package description file, and upload the compressed package archive to a remote repository.

wxp is a command-line utility that allows you to perform all tasks exposed by the wxPackageManager and wxPackager GUI and also create and maintain repositories of packages.

Francesco Montorsi has already worked on valuable wxWidgets enhancements, but has excelled himself in this project, bringing a high standard of coding and attention to detail. It needed a fairly broad range of skills including knowledge of GUI design and implementation, network programming, multithreading, and XML. The project will make a significant difference to the ease of use of wxWidgets components when the package format is taken up by component authors. It’s doubtful if the package manager would have been built without the support of Google.

Links:

The CVS repository where the sources are hosted:
http://cvs.wxwidgets.org/viewcvs.cgi/sandbox/packagemanager

The server which hosts the latest release of the three programs:
ftp://ftp.wxwidgets.org/pub/utils/wxp/

Screenshots of wxPackageManager and wxPackager on Windows:
ftp://ftp.wxwidgets.org/pub/utils/wxp/wxpackagemanager.jpg
ftp://ftp.wxwidgets.org/pub/utils/wxp/wxpackager.jpg

The Package Manager on Windows XP:


Network class improvements

Angel Vidal’s project involved a range of fixes and enhancements to the wxWidgets network classes. These include unifying socket code for each plaform and rationalising common code; applying patches and updating the SourceForge trackers; adding proxy support for Connect() calls; improving UDP socket support; and testing on Linux 32/64, MSW and Mac OS X.

These improvements haven’t yet been incorporated into the main development branch, but we hope that after a little more work the result will be far better and more easily maintainable network code than in wxWidgets at present.

Angel's code is available in the SOC2006_SOCKET CVS branch.

Right To Left language support

As befits a framework developed by a group of people from many different countries, wxWidgets has long had facilities to help with internationalization and localization issues, but until now it had no support for RTL (right to left) scripts such as Arabic or Hebrew as we didn't have either the resources or knowledge of these languages necessary to implement it. Diaa Mahmoud Sami Abdel-Ghani started on the project to change this and to add full RTL support, including mirroring of the GUI elements, to the library. The project started well enough with the discussions of the API changes needed for this and, relatively soon thereafter, Diaa wrote the code to allow wxWidgets applications to show up correctly in Arabic locale under Microsoft Windows. Unfortunately, after the mid-term point almost no more work had been done until the very last few days of the program, and so the initial goals hadn't been fully achieved which led the mentor to give a negative final evaluation. Nevertheless, the project was far from being a complete failure as all code written by Diaa was integrated into the main wxWidgets sources and several people, notably Tim Kosse and Robert Roebling, were motivated enough by this to fix the remaining bugs and add RTL support for the GTK+ port.

So, while this project wasn't an unmitigated success from the student's point of view, it definitely helped wxWidgets as it has gained RTL support - probably imperfect but incomparably better than no RTL support at all. It wouldn't have happened without GSoC.

The RTL support is in CVS HEAD (2.7).

Beware: 2.7.1 Coming Tomorrow

wxWidgets 2.7.1 will be released on Wednesday October 11 2006 (I thought the year was worth mentioning, especially for people used to our usual release schedules). So today you have the last chance to test your code using the latest cvs sources or the last daily snapshot and let us know about any new problems in 2.7.1 so that we could fix them before the release (and, of course, break something else to compensate for it).

Please pay attention to the documented incompatible changes in the beginning of docs/changes.txt, especially if you hadn't used 2.7.0 before.

Thank you for testing!

wxFileDialog and Windows Vista

There are some changes regarding the native file dialog
in Windows Vista. Perhaps best explained by a shell
developer here: If one changes properties of the native
file dialog, one gets the "old" file dialog from Windows XP.

Here's an example of the difference: ("Old" is the first menu
option from the filedialog portion of the dialog sample, "New"
is the second.)

"Old":















"New":
















The problem is that the dialogs sample uses
> dialog.CentreOnParent();
which causes Vista to revert to the "old" file dialog.

So, if you are using common dialogs just keep an
eye out if you customize it all; as even centering it
with its parent could change the appearance of it.
In fact, calling any wxWindow method can be
problematic as it can make the look of a common
dialog non-native, or it may not work at all (in
some cases on some platforms setting the
background color doesn't work, for example).

I posted on the mailing list awhile back,
http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?5:mss:78283:200610:fgbndhmhiamfkklpjajh
but sometimes it is a lot better with pictures :D.

Also, it still happens with RC2, which is supposively
the last release before RTM (Release To Market),
so it is likely that this will stay.

For those to wish to interact with the new Windows
Vista file dialog API, they can use the IFileDialogXXX
COM interfaces. This also includes derivatives
such as IFileOpenDialog. Hopefully wxWidgets
won't end up having to support a seperate file
dialog interface; but then I guess one could
just pImpl it as well.

March of progress in action: wxAboutBox()

Finally, 13 years after its beginning, wxWidgets has gained this mostly indispensable feature of any modern GUI toolkit: the possibility to show the standard "About" dialog with one line of code. As of today, wxAboutBox() function can be used to create a dialog box like this

or like that

or, if all else fails, like this

The generic dialog is not finished however as the best way to implement is seems to be using yet another new control: the hypothetical wxCollapsiblePane. The hope is to have it soon, finish wxGenericAboutDialog next, and release 2.7.1 immediately thereafter.

What would you like to see out of wxBlog?

What would like to see out of wxBlog?

Current ideas are:
- Weekly recaps
- Just major events

Maybe this with personal commentary by
developers and former developers?

This blog was started not really out of
personal need, but more out of some of
the ideas on the developer's mailing list. I
(Ryan) will of course try to have a little fun
every now and then as well.

Feel free to comment!

Early October and a bit of September recap

The wxDataViewCtrl class gotten some documentation.
wxDataViewCtrl aims to be a replacement for wxListCtrl
and wxTreeCtrl.

A standardized, and sometimes native, way for showing
an about dialog was added to CVS. The main way to do
this is through the wxAboutBox() function .

There is a bit of discussion over the status of the
SOC2006_SOCKET branch of CVS. This was the branch
started as part of Google's summer of code to make
improvements to the wxSocket APIs and implementation.

Changes to the wxIcon API on wxMac were also proposed
in order to better interact with the native Carbon API. Ports
are often inconsistant on the ease of use with
Native APIs; for example wxMac does not have a streamlined
way to interact with all types of window handles, such as
wxWindow::AssociateHandle; often times this is due to
the design of the Native API itself.

New classes for graphics were added, including wxGraphicsPath
and wxGCDC, in order to interact with APIs such as GDI+
on Windows and Cairo. There is currently no documentation
for the classes, however. The interface is available through
wx/graphics.h.

2.8 Release Schedule

Welcome to the wxBlog!

There is a bit of a flurry on the development side lately
in an effort to get out a 2.8 release. According to a recent
thread on wx-dev (the developer mailing list), there are several
reasons for this. The most prevalent reason appears to be the
impending release of Leopard (or OSX 10.5), the next version of
the macintosh operating system. Stefan Csomor, the lead of the
mac port of wxWidgets, expressed that the mac port of
wxWidgets was not "up to snuff" enough for leopard.

A possible part of the reasoning is that wxWidgets
is included in Tiger (OSX 10.4), and is going to be included
in Leopard as well.

Several possible targets were discussed. Stefen expressed a
desire to get the final 2.8 release in time for Leopard,
possibly as soon as the end of the month (November 1). Some
others discussed an end-of-year target.

Currently discussions are underway for the release of 2.7.1, the
next development version.