[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?
--DW
- Follow-Ups:
- [haiku-appserver] Re: purpose of libappserver.so
- From: Axel Dörfler
- References:
- [haiku-appserver] Re: purpose of libappserver.so
- From: Axel Dörfler
Other related posts:
- » [haiku-appserver] purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- » [haiku-appserver] Re: purpose of libappserver.so
- [haiku-appserver] Re: purpose of libappserver.so
- From: Axel Dörfler
- [haiku-appserver] Re: purpose of libappserver.so
- From: Axel Dörfler