Re: [Ekiga-devel-list] [RFC] Plugins/Order of initialization in Ekiga

Jan Schampera a écrit :

as discussed before on IRC, Ekiga's current initialization procedure is
either in the wrong logic, wrong order or too inflexible to introduce
the new plugin system:

+---- PProcess::PreInitialise ()
+---- g_thread_init ()
+---- gdk_threads_init ()
+---- gm_conf_init ()
+---- [Gettext init]
+---- gnome_program_init ()
+---- [IF BONOBO] bonobo_component_init ()
+---- PTrace::Initialise ()
+---- GnomeMeeting::Process ()->BuildGUI ()
  +---- gnomemeeting_addressbook_init ()
  +---- gnomemeeting_stock_icons_init ()
  +---- [Create the windows]
  +---- [IF DBUS] gnomemeeting_dbus_component_new ();
  +---- gm_statusicon_new ()
+---- GnomeMeeting::Process ()->DetectInterfaces ()
+---- GnomeMeeting::Process ()->Init ()
+---- GnomeMeeting::Process ()->DetectCodecs ()
+---- gnomemeeting_conf_init ()
+---- [UI init]
+---- gtk_main ()

Where to hook plugin initialization?

IMHO it needs
- a working gmconf
- MAYBE a pre-initialized but not built UI
to make all other components available as plugins/with plugin addons.

In the current (above) order my first hook would be right after the
PTrace initializer.

There are basically two things in my base code :
- a GmService object, which must probably be available through a process-wide getter ; - a GmPluginManager, which needs the GmService object when initialized but nothing more at this point.

The problem is when we ask the GmPluginManager to load plugins, because *they* can need more.

For example, at least one of the existing plugins needs gmconf.

Future examples will probably be the gstreamer audio&video plugins (and perhaps a gstreamer codecs plugin). Which means that devices and codecs detections should happen *after* plugin load!

Notice too that in the future, I expect the dbus component to be loaded as plugin ; probably bonobo should be too, if it's possible...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]