[haiku-appserver] Re: Refactoring

Hi,

first, let me say that I really like what Axel is proposing in every single 
detail. I have thought along the same lines.

I try to keep this email short. Please re-read what Axel wrote about 
ServerScreen and then go look at the actual code. It is currently much more 
straight forward to think of ServerScreen as a representation of a 
physically attached screen. So a ServerScreen manages a graphics driver (or 
later possibly one output of a graphics card). In this setup, it is clear 
how to configure a physical screen. For example, when a Workspace becomes 
active, it is clear that it uses the ServerScreen instance to change 
resolution, color space etc. I know that some of you had something different 
in mind at first, but again, just look at the code, it is just obvious where 
it goes from there. Maybe we can rename it to PhysicalScreen if that makes 
everybody more happy.

Second, I really love the idea to think of a Workspace as a container for a 
certain configuration of the physical screen(s). When multiple independant 
physical screens are supported, one Workspace will represent a certain 
setting of _all_ the screens. Before you disagree... this is pretty much 
exactly the way workspaces work now on R5. For example, you might have all 
workspaces configured the same - save one, which is configured to have the 
video overlay on the external output of your laptop and has the resolution 
that fits your beamer. When you make a presentation or want to watch a 
video, you simply switch to that workspace and everything is setup. What 
Axel has proposed will allow for exactly this elegant way of using 
workspaces. Just extended to multiple screens.

Third... DarkWyrm and Adi keep mentioning that the code has to be the way it 
is, and that it being complicated is because of the complexity of the 
app_server. Sorry, but I have to disagree. The app_server really has _no_ 
reason of being so hard to understand as it currently is for a new 
developper joinging the team. And this really hurts development. Everyone 
having come to the team had this first impression. The code containing so 
many errors is just proof of it. Please, I don't mean to hurt anyones 
feelings. I would not want anyone to have a look at the WonderBrush code 
right now. I know how hard it is to be brave and refactor almost your entire 
code base. I understand this is code that has grown.
So I would say, please, have some trust in Axel, let him do his magic, it 
can only help. The problem is that many of the central classes _don't_ 
currently have clear responsibilities, and that makes the code flow very 
hard to follow. Refactoring the classes to make the code flow more clear 
will help app_server a great deal, I'm sure of that. And the 
responsibilities for the classes that Axel has layed out, really make a lot 
of sense to me. Encapsulation and forcing certain code paths can really do 
wonders for the robustness and correctness of the app_server, and that is 
one thing that it is still lacking in many places.

Best regards,
-Stephan

P.S. I have started work on drawing into bitmaps a couple days ago, but I 
had to work over the weekend. I hope to have something ready by the end of 
the week though.

Other related posts: