[interfacekit] Re: Structure of the app_server

I've gone and dug up most everything in the way of docs that you've 
posted thus far -- and it's a lot to digest!  I need to cogitate on this 
stuff a bit more -- fit it together with what I've been thinking about 
-- but I have a couple of questions.

I'm unclear on exactly the role layers play and what their relationship 
to server windows is.  It *sounds* like the layer does the drawing and 
holds information about the client-side window and the server window 
just maintains some metrics  regarding the window's placement and, of 
course, a reference to the current decorator.  Is that about right?  Is 
there a 1:1 relationships of layers to windows?  If so, is there a 
logical reason why these are two separate classes?  Maybe  I'm being 
thrown off by the "Layer" name -- I'm not really groking the abstraction 
it represents:  a layer of *what*?

Something I wanted to note, I remembered reading in the news lists some 
time ago that the desktop is nothing more than a window whose client 
area is -- you guessed it -- the size of the desktop.  I recall the post 
stating that if you could hunt the window down and kill it, you'd have a 
no-man's land of random crap in video memory as your background.  I've 
never tried it, but it's food for thought.  The question that comes to 
mind for me is this:  is there one of these screen-sized windows for 
each workspace, or just one representing the desktop generally?  Seems 
to me that since each workspace can have a different resolution, a 
desktop-window-per-workspace policy might simplify things a bit.

Couple of things I want to re-iterate.  None of this prototyping work 
needs to be production quality.  It should only be a proving ground for 
ideas.  Also, we need to heavily document our work.  Two reasons for 
this:  First, so that new people coming onto the project can come up to 
speed quickly.  Second, to ease maintainance and extension down the 
road.  The project at work which has had me on the rack the last several 
weeks is poorly designed, but worse, it's poorly documented.  Figuring 
out how systems work together, or even what's being used and what is 
just baggage from previous versions that no longer serves a purpose has 
been a certifiable *nightmare*.  I don't want to see us do this to 
ourselves. =P

Anyway, enough manager-mode, I'm goin' to bed.

e

>Just wondering where everyone went the last couple days - haven't heard 
much 
>about anything. I, personally, have been major swamped with work (the 
kids 
>have small concert next week), but I have been getting some stuff done.
>
>I reworked the "fluff" test code that I banged out and I seem to think 
I have 
>an idea for the actual structure of the app_server. The current code 
crashes 
>the input server (figure *that* out ;), so here's an RFC before I go 
fixing 
>it.
>
>Below I have a comparison of what the AtheOS server does and I think 
what the 
>OpenBeOS server should do. An explanation follows the pseudocode. :)
>
>AtheOS:
>-------------------
>server.cpp:
>main()
>{      Create Layer array
>       Create Bitmap array
>       Load AppServer Config
>       Set data for workspaces to defaults
>       Load config file
>       Initialize keyboard poller
>       Create & Run app_server
>}
>AppServer::AppServer()
>{      Set internal pointer to self
>       Initialize font stuff
>       Load the decorator
>}
>AppServer::Run()
>{      Create a buffer
>       Create the AppServer message port
>       Initialize workspaces
>       Initialize Input system
>       Enter main message-dispatching loop
>}
>desktop.cpp
>init_desktop()
>{      Create the screen bitmap
>       Driver load/init loop
>       Get framebuffer area info
>       Call setup_screenmode
>       Create top layer for workspace
>       Set cursor
>       call display driver->MouseOn()
>}
>ddriver.cpp:
>DisplayDriver::DisplayDriver
>{
>       Init cursor data to NULL
>}
>DisplayDriver::MouseOn()
>{      if no current mouse, make one from the image pointer
>}
>DisplayDriver::MouseOff()
>{      delete mouse pointer
>}
>OpenBeOS:
>-------------------
>main()
>{      Create, Init, & Run app_server
>}
>AppServer::AppServer()
>{      Empty & delete Layer BList
>       Empty & delete Bitmap BList
>}
>AppServer::Initialize()
>{
>       Create the AppServer ports
>       Initialize Desktop
>//     Start poller thread
>//     Start picasso thread
>//     Enter main message-dispatching loop
>}
>
>Desktop.cpp
>init_desktop()
>{
>       Instantiate and initialize display driver
>       Create the screen bitmap
>       Get framebuffer area info
>       Call setup_screenmode
>       Create top layer for workspace
>       Set cursor
>       Turn mouse on in display driver
>}
>
>DisplayDriver.cpp:
>DisplayDriver::DisplayDriver
>{
>       set is_initialized to false
>}
>DisplayDriver::Initialize
>{
>       Driver load/init loop
>       Load stub driver if not found
>       set is_initialized to true
>}
>
>The way I have structured the code is that the AppServer is created and 
run, 
>and the code is written so that very few changes to the code are 
necessary to 
>convert it from a BApplication to the regular app that it will be once 
in 
>place.
>
>The Desktop is what I'm not sure of at this point. Right now, it's 
merely a 
>BList and access is by the appropriate C calls. I can't help but wonder 
if 
>having a Desktop class for use within Desktop.cpp would be helpful.
>
>The DisplayDriver class is used mostly to encapsulate the graphics 
driver 
>mess from the rest of the server - it should just care about having a 
frame 
>buffer, stats for the buffer, and doing what it needs with just that. 
For our 
>testing purposes, I have also created a DirectDriver subclass which 
sets up a 
>BWindowScreen for testing use under R5. Instead of doing all the 
>initialization crap (loading drivers, etc), it just creates an instance 
of a 
>custom BWindowScreen and attempts to hide all the related crap in 
dealing 
>with that beast from the rest of the server. What's nice is that we can 
set 
>up that custom class to post messages (when we get to that part, that 
is) 
>just like the Input Server would.
>
>It seems to me that just getting the basic desktop will be our first 
order of 
>business (no small task), as in what you see if you kill everything 
except 
>the Input Server.
>
>A sidenote about something I just discovered - Tracker handles 
wallpapers, so 
>less work for us. :)
>
>--DW

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: