Picking a toolkit for a new lump editor

[Blzut3]

I've recently been put in charge of an open source cross-platform lump editor project. What I would like to know is out of two tool kits what end-users and developers would prefer for the interface of this program to use. The choices are Qt or GTKmm. If you would like to suggest the use of another tool kit please also state which of those two you would prefer for the record.

[Kaiser]

Thumbs up for Qt..

[RestlessRodent]

GTKmm

[Steeveeo]

never heard of either...sadly...

[esselfortium]

Blzut, this is great to hear. :) I hope this project gets somewhere, as none of the existing lump editors are capable of all the things I'd like.

Steeveeo said:

never heard of either...sadly...

Then you don't need to post about it.

[leileilol]

Qt because it doesn't try to push some foreign look and feel onto anyone familiar with their operating system

[Graf Zahl]

Kaiser said:

Thumbs up for Qt..

... which may become a major pain for Windows users as it's an utter pain in the ass to set up for VC++ to compile. Forcing use of MinGW is not a bright idea IMO. Especially it this is supposed to be a community project you will need broader support of compilers and especially libraries that are easy to set up. Qt fails here - unless someone manages to create a simple to use VC++ setup for the GPL'd distribution which unfortunately requires MinGW to work.

GhostlyDeath said:

GTKmm

I repeatedly stated my dislike about anything GTK related. Unless they have changed their attitude towards the use of native controls it'd be a dead end for me. Sorry to say this but I wouldn't install GTK and I wouldn't bother to use any app using GTK as an interface. I'm sorry to say that my experience with Windows users in general is that they don't like applications using a completely different user interface. This is especially true for an application that by design requires frequent use of file open / file save dialogs which is the case for any kind of lump management tool.


The bottom line:

If it is between these 2 libraries Qt is probably the only option even though it might reduce the amount of potential contributors. I wouldn't advise to use GTK (or any other library that implements its own common dialogs and menus) for an application that is supposed to work on Windows.


However, if I had to choose a GUI library, it'd be wxWidgets. Unless you need OpenGL support it's not too complicated to set up in Windows regardless of compiler. Regardless of what people might tell you it can be done by installing the source, running the compiler once and setting up the paths. Which might mean you'll get more help with this project.

[chungy]

Qt ftw

leileilol said:

Qt because it doesn't try to push some foreign look and feel onto anyone familiar with their operating system

It'd only really matter on Macs anyway. I doubt many Windows users will notice that Qt uses the same controls that Notepad uses. And then on *nix, you can have whatever look you feel like (default is kind of Windows-ish).

Graf Zahl said:

... which may become a major pain for Windows users as it's an utter pain in the ass to set up for VC++ to compile. Forcing use of MinGW is not a bright idea IMO. Especially it this is supposed to be a community project you will need broader support of compilers and especially libraries that are easy to set up. Qt fails here - unless someone manages to create a simple to use VC++ setup for the GPL'd distribution which unfortunately requires MinGW to work.

Users are not necessarily developers. Besides, if you really want to use MSVC, why don't you just make a project for it?

Let's see how many compilers people would possibly ever use:
1. GCC (including the MinGW fork)
2. MSVC

Maybe you'll get someone to do it with icc, or even pcc, but it doesn't really matter. You have two compilers to really worry about, and GCC is probably the safer choice to target anyway, especially if you're talking about a cross-platform application.

[Graf Zahl]

MikeRS said:

Users are not necessarily developers.

If you want to work with other developers you have to consider their needs. Not many Windows-based programmers are willing to work with stone age tools like makefiles and similar garbage.

Besides, if you really want to use MSVC, why don't you just make a project for it?

There's that nasty word again. If it was just that simple... :(

Let's see how many compilers people would possibly ever use:
1. GCC (including the MinGW fork)
2. MSVC

Correct. Everything else can be dismissed out of hand I'd day. But the thing is: Qt/GCC only compiles with MinGW on Windows and the distribution doesn't help in the slightest to make it work on MSVC unless you are fluent at reading makefiles (which I am not.)

I reiterate: Windows developers are used to better tools than what GCC has to offer. To be blunt: When programming I want to concentrate on the programming, not the project maintenance - and most defintely not on working with tools that are hard to work with. There's reasons why I use MSVC exclusively - and I know I'm not alone in this.

From a pure user perspective it's totally irrelevant which compiler is used but from the developer perspective it is not. A project that's GCC exclusive will possibly only attract the Linux crowd who seem to be content not to have a proper development environment, for inexplicable reasons.

[RTC_Marine]

If its between those 2, I'd choose qt

