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

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 20 Jan 2005 18:22:47 -0500 EST

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

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 
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?


Other related posts: