[interfacekit] Re: about BRoster

"Adi Oanca" <e2joseph@xxxxxxxxxx> wrote:
> [ The original message that I've sent you might not be delivered, so, 
> to be
> sure... here is a second one :) ]

Both arrived. :-)

I CC this mail to the IK team list, since it might be of interests for 
others, in particular DarkWyrm.

> Hello Ingo!
> 
> I have a method:
>     BWindow::handle=5Factivate(...);
> that takes care of window activation when an activation message is 
> sent from
> app=5Fserver.
> 
> In disassembly code, a call to:
>     BRoster::UpdateActiveApp( team=5Fid team ) const;
> 
> What can you tell me about this method, and better! what can you tell 
> me
> about window activation=3F
> 
> What can you tell me about "the connection" between BRoster and 
> BWindow=3F

Most of it you already discovered by yourself. The registrar manages 
the roster of running application. It also keeps track of which 
application is the active one. When the user activates a window of 
another application, the app server notifies the windows -- both the 
one going to be deactivated and the one to be activated -- and the 
activated window notifies the registrar to update its active 
application. The registrar sends a B=5FAPP=5FACTIVATED message to the 
concerned application (the R5 implementation is buggy in this respect) 
and B=5FSOME=5FAPP=5FACTIVATED messages to all other applications.

As you found out, the window notifies the registrar via 
BRoster::UpdateActiveApp(). The method is not implemented yet, since 
the exact working of the activation was not laid out at the time the 
registrar was implemented. Also, BRoster::ActivateApp() has an 
implementation, but it needs some reworking. I brought the issue up on 
the list a while ago, but a decision were not made:
  http://www.freelists.org/archives/interfacekit/07-2002/msg00048.html
  http://www.freelists.org/archives/interfacekit/07-2002/msg00049.html

Unlike then, now I have a clear picture how things could work. First of 
all, the registrar has little to do with window and app activation; it 
knows, which application is currently active and sends the notification 
messages, but the one in charge of everything related is the app 
server. The passing of information works in every case as described 
above: The (user or programatical) action is first realized in the app 
server, which notifies the concerned windows, which in turn notify the 
registrar.

BRoster::UpdateActiveApp() simply tells the roster, that the supplied 
team is now active. Registrar side, this operation is a no-op, if the 
team was already marked active. So, BWindow::handle=5Factivate() calls it 
always, when the window is activated; it doesn't need to care, whether 
the app was already active. The return value of the method can either 
tell whether the operation was successful, or whether the app indeed 
has been activated, i.e. was not active before. We can define it as 
needed.

BRoster::ActivateApp() is currently implemented as 
BRoster::UpdateActiveApp() should be. This has to be changed. Instead 
it has to directly ask the app server to activate the application. The 
app server can deny the request, if the app doesn't exist or has no 
appropriate window.

I will move the code from BRoster::ActivateApp() to 
BRoster::UpdateActiveApp(). Then feel free to implement the former one.

CU, Ingo

Other related posts: