What is Reddit's opinion of wxWidgets?

From 3.5 billion Reddit comments

It is my opinion it is the best of a bad bunch; really QT merit is in that fact that wxWidget and GTKmm are worse: see here: http://www.wxwidgets.org/develop/standard.htm

It does somethings well like being well distributed, documented and most importantly has as drag and drop creator.

However the problem with it is it is of a design style not really compatible with modern C++. It doesn't namespace , it defines it's own containers (least forgivably is QString, how I hate you), everything is 'new' manually.

The fact is QT is a C++ library implementation in it's own right, it can be used more or less in place of the standard library, however it is my view that it is worse than std lib because it takes a very esque approach ins't standard.

Finally if I want to have a graphic window I do not want my end users to have get QT network and audio libraries it is just too big.

I don't know about "easily" but Code::Blocks is a cross-platform C++ IDE which supports developing using the wxWidgets framework, which is also cross-platform.

I think its place is similar to Xamarin.Forms but with a desktop focus. The Eto controls aren't "hosted" in WinForms, GTK#, etc. but are instead wrappers around these native platforms, allowing for a single UI definition that is implemented with native frameworks under the hood, across all the supported platforms, similar to something like wxWidgets does in C++, or libui in C. It can use the designers built-in to Visual Studio for both Windows and Mac to preview the design, much like WPF, and supports XAML for UI layout and data-binding or JSON, although the documentation for these is sorely lacking.

One fascinating aspect of the design is that it can be used with XAML like WPF or with code like WinForms and so you can set up data-binding in XAML or in code which is interesting to see, considering with WPF it can be hard to tell what the XAML is doing.

Its support for macOS is superior to all the non-web-based C# GUI frameworks I have tested (I haven't tested and am not a fan of web-based frameworks).

If you want to keep your code portable between platforms, give wxWidgets a look. I just recently started using it in my C++ programs (OS X) and it's a pretty happy system to work with.

A nice advantage of wxWidgets is that it uses the native controls on whatever platform it's running on, so your app won't jump out as "I'm using a custom UI thingy".

I've only used it with C++, but you can find a C interface here.

I normally don't recommend people use C++ (not CPP!) for GUI programming, but if you want to get into it using C++, you could try the wxWidgets library, which is what Code::Blocks itself uses. If you want graphics/multimedia rather than a GUI, then look at something like SDL.

From your other posts here though, I would say you are probably nowhere near ready for attempting such a project yet. I would concentrate on learning more about C++ and the C++ Standard Library.

> You're gluing together iOS libraries, but what's the last algorithm you wrote?

Well, that is kind-of-true. But gluing libraries together into a unique application can be a lot of fun too. Besides, "pure" algorithms tend to be the kind of utilities you need to get real work done. When did you write a quicksort, or a hash table the last time? You don't because it is not interesting. (Unless you do it to try out a new language, but then you don't use it in production anyway.)

On the other hand, I'm right now writing a CakePHP-JSON-CoreData object mapper for an iPad app with robust syncing of changes in both directions. That includes a lot of parts on low and high level that should count as algorithms.

> You're learning some new API because the manufacturer requires that (...)

Is that true? let's say Apple used the Win32 API for iOS instead of Cocoa Touch. That would make a lot of developers feel much more at home. Would the apps work well and look good? Probably not.

Yes, it is a silly example. Even a strawman. But you get my point: Cocoa touch was developed to fit the device. That's why I use it. Technically, it wouldn't be a problem to just plot pixels on the screen and do all UI manually. Something like wxWidgets would probably work fine with the embedded port. http://www.wxwidgets.org/docs/embedded.htm

But yeah, you sometimes need a new API. As long as the documentation and API itself is good, it's not much of a problem.

Do you have any of the following programs installed? http://www.wxwidgets.org/about/screenshots/

Audacity uses wxwidgets but has the dlls in its root folder.

Probably targeted because hackers used it for GUI elements for their program, would be my guess? You sure you didn't install any cheats?

they're most likely using some cross-platform ui framework like Qt (http://www.qt.io/) or wxWidgets (http://www.wxwidgets.org/) or they could have theoretically made their own ui system (tapping directly into os apis or maybe even using opengl/directx).

for c#, your best bet is to just make a WPF (Windows Presentation Foundation) application. /u/FrancoCuevas points out WinForms but i wouldn't suggest anyone start there as it's outdated tech.

