FreeLists / haiku-appserver / [haiku-appserver] Re: purpose of libappserver.so

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

"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.