What are some good widget toolkits or user interface libs for writing tiny applications?

[psy_commando]

(I'm not sure if this goes here, but I haven't found any other places that would be a better fit)

So I've been mainly making console utilities, but now I'm realizing a lot of people seems intimidated by the console screen. And I've stumbled on some really annoying limitations with console applications too... So I'm thinking writing little frontends for my utilities might solve that issue..

So I've been looking and trying various toolkits for a while, Ultimate ++, Qt, WxWidgets, etc..

But, I've had massive problems with all of them.

Ultimate ++ just bypasses the c++ stdlib, which is not cool at all.. And there is no community for it. And The IDE is hard to understand..

Qt is decent, and I'm familiar with it from having worked a lot with it. But, the amount of redistributables are ridiculous for a less than 1,000 lines GUI application... And compiling a program to run Qt statically didn't work for me this far, thanks to really out of date documentation on the subject. Not to mention the licensing BS that comes with static linking. (I still have no freaking ideas why they needed to come up with a legal BS nuance between shared libraries and static libraries, when it really changes nothing in the end..)

WxWidget never worked for me. I tried to compile it several times using mingw32, and even the pre-built binaries, but the default codeblocks projects for wx widgets just won't launch, and all I get from searching is dumb ideas like putting dummy symbols in the code.. That's not a very good sign IMO..

And, then there are the built-in visual studio gui toolkits, but, using their gui framework apparently suppresses some C++11 features..(I'm not talking about MFC)

So, I'm a little lost as to what to try next.. Does anyone have any suggestions ?

I'm open about using another language, as long as its preferably portable and not too complicated.

I've considered Java, but these days its pretty hard to make people install java..

My main concern is mainly making a single binary application. With maybe 1-2 accompanying dlls max..

[Alpha]

I develop in Python with Qt (PyQt). While it's not as friendly to ask everyone to install, it can be easily frozen and you can just give people the .exe files (and provide the two .dll files for Qt).

[evandixon]

I have next to no experience in C++, but .Net is pretty good for GUIs, though you'd have to reference your C++ code somehow, and learn C# (and from what I've read, isn't as hard as from C++ to other languages). I can't tell you how you'd do it, if you chose this path, but Codemonkey85 pulled it off.

He wrote a library for 5th gen games using C++, then used C# to make a front-end.

(Library) https://github.com/codemonkey85/PKMDS

(C# Interface) https://github.com/codemonkey85/PKMDS-Win32-DLL

(GUI) https://github.com/codemonkey85/PKMDS-Save-Editor

I'm also curious as to what VS suppresses from C++ 11 (since I'm going to have to learn C++ later in the year).

[psy_commando]

I develop in Python with Qt (PyQt). While it's not as friendly to ask everyone to install, it can be easily frozen and you can just give people the .exe files (and provide the two .dll files for Qt).

You need only 2 dlls ?

That's weird, the windows deployment page seemed like it would be a lot more : http://doc.qt.io/qt-5/windows-deployment.html

Weird.. I guess I could take another deeper look.

I have next to no experience in C++, but .Net is pretty good for GUIs, though you'd have to reference your C++ code somehow, and learn C# (and from what I've read, isn't as hard as from C++ to other languages). I can't tell you how you'd do it, if you chose this path, but Codemonkey85 pulled it off.

He wrote a library for 5th gen games using C++, then used C# to make a front-end.

(Library) https://github.com/codemonkey85/PKMDS

(C# Interface) https://github.com/codemonkey85/PKMDS-Win32-DLL

(GUI) https://github.com/codemonkey85/PKMDS-Save-Editor

I'm also curious as to what VS suppresses from C++ 11 (since I'm going to have to learn C++ later in the year).

I was planning on just calling the command line utility via the gui application, basically just a bunch of very simple front-ends. Though, you can call c++ dlls from a lot of other languages and even scripted languages. But, my code right now isn't suitable for a dll.. So, just calling the console app through a gui frontend sounds like the easiest way to go.

And it seems he's using Qt for his user interface. There doesn't seem to be any C# in the projects you linked or at least, I can't see any.

And about the issues with VS and C++11. Its not VS itself, but more C++ .net, or anything that adds new keywords to the C++ language. I can't find the article anymore, thanks to google and duckduckgo not being helpful..

But it seems some of the headers from the c++11 STL contains symbols that clashes with C++ .net. Or some library used by some project types with VS..

Also, the MSVC has less support for C++ 11/14 than GCC or Clang basically. And there are some really annoying bugs you have to deal with. Like on VS2012, you couldn't use std::future with a function type that had a void return type, even though you really should. So, you always have to look up what feature of c++11 VS supports or not. >_<

[Alpha]

You need only 2 dlls ?

That's weird, the windows deployment page seemed like it would be a lot more : http://doc.qt.io/qt-5/windows-deployment.html

Weird.. I guess I could take another deeper look.

Yeah, deploying with PyQt is slightly different. It kinda automatically bundles it all into one thing automatically. I actually checked some of my releases and even the dlls were frozen into my binaries, so I just had one executable in the end.

[psy_commando]

So I took a look, and I need 9 dll to get my Qt program to work. And that's the simplest program with a gui that's possible to make..

If I could get rid of unicode support, I'd lose 3.

And I think compiling with visual studio's compiler instead of mingw would remove 2. But then I'd probably have to have a separate Qt base to compile for WinXP...

[Kaphotics]

All of my recent tools have been programmed in C# and Visual Studio. It's quite easy to make a GUI, then just feed the console parameters to a method inside the parent form.

[psy_commando]

Yeah, deploying with PyQt is slightly different. It kinda automatically bundles it all into one thing automatically. I actually checked some of my releases and even the dlls were frozen into my binaries, so I just had one executable in the end.

But it must have made a huge exe file, no ?

All of my recent tools have been programmed in C# and Visual Studio. It's quite easy to make a GUI, then just feed the console parameters to a method inside the parent form.

Hmm.. That might just be the easiest solution at this point..

I guess I could give it a try, again. Hopefully, my C# is not too rusty...

[evandixon]

Since you're going with C# and VS, I'd recommend you try WPF. It's newer than Windows Forms, and has better performance. Might not be strictly the easiest to learn (especially if you're used to Windows Forms), but I think it's the better route. WPF's MUCH better when it comes to GUI scaling (meaning Windows Forms are blurry on my Surface, displaying at 150%, while WPF looks fine).

