[haiku-appserver] Re: BScreen support

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 05 May 2005 14:34:35 +0300

Stefano Ceccherini wrote:
>>      Things are simple enough here too...
>>      If the display_mode differs send a message to >RootLayer thread and let 
>> him do that
>>change for you. In any case RootLayer will have (you can >implement that if 
>>you want :-) ) to
>>follow the exact steps when changing workspaces with >different resolutions.
> Ok, I am just a little confused because, intuitively, changing resolutions 
> and messing with
> workspaces is a thing which the "Desktop" class should do,

        Yet you can/will have multiple RootLayers running at the same time, 
each one having
its monitor set - your wife can be on the same PC if you have 2 monitors, 2 
mices and 2 keyboards
- a user can login remotely on the same machine and have its RootLayer 
        RootLayer class is the one you're looking for, Desktop if for single 
instance things
(every window has a unique entry, same for every application, cursors should be 
here too).

> but I am not yet so familiar with the code, maybe I just have prejudices (or 
> however it's spelt).

        :-) You're entitled. Once you get to know the design you'll find that 
it's quite
nice - it can be nicer if better ideas hold.

>>      The mode you chose with you latest checkin is not >nice. 
> Actually the last checkin just fixed the crashing bug, the code is not meant 
> to be definitive at all.

        Ah, ok. :-) Just want it to be right.

>>Plus, you have to clear all
>>visible regions of Layers present in the current(old+new >workspace if 
>>changing wks) workspace
>>and finally issue a invalidate request for the whole screen. 
> Shouldn't there be a RootLayer method to do that ?

        The method for changing resolution should look like this:
// RootLayer Frame will be set to the new resolution
RootLayer::change_res(int16 height, int16 width)
        fFrame.right = width-1;
        fFrame.bottom = height-1;
                Frame/Bounds()_it's_the_same); // it's OK for the moment

then it should be called from a case from inside WorkingThread() method.

> At least, I would do it in there, as RootLayer is the class which messes with 
> layer et all
 > (you said that). Oh, but we can't call any RootLayer method from any other 
 > class, as we can't
 > lock it (see the problem ?).

        Yes. Let's try this: if you want to get something and you need to lock 
RootLayer's thread,
then lock, get your data and unlock. But if you want to set something, (a 
service is missing)
then you should add that service where its place is and send a message for it 
to crouch.

> Okay, we send a message to rootlayer, but then I wonder why
 > RootLayer has so many public methods, as we can't call them.

        Hm... don't know what gave you that idea.
        You can call a lot of public methods without locking. If you have a 
closer look, you will
see a lot of them simply send messages to RootLayer's thread.
        You can safely use lots of public methods, and in the near future all 
of them - some I just
forgot to make private (like SetWorkspaceCount(), SetActiveWorkspace(), 
        [ some methods like ResizeBy() should be removed, others like 
SetScreenResolution() need to
be implemented (for example you could use this method to ensemble a message and 
send it to RL's
thread) ]


Other related posts: