Review Request 120099: RFC: UI-Files inside resources instead of filesystem

[Christoph Cullmann]

> On Oct. 5, 2014, 5:58 p.m., Christoph Feck wrote:
> > Sorry for chiming in late, just noticed the commit.
> > 
> > Any reason why the resource is checked first, not last?
> > 
> > If the programmer decides to use the resource, the "locateAll" effectively turns into a "locateNone". Not really friendly to administrators.
> 
> Christoph Cullmann wrote:
>     Actually that is a big benefit in my eyes, if you ship software with compiled in resources, you don't want people mingling around with them, IMHO.
>     E.g. in ktexteditor I could use this and be sure that no actions or stuff is missing only because some "fixed" ui file got placed in the right location.
> 
> Albert Astals Cid wrote:
>     I agree with Christoph Feck, we should not disable such an important feature as locateAll, if you don't want locateAll don't use it, but don't break it with strange rules as "LocateAll won't do locate all if your xmlgui is in your .rc file instead of the filesystem".
> 
> Christoph Cullmann wrote:
>     ? I don't get that point, I don't break "locateAll", the patch just changes the default lookup of setXMLFile, if the application/library author decides to put the ui file in a resource.
> 
> Albert Astals Cid wrote:
>     It does break setXMLFile behaviour, the code has a locateAll but now we're checking for the rc file before, so setXMLFile behaves differently on depending how you install/package your application. That's unexpected and i would say undesired, and even if it is desired, it is undocumented.
> 
> Albert Astals Cid wrote:
>     And it also probably breaks all kind of editing of toolbar by the user.

That is true, you would need to call setLocalXMLFile, in addition, thats true :(
I agree that this needs to be either fixed or documented, still I don't see the problem with the fact that the application/library author can enforce that the resource file is used.
But as two people think it is an issue, I should fix it the way you say.
Should I reverse the direction of the lookup then, to have it behind the current "kxmlgui5/" but in front of the deprecated locations that warn?


- Christoph


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120099/#review67966
-----------------------------------------------------------


On Oct. 5, 2014, 5:32 p.m., Christoph Cullmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120099/
> -----------------------------------------------------------
> 
> (Updated Oct. 5, 2014, 5:32 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> -------
> 
> Instead of installing them in the kxmlgui5 share prefix, install them in a kxmlgui5 prefix in resources.
> That will allow to test stuff without installing it first, as the resources will be found anyway.
> Still the "I can edit it and have a copy in my writable datadir" should work.
> Question is: is it possible with one "kxmlgui" prefix for the resource or is it better to swap that around like "componentname/kxmlgui5/.."?
> 
> 
> Diffs
> -----
> 
>   src/kxmlguiclient.cpp e8170ad 
>   src/kxmlguifactory.cpp c4ad97b 
> 
> Diff: https://git.reviewboard.kde.org/r/120099/diff/
> 
> 
> Testing
> -------
> 
> Compiles & if I package ui file in kate into resource, works.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20141006/ff95189b/attachment.html>