Fallbacks for packages

[Marco Martin]

Hi all,

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?

-- 
Marco Martin