[haiku-commits] Re: r41215 - haiku/trunk/src/add-ons/input_server/devices/keyboard
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: "haiku-commits@xxxxxxxxxxxxx" <haiku-commits@xxxxxxxxxxxxx>
- Date: Mon, 11 Apr 2011 18:23:48 +0200
Stephan Assmus <superstippi@xxxxxx> wrote:
> Hi,
>
> Am 11.04.2011 17:22, schrieb jonas@xxxxxxxxxxx:
> > + case TM_QUIT_APPLICATION:
> > + {
> > + TeamListItem* item =
> > dynamic_cast<TeamListItem*>(fListView->ItemAt(
> > + fListView->CurrentSelection()));
> > + if (item != NULL) {
> > + BMessenger
> > messenger(item->AppSignature()->String(),
> > + item->GetInfo()->team);
> > + messenger.SendMessage(B_QUIT_REQUESTED);
> > + UpdateList();
> > + }
> > + break;
> > + }
>
> The button is useful, but I wonder about the UpdateList() invokation.
> Does the list principally update live to the running applications or
> does it have to be invoked manually?
UpdateList() is run by way of a BMessageRunner on a 1 second interval
while
the Team Monitor is showing. (I'd like to shorten it to half a second.)
(The kill function whose code I mostly copy-pasted, appears to be
synchronous, so the call is meaningful there.)
> The SendMessage() call is
> asynchronous, so the application will likely not have finished the
> request when UpdateList() runs and so this code seems either fragile
> or
> unnecessary (when BRoster events are used anyway).
True. Calling UpdateList() from there is just wasting cycles.
> At the same time, it
> would be cool to send the message with a reply+timeout, and tell the
> user if the timeout has ellapsed, indicating that the application
> hangs
> (and suggesting to kill instead). What do you think?
Sounds nice. I'll see what I can come up with.
/Jonas
Other related posts:
