On Tuesday 22 July 2014 11:27:48 Sebastian Kügler wrote: > > 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.
yeah, seems useful in many situations. however, the concern i have is the following: basically, any plasmoid being able to depend from nay other plasmoid.. so any random change, would break the depending plasmoids. This violates the isolation promise that is one of the points o Package.. thinking.. there should be something to define that the package can be used as a fallback.. may depend from the package structure so only some types of packages would allow it, or the package providing a file that contains a whitelist of files it can expose.. hmm -- Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel