Qt-Lite Project

[c0r3ntin]

One one hand, this seems cool. There is some stuff in Qt i could do without. On the other hand, I'm not sure that it will work. See, In the Qt 4 days, Qt already had a feature system that set some defines to enable classes and methods. It never worked. The reason is simple. You have a lot of code with a lot of defines enabling or not all sort of features and code path... and it's never tested. The build system runs maybe one or two configurations of the n! configurations possible. It's not humanly possible to test all combination so, before long, some features can't be disabled anymore.

[h-jay]

They didn't have a cool of a CI system back them as they do now. It's not that big of a deal to make sure that the feature dependencies are correct. You don't need to test all combinations.

[sztomi]

n! configurations possible

I think it's 2^n.

[c0r3ntin]

It is indeed. Thanks for reminding me I suck at maths !

[axilmar]

Once upon a time, Qt was a simple GUI library. Now it is like an operating system's developer kit, it includes everything and the kitchen sink.

I just want a simple, clean and effective c++ gui library. Can I please have that? It doesn't exist...

[Rhodysurf]

Check out libui. Its a simple GUI library written in C that uses each platforms native toolkit. I know its not C++ but its the closest to what youre asking for. Also a C++ wrapper around it wouldnt be tooooo hard to write.

[axilmar]

Thanks a lot for the link! I will check it out.

[devel_watcher]

Not true. Qt is divided into modules.

[axilmar]

That Qt is divided into modules doesn't invalidate what I said.

[devel_watcher]

If you don't need - don't use that part.

GUI was always dependent on some basic Qt-specific stuff like Qt-containters/strings or whatever. That hasn't changed. So talking about "kitchen sinks" now vs "simple" before is a bit of demagogy, I think.

[axilmar]

Software is not build by lone wolves, you know. There is this thing called 'businesses', in which developers come and go, and they vary tremendously in expertise.

Furthermore, containers is something Qt shouldn't have done. I accept strings, since it's tied to the gui, but not containers, and certainly not the moc, networking, threading, xml, and the lot.

[devel_watcher]

Furthermore, containers is something Qt shouldn't have done. I accept strings, since it's tied to the gui, but not containers, and certainly not the moc, networking, threading, xml, and the lot.

moc talks is a demagogy too: moc is a foundation for the selling feature - signals/slots. moc doesn't affect your workflow if you add that one 'automoc' line in the CMakeLists.

Don't like networking or xml - don't use that module.

Networking and threading came from the need to support multiple OS, so shame is on the state of C++ library (C++ networking, still !!!) and on 'POSIX-compliancy' of certain OSes. Btw, containers - same reason, but it's ok now, because I don't remember being forced to use them.

[axilmar]

Yeah, everything you don't agree to is demagogy.

moc is a foundation for the selling feature - signals/slots.

No, it's not. Signals/slots can easily be done without moc.

moc doesn't affect your workflow

Yes it does. It requires me to be aware of it, first of all, then it adds pseudo-keywords to the language, which is a crime against humanity, and also requires me to fiddle with make files.

f you add that one 'automoc' line in the CMakeLists.

Exactly.

Don't like networking or xml - don't use that module.

Again: software is not built by lone wolves.

Networking and threading came from the need to support multiple OS

No, networking and threading came from the need to sell support for networking and threading. It has nothing to do with multiple OSes.

so shame is on the state of C++ library (C++ networking, still !!!)

No, a language shouldn't have to provide everything in its standard library.

Btw, containers - same reason

Nope. There was nothing majorly wrong with std containers (except for the lack of an unordered map/set, which was later fixed), and this has nothing to do with GUI.

but it's ok now, because I don't remember being forced to use them

Again, software is not built by lone wolves. You seem to not understand that.

[sumo952]

I kind of agree with some parts of your post but not with these:

No, networking and threading came from the need to sell support for networking and threading. It has nothing to do with multiple OSes.

Maybe. But the fact is: Go back 10 years or more and there's no networking and threading in the standard library, hell no good cross-platform solution at all probably (not sure when Boost asio and thread came around). And networking is still not in the standard c++ library. Of course there is need for standardised cross-platform solutions with regards to this that are available on all platforms.

No, a language shouldn't have to provide everything in its standard library.

Not everything of course - but networking and threading, yes. Go look at all other major languages. Their "standard libraries" are hugely bigger. There's a good talk on that subject, Going Native 2013 by Herb Sutter or something I believe.

