[interfacekit] Re: Structure of the app_server

good work. I think the desktop part is the tracker itself.  it may set up a
BView/BWindow that is unique or a custom BView.  The way I see it anyway is,
just have a simple application create a bview and a bbitmap to draw and
thats our desktop.  let the server initally switch to the desired resolution
and leave the desktop area to a separate process.  so basically the desktop
is just another app that would run.  I just thought of this so if it doesnt
make sense tell me.

thats all I will add for now, i skimmed through what you wrote.  I have to
get to sleep or I'll fall asleep right now.

-yt
----- Original Message -----
From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
To: <interfacekit@xxxxxxxxxxxxx>
Sent: Thursday, September 27, 2001 2:59 AM
Subject: [interfacekit] Structure of the app_server


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