Slashdot Mirror
WxWidgets 3.0: First Major Release in Several Years
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.
2013 - 1998 = 15
Fifteen != Seven
Slashdot Editors != Editors
Also FatPhil on SoylentNews, id 863
Seven, of course.
Didn't you read the summary?
Required reading for internet skeptics
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?
---- Booth was a patriot ----
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 machines.
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.
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
This is my first ever submission to /. so maybe it's perfectly normal and I just have no idea how do these things work but I'm as puzzled as you because the original submission said "First Major Release in 15 years"...
... 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 it makes my job a little easier, but not a whole lot. 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.
I'm guessing I'm still going to need my platform-specific compilers/SDKs/IDEs on each platform for this all to feed into, as well. On the Mac side (the last place I built a graphical app, and that was several large cats ago) I'm a little unsure how using this with C++ or whatever is going to save me time over using Xcode with ObjC.
I welcome responses or thoughts on the pros and cons of all this, either from the WxWidgets folks themselves, or from other devs.
Village idiot in some extremely smart villages.
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.
Several != Seven
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
Custom electronics and digital signage for your business: www.evcircuits.com
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*
If you're a zombie and you know it, bite your friend!
This is my first ever submission to /. so maybe it's perfectly normal and I just have no idea how do these things work but I'm as puzzled as you because the original submission said "First Major Release in 15 years"...
Don't worry, you'll get used to it
I have had my submits turned into articles that I don't even recognized ... ahh... what can I say, the /, editors like to think that they are magicians
This phenomenom has getting accutely troublesome especially _after_ Commander Taco has left
Muchas Gracias, Señor Edward Snowden !
It's been corrected from Seven, as evidenced by other early comments, including the one to which I replied.
Required reading for internet skeptics
Sounds like a different implementation that does the same thing as QT.
Not exactly. Both Qt (not QT) and wxWidgets are cross-platform, but wxWidgets uses native widgets wherever possible (as their home page says, "Unlike other cross-platform toolkits, wxWidgets gives its applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI."), whereas Qt primarily uses its own widgets.
Does it support Qt? :P
And Qt is not really C++ as it relies on MOC.
Its about time for a GUI toolkit that actually fully leverages what C++11 has to offer.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
P.S. Thanks for the editors for correcting this, I'd still prefer my original submission but at least the current one is not factually wrong any more.
Not that I can't get a joke but actually, there is wxQT (albeit in a pretty preliminary state AFAIK, but then I've never really looked at it myself).
Qt also gives the application native look and feel, for the most part - it just achieves the same by using low-level primitives (e.g. uxtheme.dll on Windows).
The irony is that while the readership complains about the lack of editing of submissions, as your story and others illustrate, those editors do far more harm than good when they bother to read/alter submissions.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Qt also gives the application native look and feel, for the most part - it just achieves the same by using low-level primitives (e.g. uxtheme.dll on Windows).
But some of its standard dialogs don't exactly look like the native dialogs in all cases; for example, on OS X, its "file open" dialog is most definitely different from the native one. (I'm not sure about Windows, but I suspect Gerald had a reason to continue to use the native dialog in Wireshark rather than relying on Qt's dialog.)
A. This is news for nerds.
B. Click on the supplied link.
It is a cross platform UI toolkit that defaults to native widgets.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Qt is rather inferior to QT, to be honest.
I've never known a window widget library to have good drink selection and fresh donuts.
And Qt is not really C++ as it relies on MOC.
Its about time for a GUI toolkit that actually fully leverages what C++11 has to offer.
C++11 is not even supported on most of the target compilers yet. And you can use c++ for signals/slots these days without string intermediaries.
http://qt-project.org/doc/qt-5.1/qtcore/qobject.html#connect-4
MOC just generates some signals/slots boilerplate code, which is C++ code. You might as well bitch that UIC is not C++ either because it generates C++ boilerplates from XML.
PS. the moderators utterly fail - the parent is neither informative nor correct. oh well. I guess I and everyone at Trolltech/Nokia/Digia didn't know they wasn't using c++ for last 10+ years.
Also for small values of 7. I took a fuzzy math course too. :)
I've fallen off your lawn, and I can't get up.
See, 7 is why we're fat. It's that whole two pi thing. We should be satisfied with one pi, but no, we have to have two. No wonder we're rounding up.
Mmm. Two (strawberry + key lime) pie.
Also, two (pizza) pie. Which is, strangely enough, the same as "pie pie."
Sufficiently large values of seven, indeed.
I've fallen off your lawn, and I can't get up.
The file dialog used by Qt for Windows is the native one.
Even if you add extra widgets to the dialog, as Wireshark does?
And Qt is not really C++ as it relies on MOC.
A non-sequitur at it's finest. Using MOC does not make Qt any less a C++ framework since the only way Qt can be compiled is with a C++ compiler.
Only if you use the static methods on QFileDialog. If you don't it's the non-native file dialog.
*Its* finest, of course.
I see what you mean, but nevertheless when editing Qt code, one sees additional keywords that do not appear in the C++ standard. The fact that these keywords are pre-processed by a special compilation step into C++ code does not make the code you actually edit standard C++. I think this is an important distinction.
Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out.
WOOOSH!
My C++ compiler does not compile signal: or slot: tokens. Qt is not C++ in the same way as Microsoft COM is not C++, even though its mostly built with C++ and MIDL generator spits out C++ boilerplate as an option.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
It's been many years since I've used wxWidgets (wxWindows it was called back then), but
a) You don't need all that. You only need it when you want to have an about box, and a close command, etc.
b) It's a bit boiler plate, since you do need to put that in your program time and time again, but it's very flexible, and it's not that much code if you consider it carefully. There is a function that sets up a window, one that attached menus to a window when you open it, and functions to act on menu selection.
c) If it's too much manual labor, then there are GUI editors to get you started, if I'm not mistaken.
I've always liked wx, and I will consider using it again when the need arises for a native app.
"Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out."
Ummm, so does wx, that's the only way to have sensible cross-platform support. Once wx is in your code, you ain't getting it out...
Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out.
That could be said of most cross-platform toolkits and its hardly surprising. C/C++ traditionally hasn't bothered to make the distinction between an immutable and mutable string, nor provide hints as to who owned the string (implementation or caller), or of making efficient use of memory, or of providing utils to convert or manipulate character sets or encodings. So the toolkits typically encapsulated strings in classes to provide these things.
And even though the standard C++ library has a std::string class, I expect toolkits have enough reasons to stick with their own classes. And that's just strings. I expect there is a similar story for things like threads (and various thread patterns like thread pools), collections, semaphores, mutexes, file handles, sockets, etc.
You can reduce this to
if you want, but this would just show you how to display "Hello, world" in a message box while the program at your link shows you a typical skeleton of a simple but realistic application. It doesn't try to be minimal, this is just not the point.
From the wx docs:
"You may notice that wxString sometimes has many functions which do the same thing like, for example, Length(), Len() and length() which all return the string length. In all cases of such duplication the std::string-compatible method (length() in this case, always the lowercase version) should be used as it will ensure smoother transition to std::string when wxWidgets starts using it instead of wxString."
Which shows that they at least appreciate that you should leave as much as possible to the language you're writing your toolkit in.
Write portable C++ code, write a UI layer using a portable toolkit. But don't let that toolkit get its tendrils into the bulk of your code, because at some point you'll wish you hadn't.
You've made me ruin my moderation in this thread, but I can't let such wrong statements unreplied.
The fact that these keywords are pre-processed by a special compilation step into C++ code does not make the code you actually edit standard C++.
Wrong. Is not a special compilation step. Is the classic C preprocessor, which is as standard C++ as any other feature of the language. Does this mean that udev is not standard C because it defines a foreach with a macro?
Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out.
Qt has its own notion of string, because till C++11 there was no string type that allowed Unicode. Likewise for threads. Besides, QThread has features to integrate with an event loop, notion that the standard library doesn't have.
How the hell were programs written with WxWidgets using threads? Relying on Windows POSIX capabilities? Seriously.
And don't even try again the "but Qt duplicates all the containers". Qt's containers use a very different implementation (e.g. with implicit sharing), and so have pros and cons against STL containers. And Qt's containers have compatibility APIs with the STL ones as well. And you are not forced to use them at all. If some part of the API exposes a Qt container, you can convert to and from STL, since such functions are provided.
The C++ standard library is now much better than it used to be, but Qt started in an age where the STL wasn't even an acceptable option in all the environments where it had to run.
Once Qt is in your code, you ain't getting it out.
Certainly not. People is migrating from VxWidgets (e.g. VLC) to Qt, and not the other way around. Why it might be? Maybe is because is such a good application framework that is convenient to use, even for non-graphical applications.
My C++ compiler does not compile signal: or slot: tokens. Qt is not C++ in the same way as Microsoft COM is not C++, even though its mostly built with C++ and MIDL generator spits out C++ boilerplate as an option.
My C++ compiler doesn't compile "#include" either. Because it doesn't have to. You need to run the file through a preprocessor. That's part of the standard, and is unavoidable at this time.
If don't like the use of the C preprocessor, fine. But don't lie saying that is not "standard". It might not be the part of the standard that you like the most, but is standard. And using a tool for generating code is perfectly normal. Or is protobuf no longer a "standard C++" tool?
There is a proof of concept clang plugin that would provide the QObject features without MOC. That doesn't make it better in all use cases, since that would be tied to a compiler.
No, seriosly, one might not like one solution to a problem. But having no solution is worse. If one day there is a better solution, the Qt project will adopt it. But right now there isn't one that fills all the features provided by Qt with the current implementation.
Qt uses the moc precompiler, which is *not* c macros. It does transformations to the input text that is impossible with C macros. If it was possible with macros they would just have you include some QtMacros header at the start and not have to run a Qt-specific program that wrote the input to the C++ compiler.
Qt has its own notion of string, because till C++11 there was no string type that allowed Unicode
Only for fools who thought you need 16-bit code units to store a larger character set, rather than a variable-length encoding. Considering UCS-2 has been scrapped and replaced by the variable-length UTF-16 encoding you look pretty stupid now. And we are all paying for Qt's and Python's and Window's blindness to how to actually get things done (hint: look up UTF-8 for a solution proposed 30 years ago now and implemented in ONE DAY on Plan9). 16-bit code units is a blight that has probably caused more damage to internationalization that the most red-neck American programmer.
Qt uses the moc precompiler, which is *not* c macros. It does transformations to the input text that is impossible with C macros.
Next time you write about something, use it first, please. MOC is not a precompiler nor "transforms" input text. It generates code. Like a bazillion other tools that generate perfectly standard C++ code.
Only for fools who thought you need 16-bit code units to store a larger character set, rather than a variable-length encoding.
Execellent. That's why everyone is using std::string in i18n-ed text, and why C++11 didn't introduce new string types.
But yes, call people stupid as long as you want. Now you are probably right.
What I meant was exactly what you said: MOC is *not* a macro expansion. I was responding to somebody earlier who claimed it was macros.
Yes, intelligent people are using std::string in i18n text, and in fact the best i18n and Unicode support is from libraries that work this way. The biggest impediment to Unicode is morons who want to treat it as glyphs and thus think it is really important to work with the code units rather than sequences of text. Look up UTF-8 before you stick your foot further in your mouth.
Read again the thread. You said that MOC is a precompiler (wrong, is a code generator), and that it transforms the input text in ways impossible with C macros (even more wrong).
I said "Is the classic C preprocessor" in response to "these keywords are pre-processed by a special compilation step into C++ code" which is absolutely right.
And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.
I see. You wrote "Is the classic C preprocessor,..." which I misread as "It is the classic C preprocessor..."
I would argue that both the C preprocessor and MOC *are* "compilation steps", however.
And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.
By using pattern matching. For instance, strstr(utf8text, "utf8char") will find the character given in "utf8char" (with the really nice advantage that the definition of "character" can be modified to follow the Unicode standard). I would be very interested in why you think this is impossible. Should be fascinating!
OK, I give up. The fact that you still think that using a string as a vector of bytes is comparable with a class that is capable of understanding the text it stores, with some encoding conversion capabilities, and more, should be a clear enough indication that we don't have the same expectations on what is a class for human text. And the fact that you still try to put words in my mouth signals that it isn't worth wasting time with you.
Luckily enough that people admit that you should use a Unicode library, because even C++11 supports Unicode terribly, and there is work underway to improve it. Meanwhile, I'm happy to have QString. And I'll be happier if with Qt6 there is a type that can replace it.
Maybe you should read stuff from people who actually program:
http://www.utf8everywhere.org/
Here is some actual comments from boost developers:
http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/recommendations_and_myths.html
Here is an actual proposal to fix filenames on Windows by translating from UTF-8 (filenames on Windows are the *only* reason people use UTF-16, and Microsoft's refusal to allow the a api to handle UTF-8):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html
Long discussion with many points of view (including yours) but I hope this convinces you that there is disagreement with you:
http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful
Here is somebody trying to patch boost to handle unicode by supporting UTF-8:
http://sourceforge.net/p/tinyxml/patches/54/