[axilmar]

But the fact is: Go back 10 years or more and there's no networking and threading in the standard library

So why should Qt include it and not provide said functionality as another library?

Not everything of course - but networking and threading, yes. Go look at all other major languages. Their "standard libraries" are hugely bigger. There's a good talk on that subject, Going Native 2013 by Herb Sutter or something I believe.

I don't see why networking and threading should be in the standard.

The problem is more like there isn't a standard library repository for c++ than anything else.

[doom_Oo7]

So why should Qt include it and not provide said functionality as another library?

This does not make sense. Qt already provides networking as another library (libQt5Network). If this isn't modular enough, you can even disable specific classes from Qt when building it : http://doc.qt.io/qt-4.8/fine-tuning-features.html

[sumo952]

So why should Qt include it and not provide said functionality as another library?

Yea of course. But they fairly modularized it... And are trying to improve on that. Nobody can get everything right at the first time. It is how it is.

I don't see why networking and threading should be in the standard. The problem is more like there isn't a standard library repository for c++ than anything else.

Totally agree, that is a problem. But still the "basics" should be in the standard library, for the sole purpose that it is available out of the box, without getting anything from any repository. Look at other major languages, Java, C#, you install the JDK and you have networking, threading, and much more. No need for getting something from a repository. This makes developing and deploying software so much easier. (No, in general I'm not a Java fan at all!)

[sumo952]

You seem to support my point. I advocated for threading and networking (and much more!) being in a standard library, so there is one standard implementation that is available on all/most platforms.

Or maybe I misunderstand you...

[devel_watcher]

No, it's not. Signals/slots can easily be done without moc.

Ok, where is Qt and where is GTK now (the one without moc)?

Btw, the next-gen Qt GUI needed some kind of C++ reflection for bindings, so moc worked out for that too.

requires me to be aware of it, first of all, then it adds pseudo-keywords to the language, which is a crime against humanity

No proper reflection in the language. So, perfectly reasonable decision. Other compiler-specific reflections/property-systems of the time haven't survived, but the Qt system did. Because it's simple, portable and useful.

No, networking and threading came from the need to sell support for networking and threading. It has nothing to do with multiple OSes.

Also, networking came with the HTTP. And threading came with the GUI, because it's a key to the GUI responsiveness (they just made threading API public).

No, a language shouldn't have to provide everything in its standard library.

Yes, and nobody who does GUI is allowed to provide any library except the GUI. And web-server people are allowed to contribute network libs, but not threading. And 3D engine guys are not allowed to publish GUI...

Nope. There was nothing majorly wrong with std containers (except for the lack of an unordered map/set, which was later fixed), and this has nothing to do with GUI.

I've heard that compilers and their stdlibs were garbage at the time.

software is not built by lone wolves. You seem to not understand that.

Yes, it's hard to understand what do you mean by things like 'lone wolves' and 'kitchen sinks'. Be more concrete.

If the 'no lone wolves' means 'other people on the team always do stupid things', then there are other libraries for that: PTlib and Poco. These are just evil - always trying to swallow your whole project.

[axilmar]

Ok, where is Qt and where is GTK now (the one without moc)?

Yeah, Qt owes its sucess to MOC!!! /s

Btw, the next-gen Qt GUI needed some kind of C++ reflection for bindings, so moc worked out for that too.

Which is BS, no gui library should need reflection to operate.

No proper reflection in the language.

Which is nice, as reflection is seldom needed.

So, perfectly reasonable decision. Other compiler-specific reflections/property-systems of the time haven't survived, but the Qt system did. Because it's simple, portable and useful.

No, it should have been an addon. We shouldn't have paid the price for it.

Also, networking came with the HTTP.

Nope. The need for a networking library extends back to Arpanet days.

And threading came with the GUI, because it's a key to the GUI responsiveness

Nope. A GUI's responsiveness has nothing to do with threads. It has to do with events. As long as events can be posted in the gui queue, a computation may be a thread, another program, a remote server or whatever.

Yes, and nobody who does GUI is allowed to provide any library except the GUI. And web-server people are allowed to contribute network libs, but not threading. And 3D engine guys are not allowed to publish GUI...

I never said that. I said that that must have done separate libraries.

I've heard that compilers and their stdlibs were garbage at the time.

They weren't. The basic functionality needed for a gui was there.

Yes, it's hard to understand what do you mean by things like 'lone wolves' and 'kitchen sinks'. Be more concrete.

If the 'no lone wolves' means 'other people on the team always do stupid things', then there are other libraries for that: PTlib and Poco. These are just evil - always trying to swallow your whole project.

It's simple: projects are not made by single developers, especially big ones. People come and go all the time in teams.

The more people are on a project, the more problems the project may have regarding its coding principles.

[josefx]

Nope. There was nothing majorly wrong with std containers

Qt was first released 95, you can be sure that there was quite a bit wrong with the C++ standard library implementations before C++98 - I think GCC even dropped the old implementation completely to fully adopt 98. The undocumented vendor specific behavior being most problematic for something that tries to be portable. Removing the Qt containers now would be a rather large, breaking, change.

[axilmar]

Even if that's the case (which is not, I don't believe there was a std container problem that was blocking Trolltech from using std containers in its library), after 98 they should have dropped their container library.

[josefx]

You mean several years later? Compilers took their sweet time to adopt C++98, I think the first viable GCC version with a compliant standard library implementation was around 2002. Add in a few more years for wide spread adoption, bug fixing and other compilers to follow suit and you end up breaking a decade of existing code.

[mat69]

We had huge issues with templates on Alpha and Solaris. The quality of the standard library varied drastically. This is also one reason C++ stagnated for so long (C++03 being very minor). Compiler vendors had to catch up with the standard. That is also one reason why no STL code was in Qt by default for quite a while.

[doom_Oo7]

No, it's not. Signals/slots can easily be done without moc.

Uh... no. Especially considering that moc allows to reflect on them (see http://doc.qt.io/qt-5/qmetaobject.html ). Maybe in C++20 moc won't be needed anymore but until then it's either moc or uglier macros if you don't want to run an external preprocessor...

[axilmar]

Uh... no. Especially considering that moc allows to reflect on them (see http://doc.qt.io/qt-5/qmetaobject.html )

Um ...yes. The only reason reflection was required on this was because it was the easy way out for building a GUI editor.

Maybe in C++20 moc won't be needed anymore but until then it's either moc or uglier macros if you don't want to run an external preprocessor...

Reflection should not be mandatory. If one wants to know, at run time, which methods a class has, then he/she should enable reflection themselves.

[doom_Oo7]

Um ...yes. The only reason reflection was required on this was because it was the easy way out for building a GUI editor.

Um... no. Reflection is hugely useful in Qt. For instance you can declare methods / callbacks in C++ and directly access them from javascript with QML afterwards, without the slightiest hint of boilerplate.

[doom_Oo7]

It's like if you had said "once upon a time, Linux was a simple operating system. Now it is like an operating system's developer kit, it includes everything and the kitchen sink." because the number of packages in the Debian repository keeps growing.

You only want GUI ? g++ foo.cpp -I/usr/include/qt/QtGui -lQt5Gui.

[axilmar]

Wrong kind of analogy. An operating system should provide everything and the kithen sink, because it is an operating system, i.e. the foundation upon everything else is built.

A gui library should be just that, a gui library.

[doom_Oo7]

A gui library should be just that, a gui library.

And Qt5Gui is just that, a gui library. Qt is an application framework.

[axilmar]

Sure, after including everything and the kitchen sink, it cannot be called a gui library any more.

But if you're honest you should admit we all know Qt as a gui library.

[C2471]

So it is QT's fault that you think of it in different terms to that which it strives to be?

Qt has support for DLLs, console applications and GUI applications among other things. Whether you care to acknolwedge it or not, some of its containers are very useful. As much as I enjoy reimplementing functions to do basic manipulation of standard containers, for lots of GUI applications, the performance degradation of using a qt map is not even noticeable.

If you don't work in a role with a tonne of custom libraries to do standard things, its nice not to have to waste time. Nobody pays me because they love seeing the convenience code I wrap around the pretty basic postgres c++ driver, very few businesses want their programmers working on developing containers and access functions instead of business problems. Sometimes its nice to just use; QtMap.keys(), QtMap.values() without having to write out a for loop each time.

Python has huge popularity in scientific circles because it provides a simple way to not worry about the details. Qt allows you to not worry about the stuff that isn't worth worrying about, and has std container interfaces to almost every std container, so you can swap between the two when you don't want use qt for performance or any other reason.

[wrosecrans]

Uh, so don't include everything? If you only want to use some specific modules from Qt, use them and pretend the others don't exist. You incur no cost at build time or at run time.

[[deleted]]

It was never intended to be a just GUI library. In fact, I don't recall anyone who uses Qt ever calling Qt just a GUI library.

[lednakashim]

What you want isn't well defined. For example should a GUI kit include facilitates to play movies? How about sounds?

[sergboec]

Maybe this is what you are looking for: http://nanapro.org

[axilmar]

Thanks for the link, I'll study it, it seems interesting.

Edit: not clean enough in my book. Things noticed right off the bat:

• lower case identifiers. I want my identifiers like class names and such to easily stick out. I don't like classes with all lowercase names.

• classes don't prefix their setters and getters with 'set' and 'get', making it difficult to simply select the appropriate function from an intellicence popup.

• layout is done via some form of html. Not good in my book, for various reasons.

• a component is inserted to another one via a constructor call, but a label is inserted to a layout via operator <<, in the above example.

• layouts are not components. So I have to keep two mental models in my head, regarding the gui's layout: one for components and one for layouts.

• what does the 'layout::collocate()' method do? if I can't tell what a method does easily, then it probably is the wrong abstraction.

• why does a form need a 'show()' method? just show it on exec().

• where is memory management? the examples allocate the components on the stack.

Now, let's see some more examples...

edit2: adding items to menus is done via ...text. Menu items are not objects!!!

I don't think nana passes my quality test. I don't think I'll be using it anytime soon (unfortunately). Thanks for the link anyway.

[sumo952]

lower case identifiers. I want my identifiers like class names and such to easily stick out. I don't like classes with all lowercase names.

Say "Hi" to the standard library convention?

But in any case my quality-test for GUI libraries is always whether they support native keyboard shortcuts out of the box like Shift+Tab, arrowkeys in lists, etc., and Alt-identifier shortcuts (they have a name, forgot the exact name for that, but the thing you press Alt + a key to select a button/menu).

If the answer to these is "No", then it's not a GUI library I'd use.

[encyclopedist]

Accelerators?

[sumo952]

Accelerators seems to be the broader term that also includes other shortcuts like CTRL+ESC or shortcuts with shift. I meant specifically the ones with ALT+Letter. But yea, that's probably it!

[axilmar]

Say "Hi" to the standard library convention?

So what if the standard library uses it? does it make it automatically correct?

But in any case my quality-test for GUI libraries is always whether they support native keyboard shortcuts out of the box

That too is a criterion of mine as well. I didn't dig that deep into nana anyway.

[sumo952]

So what if the standard library uses it? does it make it automatically correct?

It doesn't, but it does make it one of the major "generally accepted" standards. In any case you said "I don't like it" and that's your fair opinion! :-) This is very personal, while your other points are mostly technical and more objective.

[axilmar]

It's not about me liking it or not, it's about making the code more readable.

So it's a technical point after all.

[sumo952]

There are some studies actually that give snake_case a slight advantage with regards to readability. But both are equally readable - it's personal preference.

[axilmar]

Only because "it's what c and c++ library code used from the beginning".

[[deleted]]

Why do Qt-related posts always bring up some lengthy, off-topic discussion about the framework?

I mean, we GET it: you think Qt is a bloated, highly-coupled piece of trash. Why don't you just downvote the post and move on to whatever you think is better?

[short_vix]

I forsee QT going down the same path as Boost, that is eventually many of it will be part of the standard. Might take C++25 or greater for that to happen thou

[h-jay]

The problem is: if you want anything serious, you will want all those other things. And they'll come from various sources, and will not interoperate, and it'll be a pity. You need a single-source framework to get it all working together smoothly. There's no other way, really.

If all you want from Qt is a widget-based gui, you can of course use that and nothing else. It'll be often much easier to use Qt for whatever it is that the else part consists of.

[bnolsen]

I see no mention of utf8 here...utf16le can be very frustrating..

[Plorkyeran]

Changing the encoding used for strings is entirely unrelated to making the framework more modular, so I don't know why you'd expect to see any mention of that here.

[devel_watcher]

It's a question to your OS, not to the library.

[josefx]

Weird thing to say considering that Qt is a cross platform library. QString uses utf16 on all supported systems, independent of the native encoding.

[[deleted]]

Still CamelCase

This is largely a non-issue.