"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote: > > How about drawing those previews inside the app_server into a > > BBitmap > > Appearance has passed to it? At least I don't see the necessity for > > the way it's done now. > That would require a significant amount of code to do so. The drawing > functions in the DefaultDecorator, for example, take a little over > 200 > lines of code. Big deal. The BeHat decorator (not currently in the Why would you want to do that? Why not just have the app_server use this display driver to draw into the bitmap buffer provided by Appearance? I don't see a problem with this, nor much work. [...] > This is almost all of the files in the library itself. Additionally, > the private API for system cursors is kept in the library and will be > also used by Appearance at some future time. You could say that > Appearance is our equivalent of Be's ScrollBar preferences app - it > has > a tendency to break the general protocol followed by most preferences > apps because it's using a private API and it tweaks things handled by > the app_server itself. Well, private APIs are one thing and fine, but I think this is another case, as both, app_server and Appearance link against this library. What would the app_server do with this private API? > The decorators themselves also link against libappserver. There was a > time when Appearance and the window decorators had their own copies > of > the sources that they needed, but it was hard to keep them in sync > because of the multiple copies in the tree. It also speeds up build > time because there are half as many files to link whenever you're > working on something like the ServerWindow class because none of the > foundation classes have been changed, and while you could just have > the > decorators and Appearance link against the app_server itself, I think > that's more hackish than what's in place. I hope this clears things > up > for you. :) Why not just link the decorators against the app_server, then? That's the usual way to deal with add-ons. Bye, Axel.