I've just done something that I hadn't done during the entire time I was working on wxWidgets: removed an entire port. And not even just one of them but two at once: wxPalmOS and wxMGL. The latter wasn't used since many years and I don't think the former has been ever really used at all. Moreover, the platforms targeted by these ports don't themselves exist any more. So removing them was a pretty straightforward decision as there were no benefits at all in keeping these ports while maintaining them took small but non zero amount of work.
The decision is less clear cut for them but there are other ports which might be dropped soon too. wxGTK1 will probably disappear when GTK+ 3 support is merged into trunk. The old Cocoa port should be removed too, if only to avoid confusion with the new wxOSX/Cocoa. wxMotif is definitely not very relevant any more so it will probably go as well. I'm not sure if anybody is interested in wxPM (OS/2 port) but it could be a candidate for removal in the near future as well.
The one port which we, or at least I, had high hopes for was the DirectFB-based wxUniversal, a.k.a. wxDFB. Unfortunately it hasn't attracted any interest from the community so it has never developed into a fully-fledged port. This is really a pity as I'd like to see wxWidgets used more on low-powered embedded devices where DirectFB is pretty popular and I still hope that we can find somebody interested in working on it. And while there is hope, we're not going to remove it, even if it's really not very useful in its current state.
With all these ports gone or going, what is remaining? The three major ports are, as always, wxMSW, wxGTK(2) and wxOSX. wxDFB, wxX11 and wxWinCE are not used much but still exist in a more or less reasonable shape. We also hope to have wxGTK3 soon and, more excitingly, the new wxiOS port. Other than that, wxQt port was started but seems to have stalled and, in any case, it was never clear if it made much sense. wxAndroid would be the port I personally would most love to see but it requires a big effort and in spite of having been discussed several times nothing much has happened.
I think writing new ports -- or maintaining and improving the existing ones -- is much simpler now than it used to be because of the clear definitions of the classes API (for the most part anyhow), more clear documentation and the unit tests allowing to automatically check the code correctness. And working on your own port is very rewarding and (at least in my, perhaps atypical, opinion) a lot of fun so if you're looking for a fun open source project for 2012, you could do worse than choose working on wxSomethingOrOther!
Subscribe to:
Post Comments (Atom)
6 comments:
One of the reasons for the relative silence around wxDFB is that it's really not in such a bad shape as you seem to assume - I can assure you wxDFB is still in active use in a whole family of products (the youngest member hasn't even hit the market yet)!
Hi Anders (and happy 2012!),
I'm definitely glad to hear that it's still used by you but I hoped that it would attract other people too, it's a bit awkward to rely on a single user for this port, even if it's an important one. And I am quite sure that it could be useful in a lot of places as wx API is much more powerful and significantly simpler to use than raw DirectFB. So I'm somewhat surprised by the lack of interest in it...
Vadim, shortly, very good decision. In my opinion wx should concentrate on the following platform:
-Windows 2K8/XP/7 etc. 32-bit and 64 bit
-Linux Ubuntu/Centros/Redhat
-FreeBSD/OpenBSD
-MacOS
and....
Android, or other portable mobile Linux
that's really lots of platform, and lots of work.
Regards, Daniel
In order to attract new developers, I think that all ports should at least be mentioned in the official documentation.
This page: http://docs.wxwidgets.org/trunk/page_port.html only mentions wxWinCE and none of the other embedded ports. A good place to get started seems to be here: http://www.wxwidgets.org/docs/embedded.htm , but if I want to check for instance what classes are supported (http://wiki.wxwidgets.org/Development:_Supported_Classes) wxDFB is not even mentioned.
This is a "Thank You!" to the Vadim and all the other maintainers and developers on the associated projects.
Thanks for your hard work - I hope myself to take part. I am not going to use the usual (and very true) "no time" excuse though - in my case I just need more practice before I feel competent enough to weight in. I will be working on the Ruby port when I can :) I would absolutely love to work on the embedded device library, but I have no such device ;) I used to write 8-bit games.
Anyway, thanks again for your hard work!
Kevin
I know this is a pretty old post, but I think that wxDFB (wxUniversal) still has potential. However, I think it really needs to find its way into the existing ports: wxMSW, wxOSX, and wxGTK. (Of course, the existing wxDFB portion can be kept, too!) Basically, (assuming wxDFB has good theming support) wxUniversal can be a "Qt for wxWidgets", with skinning and such. If you enable custom drawing in the modern ports, wxDFB kicks in and does it.
I'm probably just babbling nonsense, but hopefully you can see my idea!
Post a Comment