Reparenting

[brcain]

Hello,

How do you do reparenting within Designer?

Is there an equivalent of the old UIM/X widget browser where you drag-and-drop a widget tree hiearchy into the new parent? Or, is there another way?

Thanks,
Ben

[high_flyer]

What do you mean *re*parent with designer?
Reparnting means changing a parent to an object, which suggests a dynamic process (i.e at run time).

[brcain]

By reparenting ... I mean changing the widget hiearchary ... moving an entire tree from a given node to another. For example, I might want to move (or copy) the children nodes of one parent widget to another. This might occur when wanting a set of widgets to be managed by some other widget.

[high_flyer]

It could be that I still don't understand, but when you move a widget from one container widget to the other, the new container widget becomes the new parent of the moved/copied widget...
But this you might know already, so I guess I just don't follow...

[brcain]

when you move a widget

Moving is a different concept from changing parent. Perhaps that's the best way of explaining. I'm referring to changing the "ownship" of the widget ... changing which parent "contains" the child widget[s]. The reason I ask this is that sometimes it's very difficult to do this graphically ... with a move operation ... because the parent widgets may have very little screen space to actually drag the widgets into. Other tools I've used in the past have an editor that strictly shows the widget hierarchy. They also have an explicit parent field that can be edited ... which would also accomplish the reparenting.

[high_flyer]

Moving is a different concept from changing parent.

Not in designer.
And it does makes sense - see below.
But you can change the parent in code, which will also move the widget physically on to the new parent.

I'm referring to changing the "ownship" of the widget ... changing which parent "contains" the child widget[s].

Yes, we are talking of the same thing, but in this case, visually containing also means being the parent of the widget.

because the parent widgets may have very little screen space to actually drag the widgets into

Hmm... then somthing in the grphical design of your GUI must be wrong.
What is the point of such a small container, that is so small you cant drag and drop in to it?
It means you just see a small speck on the GUI...
However,what you can try is, cut the widget you want to insert in to the small container, select the container, and then paste.

[brcain]

What is the point of such a small container, that is so small you cant drag and drop in to it?
It means you just see a small speck on the GUI...

It's only initially small ... while editing.

An example ... when I create a grid layout widget and add the first child ... it resizes so that it's difficult to add the second widget graphically to the correct parent.

Another example ... when I want to move widgets to a new parent that's not visible.

However,what you can try is, cut the widget you want to insert in to the small container, select the container, and then paste.

I'll try that (e.g. selecting in Object Inspector ... then pasting). I'm still on the learning curve.

[brcain]

I'll try that (e.g. selecting in Object Inspector ... then pasting). I'm still on the learning curve.

This doesn't always work. It doesn't paste to the desired parent widget I have selected.

I may just have to hand code the main window. The tool really needs more capabilities in this area.

[wysota]

An example ... when I create a grid layout widget and add the first child ... it resizes so that it's difficult to add the second widget graphically to the correct parent.

So first position widgets and then apply a layout, not the other way round.

Another example ... when I want to move widgets to a new parent that's not visible.

Are we talking design or run time? If the former, then all widgets are visible (provided you didn't shrink it manually, forgot to set sizeHints or layouts or stack some other widget on top of it - all of them being design flaws of your gui not the editor.

I'll try that (e.g. selecting in Object Inspector ... then pasting). I'm still on the learning curve.

Maybe you have a wrong approach here? Try to first build a hierarchy of objects you need, apply layouts to each hierarchy and only then position the groups as they should remain and as the last point, apply the layout to the form itself.

[brcain]

So first position widgets and then apply a layout, not the other way round.

That's probably it. I'm used to desigers that also support a top-down approach ... which can be useful for refactoring.

Maybe you have a wrong approach here? Try to first build a hierarchy of objects you need, apply layouts to each hierarchy and only then position the groups as they should remain and as the last point, apply the layout to the form itself.

Does this approach work well with redesigning an interface?

[wysota]

That's probably it. I'm used to desigers that also support a top-down approach ... which can be useful for refactoring.

Designer supports it too, but if you have trouble using it, you can try a different approach (which is in my opinion more intuitive anyway).

Does this approach work well with redesigning an interface?

Sure, you can always break a layout and reposition your widgets.

To be honest I'm not fond of statements "I have seen xxx do yyy. Why Designer/Qt does it differently?". I could probably ask you dozens of questions asking why xxx doesn't do zzz which is supported by Designer/Qt. Remember, nobody forces you to use either Designer or Qt. Most people like Qt also because it is easy to program using it. If you are used to bad habits, then maybe it is time to try to get rid of them and try a bit different approach, maybe you'll learn something new and if you do, you'll have the knowledge and experience to compare both approaches and choose one which fits you better. Not all that is expensive/commercial is well designed just because of being commercial, you should be aware of that when you enter a new environment. BTW, Qt is commercial too - all those statements apply to it as well. If you use Qt, use it because you like it, not because it is commercial/open source.

[brcain]

To be honest I'm not fond of statements "I have seen xxx do yyy. Why Designer/Qt does it differently?".

We all learn by comarison and contrast.

Remember, nobody forces you to use either Designer or Qt.

I am "forcing" myself because I think it’s built upon a well designed framework. I do think there is room for improvement with Designer though. BTW, that's not intended as a personal insult to you ... just my humble opinion