WxWidgets 3.0: First Major Release in Several Years 147
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.
A suggestion... (Score:1)
Re: (Score:1)
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
Re: (Score:1)
Does it support Qt? :P
Re: (Score:2)
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).
Re: (Score:2)
Re: (Score:2)
A. This is news for nerds.
B. Click on the supplied link.
It is a cross platform UI toolkit that defaults to native widgets.
Re:A suggestion... (Score:5, Informative)
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.
Re: (Score:2, Insightful)
Its about time for a GUI toolkit that actually fully leverages what C++11 has to offer.
Re: (Score:1, Informative)
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 [qt-project.org]
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/D
Re:A suggestion... (Score:5, Informative)
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.
Re: A suggestion... (Score:2)
"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...
Re: (Score:2)
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
Re: (Score:2)
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 cla
Re: (Score:2)
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 [freedesktop.org]?
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 th
Re: (Score:2)
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 var
Re: (Score:2)
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.
Re: (Score:2)
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 mout
Re: (Score:2)
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.
Re: (Score:2)
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 modi
Re: (Score:2)
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 [stackoverflow.com], b
Re: (Score:2)
Maybe you should read stuff from people who actually program:
http://www.utf8everywhere.org/ [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 [boost.org]
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 [open-std.org]
Long discuss
Re: (Score:2)
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.
Re: (Score:2)
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++" [google.com] tool?
There is a proof of concept clang plugin [woboq.com]
Re: (Score:2)
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).
Re: (Score:2)
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.)
Re: (Score:2)
The file dialog used by Qt for Windows is the native one.
Even if you add extra widgets to the dialog [qt-project.org], as Wireshark does?
Re: (Score:1)
Qt is rather inferior to QT [quiktrip.com], to be honest.
I've never known a window widget library to have good drink selection and fresh donuts.
Re: (Score:2)
Some (in)equations (Score:5, Funny)
Fifteen != Seven
Slashdot Editors != Editors
Re: (Score:1)
"The first new stable wxWidgets release in years and the first new major release since 1998"
Read that again more carefully.
Re: (Score:1)
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.
Re: (Score:2)
"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.
Some (in)equations (Score:2)
Also for small values of 7. I took a fuzzy math course too. :)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
No, you simply missed that the "editor" had said it had been seven years. Your post qualifies for the standard "Whoosh?" response.
Re: (Score:2)
wxWidgets 2.6 and 2.8 were pretty major releases, actually.
Re: (Score:2)
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.
Further (in)equations (Score:3)
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.
Re: (Score:2)
I'll have some chai tea, please. Two cups, one identity.
Re: (Score:2)
I meant, walk into a pizzaria and say: "I'd like a pie" or "I'd like a pizza" and you'll get the same result (which is probably "what size, and whaddaya want onit?")
Which brings me around to that weird question, "you want a cheese pizza?" ... I know there may be *specialty* pizzas that don't have cheese out there, but a "pizza" is crust, sauce and cheese. Anything *else* is a variable you specify. Specifying "cheese" is, at least if you're not preceeding with "goat", both superfluous and annoying. If I say
Is it still relevant? (Score:2)
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?
Re:Is it still relevant? (Score:5, Informative)
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.
Re:Is it still relevant? (Score:5, Informative)
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...
Re: (Score:2)
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.
Re:Is it still relevant? (Score:4, Informative)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
So, why you didn't contribute to fix this if you have access to the library source code?
We didn't have a dedicated developer on OSX, more like an enthusiastic user who could compile it but not so much code. Sometimes he could Google some workarounds other times we did a workaround in the blind.
In either case we did not feel comfortable hacking the wxWidgets internals, as we had no OSX experience or ability to debug.
With Qt this isn't an issue, as we mostly don't have to worry about stuff not working on OSX if it works on Windows and Linux.
Re: (Score:2)
If you don't have experience with a platform and can't debug on it, how can you offer a trustable software for it?
Because we use portable libraries and code, and we have plenty of testers.
Re: (Score:2)
It is also pretty light not as light as the FLTK but still pretty light.
Re: (Score:2)
Re: (Score:2)
QT is not light at all so WX.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
You can use LGPL version of Qt and link statically.
Note that the LGPL requires that you provide a way to relink in a new version of the library (QT in this case).
Re:Is it still relevant? (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Yeah but do you see major companies or major players using it? I see a bunch of research labs from major universities, minor products from some corps, and miscellaneous small companies. Is there a major user / well known product?
Google?
Re: (Score:2)
Yeah but do you see major companies or major players using it? I see a bunch of research labs from major universities, minor products from some corps, and miscellaneous small companies. Is there a major user / well known product?
Google?
What do they use it for? (No, "Google Earth" is not the correct answer; that's Qt-based.)
Re: (Score:3)
What do they use it for? (No, "Google Earth" is not the correct answer; that's Qt-based.)
Google Drive, as per the wxWidgets home page, which says "The recently released Google Drive system desktop client uses wxPython."
Re: (Score:2)
As already mentioned, you might know about the company making Google Drive. And you might recognize a few other products from this list [wikipedia.org].
There is also Intel VTune [blogspot.com] about which I learnt completely accidentally, so who knows which other major companies use it without advertising it.
Re:Is it still relevant? (Score:5, Informative)
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.
Re: (Score:2)
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
Because I was sick of posts about 15!=7 (Score:2)
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's that thing... (Score:1)
But what does it really mean in practice? (Score:2)
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
Re:But what does it really mean in practice? (Score:4, Insightful)
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%...
Re:But what does it really mean in practice? (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
Re:But what does it really mean in practice? (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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)
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.
Re: (Score:2)
Documentation for Qt is top notch as well.
Too bad it's a C++ library... (Score:3, Interesting)
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*
Re: (Score:2)
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
Re: (Score:2)
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++.
Re: (Score:1)
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.
Re: (Score:2)
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....
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
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+
Re: (Score:3, Funny)
Seven, of course.
Didn't you read the summary?
Re:Seven Years (Score:4, Interesting)
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"...
You'll get used to it ... (Score:2)
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
Re:You'll get used to it ... (Score:5, Funny)
Well, somebody has to add spelling and grammatical errors to the submission.
Re: (Score:2)
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.
Re:Seven Years (Score:4, Insightful)
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.
Re: (Score:3)
Re: (Score:2)
It's been corrected from Seven, as evidenced by other early comments, including the one to which I replied.
Re: (Score:2)
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
Re: (Score:3)
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.