Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

WxWidgets 3.0: First Major Release in Several Years

Unknown Lamer posted about 8 months ago | from the still-breathing dept.

GUI 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.

cancel ×

147 comments

Math (0)

Anonymous Coward | about 8 months ago | (#45396087)

1998+7 != 2013

Seven Years (0)

Anonymous Coward | about 8 months ago | (#45396103)

What's 2013 minus 1998 again?

Re:Seven Years (2, Funny)

narcc (412956) | about 8 months ago | (#45396169)

Seven, of course.

Didn't you read the summary?

Re:Seven Years (3, Interesting)

VZ (143926) | about 8 months ago | (#45396299)

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 ... (2)

Taco Cowboy (5327) | about 8 months ago | (#45396571)

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 ... (0)

Anonymous Coward | about 8 months ago | (#45396665)

Yes, I once submitted an article about statistical analysis in Python and what came out the other end was something about the likely mating habits of the Pteranodon. I think the only words that survived the edit were "a", "an" and "the" :-)

Captcha: primed : some may see that as the past tense of "to prime" but I've obviously been in the industry too long - my first thought was that it was a prime-generating daemon running under a UNIX-like operating system.

Re:You'll get used to it ... (5, Funny)

davester666 (731373) | about 8 months ago | (#45398097)

Well, somebody has to add spelling and grammatical errors to the submission.

Re:Seven Years (1)

VZ (143926) | about 8 months ago | (#45396829)

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 (3, Insightful)

gmhowell (26755) | about 8 months ago | (#45396965)

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:Seven Years (2)

twistedcubic (577194) | about 8 months ago | (#45396495)

Several != Seven

Re:Seven Years (1)

narcc (412956) | about 8 months ago | (#45396593)

It's been corrected from Seven, as evidenced by other early comments, including the one to which I replied.

A suggestion... (0)

BitterOak (537666) | about 8 months ago | (#45396111)

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?

Re:A suggestion... (0)

Anonymous Coward | about 8 months ago | (#45396135)

Sounds like a different implementation that does the same thing as QT.

Anyone used this and QT that can give us a comparison? I've only used QT and for the most part like it.

Re:A suggestion... (-1, Flamebait)

mythosaz (572040) | about 8 months ago | (#45396181)

QT the convenience store chain? Quicktime video?

I can only assume that WxWidgets is an Android home-screen widget that shows me the location of the nearest QuickTrip convenience store.

Also, yes, explain what this shit is in the headline...

Re:A suggestion... (4, Informative)

Guy Harris (3803) | about 8 months ago | (#45396669)

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:A suggestion... (2, Insightful)

savuporo (658486) | about 8 months ago | (#45396749)

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.

Re:A suggestion... (0)

Anonymous Coward | about 8 months ago | (#45396905)

> And Qt is not really C++ as it relies on MOC.

Yes, we can all look it up, but would it have killed you to mention, even with a sentence or two, what the heck MOC actually is?

Re:A suggestion... (1, Informative)

Anonymous Coward | about 8 months ago | (#45397337)

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/Digia didn't know they wasn't using c++ for last 10+ years.

Re:A suggestion... (1)

Desler (1608317) | about 8 months ago | (#45397397)

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.

Re:A suggestion... (1)

Desler (1608317) | about 8 months ago | (#45397421)

*Its* finest, of course.

Re:A suggestion... (4, Informative)

brantondaveperson (1023687) | about 8 months ago | (#45397493)

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... (0)

Anonymous Coward | about 8 months ago | (#45398331)

Really? The first C++ compilers were generating C. Would someone saying that C++ is not really C would have commited a non-sequitur at "it's" finest?

Re:A suggestion... (1)

savuporo (658486) | about 8 months ago | (#45398587)

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:A suggestion... (0)

Anonymous Coward | about 8 months ago | (#45398151)

It's about time for a GUI toolkit that stops with the C++ madness.

Re:A suggestion... (1)

shutdown -p now (807394) | about 8 months ago | (#45396933)

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:A suggestion... (1)

Guy Harris (3803) | about 8 months ago | (#45397023)

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:A suggestion... (0)

Anonymous Coward | about 8 months ago | (#45397307)

The file dialog used by Qt for Windows is the native one.

Re:A suggestion... (1)

Guy Harris (3803) | about 8 months ago | (#45397379)

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:A suggestion... (1)

Desler (1608317) | about 8 months ago | (#45397413)

Only if you use the static methods on QFileDialog. If you don't it's the non-native file dialog.

Re:A suggestion... (1)

Anonymous Coward | about 8 months ago | (#45397239)

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:A suggestion... (0)

Desler (1608317) | about 8 months ago | (#45397417)

Qt is far more than a widget library. Have you ever even used it?

Re:A suggestion... (1)

BanHammor (2587175) | about 8 months ago | (#45397803)

WOOOSH!

Native look is for custom (0)

Anonymous Coward | about 8 months ago | (#45398305)

wxWidgets gives its applications a truly native look and feel

That's it.

As a developer, if I'm into writting a custom application that will run basically on one platform, I will pick wx. It gives me the most integrated look, but I don't need to learn a new API, and the application could be easily adjusted to any other supported platform (you will probably have to slightly tweak the UI).

Qt on the other hand is great if you want an application that looks and feels consistently between platforms. That's why projects like Skype use it.

So wx is great for custom applications, and Qt for consumer software.

Re:A suggestion... (1)

feral-troll (3419661) | about 8 months ago | (#45396243)

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.

Re:A suggestion... (1)

Anonymous Coward | about 8 months ago | (#45396673)

Does it support Qt? :P

Re:A suggestion... (0)

Anonymous Coward | about 8 months ago | (#45396843)

Not yet, but there seems to be a branch with partial Qt support.

Re:A suggestion... (1)

VZ (143926) | about 8 months ago | (#45396845)

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:A suggestion... (0)

Anonymous Coward | about 8 months ago | (#45396901)

"If you are not a geek, and missed the link to their website in the summary," ...then why are you reading Slashdot? This isn't a beginner's guide to computers.

I assume this is what you were too polite to say. I'm not going to read the American Journal of Analytical Chemistry and berate them for not including enough explanations for laypeople. Is it perfectly okay to have resources that aren't aimed at laypeople or are specific to a field. If you know modern software development, you know wxWidgets, have run across it, or can infer by context what it is. If you don't know the field, you are simply demanding that people who *do* know it hold your hand and lower their discourse to your level, which is unreasonable.

To anybody flailing about for help: people will be polite and explain it, but demanding that a site aimed at a certain level lower the bar to your level of understanding ultimately doesn't help you in the long run. You'll understand everything all of a sudden, but only because the site's caliber of stories lowered itself to your knowledge level. Instead, try looking things up you don't understand for a few years, and when this all seems natural and you understand all the stories, you will have acquired a higher knowledge level and improved yourself rather than reducing Slashdot.

Re:A suggestion... (0)

Anonymous Coward | about 8 months ago | (#45397287)

The funny thing is it has a rather unique name that comes up in Google right away, so there is no ambiguity preventing you from figuring it out, only laziness. It might be nice to save some people the effort, but this is rather different than some obscure acronym that overlaps with several other technical field acronyms with different meanings.

Re:A suggestion... (1)

LWATCDR (28044) | about 8 months ago | (#45397227)

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

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

Some (in)equations (5, Funny)

fatphil (181876) | about 8 months ago | (#45396125)

2013 - 1998 = 15

Fifteen != Seven

Slashdot Editors != Editors

Re:Some (in)equations (1)

Anonymous Coward | about 8 months ago | (#45396153)

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

Read that again more carefully.

Re:Some (in)equations (0)

fatphil (181876) | about 8 months ago | (#45396161)

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.

Re:Some (in)equations (1)

BSAtHome (455370) | about 8 months ago | (#45396261)

"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.

Re:Some (in)equations (0)

Anonymous Coward | about 8 months ago | (#45396675)

All finite numbers are approximately seven when you start talking about transfinites :-)

Some (in)equations (1)

fyngyrz (762201) | about 8 months ago | (#45397343)

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

Also for small values of 7. I took a fuzzy math course too. :)

Re:Some (in)equations (1)

twistedcubic (577194) | about 8 months ago | (#45396537)

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".

Re:Some (in)equations (1)

Aphadon (3402087) | about 8 months ago | (#45396575)

Depending on your species, it could also be one (1), two (2), three (3), many (4) and lots (16).

Re:Some (in)equations (1)

Desler (1608317) | about 8 months ago | (#45396775)

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

Re:Some (in)equations (0)

Anonymous Coward | about 8 months ago | (#45396799)

Fifteen != Seven

It does for sufficiently large values of Seven.

Further (in)equations (2)

fyngyrz (762201) | about 8 months ago | (#45397369)

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:Some (in)equations (1)

pjrc (134994) | about 8 months ago | (#45396945)

wxWidgets 2.6 and 2.8 were pretty major releases, actually.

Re:Some (in)equations (1)

tinkerton (199273) | about 8 months ago | (#45398643)

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.

Is it still relevant? (1)

nurb432 (527695) | about 8 months ago | (#45396227)

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? (5, Informative)

VZ (143926) | about 8 months ago | (#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.

Re:Is it still relevant? (4, Informative)

Lord Crc (151920) | about 8 months ago | (#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...

Re:Is it still relevant? (1)

dkf (304284) | about 8 months ago | (#45398273)

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? (1)

LWATCDR (28044) | about 8 months ago | (#45397253)

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

Re:Is it still relevant? (1)

temcat (873475) | about 8 months ago | (#45398347)

Do you mean Qt or wx?

Re:Is it still relevant? (1)

amigabill (146897) | about 8 months ago | (#45397909)

The main reason for me to be interested in wxWidgets is the apps that use it.

I'm interested in KiCad, therefore I'm interested in wxWidgets. Audacity, etc...

I'm also interested in Qt, GTK, etc. as well. For example, I'm interested in GTKwave, therefore I'm interested in GTK... And so forth.

Re:Is it still relevant? (1)

occasional_dabbler (1735162) | about 8 months ago | (#45398197)

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:Is it still relevant? (3, Interesting)

LWATCDR (28044) | about 8 months ago | (#45396317)

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:Is it still relevant? (1)

oodaloop (1229816) | about 8 months ago | (#45396323)

Their website has a list of users [wxwidgets.org] . It's more than a few.

Re:Is it still relevant? (0)

Anonymous Coward | about 8 months ago | (#45396401)

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?

Re:Is it still relevant? (1)

aristotle-dude (626586) | about 8 months ago | (#45396647)

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:Is it still relevant? (1)

Guy Harris (3803) | about 8 months ago | (#45396677)

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:Is it still relevant? (2)

Guy Harris (3803) | about 8 months ago | (#45396697)

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:Is it still relevant? (1)

VZ (143926) | about 8 months ago | (#45396885)

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? (4, Informative)

pjrc (134994) | about 8 months ago | (#45396369)

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.

Because I was sick of posts about 15!=7 (1)

aitikin (909209) | about 8 months ago | (#45396293)

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's that thing... (1)

dohzer (867770) | about 8 months ago | (#45396351)

... that everyone's using and needs no introduction.

But what does it really mean in practice? (2)

Shag (3737) | about 8 months ago | (#45396427)

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.

Re:But what does it really mean in practice? (4, Insightful)

osu-neko (2604) | about 8 months ago | (#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%...

Re:But what does it really mean in practice? (5, Informative)

pjrc (134994) | about 8 months ago | (#45396687)

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:But what does it really mean in practice? (1)

Plouf (957367) | about 8 months ago | (#45397241)

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]

Re:But what does it really mean in practice? (0)

Anonymous Coward | about 8 months ago | (#45397659)

Eclipse on OS X doesn't look native at all. Even on Windows, things are still a little queer.

Re:But what does it really mean in practice? (1)

Plouf (957367) | about 8 months ago | (#45398067)

Well it depends, observe how the package explorer tree is actually the native tree widget. How the tables are actually native tables with proper look&feel for the sorting and column resizing. Observe how the menu bar on OS X is actually properly positionned. Observe how the buttons in the configuration sreens, all the scrollbars are native. Notice that drag&drop from and to the desktop or the Windows Explorer actually works, and also proper copy/pasting of files from external applications. These are all these smalls details that make a big difference at the end of the day.

Re:But what does it really mean in practice? (1)

sg_oneill (159032) | about 8 months ago | (#45396713)

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 but you will still want to adapt things to fit UI expectations, ie the radically different menu styles of windows vs macs, and so on, as well as perhaps putting some effort into following the style guides of the various platforms. Glossy plastic and brushed steel are mac stylistic language. Smoked plastic and flat greys are windows stylistic language. 70s Brown on brown for ubuntu. Etc.

Re:But what does it really mean in practice? (4, Interesting)

pjrc (134994) | about 8 months ago | (#45397047)

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.

TroLl (-1)

Anonymous Coward | about 8 months ago | (#45396443)

said one FreeBSD with the laundry and abroad for www.anti-slash.org FrreBSD pro6ect, Right now. I tried, [nero-online.org]. a previously for it. I don't track of where

Trolltech's QT (4, Interesting)

EmperorOfCanada (1332175) | about 8 months ago | (#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.

Too bad it's a C++ library... (3, Interesting)

innocent_white_lamb (151825) | about 8 months ago | (#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*

Re:Too bad it's a C++ library... (0)

Anonymous Coward | about 8 months ago | (#45396701)

Text-UI? Surely that would just be TUI? We don't call a GUI a Graphical-UI.

Re:Too bad it's a C++ library... (0)

Anonymous Coward | about 8 months ago | (#45397365)

mmm TUI is all ready well defined, and much more than text ui... see oberon tui or plan9 tui for examples; hints: not overlapping windows, keyboard accelerated, message based text in line compiling with mouse ( to lingo bytecodes or oberon modules ) powerfull stuff, so spartan and so flexible, almost like smalltalk. Play with BlackBox for something TUI on windows http://www.oberon.ch/blackbox.html and http://oberonrevival.sourceforge.net/

Re:Too bad it's a C++ library... (2)

OldFart58 (663547) | about 8 months ago | (#45396737)

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 handling Windows messages, etc. It was very low-level stuff, tedious and prone to error.

If you're happy with a CURSES-like library, that's fine (I've done my share of that also with C on DEC platforms, back in the VT-100 days) - but for anything this side of Y2K, application frameworks and OOP are the way to go. wxWidgets is definitely a valid way to get a cross-platform (and cross-language... look at wxPython) GUI app out there and still keep what's left of your hair.

Disclaimer: I've been using wxWidgets (was wxWindows) creating apps for a Fortune 500 international since the early 2.0 days (mid-90's).

Re:Too bad it's a C++ library... (1)

Anonymous Coward | about 8 months ago | (#45396877)

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:Too bad it's a C++ library... (1)

pjrc (134994) | about 8 months ago | (#45397127)

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:Too bad it's a C++ library... (1)

Anonymous Coward | about 8 months ago | (#45397353)

No I did it in X, long before GTK existed (1994 timeframe) on an SGI Indigo 2. I didn't like it compared to C# or Qt now. I tried GTK, but the documentation was written as if you already knew it and only needed reference. I tried Qt after that and found it much easier to learn.

Like I said, I know its possible, but wouldn't think anyone in their right mind would still be doing it.

Re:Too bad it's a C++ library... (0)

Anonymous Coward | about 8 months ago | (#45397367)

The C++ type system can't help keep track of the fact that the less than operator defined for a particular class has output that's only sensible for sorting purposes, not for mathematical purposes. The C++ type system can't keep track of the fact that a particular union type's access pattern prevents classes in it from being clobbered.

But it sure does prevent you from casting pointers.

Re:Too bad it's a C++ library... (0)

Anonymous Coward | about 8 months ago | (#45397449)

GTK+ can be quite nice to use from Vala, everything is clear and easy and all the casting and repetitive cruff is resolved... and mix with plain old C very nice. Not bad, i like it

Re:Too bad it's a C++ library... (2)

VZ (143926) | about 8 months ago | (#45396903)

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:Too bad it's a C++ library... (0)

Anonymous Coward | about 8 months ago | (#45397207)

I understand your pain. I was in the same position once I realized that GTK was getting increasingly crappy. I do most of my writing in C and have no love for C++, but I've reached a compromise in that I write my stuff in a cleanly split frontend and backend design. With the C++ Qt code being the frontend which calls the stuff written in C. Neither leak into each other that much. If you're doing proper design in the first place this method will not fail you.

Re:Too bad it's a C++ library... (1)

istartedi (132515) | about 8 months ago | (#45397517)

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 to where you can dynamically link whatever you want easily, with the understanding that it "voids the warranty".

Re:Too bad it's a C++ library... (1)

Jeremi (14640) | about 8 months ago | (#45397591)

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++ for a few years, writing a program in C now feels like driving a car that's stuck in first gear.

Re:Too bad it's a C++ library... (1)

amigabill (146897) | about 8 months ago | (#45397917)

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.

Excellent! There is some opportunity for you to create a C layer onto the C++ subsystem, then you yourself as well as others can benefit from that. :)

Re: Too bad it's a C++ library... (0)

Anonymous Coward | about 8 months ago | (#45398527)

I feel your pain.

My compromise has been to use Qt for the front end stuff. It uses a benign subset of C++ which is less likely to burn your fingers than going all the way and it is quick to learn. I still have to reset my thinking from plain C to avoid the bear traps which differentiate the languages but the experience is tolerable.

Another layer (0)

Anonymous Coward | about 8 months ago | (#45396605)

The whole concept of wx is silly. The additional layer basically means that it's awful buggy and breaks with new releases of whichever layer. And while it's to some extent technically correct to call wx "native", I have yet to encounter a wx application where the actual user experience could be called anything close to native.

Re:Another layer (0)

Anonymous Coward | about 8 months ago | (#45397731)

Well, it's the only thing Erlang has to use as a GUI programming interface, so any update is welcome.

Hello world (-1)

Anonymous Coward | about 8 months ago | (#45397991)

Jeez look at how much code one needs just for hello world!
http://docs.wxwidgets.org/trunk/overview_helloworld.html

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...