On Mon, Aug 12, 2013 at 08:02:55PM +1000, Chris Adams wrote: > [...] > However, what I do know for sure is that nobody ever tried to come up > with a set of requirements and discuss the topic with the rcc > maintainer. > > > I don't know too much about the specifics of the qmlbundle implementation > at all, but I do know at least some of the requirements which drove its > development. As to whether or not qrc would have worked for these > use-cases is a different question (and one which I also know next to > nothing about, so I'm not trying to answer the "why wasn't qrc used" > question at all here). But some of the things are: > > 1) Since a QML module can consist of just qmldir + .qml documents + .js > resources, we can't require a plugin or executable into which the bundle > gets embedded, to exist at distribution time > > 2) Going forward, including the compiled QML typedata into the bundle as > a two-stage build step was a goal. This would greatly speed up > application startup time for obvious reasons (no need to parse the > bundled .qml files, no need to compile the parsed tree, just mmap the > compiled typedata and do the fixups for the virtual address offsets, > etc).
Bundling architecture-independent data with an architecture-dependent binaries is the bread-and-butter job of the Qt Resource System. It's not restricted to that, but it's what the resource system is meant for. As far as I can see, there are two use cases here: 1. Having a couple of .qml, .png and whatever non-executable, but potentially target (resolution...) dependent resources loaded and "run" in some kind of viewer application. -> Smells like the resource system might be suited (rcc -binary, recognize/load result into viewer application) 2. Bundling a couple of .qml, .png, and whatever architecture- independent data together with some real compiled code. -> Smells like the resource system might be suited (a shared object/dll with compiled-in or dynamically loaded resources as usual) I don't see any obvious reason to dismiss the existing ressource system in either case, nor to run a new-from-scratch approach instead. I am not (yet) aware of another case. So what do I miss? > The whole resource code (core + the rcc commandline tool) is barely > 3000 lines of code. Might be not the nicest, nor the most obvious > code ever, but field-proven, and "just works". Someone might even be > able to look at it and find out. > > <sarcasm> But why bother when re-inventing wheels is so much more > fun. And of course, the few thousand more lines of qrc tooling > integration is nothing to be concerned of, either. It will magically > adjust itself, at no cost. As usual. </sarcasm> > > The refusal to even only consider re-use of existing assets is a huge > sink of resources. > > > It's not about fun, in many cases, it's about pragmatism. For fifteen years, Qt application startup time has never been a serious issue, thanks to native code and proper compilation. Even declarative UI elements have been compiled by default, and All Was Well. If now, with machines a dozen times beefier than before, startup times suddenly become an issue, a flag should be raised. A _pragmatic_ approach to the problem would certainly not be to add more workarounds and re-invent more wheels, but to go back and find out at what time what new feature caused what part of the damage. For starters, the whole idea of shifting computational effort from build time to run time by replacing properly compiled native code with run-time interpreted code _and expect acceptable performance especially on resource-constraint embedded and mobile target systems_ looks bizarre enough to justify a reality check. Andre' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