Sky Editor uses WPF, while PKHeX uses Windows Forms, so whichever route you choose, you could use either as a reference.

[xorhash]

If you're targeting Windows and Windows only, definitely go with C#/.NET. It's been advancing to become the de-facto standard for applications on Windows, period. The .NET ecosystem is large, getting help for C# is trivial and if you're coming from a C++ background, you'll adapt fast. Needless to say, that convenience comes at a price: Hard portability. .NET binaries require the CLR (common language runtime), which is provided by essentially only Mono on non-Windows platforms (though there is Xamarin, but I'm unsure about its qualities, never having worked with it) and the .NET framework itself, which is also provided by the same projects.

However, Mono in particular keeps lagging behind the upstream .NET implementation, and some parts, are not implemented at all. This is particularly important if you want to target non-Windows users. PKHeX (mostly) runs, using Winforms. There's a bit of an encoding mess and a warning while starting it, but that's the worst of it. However, for example, Sky Editor does not run in Mono, which does not implement WPF and there are no plans of doing so.

There's also the option of installing .NET in Wine and using that to run the binaries – which is also a necessity if your application calls back into native shared libraries – but that's quite a lot of sheer installation weight to carry around. This gets especially obvious if people don't have a global Wine+.NET installation, as seems to be the case on Mac OS X: The frozen Mac OS X redistributable binary by fm360 does that, and weighs a heavy 331 MB. Even if that doesn't sound like much to you, it does slow down adoption of new versions, it's a big upload for every release, and despite it being 2015, there are people with data caps on their Internet connection.

C#/.NET looks convenient, but please do beware of the costs that come with it.

[psy_commando]

So, it seems I can still do C#. (Probably that I'm not using the best practices though, but I'm not doing anything fancy. And besides my command line app is already handling most of the validation)

I was able to get the thing working in under a day! The app is a big 19kb big, which is a far cry from the 50+ mb with Qt!

If you guys are curious : https://github.com/PsyCommando/ppmdu_gui_frontends/releases/download/v1.1/ppmd_packfileutil_gui_1_1.zip

