On 2021-03-15 16:20, josef Reidinger wrote:
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.
Well, I expect that editor do it for me or at least guide me. My goal
is to really have UI design created by designers and not programmators
and if some parameter is mandatory I expect designer emphasize it
enough.
That is a myth. You should know that. You need software developer
skills; it's not just drawing nice pictures. You need to know the
underlying logic to make it behave well when it resizes, or even just
for a reasonable initial size.
Any average end user can draw a static dialog; that's trivial. It's the
dynamic part that kills it every time, i.e. geometry management and
useful initial size.
> 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.
Yes, you can always work around it
That's not a workaround, it's the way this is designed; and it's even a
lot more powerful. You can use a layout stretch for trivial things like
alignment left / right / top / bottom / center / hcenter / vcenter; and
you can use it to add some more visual spacing and to make it not
totally centered, but to distribute size in, say, a 1:3 ratio between
the left and the right border.
It is different to just drag right border and snap it to
some line ( like e.g. powerpoint do )
It's not PowerPoint. Again, PowerPoint lets do draw STATIC things. We
need reasonable DYNAMIC behaviour.
That's the trivial side. I worry more about the sheer amount of texts
vs. broken English.
I am not sure if I get it. So you think that bigger problem is that we
have a lot of new text in tooltips that will contain broken english?
I see the quality of our help texts (or rather the lack of it,
explaining only the obvious) in our current dialogs. I see how often
there is very broken English in our current dialogs (and nobody seems to
take notice). I don't think that adding even more of that will help any
user.
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.
And this is what I hope from Designer tool. That it hides a lot of
details for me and I just design nice dialog with widgets and then
connects somehow that widgets to data in my program.
Simplification always means dumbing down to some extent. Qt Designer
already uses a lot of very reasonable defaults, but you still need to
know what's there to be changed in case you need to change it; because
you might have a non-trivial use case.
Qt Designer has a property editor for each widget so you don't have to
dig in the widget reference docs so often; that's another clear
advantage. But still, you need to have a general idea what all those
properties do.
Use libyui the way it was intended to be used, and it will become
considerably easier.
Sadly this does not help with my main goal. WYSIWYG dialog editor that
allows anyone to play with how dialog looks like. Something like if
Ken wants to change dialog to have less spacing there and different
arrangement elsewhere like feature we get in few weeks ago from him.
Again, it's the dynamic behaviour that makes or breaks it. You can turn
it any way you want, you still need to know how to achieve a certain
dynamic behaviour: "When the dialog gets larger, I want that extra space
to be distributed between this and that widget, and that other widget
should remain as it is".
Kind regards
--
Stefan Hundhammer <[email protected]>
YaST Developer
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG
Nürnberg)