if not, I'd suggest wxWidgets, atleast then you get native support and everything else to go with it

[Blzut3]

Looks like there almost unanimous agreement towards Qt (instead of GTKmm) in this community. I've started work on the Qt front end, but there is still time to decide.

[chungy]

You could also put all the core functionality into libraries, and people can make totally new/different front ends. For example, Graf can maintain a Win32 UI, while you have a Qt one :)

[Blzut3]

The only problem is things like a graphics editor would end up being specific to a particular UI. Since the back end doesn't contain any GTK, Qt, etc code it is possible to compile SDE without any library other than the standard C lib. So as it is now multiple UIs could be maintained. The editing features would be different.

[MP2E]

I prefer QT4 greatly, sure you can't VC++ it, but MinGW works JUST as well. Simple ./configure && make, or if you want an IDE use Code::Blocks. Problem solved.

[Graf Zahl]

MP2E said:

Simple ./configure && make,

No sane developer would work with that! :D

MP2E said:

or if you want an IDE use Code::Blocks. Problem solved.

... apparently nobody uses that. Each time I find a MinGW project it's stone age only. I haven't even once downloaded a project that I could open with Code::Blocks and work on it.

[Gez]

Go for Qt. Sure, it still has problems with MSVC but I think it's going to change. Visual Studio support has apparently been added to qmake for example.

As for the autotools, they're not simple. There's a reason people are switching to cmake.

[chungy]

Graf Zahl said:

No sane developer would work with that! :D

What, is it too much for you to type?

[Graf Zahl]

MikeRS said:

What, is it too much for you to type?

I don't use such archaic tools. In my opinion a computer is there to take away such work, not to make it more complicated than necessary.

[chungy]

now you're just speaking backwards. configure scripts and Makefiles exist for the entire reason of taking away unnecessary work.

[Gez]

MikeRS said:

now you're just speaking backwards. configure scripts and Makefiles exist for the entire reason of taking away unnecessary work.

But they are themselves unnecessary work. As I said above, there is a reason people are switching to cmake now.

Running "./configure; make; make install" seems easy enough, right? But the magic behind making those commands tick the right way is extremely difficult to master. Any developer, even of a relatively simple project, who has to setup the build system on their own will likely confirm this. The developer has to use (and learn) syntaxes for the combo of automake + autoconf + libtool + make + sh + perl + m4. A measure of the autotool complication is indicated by the fact that source code tarballs of only a few hundred KBytes of size may require at least 0.5 MByte of space for the build scripts and autotool helper files.

In KDE3 development, we ended up with an autotools-based build system that most of our developers did not fully understand. I estimate that no more than 10 people were able to fix any major problem occurring with it, first and foremost our "buildsystem-guru" Stephan Kulow. Over the years, these guys must have been contacted by hundreds of co-developers with requests for help to fix build problems in specific applications and modules.

So, among KDE developers, and probably the developers of other autotools-based projects, there is the opinion that dealing with the build system is hard, almost higher magic. This is a myth. A myth created by autotools. CMake is able to destroy this myth. Yes, there is a new syntax for the CMakeLists.txt files, but it is easy to learn.

(Source: http://lwn.net/Articles/188693/)

If it's done correctly, the "./configure; make; make install" thing is very simple for the end user. The issue is doing it correctly. For large, cross-platform projects with a lot of dependencies, it can be a nightmare.

[Blzut3]

SDE is already using cmake so the command to compile would be "cmake .;make". Even less work than "./configure;make"! Also, cmake can generate Code::Blocks project files.

SDE's source can be found at the following location if anyone is interested. https://sourceforge.net/projects/sde/

[Kaiser]

Graf Zahl said:

However, if I had to choose a GUI library, it'd be wxWidgets.

Getting wxWidgets to compile with Visual C++ is just as bad as Qt, if not worse.

[Graf Zahl]

What makes you think that?

Unpack project, start compiler, load project file, compile, done.

That is, unless you need special settings (which normally should not be the case.)

With Qt there isn't even a project file.

[Stilgar]

I vote for not QrapT.

[exp(x)]

Gez said:

But they are themselves unnecessary work. As I said above, there is a reason people are switching to cmake now.

Ugh, cmake is such a piece of shit when it comes to cross-compiling. I could not figure out how to compile a 32-bit Doomsday binary on my 64-bit system even after reading the documentation. On the other hand, I have no problem building 32-bit linux and Windows binaries of Chocolate Doom or Odamex.

[40oz]

esselfortium said:

Then you don't need to post about it.

I was under the impression that that post was made so that someone would TELL a little about these tool kits, instead of making it so you need a password to join the club.