At a cursory glance I don't see anything obviously wrong. I'd need to see the actual error message outputted (by I'm assuming MSVC).

> On a side note, are there any libraries that already do this?

Plenty. Check out wxWidgets, which has a permissive license. The Windows API is a huge, hard-to-tame beast. Frankly a few classes won't cover most of what you need to do. I don't recommend trying to write a Windows API wrapper on your own.

Yes, unfortunately.

Microsoft has been pushing C# very hard. So if you want to use Windows Forms and WPF, you have to use some type of managed code - and C# is the best fit. All of the GUI design tools are aimed at this - and it really is a lot easier than building graphical interfaces in C++. At one point Microsoft had an extension package that enabled managed C++, but it was overcomplicated.

Apple kinda did a similar thing with dropping the Carbon APIs in favor of Cocoa, which requires Objective-C.

You can still mix languages if you have an existing set of C++ logic that you want to interface with a C# GUI. Although if you want to do everything in C++, MFC still exists (just not in the Express versions), you can still always write directly to the Windows APIs - but a better, cross-platform alternative is either wxWidgets or Qt, both of which are available for free under the LGPL license.

(Disclaimer: I've not used everything mentioned above, but that's my understanding of the situation.)

Have you got all this installed? :

>Requirements for Building TrueCrypt for Linux and Mac OS X: >----------------------------------------------------------- > >- GNU Make >- GNU C++ Compiler 4.0 or compatible >- Apple Xcode (Mac OS X only) >- NASM assembler 2.08 or compatible (x86/x64 architecture only) >- pkg-config >- wxWidgets 2.8 shared library and header files installed or > wxWidgets 2.8 library source code (available at >http://www.wxwidgets.org) >- FUSE library and header files (available at >http://fuse.sourceforge.net > and http://code.google.com/p/macfuse) >- RSA Security Inc. PKCS #11 Cryptographic Token Interface >(Cryptoki) 2.20 > header files (available at ftp://ftp.rsasecurity.com/pub/pkcs/pkcs- > 11/v2-20) > located in a standard include path or in a directory defined by the > environment variable 'PKCS11_INC'.

get ahold of code::blocks and the wxwidgets plugin for it. You'll need to find an online guide to getting it compiled and set up in code:blocks, but that's a valuable learning experience ;)

Then you can write windows apps, its not too difficult to use and you could certainly knock out basic stuff pretty fast.

My suggestion would be wxWidgets: http://www.wxwidgets.org/

From what I can tell, it's design seems to borrow from MFC while it has a big advantage over MFC in that it is still being actively developed.

It also has another massive advantage over MFC in that it is designed to be a cross platform GUI framework.

If using Boost 1.37, append -mt to the boost libraries in the makefile.

-Requires wxWidgets 2.9.0 or greater, which uses UTF-8. Don't try 2.8, it -won't work. +Requires wxWidgets 2.9.1 or newer.

You need to download wxWidgets from http://www.wxwidgets.org/downloads/ and build it yourself. See the build instructions and configure parameters

>So your logic is that you don't want to open your sources because you never got funding like GNU projects ?

No, my point is that it's not really "free" in any sense if you force anything that interacts with the library in a particular way to be open-source.

>There're no funding for those really failed or meaningless projects.

You have no idea how many research projects fail to do something significant or lasting. There is funding for those projects, just not continued funding. You won't hear about them because they never made it big. Others had funding but the work was deemed complete.

The reason I think this is a problem is because I think certain libraries could theoretically be maintained "free" by a community to share the effort, while still allowing individual developers to link as they please without being legally bound to release their private code. I'm thinking of something like the wxWidgets license which is like LGPL plus an exception to allow binary distribution of proprietary code. I will concede there are probably ways to violate such a license, but the license makes it far more useful to private developers than a viral open source license.

Well, it's OSS, but the F is arguable. It may have patent grants now, but that can just at Microsoft's whim. Personally, if I was developing cross-platform code, I would go with an API that doesn't have any concerns over patents being held over people the way Microsoft sometimes likes to.

Maybe look into other alternatives like wxwidgets or fltk.

Every API will involve the end users having to install a runtime, but I guess it depends on which is heavier. All are going to be a give-and-take game. For example, something that's standard on UNIX (like wxwidgets) will probably be simple to install under windows, but under os-x might require a user to install macports or fink. And vice versa, something simple under windows or os-x might not be part of any standard linux distribution, so a user might have go out and find their own packages, or compile from source.

Hence why I suggested a web app. But AJAX and JS aren't your only options there either. PHP can do some funky things. Of course, you could do a cgi app using perl, python, awk, or whatever, but the interface might take some work.

But I'm not a developer, so take everything I say with a bucket of your fruitiest flavoured salt.