Introducing The Desktop
Since it would probably be boring if I just wrote which bugs I fixed in the app_server today, or which function I renamed to make it easier on the eyes, I think I can better use this forum to introduce some app_server concepts, in varying detail, and in small steps.
The first concept I will introduce you to is the Desktop. Not the Desktop you see as part of your daily (?) computer experience, but the Desktop as the app_server manages it. Every user logged into your system will get a different Desktop object. Every user? Well, for now, this is just you - but the app_server can manage as many desktops as needed. If you notice this for R1 remains yet to be seen, but the chances for this are not too bad.
Anyway, every desktop has certain input devices, and output devices assigned. It will also manage all applications of its user, and the workspaces configurations the user has defined. The desktop also knows all screens visible on screen and their order. If a desktop object is deleted, it will also quit all applications the user had running, and that will also close all windows those applications had opened before.
Your physical screen(s) as well as all the mice and keyboards connected to your computer will typically be owned by the desktop object. Of course, if you happen to have two of everything, these resources could also be shared between concurrently logged in users. The input or output devices may also be connected via the network, even though it's not very likely that this will be supported in R1.
Right now, when a BApplication is created, the application will first ask the app_server for a desktop object, and when the application got this object, it will then have the desktop create the server part of the BApplication, which is currently called ServerApp. That's usually about all an application will talk to the desktop - even if it's the main actor, it will also stay in the background, and delegate most features to other classes.
A desktop object is only created, if an application asks for it - and that will be the moment when you'll need to authorize yourself to be able to open anything on screen. Right now, the app_server doesn't care about passwords, though. The desktop object is the app_server's key to multi-user support - even if it is currently not really used that way, it lays the foundation for R2 and beyond.
4 Comments:
Very please that you also tought about this kind of explaination. A real real good idea and a great pleasent read to me !!
Thanks a lot !
Good to know also that multiuser is already kind of implemented, even if it will not be used in R1.
The input or output devices may also be connected via the network
Axel,
Can I clarify - are the video and sound output devices connected via a network supported? I.e. the sound/video card output on a network machine is re-directed to the sound/video card on my local machine?
Thanks,
Andrew McCall(Dr3w)
Hi Axel,
thanks for the explanations, I also like that you'll write about the app server, I'm waiting for the rest parts.
Could you also write about the whole progress of Haiku? I.e. what has to be done to run an mp3 player app which plays mp3s from a FAT32 partition?
Adam
To Andrew: Right now, networking in the app_server is not yet implemented at all, and even possibly might not for R1. So don't take the remote desktop capability for granted already :-)
Sound is also not handled by the app_server - that would need to be solved differently and with media_server support.
To xiphy: I can do something like this from time to time. Jérôme has already managed to play an mp3 from Haiku, BTW.
Post a Comment
<< Home