Re: Possible libosso bug?
Eero Tamminen wrote: > The messages are answered by the co. processes, not D-BUS itself. > If the message is sent with auto-activation flag, the co. process > is started. Otherwise the message is lost (I think). If you pass something as retval, you will get error code and something like "No such service" in the retval "s"-field. > I think all these libosso functions use the D-BUS auto-activation flag. True for osso_* -- muali -functions seem not to. > I would say that it's a bug in the Browser. I agree. > You might also use the co. D-BUS message directly _without_ > auto-activation. That should do it (or you could ask dbus if the service is running or not). OTOH telling the browser to exit is not nice, the user might be using it for something else too. -- Santtu Lakkala ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Possible libosso bug?
Hi, ext David Hazel wrote: > I encountered the following unexpected behaviour while testing my > application, and I wanted to run it past the people on this list to see > if this is a known "feature". > > My application opens the browser as part of its normal operation. On > application exit, the browser is closed. The call used to do this is: > > osso_rpc_run_with_defaults(mvarAppCtx, "osso_browser", > OSSO_BROWSER_EXIT, NULL, DBUS_TYPE_INVALID); > > Now, if the browser is open when this call runs, it closes down exactly > as expected. However, if it has already been closed by the user, the > above call OPENS it! > > Given that the call is telling the browser to exit, I would expect one > of two things to happen if the browser is not open: > > 1) The call is ignored, because it is asking for a browser state that > already exists The messages are answered by the co. processes, not D-BUS itself. If the message is sent with auto-activation flag, the co. process is started. Otherwise the message is lost (I think). I think all these libosso functions use the D-BUS auto-activation flag. > 2) The call fires up the browser and immediately closes it (because the > OSSO_BROWSER_EXIT request has to be dealt with by the browser itself). > > Instead, what actually happens is that the browser opens and stays open > (on its default home page). > > Is this a known "feature" of libosso or the Browser? If not, should I > report it as a bug? I would say that it's a bug in the Browser. You might also use the co. D-BUS message directly _without_ auto-activation. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Possible libosso bug?
I encountered the following unexpected behaviour while testing my application, and I wanted to run it past the people on this list to see if this is a known "feature". My application opens the browser as part of its normal operation. On application exit, the browser is closed. The call used to do this is: osso_rpc_run_with_defaults(mvarAppCtx, "osso_browser", OSSO_BROWSER_EXIT, NULL, DBUS_TYPE_INVALID); Now, if the browser is open when this call runs, it closes down exactly as expected. However, if it has already been closed by the user, the above call OPENS it! Given that the call is telling the browser to exit, I would expect one of two things to happen if the browser is not open: 1) The call is ignored, because it is asking for a browser state that already exists 2) The call fires up the browser and immediately closes it (because the OSSO_BROWSER_EXIT request has to be dealt with by the browser itself). Instead, what actually happens is that the browser opens and stays open (on its default home page). Is this a known "feature" of libosso or the Browser? If not, should I report it as a bug? David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers