[interfacekit] Re: Structure of the app_server

I have also been very busy the past week -- my miniscule team at work is
under intense deadline pressure to ship *on* 10/22.  Even a day later,
and it will be *bad* for us. =(  I have, however, been jotting down
ideas here and there when I can -- I've been mulling over the structure
of the font cache most recently.  I'll have to take some time later
today to review what you've got below -- looks pretty extensive! =)

e

DarkWyrm wrote:
> 
> 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

Other related posts: