Why isn't QLayout a QWidget?

JonB

I know QLayout/QLayoutItem isn't a QWidget, but why isn't it?

In HTML I layout with DIVs and they are HTML elements, just like everything else. In .NET I'd use a Panel and they are Controls, just like everything else. It's obviously what I'm used to, why did Qt decide to complicate with a completely distinct class?

[Incidentally because layouts aren't widgets you can't address them from style sheets, which causes irritation.]

SGaist

Hi,

Lets try to think about it to other way around: why would a layout need to be a QWidget ? We are talking about a concept that is "abstract": handle the size and position of visual objects.

On a side note, HTML's div and .NET are way younger thus it's no really a faire comparison to do.

JonB

@SGaist
I just find it complicates things for me. (It doesn't help that all my UI has to be in program, no Creator designer.) The example I typed in at end above: it's because someone decided that layout would not just be a QWidget that we have the pain-in-the-ass that it can't be style-sheeted.

I'm just interested in pros or cons. I'm not trying to "do a fair comparison", it's just OOI. They are indeed newer, perhaps you're indicating that they may have made a simpler decision in retrospect?

SGaist

@JonB said in Why isn't QLayout a QWidget?:

I just find it complicates things for me. (It doesn't help that all my UI has to be in program, no Creator designer.)

Can you elaborate on that ?

JonB

@SGaist
I use Python & PyQt. It's a large project. No Qt Designer for me. I work in a very good Python/PyQt IDE & Debugger. All UI stuff is done with explicit dynamic creation in code. So I have to remember the hierarchy/layout in my head, and keep having to create widgets & layouts. Whereas with a designer probably you wouldn't have to see/think about it so much. that's what I mean.

kshegunov

If you think about it some more, what would that widget-layout class be named? QWidgetLayout? You know how the rule of thumb when designing classes goes - if it names 2 things it's not 1 class, it's 2. If it is then it's derived, if it has then it aggregates. So from design point of view this is the correct decision - a widget has (or not) a layout, and the widget is not a layout, it's the base for a visual element, not the base for a layout element.

JonB

@kshegunov
Look: let's take an example we can agree is simple and well-designed: HTML. I don't have an abstract layout class, I don't have a QWidgetLayout, DIVs are elements like every other kind of "widget". I don't have a "widget layout class" per se, I just manage with "widgets". What benefits am I missing? KISS!

Chris Kawa

In HTML I layout with DIVs and they are HTML elements, just like everything else. In .NET I'd use a Panel and they are Controls, just like everything else.

The "just like everything else" is this weird notion that every entity representable in a language should be of some common base type, like everything is object in Java. That's just not how the world works. Similarly - not everything is a widget. A relation is not a widget. A property is not a widget. An algorithm is not a widget. A layout is an algorithm that defines a relation between widgets in terms of their properties (size and position). That's not something that is a widget itself, nor should it be. It's not stylable via css because css is meant to style graphical elements, not algorithms.

kshegunov

@JonB said in Why isn't QLayout a QWidget?:

and well-designed: HTML.

That's a joke, right?

What benefits am I missing?

https://en.wikipedia.org/wiki/Separation_of_concerns

Chris Kawa

simple and well-designed: HTML

Thanks, I spilled my coffee on the keyboard...

I would kindly suggest you go through the history of HTML and how stitched from bits and pieces it is, how people tried to make it well defined by turning it into subset of XML, other experiments like SHTML, DHTML and how it became this unearthly bag of randomly named tags most of which no one uses and which requires 2 or 3 more languages just to represent anything sensible... Yeah, HTML really is no marvel of simplicity and elegant design.

JonB

It comes down to practicalities, where you choose to draw the line between one class & another. Of the UI systems I personally have used, like HTML, .NET (Web & Windows) & MFC, they do not have a non-control/widget class to handle layout. Qt does. What have I missed out on?

[P.S. Guys, come on,

Look: let's take an example we can agree is simple and well-designed: HTML.

Would it have helped if I'd added a wink?]

Chris Kawa

@JonB said in Why isn't QLayout a QWidget?:

they do not have a non-control/widget class to handle layout. Qt does. What have I missed out on?

Qt has better responsibility concern separation than those.

Would it have helped if I'd added a wink?

a little ;)

kshegunov

@JonB said in Why isn't QLayout a QWidget?:

It comes down to practicalities, where you choose to draw the line between one class & another. Of the UI systems I personally have used, like HTML, .NET (Web & Windows) & MFC

From these three, I'd worked with two. I used to believe, when I was young and dumb as a shoe obviously, that MFC is the greatest invention since the sliced bread. Granted it's an improvement over what I was doing at the time, which was implementing window procedures, but then again - not knowing any better is hardly an excuse. ;)

aha_1980

@JonB

I use Python & PyQt. It's a large project. No Qt Designer for me.

I've never done that, but i think I heard you can still use designer and convrt to python code with a tool.

SGaist

Yes, you can used designer based widgets with PyQt as well as PySide2.

JonB

@aha_1980 , @SGaist
Yes, I am aware there is a way to use Qt Designer with a PyQt program.

However, my point about the existing code being "large" (and not written by me) is that I have no intention of trying to redesign thousands of lines of existing code relying on explicit dynamic creation of widgets to a completely different model.

Additionally, my point about the excellent IDE/Debugger I use for Pythoning (PyCharm) is that Qt Designer would be completely non-integrated. You have to introduce a separate, command-line step to "compile" your designer work to code every time you make any change (whereas Python itself does not have any "compilation" stage). The whole thing no longer sits inside PyCharm, let alone I don't know if its vital code completion --- which is tricky at the best of times with Python being non-typed and non-declared --- or debugging would work well with external uic files or whatever it is that gets generated. How would you feel if you had to use Qt Designer quite outside of the Qt Creator you use to edit code, switching between them all the time, and having to remember to save from one before moving to the other?

As I say, I don't know because I don't use Designer, but I would imagine by the time you've drug & dropped stuff it creates the layouts as well as the widgets for you as necessary or easily/visually. When you have to do it in code explicitly it takes up screen space to look through (when you're trying to visualize what the code is constructing), it's just cumbersome. It does not help that PyCharm's best efforts to provide typing/completion help in a hopelessly type-brain-dead language often struggles to find anything correct for the context. So I will find myself trying to put a QWidget somewhere that a QLayout is what is required, and vice versa. Which means a lot of manual documentation searching to get it right. I just find that Qt's "controls hierarchy" of interleaved layout -> widget -> layout -> widget -> layout -> widget -> ... , instead of just widget -> widget -> widget I'm used to, complicates my code.

Don't get me wrong: you know I think Qt is really good for what it offers. But this is my thread, so if I wish to bitch about its choice I feel I am entitled to do so! In terms of theory, you can abstract anything to any depth you fancy, the question (for me) is whether a given decision is more or less productive for the programmer. Which is what we are discussing here :)

Chris Kawa

the question (for me) is whether a given decision is more or less productive for the programmer

I can understand that seeing you being a python developer it boils down to programmer's productivity. That's what the language came to life for after all - to be more productive.
The thing is that after a program is written it needs to run in the wild, and at that point other concerns come to light - efficiency, memory footprint, power consumption etc. While stuffing layouting into widgets might translate to fewer lines of code it impacts negatively all the other aspects - it would be less efficient at runtime, it would take (considerably) more memory and it would drain battery faster.
I understand that these are not the first class concerns for python developers, but Qt is a C++ library in its origins and the language was chosen because it caters to similar set of principles. It's just a delicate balance between number of code lines vs runtime metrics vs theoretical design elegance, and Qt sways in the direction of the latter two.

I mean look, it's not like you can't do what you want - you certainly can write your own QWidgetyLayout class and drop your code lines down:

template<typename WidgetType, typename LayoutType>
class WidgetyLayout : public WidgetType, public LayoutType
{
public:
    template<typename ...Args>
    WidgetyLayout(Args... args) : WidgetType(args...), LayoutType(this) {}
};

Bam. It's a layout that's also a widget. You're done.
(sorry, I don't know python enough to do the same)

It just doesn't make sense on a more general level.

JonB

@Chris-Kawa
Yeah, that looks like it would help me in C++, but you just can't do this in Python, that's the problem :( There are no "templates" and no robust "type checking", let alone that whatever you do come up will likely stump the IDE so it won't have a clue what to let you pass/what to offer you for completions. It's not your/Qt's fault, but it's not mine that I have to program in this blessed language either!

kshegunov

Actually the above code does not require templates, Chris put it there so he could easily delegate the constructor arguments is all. The problem is, however, that even if you do that you lose the base of the widget controls like QLineEdit and such.

One additional remark. Qt is a library targeted at user programmers, blessed language or not it makes certain promises that it has to keep, which require it to take some technical measures to fulfill them. For example it promises binary compatibility, thus it's doing the d-ptr idiom all over the place. If you write an application you care not about this, but you do care if the toolkit you use is going to be consistent and stable.

but it's not mine that I have to program in this blessed language either!

I don't want to break your bubble, but Qt is originally written and intended for that language with all its quirks. Using another language introduces all new level of quirks one needs to deal with on top of that. It's unfortunate, but it's how it works.

JonB

@kshegunov

that even if you do that you loose the base of the widget controls like QLineEdit and such

That would be hopeless. I (separately) sub-class every Qt widget type I use, to provide my own extension methods if I want. I absolutely need my JLineEdit(QLineEdit) & JComboBox(QComboBox) etc. classes to know they are derived from the appropriate base class in order to get the IDE to offer suitable completions etc.