[Development] QIcon, ... in QtGui (was: QStandardItemModel moved to "QtWidgets" module, not good idea?)

[lars.knoll at nokia.com]

On 1/2/12 5:53 PM, "ext Stephen Kelly" <stephen.kelly at kdab.com> wrote:

>On Monday, January 02, 2012 11:43:18 Olivier Goffart wrote:
>> On Monday 02 January 2012 06:20:59 gunnar.sletta at nokia.com wrote:
>> > The argument does indeed exists. QtGui's primary function is to be a
>> > windowing system and graphics enabler. The minimum that is shared
>> > between
>> > QML and widgets.
>> 
>> Ok
>> 
>> > > There is also QFileSystemModel which could be moved to QtGui if
>> > > QIcon
>> > > was moved also (why is QIcon in widgets?) and its dependency on
>> > > QMessageBox was removed.
>> > 
>> > QIcon is a style concept
>> 
>> Not exactly (it is the enabler for the toolbar, menubar, actions, ...
>>in a
>> way that is totally independent of the style.  Only QIcon::fromTheme is
>> related to the style)
>> But let us assume it is.
> 
>Regardless of the *Q*Icon case (I'm not familiar with its code), I don't
>see why an icon is a style concept.

It's not purely a style concept, but I'm not too happy with the current
QIcon implementation, and it has many ties to things that should not move
into Gui, making it very hard to decently separate it out from widgets.

> 
>> 
>> > and belongs together with QStyle and we do not want QStyle in QtGui.
>> 
>> No, eventually, QML will need style as well. (on desktop)
>> You can have style outside of QStyle.
>> 
>> > As both the QFileSystemModel and QStandardItemModel relies on it, they
>> > cannot be moved to Gui. At least not without some surgery, and
>> > the surgery would imply source breakage so also not an option.
>> 
>> QIcon in QtGui would fix it :-)
>> 
>> 
>> Also, i think QAction, and QShortcut should go to QtGui.
> 
>I agree that these shouldn't be tied to a particular gui concept as QML
>will need them too. Ideally the new classes would already be in place and
>these classes would be implemented in terms of that.
> 
>But is there any time to do that at this point? If there isn't then we'll
>end up with fragmented API (duplicated concepts) probably like
>QQuickAction etc (which also doesn't make much sense if an action class
>shouldn't be tied to a gui concept).

QShortcutMap is already in QtGui, and that's all that's required to
properly implement shortcuts in QML. QShortCut and it's C++ API is a class
very much tied to widgets and thus doesn't belong into Gui.

QAction for now is completely in Widgets, as I suspect that we will end up
with a rather different API when trying to implement something for QML. In
addition, QAction is very tied to many widget based classes, so it's
simply better and easier (and avoids breakage for existing apps) to leave
the class alone.

Let's see whether we need a C++ API for actions and shortcuts at all in Qt
Quick.

Cheers,
Lars