I'm fairly happy with the workflow and result! And I was able to compile it for the .NET 3.5 framework, which also works with Windows XP SP2 !

It might not be very portable, but at least that's going to help take care of a bunch of issues my end users have been having!

Thanks a lot for the help everyone !

Since you're going with C# and VS, I'd recommend you try WPF. It's newer than Windows Forms, and has better performance. Might not be strictly the easiest to learn (especially if you're used to Windows Forms), but I think it's the better route. WPF's MUCH better when it comes to GUI scaling (meaning Windows Forms are blurry on my Surface, displaying at 150%, while WPF looks fine).

Sky Editor uses WPF, while PKHeX uses Windows Forms, so whichever route you choose, you could use either as a reference.

Well thanks for the advice, but I'm not doing anything very fancy.

Basically 2 textbox and a few buttons to browse for files and run the utility! I'm just working on some kind of poor man's GUI for people scared of consoles basically.

I'm not getting into any kind of extensive GUI programs until I'm done with reversing a good chunk of the game first.

And even then, I'd rather let others make GUI tools that just call my command line apps instead to be really honest

I just went with windows form to stay as compatible as possible.

If you're targeting Windows and Windows only, definitely go with C#/.NET. It's been advancing to become the de-facto standard for applications on Windows, period. The .NET ecosystem is large, getting help for C# is trivial and if you're coming from a C++ background, you'll adapt fast. Needless to say, that convenience comes at a price: Hard portability. .NET binaries require the CLR (common language runtime), which is provided by essentially only Mono on non-Windows platforms (though there is Xamarin, but I'm unsure about its qualities, never having worked with it) and the .NET framework itself, which is also provided by the same projects.

However, Mono in particular keeps lagging behind the upstream .NET implementation, and some parts, are not implemented at all. This is particularly important if you want to target non-Windows users. PKHeX (mostly) runs, using Winforms. There's a bit of an encoding mess and a warning while starting it, but that's the worst of it. However, for example, Sky Editor does not run in Mono, which does not implement WPF and there are no plans of doing so.

There's also the option of installing .NET in Wine and using that to run the binaries – which is also a necessity if your application calls back into native shared libraries – but that's quite a lot of sheer installation weight to carry around. This gets especially obvious if people don't have a global Wine+.NET installation, as seems to be the case on Mac OS X: The frozen Mac OS X redistributable binary by fm360 does that, and weighs a heavy 331 MB. Even if that doesn't sound like much to you, it does slow down adoption of new versions, it's a big upload for every release, and despite it being 2015, there are people with data caps on their Internet connection.

C#/.NET looks convenient, but please do beware of the costs that come with it.

Honestly, portability was my first concern, but I don't really want to deal with the headaches that comes with it. I want to spend more time writing code, and reversing the game, than dealing with all that stuff.. And besides, in my case, its not like the main utility isn't portable.

But if there was something not too complicated, that wouldn't require including 50mb of dlls with each releases, and that wouldn't need much installed on the end user's machine, I'd totally go for that!

But thanks for all the info ! That's good to know if I get a little too attached to .NET. Hopefully, I'm not planning anything very big for a while!

And if I do something big, I'll probably go with Qt then. Its less annoying to join 50 mb of dlls and etc, with something big, than with a 50kb bare bone utility!

Edited February 7, 2015 by psy_commando

[xorhash]

I'm fairly happy with the workflow and result! And I was able to compile it for the .NET 3.5 framework, which also works with Windows XP SP2 !

As much as I hate being a naysayer all the time, I'd suggest you intentionally drop support for Windows XP, which has been end of life for quite some time, and thus it does not receive security updates. Anyone who is still using Windows XP should arguably be forced by third-party developers to do so, for their own sake.

[evandixon]

Plus, if you switch to .Net 4.5, async functions become WAY easier (as long as they don't need the ui thread).

[psy_commando]

Yeah, I'd gladly drop Windows XP support, specially since I have no mean to do testing on it. But it seems a lot of people are still stuck on it. And, I didn't have to drop any features, or make any real compromises to make the utility compatible with XP. As long as that's the case, I really don't mind. It beats having people PM-ing me because the program won't run

And, I haven't had to deal with threading at all yet, but I'll keep that in mind!