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

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 19 Jan 2005 06:22:40 -0500 EST

> 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 
tree) is over 500. Double that if you want to draw via a BBitmap -- the 
calls to DisplayDriver are similar in style but not the same for 
various reasons. Appearance has its own DisplayDriver subclass for code 
reuse. You also might be wondering, "why not just use DisplayDriver, 
then?" Here's a list of the files that go with DisplayDriver or with 
the Decorator itself:
Angle
CursorHandler
DisplaySupport
FontFamily
FontServer
LayerData
PatternHandler
RectUtils
RGBColor
ServerBitmap
ServerFont

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.

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

--DW

Other related posts: