"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote: > > 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. > I must not be explaining myself very well, then. Let me try to fill > you > in on the entire situation, for both you and Bryan Varner (who > replied > off-list and asked the same question). > > I have three main reasons for you and a couple questions, as well. > The > first reason is that back when I first implemented decorators > (prototype #5), I didn't even know that you could do such things -- > it > was later when I was working with Jason Vandermark on getting the > input > server and the app server to talk to each other that I found out that > this was possible. I remember this pretty well because I thought it > was > something that worked that I thought was downright bizarre. I still > think it's pretty strange, but that's also my personal opinion. I think it's absolutely natural - when you link the add-on against the applications, your application acts like a shared library to that add- on; and that's exactly what you'd like in this situation: a code add-on that can access the code in your app. > The last reason, though, is more objective in nature and may come > from > my self-taught background. There are a number of classes which are > private ATM which I wouldn't mind seeing public eye in some form > after > R1, such as IPoint, ColorSet, the functions and classes in > SysCursor.cpp, and others. The Stephen's Painter class (based on > AntiGrain Geometry) is something that I would also like to include in > it for the moment until such time that it can be public because it is > definitely something I think developers would like access to. Most of Then those should go into the BPrivate namespace and into libbe.so. We can then rework them to adhere to the standards of a public API and make them public one day. > the classes in libappserver are brought in by the decorators' need to > directly access DisplayDriver. It's probably a design no-no to have > decorators directly access the graphics driver object, but that is > currently what they do -- when I implemented them, AtheOS' server did > it and I didn't see anything wrong with it. > > What I would like to know is this: why would you *want* to link to > the > server? What advantage is there in not using a shared library? If > there > is code needed by several sources, why not? It's cleaner, it's faster (loading times), and most importantly, it reduces the number of public global shared libraries which is always a good thing if possible. Bye, Axel.