Qt - How do you like to use it?

[MrDeathNote]

Hey guys, I know a lot of ppl here like Qt (myself included). I was wondering, how do you guys like to use it? Do you prefer to use Qt creator and add widgets in a drag and drop style or do you like to code the ui? I prefer to code the ui but i'd like to hear your opinions on any Qt related topics.

[wearymemory]

Beware the dangers
that will always arise from
code generators.

[Live-Dimension]

I prefer to rapidly just built the UI with D&D for now. Until I get better at Qt, that is. Later I'd probably code out the UI, after giving it a quick design in a window to test everything out. Thats what I do in purebasic, anyway.

[Arce]

For those of you who don't already know, the Elysian Shadows Content Creator is now written in C++ and Qt. Though I am no expert in Qt, I do have several months experience, and feel like I've definitely seen the ups and downs...And am pleased to say, l feel that there are more ups. Granted, it may not be the correct tool for everything, and uses very large and extensive frameworks...I feel like it's the ultimate rapid creation multiplatform GUI toolkit.

Now to answer your question:

I was wondering, how do you guys like to use it?

That's pretty open-ended, and could mean a bunch of things. I guess I'll start with the IDE itself and start from there.

When working in Qt, I always use Qt Creator (Qt's IDE). Though I'm certainly a MVC++ fan when using C++, I feel like I'm kicking myself in the nuts by NOT using Qt Creator for several reasons:

1) Qt creator is completely cross platform, and appears the same on each. The simple fact is that is you're using Qt, platform independence is important to you. Well, it just so happens that it's important to me as a developer just as much as a user, as I swap between my Macbook and PC several times a day. I simply don't want to waste me time configuring my projects to work seamlessly in MVC++ and XCode both as Gyro had to do with the Engine. Not to mention it's easy to share one .pro file among the rest of the ES team that they can easily open in Qt Creator as well, without having to worry about dumb stuff like being on the same version of MVC or whatever.

2) Qt Creator comes fully integrated with all of Qt's docs. Yeah, sure, I can have them open in Firefox on my other monitor...But the IDE itself allows you to highlight something, hit "F1," and will pull the docs for you. This is an ENORMOUS time saver when coding, and it leaves me wishing things worked the same with other IDE's. This feature may not be as important to some people, especially if you're using a smaller monitor (the default behavior is a dock on the right side displaying the docs), but I feel like it makes the IDE nice-n-friendly.

3) There are no real complaints about the IDE itself. The fact is that it's intuitive, feature packed, and I don't feel like I'm missing out by not using another. If you take a moment to figure out the different keyboard shortcuts (like with any IDE) you can quickly find yourself working faster. There's no such thing as the perfect IDE, but I've really got no problem using this one, so why not?

Now, "how do I use it?"

If I'm at work, I'm using my MacBook Pro and an external monitor. It's 30-something inches (huge), so I always take advantage of the Window->Split feature. This allows you to split the screen horizontally or vertically so that you can modify multiple sources files at a time. I feel like this is immensely useful in a language like C++ where the headers are sources are separated. My setup at work is usually 3 splits (one horizontal, two vertical) so that I can modify four files at a time. This still leaves me plenty room for the docks on the right side, debugger/console at bottom, and the standard menu on the left. I typically use the top for headers and bottom for source, but I guess it really doesn't matter. Though I do find that I tend to remove all splits before using Designer or working with the wysiwyg.

If I'm on just my Macbook (13 inch screen), I only do one horizontal split, and tend to keep the docs closed unless needed, hide the mac dock, and decrease my top split to less than 1/3 the screen.

Now, I guess I can move onto the SDK a little...

One thing I'd like to touch on is QVariant derivatives. For those of you not familiar with Qt, QVariant is the baseclass for almost all of Qt's data types. Qt uses its on encapsulating classes for primitives, allowing C++ users power that you find in more OO languages like Java and C#, such as a .toString method, conversion functions, and the great .isNull. Not only this, but they've got their own flavor of STL including classes like QList, QMap, QVector, etc. I certainly see the power and logic in using these Q objects rather than standard ones, which allow you to work nicely in the Qt framework and ensure things are mapped properly to other OS's...But I've always been a little hesitant to use Qt objects for primitives, and I always felt like this destroys me code reusability. Unfortunately, I cannot go too far into the details yet, but Falco and I are sharing a pretty decent amount of code between the engine and editor in what the call the "AssetIO Framework." Obviously, Falco isn't going to be using QInt's on the dreamcast of PSP, so it's not possible for me to use an "all or nothing" approach regarding the use of QVariants. So, when should you, and when should you not? There's no real answer, but here's my take on it:

First of all, realize that in languages like Java and C#, a common type system is a characteristic of the language itself, not some arbitrary framework you're using. Because of this, it's not possible to use autoboxing in C++. This fact, in my opinion, emphasizes the idea that the Q versions of my objects are just there to help wrap the non-Qt portions of my code to the Qt ones. So, as a rule of the thumb, I use only QVariants in classes that are completely reliant on one of Qt's frameworks (like a QObject derivative of some sort), only standard primitives in code that is shared and can be decoupled from Qt, and both in classes that wrap one to the other depending on how the wrapping is done.

Now, finally, allow me to move on to your last question:

Do you prefer to use Qt creator and add widgets in a drag and drop style or do you like to code the ui

This is a great question, thanks alot for asking.

I am a programmer, not an artist. When I was delving into Flash, I HAD to do everything from MXML/Flex, and refused to work with that damned timeline shit they use. In my original editor, you could easily tell that I had hardcoded each and every dialog box, size, position, etc. Why? Again, I'm a coder, not an artist...

But as I've grown older and done more with UI applications, I realize this excuse can only take you so far. ;p

Qt has done many things right with their formatting, spacers, size hints, etc. The developer is very lucky in this regard, as they can still accomplish a very professional looking application by hand coding everything. However, I feel that doing so is counter-productive, and a sign of an inexperienced developer. Why?

----------------------

Sorry guys, but I've been typing for like an hour now. XD

I'm about to head off to bed. But I'll try to finish this post when I get the chance, and perhaps modify it for the TCR E-NewsLetter.

[MrDeathNote]

Qt has done many things right with their formatting, spacers, size hints, etc. The developer is very lucky in this regard, as they can still accomplish a very professional looking application by hand coding everything. However, I feel that doing so is counter-productive, and a sign of an inexperienced developer.

I totally agree that Qt has done a great job with it drag and drop interface. I'm sure it's one of the best out there. I tend to hard code the main window of an app, and use the creator for any dialogs I need. I'm not sure why I like doing this, call me old fashioned but I like the control that hard coding it gives. Maybe I will get round to creating main windows with drag and drop, who knows.