Forgot your password?
typodupeerror
GUI Open Source

WxWidgets 3.0: First Major Release in Several Years 147

Posted by Unknown Lamer
from the still-breathing dept.
First time accepted submitter VZ writes "The first new stable wxWidgets release in years and the first new major release since 1998 has just been announced. wxWidgets 3.0 now includes official support for Cocoa-based 32 and 64 bit applications under OS X, GTK+ 3 under Unix and has thousands of other improvements." Update: 11/12 01:00 GMT by U L : Clarification: it's been several years since the 2.8 release series, and fifteen years since wxWidgets 2.0.
This discussion has been archived. No new comments can be posted.

WxWidgets 3.0: First Major Release in Several Years

Comments Filter:
  • Yes, we can all look it up, but would it have killed the submitter or editors to mention in the summary, even with a sentence or two, what the heck WxWidgets actually is?
    • Yes, we can all look it up, but would it have killed the submitter or editors to mention in the summary, even with a sentence or two, what the heck WxWidgets actually is?

      WxWidgets, support for OS X, Cocoa, GTK+ 3 ... if you are a geek that kind of tells you everything you need to know to make a well educated guess. If you are not a geek, and missed the link to their website in the summary, WxWidgets is a cross-platform library for GUI development on Windows, OS X, Linux and mobile/embedded flavors of these same OS'es. It allows you to develop apps for anything from full blown desktop OS'es through mobile phones, to things like cash registers and handheld credit-card swiping

      • by Anonymous Coward

        Does it support Qt? :P

        • by VZ (143926)

          Not that I can't get a joke but actually, there is wxQT [wxwidgets.org] (albeit in a pretty preliminary state AFAIK, but then I've never really looked at it myself).

    • by guruevi (827432)

      Please hand in your geek card.

      If you are on /. with an ID smaller than mine, you should know what wxWidgets is. It's been covered before when they got Perl integration: http://developers.slashdot.org/story/01/09/18/121209/new-perl-gui [slashdot.org]

    • by LWATCDR (28044)

      A. This is news for nerds.
      B. Click on the supplied link.

      It is a cross platform UI toolkit that defaults to native widgets.

  • by fatphil (181876) on Monday November 11, 2013 @08:19PM (#45396125) Homepage
    2013 - 1998 = 15

    Fifteen != Seven

    Slashdot Editors != Editors
    • by Anonymous Coward

      "The first new stable wxWidgets release in years and the first new major release since 1998"

      Read that again more carefully.

    • by fatphil (181876)
      Explanation, which the useless wastes of biomass couldn't be bothered to include in the summary:

      This is the first stable release for 7 years, which presumably has had a whole bunch of maintenance (minor) releases in the prior 8 years since the last actual "major" release.

      Strangely, I don't see IOS and Android (yeah, yeah, and Tizen, not that you pay me to say that) listed as supported platforms, so they're kinda marginal here.
    • by BSAtHome (455370)

      "Big number" minus "Another Big number" is approx.7

      That is about right, isn't it?

      Just like 2+2=5 for large values of 2.

    • It looks like the new generation of kids is redefining "several" to mean "seven". Generally, "several" is used to mean more than three, but not much more than 3. The progression is "a couple" (2), "a few" (3), "several" (more than 3, but not too many), and "many".
      • by Aphadon (3402087)
        Depending on your species, it could also be one (1), two (2), three (3), many (4) and lots (16).
      • by Desler (1608317)

        No, you simply missed that the "editor" had said it had been seven years. Your post qualifies for the standard "Whoosh?" response.

    • by pjrc (134994)

      wxWidgets 2.6 and 2.8 were pretty major releases, actually.

      • by tinkerton (199273)

        Yes, one wonders if they've made an ordinary numbering policy for releases into something more fundamental. On the other hand one could claim that development on Wxwidgets is not as dynamic as on QT.

  • Its great they are still alive, but how many people have moved over to other toolkits like QT the years?

    Why would it be worth going back?

    • by VZ (143926) on Monday November 11, 2013 @08:47PM (#45396313)

      The main reasons to prefer wx to Qt remain the same as always:

      1. Native widgets (especially important under OS X).
      2. Written in 100% standard C++ (no compiler-specific extensions, no preprocessor).
      3. More permissive licence (notably allowing static linking for non-open source applications).

      And then there is wxPython which is quite popular in Python community.

      • by Lord Crc (151920) on Monday November 11, 2013 @09:59PM (#45396773)

        1. Native widgets (especially important under OS X).

        Ironically this is the reason we moved our cross-platform OSS app away from wxWidgets to Qt. The native widgets just didn't work properly and it was a pain to fix. We made the move some 4 years ago or so, and I can't say we've noticed we're missing something...

        • by dkf (304284)

          1. Native widgets (especially important under OS X).

          Ironically this is the reason we moved our cross-platform OSS app away from wxWidgets to Qt. The native widgets just didn't work properly and it was a pain to fix. We made the move some 4 years ago or so, and I can't say we've noticed we're missing something...

          Some users really want the perfect look of native widgets, though totally looking correct does require more than that, as different platforms have different layout norms too (and then there's the "feel", which is harder still unless you go completely native). Other users don't care nearly so much.

          • by Lord Crc (151920) on Tuesday November 12, 2013 @05:40AM (#45398877)

            Some users really want the perfect look of native widgets

            Yeah, I get that. But given than the OSX offering from wxWidgets was pretty much broken on a constant basis, not-quite-native-but-functional Qt widgets won the day over broken-every-other-week wxWidgets.

            I exaggerate slightly, but the lack of proper OSX support was the main driver to Qt for us.

            • by anarkhos (209172)

              What app? I have yet to use a Qt app on OS X which wasn't a complete clunker. May as well just use wine

              • by Lord Crc (151920)

                What app? I have yet to use a Qt app on OS X which wasn't a complete clunker.

                To be fair, our GUI demands are very modest. Project is LuxRender [luxrender.net], a physically-based open-source renderer. The GUI is mostly just for visualization of the resulting render and tweaking tonemapping and other post-process parameters.

      • by LWATCDR (28044)

        It is also pretty light not as light as the FLTK but still pretty light.

      • 3. More permissive licence (notably allowing static linking for non-open source applications).

        And then there is wxPython which is quite popular in Python community.

        This.

      • 1) This could be a factor. I don't develop for OS X but it could be relevant to some (Although, personally, I feel there's too big of an obsession about "look and feel" from mac users).
        2) This is barely relevant, imo. MOC does a great job and code generators have always been a good thing if you know what they generate and are one way only.
        3) This could be a factor although I don't usually see a problem with dynamic linking.

        for Qt, there's PyQt (I've used it and it's great) and PySide (no idea).

        I used WxWi

    • by LWATCDR (28044) on Monday November 11, 2013 @08:47PM (#45396317) Homepage Journal

      I would say yes. Unlike QT it uses Native Widgets so it looks more like a native app than a QT or GTK app does. It was also pretty light weight as well. The fact that Audacidy uses it means that it is important enough. If you are a developer and are interested in multi platform it is really worth the time to explore.

    • by oodaloop (1229816)
      Their website has a list of users [wxwidgets.org]. It's more than a few.
    • by pjrc (134994) <paul@pjrc.com> on Monday November 11, 2013 @08:55PM (#45396369) Homepage Journal

      I use wxWidgets. I've mostly used verson 2.8 with ansi strings.

      As far as I know, wxWidgets is the only cross platform toolkit that compiles to program that use the native GUI widgets on Windows, Mac and Linux.

      You can usually spot Java and QT programs. They work, but things look a little out of place. Firefox does a better job, but things start going wrong if the user customizes or "themes" their desktop. Emulating the look of native GUI controls just isn't ever as good as actually using the native ones.

      wxWidgets isn't perfect. I've hit a good number of bugs. It has a pretty steep learning curve. It also doesn't seem like "new" technology. But it works. If you want to write a native application that truly looks and feels and actually is native on each platform, short of writing the code 3 times, wxWidgets is pretty much the only toolkit.

      • Xojo [xojo.com] (formerly RealStudio) is a visual basic-like language except that it's realy OOP (has nice things like interfaces and delegates for example) that compiles to programs that use native GUI widgets on Windows, Mac, and Linux. No, it's not as powerful as C/C++, but it's a lot easier/quicker.

        It's biggest weakness (IMHO) is that it's developed by a small, private firm that seems resource constrained. This leads to some releases having real issues and it taking some time for those issues to be sorted. Tha
  • FTA:

    So wxWidgets 3.0 is finally released. We should have done it much sooner than 7 years after 2.8.0 release, but better late than never. And at least this gives us a lot of statistics to analyse to see how much has changed since the last major release. So let's do just this.

    Yes, this should have been explained in the summary. No, the editors did not catch it which sucks. Yes this is the first X. release since 1998 or 99 depending on your source.

  • ... that everyone's using and needs no introduction.
  • If I'm parsing this all correctly, this is great news because it means I can port my graphical C++ (or whatever language, with hooks to C++) applications from Linux to Windows or OSX (or from Windows to Linux or OSX, or from OSX to Linux or Windows, whatever the case may be) without having to worry about UI widgetry.

    Of course, unless my applications are already written in a language WxWidgets likes, and don't make any calls to other platform-dependent things (DirectX, I'm looking at you), this sounds like i

    • by osu-neko (2604) on Monday November 11, 2013 @09:40PM (#45396637)

      Admittedly, I haven't tried porting graphical apps across platforms before, so for all I know, getting the UI widgetry right could very well be 90% of the work.

      Yeah, writing the UI code is 90% of the work. Debugging it to work consistently across all platforms is the other 90%...

    • by pjrc (134994) <paul@pjrc.com> on Monday November 11, 2013 @09:47PM (#45396687) Homepage Journal

      I use wxWidgets. Most of my experience is with version 2.8.

      If you care deeply about making a native applcation that truly has a native GUI on Windows, Mac and Linux, wxWidgets is great. Nothing else even comes close. Java, QT, XUL, FLTK, TCL/KT and others all produce programs that aren't quite right on some plaforms.

      If you don't care about cross platform native GUI applications, or you target browsers with javascript+node+[insert newest buzz], then wxWidgets is not for you. If you really only want to produce a program for Windows but maybe someday have the option to easily port to Mac and Linux, while wxWidgets can give you that, if you don't truly care are doing all 3 from the beginning, I believe you'll find wxWidgets it simply too much trouble.

      The truth is wxWidgets is pretty much its own system, an SDK in itself. It has a tremendous amount of somewhat complex design, like sizers, which means you have to go to some extra effort. Of course, for making things work well on all platforms... not simply just work, and not work well on Windows but end up sub-standard on Mac or Linux, but work truly well on all 3, the extra effort to use wxWidgets is definitely worthwhile.

      But the truth is you do have to put in extra effort. wxWidgets has great documentation to help, but the other truth is everything is heavily steeped in C++ class heirarchy. If you're good with C++, it'll feel pretty natural. If not, well, you'll get much better with C++ in the process, if you persevere. In the end, if your goal was a native application that truly works natively on all 3 platforms, the sort of thing users take for granted and never notice, you'll be rewarded.

      But if you don't really, truly, earnestly care about targeting all 3, if only Windows has to be high quality and the others are afterthoughts, or if you just want to get things done as quickly as possible with minimal learning, you'll probably find wxWidgets to be far too much trouble.

      • by Plouf (957367)
        Note that in Java you can get something similar by using SWT, which uses JNI to call the native underlying platform widgets. Used by Eclipse but can be used in a small standalone J2SE application. http://eclipse.org/swt/ [eclipse.org]
        • The problem with SWT is: it does not look native, it looks like SWT.
          On top of that, unless you have access to higher level "frameworks" programming SWT widgets feels like MFC from 1993.
          In comparision with Swing it simply sucks.

          • by Plouf (957367)
            I couldn't disagree more: I've been doing SWT development for many years, and I can tell you that SWT applications are impossible to distinguish from native applications, on any platform. Sure Eclipse looks like nothing but Eclipse, but if you take well-written SWT applications (Azureus for instance), no-one would be able to tell you that it is made out of Java. From a user point of view, SWT is just invisible. On a programming point of view, I would agree though: SWT is extremely low-level and the first th
            • and I can tell you that SWT applications are impossible to distinguish from native applications, on any platform.
              Sorry that is complete nonsense.
              The "layout" and many other things always scream "SWT!!!". If something "looks like eclipse" you can bet its SWT.

              • by Plouf (957367)
                We are probably not talking about the same applications then... Look at "azureus java" or "azureus screenshot" on Google Images and tell what reminds you of Eclipse from that.
    • by sg_oneill (159032)

      GCC and a cross compiler should be fine ,but if you got visual studio and put the effort into including a compile change for it, ,theres not a good reason not to use it.

      WXWidgets is great but its kind of shown a lot of bitrot over the years leading many to suspect its been abandoned. Apparently it hasnt. Its also had a degree of issues with dll hell in my experience, but thats more using it with python and a few non wx libraries that havent updated in millenia.

      It DOES tend to look good on native platforms b

      • by pjrc (134994) <paul@pjrc.com> on Monday November 11, 2013 @10:48PM (#45397047) Homepage Journal

        I've build programs with wxWidgets 2.8. It does automatically handle those platform specific style issues!

        I used wxMenuBar, populated with a heirarchy of wxMenu and wxMenuItem objects. I just pass a point to the main wxMenuBar object to SetMenuBar, which is from the top-level frame of the GUI.

        On Mac OS-X, it automatically appear at the top of the screen. One Linux and Windows, it automatically appears on the top of my program's window.

        Likewise for toolbars, I simply used with wxWidgets objects as documented, without any specific style stuff. They automatically adapt to fit the style of each system.

        That's the magic of wxWidgets. That work you mentioned, adapting things to fit the stylistic expectation of each system, is exactly what wxWidgets does so very well. It's vastly superior to other toolkits which attempt draw their own widgets, because the wxWidgets developers have gone to tremendous effort to actually use the native widgets from each platform. You just use the rather generic API for wxWidgets and you end up with really good native GUIs on all 3 platforms. Best yet, when the user customizes fonts, colors and whatever else, your program adapts like other truly native applications. Other cross platform toolkits fall down in that respect to the customized style, because they aren't really using the platform's native GUI.

        • by Raenex (947668)

          Best yet, when the user customizes fonts, colors and whatever else, your program adapts like other truly native applications.

          It also makes a huge difference if you're using an app via a remote desktop. Native widgets can be efficiently mirrored without sending all the pixels over.

          • by spitzak (4019)

            Native widgets can be efficiently mirrored without sending all the pixels over.

            That has not been true for a decade at least. Remote desktop on Windows sends images (with lots of compression and reuse of previosly-seen images).

            The problem is that the api to widgets is far larger than the images themselves. Remote widgets would actually increase bandwidth, not decrease it.

            • by Raenex (947668)

              The problem is that the api to widgets is far larger than the images themselves. Remote widgets would actually increase bandwidth, not decrease it.

              Sorry, this doesn't make any sense. Just consider the number of pixels that would be rendered in an editor window with a scrollbar. Now imagine all the painting a remote host would do if it wasn't native and you scrolled down.

              The difference is night and day between a non-native widget and a native one. I've done professional work using remote desktop, and I always knew when an app wasn't using native widgets.

  • Trolltech's QT (Score:5, Interesting)

    by EmperorOfCanada (1332175) on Monday November 11, 2013 @09:07PM (#45396455)
    I have wanted to love wxWidgets but I keep going back to QT. Now that QT is allowing you to port to Android and iOS I am not sure that I will ever take another crack at WX.

    Other multi platform GUI'ish things that I like are OpenFrameworks (main complaint is that it runs hot) and cocos2d-x which allowed me to turf Objective-C on iOS.
  • by innocent_white_lamb (151825) on Monday November 11, 2013 @09:18PM (#45396533)

    There's nothing wrong with C++. However, I do my programing in C (without the ++), and would love have something like this available that I could link to my C programs.

    GTK+ works fine in its way, but it moves way too fast for my taste. Function x is deprecated, use function y instead. Function y is deprecated, use function z along with function z(1) now. Ok, it's great that you're improving that thing, but not so great for a guy like me who wants to write an application today and use it for the next ten or twenty years without having to re-invent the wheel over and over again.

    Since I have no particular desire to learn C++, I now do most of my programming using ncurses to handle the screen, keyboard and (occasionally) mouse. Ncurses is a Text-UI rather than a GUI, but just like the C language itself, it works very well,it hasn't changed in many years, and it suits me fine.

    A slow-moving GUI like wxwidgets would be a wonderful thing to add to my toolbox, if it was a C library. *sigh*

    • by OldFart58 (663547)

      If it was a C library... well, you couldn't really take advantage of all of the advantages C++ has vs C especially when implementing a windowing UI / application framework - inheritance, polymorphism, etc. really make a difference. If you did that in raw C you'd have, well - pretty much what we had to use for programming to the Win16 (now Win32) API before Borland's OWL (Object Windows Library) made the scene (this is before MS ever came up with MFC) - opaque handles to this and that, breaking down and han

      • by spitzak (4019)

        GTK is a serious attempt to make a C object-oriented library. Not sure how well it works but it is more modern than your examples.

        A advantage of working with C is that it is much easier to support it in *multiple* object-oriented languages, not just C++.

    • by Anonymous Coward

      Do you really develop GUIs in C? I did that on X years and years ago and know its possible, but when you compare writing UIs in C++ vs C there really isn't much comparison. I doubt anyone would make a really good UI toolkit in C anymore.

      I doubt you are making UIs in C, maybe you are one of the last ones. You can make your UI in this, yes using C++ and just make calls to your C libs.

      • by pjrc (134994)

        Really, you've written GUI programs using GTK's C-only API and liked it?

        Did you really enjoy all that type casting of pointers? That's a lot of unnecessary trouble, when clearly some dialog box must be able to use the more generic window style setting functions. If only the compiler somehow could know your reference to the dialog box is compatible with all that other stuff the dialog box is built upon.... if only....

    • by VZ (143926)

      I've never used it myself but there is wxC [sourceforge.net]. AFAIK it's mostly used as a base for the bindings to the other languages (like wxHaskell), but perhaps it is good enough to be used directly.

    • by istartedi (132515)

      My solution to this problem is to let the GUI be C++, and have all your C in a library. I got used to doing that back in the MFC days. I learned C++ first, then learned C. My appreciation for C grew from looking at things like the JPEG libraries, which seemed to run on every system ever devised.

      IIRC, I didn't like wxWidgets because it seemed to insist on rolling its own versions of libraries that already existed. With 12 years of development since I lived in that world though, maybe they've got it down

    • by Jeremi (14640)

      However, I do my programing in C [...] Since I have no particular desire to learn C++

      I think if you learned just the basic parts of C++ you'd find it's much quicker and easier to get things working reliably than using straight C. The trick is to ignore the 253 different categories of nifty/obscure feature you don't want to deal with -- rather, only use the parts that you want to use. In particular, constructors/destructors, inheritance, virtual methods, and basic templates can all be huge time-savers once you're used to them. I started in my programming career using C, but after using C+

Real programmers don't write in BASIC. Actually, no programmers write in BASIC after reaching puberty.

Working...