Fallbacks for packages

[Sebastian Kügler]

On Monday, July 21, 2014 11:26:58 Marco Martin wrote:
> I have been thinking about the problem of the look and feel and shell 
> packages: we want them to be easily customizable for distributions without 
> forcing to copy and paste the mayority of the qml in the package (and also 
> having things like providing only a spashscreen and nothing else)
> 
> so when a different look and feel package is configured, when a file is not 
> found there, it should be checked for in the default one instead.
> 
> some different scenarios/ideas popped in mind:
> 
> Completely generic: in the package desktop file there is the name of
> another  one used as fallback
> Pros:
> * very flexible, easy way to share code between plasmoids (like various 
> taskbars)
> Cons:
> * all packages become public api, maintainace nightmare
> * possibility of circular dependencies
> 
> One partial solution would be limiting the allowed fallbacks only to
> packages  that start with org.kde.* , but seems quite ineffective, in
> reality.
> 
> Another solution is to have a single one default package to fallback,
> (defined  in the packagestructure) so in case of lookandfeel the base
> org.kde.lookandfeel would be the fallback and no other one could be used.
> It's limited, but (for this very reason) i very much prefer this.
> The drawback is that it could be used for lookandfeel and for the shell 
> packages, but *not* for plasmoids.
> 
> And a last one, would be to just use two packages in the client code. It
> would  be the solution i would normally prefer, but since the look and feel
> package is accessed by too many different processes, entry points, it would
> mean a lot of duplication of error prone code.
> 
> opinions? comments?

I think the main problem with one, or a hardcoded fallback is that, we might 
not always want to fall back to for example the desktop shell, or do we? 
People might want to customize certain aspects of the shell, and then want to 
fall back on the tablet or desktop shell, depending. I've been wondering how 
we can express that. For that reason, I think we might need a flexible 
fallback, which means solution 1 you propose.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9