"Brian J. Tarricone" <[email protected]> wrote: > If Foo-app looks for its plugins in $XDG_PLUGIN_DIRS/foo-app, and > Bar-app looks for its plugins in $XDG_PLUGIN_DIRS/bar-app, then there > can never be any conflict, even if both of them are set up as bundles > and one launches the other with their "private" bundle path in > XDG_PLUGIN_DIRS.
Okay, that solves the issue. I thought the application would search its plugins in "$XDG_PLUGIN_DIRS/" which would have made all plugins of all applications stored in the same directory. > No, it doesn't have everything it needs. It may have all the > *information* it needs, but it doesn't know to do anything with it > without extra work. Even if that extra work is minimal, you still have > to convince the app author that doing that work is worthwhile. Since most current applications do use absolute paths, if you don't want to touch application's souce code, then, you've to run them in a chroot'ed environment. There's no other way. What's different with XDG_PLUGIN_DIRS! You've to convince the author to compute the path from this env var! How is that easier than doing it from argv[0] ? Moreover, from your first post I assumed you expected applications to use argv[0] to find their own data files. So, why treating data and plugin files differently? Ok, now I see a compelling reason: XDG_PLUGIN_DIRS would be to let people use plugins not bundled with the application in addition to plugins bundled with the application, the former being kept in a /usr/share/plugins/appname directory. In short, the following approach seems good. 1) Bundled applications would be directories containing a standard file system hierarchy with ./usr/lib ./usr/bin, ./usr/share, etc. 2) When launched without path prefix, the application would assume the "base directory" is /, otherwise it would be the directory prefix with the final usr/bin truncated. To make that easy, a simple library providing a getBaseDirectory() function would be created. 3) When loading a data file, it would use this base directory as prefix. 4) When loading a plugin, the application would use a getPluginDirectories() enumerator function and its app-name suffix. I see two possible implementations to this function: 1. Simply list XDG_PLUGIN_DIRS directories, requiring desktop environment to add the base directory to this plugin dir when launching the bundled application. 2. Or, list XDG_PLUGIN_DIRS directories plus getBaseDirectory()/usr/plugins. I think the later is better, as both implementations have the same application interface, but the former has a more complex interface to the desktop. This simple command: cp -r /path/to/bundle/* / Would install the bundle application. Launching the application, bundled or unbundled would be as simple as giving its full path on the command line. When installed, you could also type its name without prefix. e.g. /path/to/bundle/usr/bin/nice_app /usr/bin/nice_app (if it has been copied to /) nice_app (if it has been copied to /) Would all launch the application correctly! To make bundle applications nicer, as you suggested, a desktop file should be provided. Where? Maybe in ./usr/share/applications/nice_app_name.desktop But that would prevent the application to have more than one desktop file... Or maybe simply ./app.desktop as you suggested, but that would make installing the bundle a bit more complex than cp -r. There may be some better way. -- André Gillibert. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
