On Mon, 11 Sep 2006 07:42:49 +0200
Julien PUYDT [EMAIL PROTECTED] wrote:
..deleted
Here is what the current code does:
a) If PWLIBPLUGINDIR is set, set the plugin search path to this value
and go to step d)
b) Get the directory containing the executable and put that into the
plugin search path
This is bad on non-win32.
It's both good and not good.
It's very useful for deployment - it means that you can have a single
directory with the application and all of the plugins with no extra work
required.
It's bad because sometimes the local directory contains other stuff
including lots of subdirectories.
While writing this, I'm thinking that perhaps searching the local
directory without recursion might be a good idea.
I'm not sure there is a single good answer here.
c) Append the value of P_DEFAULT_PLUGIN_DIR to the search path
This appending looks wrong.
What part looks wrong?
d) Assume the plugin search path is a list of directories and search
each directory recursively.
The differences between Unix and Windows are:
- The seperator between path elements is : on Unix and ; on Windows
DIR_SEP is nice to handle that.
Not sure what you mean here.
DIR_SEP (as a macro) is defined and used in pluginmgr.cxx
- The default value for P_DEFAULT_PLUGIN_DIR is C:\PWLIB_PLUGINS on
Windows and .:/usr/lib/pwlib: on Unix
The easiest way to search a user-specific search path for plugins is to
ask the user to set the PWLIBPLUGINDIR variable to $(HOME)/pwlib_plugins.
However, I guess we can add parsing to this code so that we can specify
~/pwlib_plugins or some such, where ~ corresponds to the users home
directory.
The easiest for us. Most users are unable to set an environment
variable. And remember that on unix, setting PWLIBPLUGINDIR in a shell,
makes it available only in that shell!
We should check if freedesktop.org has a specification for such things
(it has one for configuration options), as it's probably the sanest
thing to use on unix-like systems.
I'm open to implementing a standard if it makes sense and the code is
not too difficult.
I agree that removing . from the default plugin path for Unix is
probably a good idea as users often run programs in a directories that
have large sub-trees. It was removed from the Windows default value for
that very reason.
Then I would say : let's remove it from cvs right now, as a quick fix to
the issue, while we get to think about a sane replacement for that scheme.
The plugin search code has been used for the last year or so for all
plugins (including the audio and video devices) on both OPAL and
OpenH323. I'm not sure why this has suddenly become an issue that needs
an immediate patch
I'd like to know what has changed before I start modifying existing code
to fix problems
You mentioned writing new code for plugin searching (which seemed to
have something to do with the H.263 plugin) ; could you be more specific?
The H.263 plugin codec is a straight port of the old embedded H.263
codec. This code loaded the file libavcodec.so at runtime to get access
to the ffmpeg functions. The plugin does the same thing, because I
didn't want want to embed the ffmpeg code into the plugin.
When the codec was part of OPAL, it used the same plugin loader code as
PWLib and so it searched the same path. Now that the plugin is seperate
code, it needs to implement the same search mechanism internally.
Craig
---
Craig Southeren Post Increment VoIP Consulting and Software
[EMAIL PROTECTED] www.postincrement.com.au
Phone: +61 243654666 ICQ: #86852844
Fax:+61 243656905 MSN: [EMAIL PROTECTED]
Mobile: +61 417231046 Jabber: [EMAIL PROTECTED]
It takes a man to suffer ignorance and smile.
Be yourself, no matter what they say. Sting
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
