[Development] QAction-like API for QML

Kevin Krammer kevin.krammer at kdab.com
Tue Dec 18 11:24:21 CET 2012


On Tuesday, 2012-12-18, Bache-Wiig Jens wrote:
> > Now, you've most likely seen way more Qt apps than I have, but all I have
> > seen were shipping icons, most of them as part of their resources, some
> > as files.
> 
> I am pretty sure this is a misunderstanding. We do not bundle the icons
> inside the Qt libraries. People bundle it with their application
> executables. I.e they put their "edit-copy.png" file inside their
> application resources, just like we do in our examples.

Ah, that makes sense. I was misled by "Most apps probably don't want to carry 
the extra data." assuming that was referring to shipping icon files with the 
application.

> > Both mechanisms which by design load icon data by name, so at least from
> > my empirical data I am quite puzzled to learn that iconName would be
> > sufficient for specifying icons.
> 
> On Linux and related open source platforms there is an established icon
> naming standard. The linux distributions are free to ship their own icon
> themes as long as they follow the naming convention. This makes it
> possible to use icons by logical names like "edit-copy" instead of
> referring to explicit png files bundled within your application resources.
> It saves time, space and makes applications more consistent since they can
> use the same icons across different applications.

Right, but referring to a file (bundled or in the resources) is still 
referring to the icon by name, no?

Taking your example of "edit-copy", does it make any difference if edit-
copy.png is stored in some system wide shared locations, relative to the 
application executable or in the application's resources?

In the end the result is QIcon( filename ) being used, right?

> It is a nice concept but my only point was that we cannot rely on it alone
> since it makes the app useless on Windows and Mac. It would be neat to
> include icons in Qt but that would essentially be like bundling all of the
> Oxygen icons in every single KDE application and beats the purpose of it.

I am not sure I can follow here.
Where is the connection of Windows and Mac not valuing visual consistency and 
not providing some kind of central icon repository and Qt applications 
continuing to load icons from files?

> > Drawing icons on demand sounds very cumbersome to me.
> 
> That was certainly not what I was trying to suggest. I hope that clarifies
> things. :)

It does :)
It was just that drawing was the only way I could quickly come up with that 
would create an icon without having to load data from a file.

What other form of creating an icon did I miss?

Cheers,
Kevin
-- 
Kevin Krammer | kevin.krammer at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4712 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121218/5fb4e2bb/attachment.bin>


More information about the Development mailing list