On 2021-03-12 22:32, josef Reidinger wrote:
My previous experience was just with visual basic ( 20 years ago ) and
netbeans one for swing ( 12 years ago )[1].
Back then, Visual Basic (or Visual C/C++) did not have any geometry
management, so any dialogs had a fixed size, and all widgets ("controls"
in MS lingo) had fixed sizes and positions. That's why it broke horribly
if you needed to use a larger font, and you had to "make it big enough"
to fit translated messages (no kidding, that was the original statement
from MS when I asked that question on a "Windows NT for Unix
programmers" workshop back in the late 90s).
It's trivial to create a GUI builder that can only do fixed sizes and
positions for everything. But that's not what we need; we need real
geometry management. Think about all our translations and how verbose
some languages can be. Think about HiDPI vs. minimalistic screen
resolutions. And I am not even mentioning NCurses.
...
So I explore and play a bit with qt designer.
...
So I create testing project and start. The output is ui file which is
XML based, so quite easy to parse and hard to read for human.
...and the best part is that Qt comes with the "uic" (UI Compiler)
preprocessor that can create C++ code from it that you can compile and
link with your project. Not C++ code that you are supposed to edit; just
C++ code that you can embed into your own C++ classes.
I have tons of examples here:
https://github.com/shundhammer/qdirstat/tree/master/src
Look at the *.ui files.
But looks quite promising for us to parse it and e.g. try to show
ncurses equivalent.
Good luck with that.
Widgets in XML has its id, so it should be easy to connect widgets
with actions in programming language as for us the direct connect in
designer does not make much sense and I do not like it much. I think
that GUI layout should be in WYSIWYG, but connection to data model
should be in code.
I try layouts available and I am not sure if it is limitation of
designer or qt, but all layouts are quite trivial
No; you didn't look hard enough. There is the QVBoxLayout / QHBoxLayout
which is pretty much the same as our VBox and HBox, there is QSplitter
that has that movable border, there is QGridLayout that is very much
like a HTML table and which I had suggested to add to libyui a year or
two ago (which was rejected as "we don't need that" by the team).
But to make it really work nicely, you always have to set a QSizePolicy
for every widget to specify its resize behaviour, including its initial
size; and our 20 years of experience with our libyui shows that normal
application developers mostly don't grasp even the simple cases
(hstretchable, vstretchable; weights). I have little hope that it will
work better with considerably more complex concept like QSizePolicy.
and nothing like
Spring Layout[2] in Netbeans which allows to specify constrains on
widgets like align left side to center of this widget and have right
side align with left of different widget.
You add a QLayoutStretch.
Situation with layouts was
even worse for me and I failed to create design that works well with
resizing of window ( maybe issue was that I use MainDialog as base? ).
No, you didn't set the right QSizePolicy; see above.
Probably issue on my side, but it says something about usability of
designer.
Nice feature is also builtin tooltips and translations, but I worry
how easy will be to use gettext for translations instead of qt
built-in localization.
That's the trivial side. I worry more about the sheer amount of texts
vs. broken English.
There are some widgets that are currently not supported by libyui.
What I like in designer is clear separation of input and display
widgets. So it is clear which ones are for displaying info and which
should be used for getting data.
You mean how they are arranged in the Qt Designer toolbox; which has
nothing to do with what you can use them for.
I try to design more complex menu with submenus and it works nicely in
designer.
Overall qt designer for me is comparable to visual basic experience 20
years ago and still not so nice experience as netbeans designer 12
years ago.
Clearly, you have seen only the tip of the iceberg. ;-)
Having actively used Qt Designer in my QDirStat and having given quite a
number of one-week-long Qt trainings during my time as a Qt consultant I
can tell you that Qt designer is as good as it gets without nailing down
everything to fixed coordinates and sizes. I like it a lot.
But it's not a trivial tool, and it does not turn everybody into an
instant GUI expert. Its major advantage is to avoid tons of boilerplate
code that you otherwise have to write; code that is repetitive,
error-prone and hard to maintain.
What we do in libyui is not only the abstraction from NCurses; it's also
the abstraction from the gory details of complex toolkits like Qt that
allow to do just about everything, but you still need a lot of expertise
to actually use it. Libyui does much of that stuff for you, if you only
let it.
But if you put it into yet another wrapper like CWM, application
developers have a hard time to make use of libyui because CMW, like all
wrappers, loses some information between the wrapped layer and the
application (plus you need to have intimate knowledge of CWM because you
need to know WHAT method to overwrite on WHAT layer and how; the
documentation leaves a lot of questions open).
Use libyui the way it was intended to be used, and it will become
considerably easier.
Read the "layout how-to" document and look at the examples, and it will
become even easier.
Wrap it into CWM, and everything becomes arcane Voodoo.
Keep wrapping dialog parts into more and more unneeded widgets, and the
side effects will take over, and you will lose control of what is
happening. I see that a lot in our dialogs.
I could go on more, but this is a good point to stop this.
Kind regards
--
Stefan Hundhammer <[email protected]>
YaST Developer
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG
Nürnberg)
