wxWidgets is an OpenSource (both GPL-compatible and commercially-distributable), cross-platform GUI framework. It is written in CeePlusPlus, but bindings are available for other programming languages. wxWidgets was formerly known as wxWindows; the name change occurred after "discussions" with Microsoft over the use of the word "windows". See http://www.wxwidgets.org/ Also note, the product is soon to have an embedded version release. http://wiki.wxwindows.org/wximages/wxwidgets02-small.png A wiki is dedicated to it at: http://wiki.wxwindows.org ---- '''Details''' wxWidgets is a cross-platform library that provides facilities like sockets, threads, and a GUI library across operating environments including UNIX/GTK, MS Windows and MacOS. A very stable product, and a pleasure to program in. Some have described wxWidgets as '''what the standard c library should have been''', based on the breadth of its support (for example, see http://www.wxwidgets.org/manuals/2.5.2/wx_topic929.html#topic929). You'll see many of them are _not_ GUI functions, and a lot of them are handy - and that's not even the main part which are the c++ classes. WxWidgets is suitable for commercial applications; it is licensed under the LGPL, modified to add permission to statically link to it without having to distribute the source. ---- '''ExtensibleMarkupLanguage and WxWidgets''' http://xml4wxwindows.sourceforge.net/ ''Is this still active? Any other significant alternatives?'' ---- '''Comments/Appreciation''' Although I haven't gotten around to trying it, my impression over the last few years while evaluating various cross-platform GUI solutions is that this is one of the very few industrial-strength open source cross-platform widget sets, so that it's one of only a small number of choices if you want to write an app with a sophisticated GUI that is fairly trivial to compile and run e.g. both on Linux and on Windows from the same code base. -- DougMerritt The "about" at that URL adds that it also offers "online help, network programming, streams, clipboard and drag and drop, multithreading, image loading and saving in a variety of popular formats, database support, HTML viewing and printing, and much much more" ---- '''The Windex window pane cleaner project''' Shouldn't it be called "Windex"? ''If that name isn't taken, you should start a project based on it. :-)'' ''Windex is a product to wash window panes.'' ---- '''Interesting discussions on WxWidgets''' ''difficulties in having WxWidgets work well in different windows environments'' http://freedesktop.org/pipermail/xdg/2004-September/004698.html * can make to look good and yet does not feel right * This has very good points, and nobody who's done real cross platform programming would dispute it, but wxWidgets does, as much as possible, take on the aspects of the desktop environment as well as just the widgets. There's a lot of work being done in this direction. In the places where the toolkit can't just DoTheRightThing, it tries equally hard to let you make the correct decisions without interference. Unlike the implications of the post, wxWidgets also avoids taking the LeastCommonDenominator approach to widgets: it emulates most widgets that are unavailable. Since the emulated widget often involves more work, it's often less functional, pretty, and complete as the native one on other platforms, but they do make the effort. They do not, generally, discard functionality in the name of compatibility. ---- ''' WxWidgets QuickQuestions ''' '''Q''' Are there side-by-side execution problems for products that can use different versions of WxWidgets? For example, if I use WxPython that includes a version x of WxWidgets, will it clash with another software that uses version y? How are these problems overcome? -- DavidLiu '''A''' wxPython has a private copy of wxWidgets that won't interfere with any C++ wxWidgets apps you may run. Recent versions of wxPython include versioning support allowing side-by-side installs of multiple wxPython versions with run-time selection. C++ wxWidgets apps have the same problems or lack thereof that any application using a library does. Unlike some libraries, wxWidgets fully supports static linking, though, so you can reduce those concerns at the cost of some code bloat. --ChrisMellon '''Q''': We all know it is very hard to write a GUI in C and C++. Will the coding become easier with WxWidgets? '''A''' I didn't know that we all knew this. I know a lot of people can't possibly write GUIs without a drag and drop form designer but I'm not one of them and in fact I can't even understand how people find them usable. In any case, drag and drop form designers are available, although the most polished of them are commercial. Anyway, yes, wxWidgets will make it easier. That's what toolkits are for, right? I'm a long time user of wxWidgets, so of course I'm biased, but I find the object model and assumptions to fit well with what I do, and the library has the feel of something that's actually been used to it - as I developed applications with it, I'd run into a problem and I would almost always find that someone else had already had this problem and there was a convenient solution already available. --ChrisMellon '''Q''': Yes, actually, we do all know this, so your response is extremely suspicious. I remember my first Java experience; everyone said, "gee, it's so easy to write GUIs in Java", so my hopes were up. It took 1,000 lines of Java just to put up a toy window with a couple of widgets. I've done extensive GUI programming with X11, and one can get the job done with widget toolkits like Xaw, Motif, etc etc etc, but I wouldn't call it "easy". Take a command line utility, even one with a lot of options like '''ls''' or '''find'''. Now adapt it to have a GUI interface. Now look at the lines of code. 90% of them will now be GUI related; the complexity of implementing the GUI essentially always dominates. And inevitably it turns out that eventually one needs to do things that the widget toolkit didn't provide. Next thing you know you've had to write 1,000 lines of Xlib code and 5,000 lines of code reimplementing widgets because the originals provided 90% but not 100% of what you needed. Or you try something that promises simplicity, and the examples do look simple, like Tcl/Tk -- but although it's easy to do simple things, it again becomes very difficult and takes many lines of code to do anything a bit sophisticated. There's something wrong here, probably because the field needs some new ideas that haven't come along yet. So don't take that snide tone of voice that there's something wrong with anyone who complains about GUI programming. It's '''NOT''' just about Basic programmers who can't handle programming if they don't have a Form Design Wizard. I've done device drivers for graphics cards, I've modified the XFree86 Xlib internals, I know the X11 protocol, I've used many widget sets, I've '''implemented''' widget sets, etc etc etc -- I'm not in need of any handholding, but I'm telling you, yes, GUI programming is hard, and tedious, and a pain, and we're all looking for a cure for the disease. So again, your response is extremely suspicious, because it sounds like you are simply desensitized to the fact that, yes, GUI programming is indeed hard, and so long as you think that it's perfectly reasonable to have to spend 5,000 lines of code on the GUI aspect of otherwise small programs, then you're not going to have much meaningful to say about whether WxWidgets improves on the usual situation or not. -- DougMerritt '''A:''' I'd be the first to agree that there's a lot of code involved in writing GUIs, I was responding to the word "hard". I don't find GUI programming hard, even in C++, although I won't argue with tedious. There's a fair amount of boilerplate involved, which is common in C++ applications. You can toss some by using the XRC-based file format to handle your widget creation and placement, meaning that most of your code is your app behavior. But wxWidgets isn't magic and I wouldn't claim that it's unusual in this regard. Using wx ''is'' a heck of a lot easier and less code than writing it all yourself against xlib or the win32 API. Part of the problem is the amount of hand-holding C++ requires, wxPython, for example, is far less verbose and requires far less boilerplate than the C++ API does. What would you consider the peak of GUI programming, and what precisely are you looking for? You could write a form that runs LS and captures the output to a text window in a couple hundred lines with wxWidgets, most of which would be boilerplate. It'd be maybe a page in wxPython. But that's a pretty useless application, and something which, say, recreates a file browser is going to be more. I'm not claiming, and as far as I know nobody does, that wxWidgets takes all the pain out of writing a GUI (especially a cross-platform one), simply that it does a good job of reducing it. There's never going to be The One True Toolkit where you never need to create a custom widget. * What am I looking for that would be the peak? A paradigmatic breakthrough, of course. GUI programming is tedious the way assembly language programming is tedious. I'm working on it, but it's of course hard to come up with new paradigms. * P.S. You're underestimating '''ls'''; look at the man page, and think about the widgets needed to replace each of the command line options. Besides which, if one went to that much trouble, then yes, it would need some extra file browser features -- but it's nontrivial even before that point. The sheer number of options would pose some usability issues with widget type/layout etc; the ultra-naive approach would be awfully cluttered. I wasn't trying to be snide - most of the time when that question is asked people are looking for a form designer. --ChrisMellon (who also wrote the above answers). '''Q''': So, where can I find these form designers? :-) -- DougMerritt '''A''': http://wxwidgets.org/lnk_tool.htm has a listing of IDEs and dialog editors. DialogBlocks is generally considered to be the best of breed, although I prefer the OpenSource XRCed. See also http://wiki.wxwidgets.org/wiki.pl?IDEs * Thanks. I may try it out on some personal projects at home later this year, so free-as-in-beer is of course the way I'd go. Contributors: RyanNorton, et al. See: WritingPortableApplications, GuiFrameworks