Why put *.qml files in a resource file?
-
Hi,
what are the pros and cons of putting all QML files into a resource file versus just shipping the raw qml sources with the application?
So far, I can think of:
QML In resource file:
- Hides (a bit) qml source code;
- Easier to ship as it is in the exe.
- Users cannot change GUI without recompiling.
Ship QML source code:
- Users change GUI without recompiling;
- If you app is based on some JS API, then users can learn by looking at GUI.
Thanks for any input.
-
@Korchkidu said:
Ship QML source code:
- Users change GUI without recompiling;
- If you app is based on some JS API, then users can learn by looking at GUI.
Do you think that these are pro or con? As you only gave a header, but no sub-header.
If pro, I would like to hear some arguments, as I don't see why you would like the users to change or learn, unless students.
-
-
@Korchkidu said:
@KiwiJeff leting users change GUI style or build tools on top of your app is kind of great I think.
Well, yes, depending on the type of user. But what you are describing here can be realised much safer via an API then by simply open sourcing your code. Not that QML is encoded when put in the resource file, but just less open source.
-
Hmmm interesting question. I do think the resource files lead to a cleaner thing being released, but in an application I did where the QML files are just sitting in the app bundle (OSX) the collaborators have gotten used to trying out their ideas for minor changes (layout and colour and effect tweaks type things mainly) by just editing the QML themselves. Which is great because they have little interest in (or, realistically, chance of) learning to recompile the app and would be nagging me for endless changes otherwise. So exposed QML has been good for development, but it remains to be seen if we'll just leave it like that if the app ever ships properly, or whether we'll make some efforts to hide the QML away more then.
