bonobo_get_object_async (take 2)...

[Mark McLoughlin]

Hi Michael,

Hi Mark,
Please find attached trivial patch to gnome-session making the vino
activation (more) truly async & hence not blocking login etc. until it's
started :-) [ should also avoid loading those pesky moniker libraries
too I think ;-] (can I/Rodrigo commit & to the stable branch too ?).

Yep, that looks good.

/* Strip off the screen portion of the display */
p = strrchr (display_name, ':');
if (p)
@@ -59,6 +60,7 @@
if (p)
p [0] = '\0';
}
+#endif
reg_env = bonobo_activation_registration_env_set (reg_env, "DISPLAY", display_name);
result = bonobo_activation_register_active_server (VINO_SERVER_IID,
Briefly - why is that mangling of the DISPLAY variable necessary ? I
must confess that even without it vino fails to launch properly ;-) so
is there some cockup with gnome-session & the way it activates stuff
too ?

We strip off the screen number from the display name so that the object
is registered per-display rather than per-screen. We want a copy of vino
per-display rather than per-screen since vino can handle multiple
screens.

Cheers,
Mark.

[Mark McLoughlin]

Hi Rodrigo,
It's pretty bad form to send completely untested patches ...

- bonobo_get_object_async (moniker, "IDL:Bonobo/Control:1.0", &ev,
- (BonoboMonikerAsyncFn) panel_applet_frame_activated,
- frame_act);
+ bonobo_activation_activate_from_id_async ("IDL:Bonobo/Control:1.0", 0,
+ (BonoboActivationCallback) panel_applet_frame_activated,
+ frame_act, &ev);

Two problems here:

1) bonobo-activation clearly doesn't support activating an interface
name

2) Even if you did pass the OAFIID moniker string instead of the
interface name, it would still break since this is one of the few
places in GNOME that actually does still use the moniker system
for the Bonobo::ItemContainer interface

Cheers,
Mark.

[Rodrigo Moya]

Post by Mark McLoughlin
Hi Rodrigo,
It's pretty bad form to send completely untested patches ...

- bonobo_get_object_async (moniker, "IDL:Bonobo/Control:1.0", &ev,
- (BonoboMonikerAsyncFn) panel_applet_frame_activated,
- frame_act);
+ bonobo_activation_activate_from_id_async ("IDL:Bonobo/Control:1.0", 0,
+ (BonoboActivationCallback) panel_applet_frame_activated,
+ frame_act, &ev);

1) bonobo-activation clearly doesn't support activating an interface
name
2) Even if you did pass the OAFIID moniker string instead of the
interface name, it would still break since this is one of the few
places in GNOME that actually does still use the moniker system
for the Bonobo::ItemContainer interface

right, the patch is totally wrong, sorry.

[Rodrigo Moya]

Post by Mark McLoughlin
Hi Rodrigo,
It's pretty bad form to send completely untested patches ...

it wasn't completely untested, since it was working for me, at least for
some applets. But it was wrong though, so here's a better one. There are
no significant speed improvements, but at least if one applet fails
loading, the panel won't block waiting for it to answer or timeout.

[Vincent Untz]

Hi everyone,

Post by Rodrigo Moya

Post by Mark McLoughlin
Hi Rodrigo,
It's pretty bad form to send completely untested patches ...

it wasn't completely untested, since it was working for me, at least for
some applets. But it was wrong though, so here's a better one. There are
no significant speed improvements, but at least if one applet fails
loading, the panel won't block waiting for it to answer or timeout.

Since I'm easily lost in bonobo-land, I'd very much like to see Mark
review the patch ;-)

Just wondering if it's appropriate for 2.14 now that we're nearing the
RC release... Maybe it's better to wait for 2.15?

Vincent

[Rodrigo Moya]

Post by Vincent Untz
Hi everyone,

Post by Rodrigo Moya

Post by Mark McLoughlin
Hi Rodrigo,
It's pretty bad form to send completely untested patches ...

it wasn't completely untested, since it was working for me, at least for
some applets. But it was wrong though, so here's a better one. There are
no significant speed improvements, but at least if one applet fails
loading, the panel won't block waiting for it to answer or timeout.

Since I'm easily lost in bonobo-land, I'd very much like to see Mark
review the patch ;-)
Just wondering if it's appropriate for 2.14 now that we're nearing the
RC release... Maybe it's better to wait for 2.15?

as you want, but we (Michael, me and all nld10 beta users) have been
using this for some weeks, with no problem at all.

[Mark McLoughlin]

Hi Rodrigo,
This version looks much more plausible.

+ g_warning ("Patent Meeks activation code");

Cheers,
Mark.

[michael meeks]

Hi Mark,

Please find attached trivial patch to gnome-session making the vino
activation (more) truly async & hence not blocking login etc. until it's
started :-) [ should also avoid loading those pesky moniker libraries
too I think ;-] (can I/Rodrigo commit & to the stable branch too ?).

Rodrigo is also looking at the panel which uses the same method (with
commensurate performance problems I'd guess) - hopefully we can get an
easy win there too.

However - the root cause of this (a hang at login) seems related to
VINO: my suggested patch is here:

--- ./server/vino-shell.c
+++ ./server/vino-shell.c
@@ -50,7 +50,8 @@
shell = g_object_new (vino_shell_get_type (), NULL);

display_name = g_strdup (gdk_display_get_name (gdk_display_get_default ()));
-
+
+#if 0
/* Strip off the screen portion of the display */
p = strrchr (display_name, ':');
if (p)
@@ -59,6 +60,7 @@
if (p)
p [0] = '\0';
}
+#endif

reg_env = bonobo_activation_registration_env_set (reg_env, "DISPLAY", display_name);
result = bonobo_activation_register_active_server (VINO_SERVER_IID,

Briefly - why is that mangling of the DISPLAY variable necessary ? I
must confess that even without it vino fails to launch properly ;-) so
is there some cockup with gnome-session & the way it activates stuff
too ?

Curious as to why that sort of thing might be necessary ? perhaps the
vino cvs annotations make that clear ?

HTH,

Michael.

[Rodrigo Moya]

Hi Mark,
Please find attached trivial patch to gnome-session making the vino
activation (more) truly async & hence not blocking login etc. until it's
started :-) [ should also avoid loading those pesky moniker libraries
too I think ;-] (can I/Rodrigo commit & to the stable branch too ?).
Rodrigo is also looking at the panel which uses the same method (with
commensurate performance problems I'd guess) - hopefully we can get an
easy win there too.

yes, attached is panel's patch, which loads really asynchronously all
applets.

Vincent, is this ok to commit? Can we commit also to the 2.12 branch?
(we committed similar fixes to gnome-session for 2.12 also)

[michael meeks]

Post by Mark McLoughlin
We strip off the screen number from the display name so that
the object is registered per-display rather than per-screen. We want
a copy of vino per-display rather than per-screen since vino can
handle multiple screens.

Hmm; interesting. So - I get a hang trying to activate vino
synchronously; I thought that might be related to a mis-matched display;
but it's perhaps some unrelated problem.

Thanks,

Michael.