[Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders
Alan Alpert
416365416c at gmail.com
Wed Jul 3 21:29:51 CEST 2013
On Tue, Jul 2, 2013 at 2:42 AM, Bubke Marco <Marco.Bubke at digia.com> wrote:
> Hi Gunnar
>
>
>> Gunnar Sletta:
>>
>> The ApplicationWindow encapsulates a completely different concept compared
>> to normal items and trying to treat them as the same in the design tool
>> makes very little sense.
>
> Is sense, logic not very context depend? I think our argument network, which
> is designer centric, is different from yours, which is run time centric.
> Like I have written ApplicationWindow is a hybrid of a window and a item but
> it is not a item in the sense of duck typing. It is different and that is
> hurting us. And for the menus you don't need a WYSIWYG editor.
The thing is that we have a lot of lofty goals we're trying to
accomplish here, one of which is to guide the designer-centric
viewpoint to match the run-time-centric view. If they diverge then we
run into all sorts of problems, tooling may be the one we're looking
at now but performance was the original inspiration.
Window {} is not supposed to be thought of as an Item, even in the
designer-centric viewpoint, and if we fumbled that then we should try
to fix it. One complication is that we're trying to reuse Item
concepts to make Window easier to use, which may have only exacerbated
the understanding problem.
>> The ApplicationWindow floats stand alone in the windowing system, it may
>> have menu bar, status bar and toolbar, all of which require dedicated
>> support from the designer to be designable. And the code generated does not
>> go into a QQuickView, but needs to be created as via QQmlComponent::create()
>> as it creates the window itself.
>
> Actually what is the advantage to have the menu bar, status bar and toolbar
> designable? And we do not create the items from text because we need more
> control over them. I don't want to argument about that again and
> again. ;-)
>
I think by designable this just means feature parity with the old Qt
Designer. Since Qt Quick came at UIs from a different angle we can
already do tons of stuff designer could not, but we're still catching
up with what it could do.
--
Alan Alpert
More information about the Development
mailing list