[openbeos] Re: Application launching and activation...
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 22 Nov 2006 12:01:12 +0100 (MET)
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:
