[openbeos] Re: Application launching and activation...

Hi Ryan,

"Ryan Leavengood" <leavengood@xxxxxxxxx> wrote:
> In BeOS if you try to launch a B_[SINGLE | EXCLUSIVE]_LAUNCH 
> application that is already running and the window is not active, the 
> system will activate it (bring it to the front and/or move to the 
> workspace it is at and make it the focus app.) This works from the 
> DeskBar, Tracker and Terminal. Haiku does not do this. Was this an 
> active decision or is this a bug?

That's a bug or a missing feature :-)

[...]
> Also you may know of the bug on BeOS where BApplication::AppActivated 
> is never called because B_APP_ACTIVATED is never sent to the 
> application, which is what would trigger AppActivated to be called. 

I just tested it over here (Dano!), and it works just fine.

> B_APP_ACTIVATED is only sent to the window on activation. But in fact 
> B_SOME_APP_ACTIVATED is sent to the application, but this message is 
> not set up to call the AppActivated hook function (though that is 
> fairly easy to overcome.) So my question is do we want to mimic this 
> buggy behavior of BeOS or actually follow the documentation? Does 
> anyone have any idea how many applications may have been programmed 
> around this bug or might depend on it?

B_SOME_APP_ACTIVATED is only to be used when monitoring applications. 
It's not supposed to be sent to all apps, and I don't think we should 
do this.

> Looking at our Registrar code, it is correct, but we need to add the 
> link between the app_server and registrar for the activation. Right 
> now 
> it seems only the app_server is involved, so the activation code in 
> the 
> Registrar goes unused. In fact we need a two-way link so that I can 
> fix 
> the above Launch bug (activate the app window on launch if it is 
> already running.)

It doesn't have to be this way. What should happen is this:
* BApplication tries to register itself - it sees there already is an 
instance of it, so it will a) activate this one, and b) quit.

In fact, I just tested this, and all the BApplication does (in Dano) is 
to send a B_SILENT_RELAUNCH message. If you intercept this message in 
MessageReceived(), your application is never activated - the default 
handler obviously just calls BRoster::ActivateApp() on itself. Since we 
also define B_SILENT_RELAUNCH in our headers, I would guess R5 already 
does it, too.
Indeed, it's even documented this way:
file:///boot/beos/documentation/Be Book/Messages/GeneralMessages.html

Since the window already gets activation messages, it would be pretty 
easy to let it update the activation in the registrar (which could then 
send back the B_APP_ACTIVATED messages).

Bye,
   Axel.

Other related posts: