Why isn't QLayout a QWidget?

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.

Konstantin Tokarev

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

In HTML I layout with DIVs and they are HTML elements, just like everything else

Because HTML for a long time didn't have any support of author-defined layouts. User agent, a.k.a. "layout engine", was supposed to represent data on screen in the most appropriate way. Nowadays, we have CSS flex and grid layouts, so author can create desired layout without non-sematic HTML elements like <div> (or <table>:)

JonB

@Konstantin-Tokarev
Crikey, are we not supposed to use DIVs for layout any more? I'm only just getting off TABLEs....