François Revol wrote: > Le 4 août 2010 à 17:04, DarkWyrm a écrit : > >>> I think you misinterpret axel question. The fact that we do have >>> decorator stuff in the app_server is the proof that it's not locked >>> down, and nobody question the usefulness of decorator (as pointer by >>> Humdinger and Clemens works, it's building basis to support other >>> targets than desktop computers). >>> >>> The only question in debate is does all decorators should be bundled >>> in the official haiku image or not. >>> >>> For size issue, I'm myself for making alternate decorators available >>> (which they're not currently, so it will a progress) an optional >>> package, maybe within the Themes package. >> Sounds like a good compromise to me. :) > > Well, I dumped the Themes svn history to migrate it to osdrawer, but I didn't > intend on taking them along with. > I still don't see why I would. As an Easter Egg the other decorators were kind of fun. If they get exposed more openly as one of the equally good options to choose it does risk having an impact on the "look" that people associate with Haiku IMHO. I'm all for having the code set up to cleanly allow other looks (Decorators) and behaviours (Clemens' refactoring) but that doesn't mean we need to also code and ship all the possible uses of those APIs with the basic image. Allowing too many choices by default makes it harder for other graphical elements to be designed that "fit", and could make it more acceptable for different apps to have entirely different visual styles (look at the difference between appearance of GNOME and KDE apps, which often coexist on a linux desktop as there is no reference "Linux look" that designers can refer to). Haiku's single-project mentality means consistency of experience (both behavioural and appearance) is an area where the project can really stand out. Simon