Assets: Does it need to be transparent?

[Tyler Mandry]

Not only does this cause speed issues, but essentially it's "overlaying"
assets on top of the rest of the file system, which can shadow real files
on the device without providing an easy way to get to them. I don't think
this is a good idea.

I don't see what would be wrong with putting everything in assets/. Other
platforms (i.e. MacOS) have different paths to put supporting files, and
developers have to deal with those. Additionally, I personally think it
would eliminate a lot of confusion over where a file is "coming from."

Finally, Chris's patch dealing with trailing slashes was reverted because
it slowed down applications further. His patch isn't the problem, it's the
fact that assets has to be searched for every file that's the problem!!
Besides, we can't live with a bug that requires you to put trailing slashes
at the end of every path. It's confusing, inconsistent with documented Qt
behavior, and certainly not the "Qt way."

On Fri, Feb 17, 2012 at 1:25 PM, Chris Browet <cbro at semperpax.com> wrote:

> Hi,
>
> The way the Assets are implemented, every single file access made in Qt
> will try to go the assets first.
> When trying to find out why my QML app was so slow to start, I noticed
> that not using the assets as they are now gained me up to 20% in startup
> time.
>
> My question is thus: Is there another reason for transparency than maximal
> compatibility?
>
> If not, IMHO, it would be better to gain some speed rather that keep max
> compatibility. When switching platforms, the file locations are what is the
> least compatible, and is expected to be adjusted...
>
> I'd suggest to only try the assets if the path starts with "/assets" or
> "file:///assets"
>
> What do you think?
>
> - Chris -
>
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>


-- 
Tyler Mandry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20120331/0ecf7166/attachment.html>