On Wed, Sep 24, 2008 at 06:51:06PM +0200, Anders Brander wrote:
> On Wed, 2008-09-24 at 12:18 +0200, Einar Ryeng wrote:
> > Considering the rather broken state of many third-party plugins (in any
> > program), I think some measures should be taken to shield rawstudio from
> > the plugins in any way possible. Specifically, I suggest placing at
> > least the main operation of plugins in separate processes, so that an
> > error in the plugin will not bring rawstudio down. Of course it doesn't
> > matter that much whether the fork/exec loads an .so file or executes a
> > program directly. It may well be that you've already thought this
> > through, I'm just commenting on it because you talk about .so files.
>
> I haven't thought about this at all. Btu I think we should look into how
> hard it would be to do plugins in a seperate process.
> Maybe a process for GUI and main application and a process for ALL
> plugins..?
That should be easy enough, I guess. But processes are cheap in posix,
so I don't see any need to reuse them. I guess we'd first need to decide
how we'd like the user to interact with the plugins. After all, process
juggling isn't that hard to do as long as the GUI can be kept
single-threaded.
> > > I would really like some feedback on this.
> > > - What is the best way to implement this GModule? dlopen()?
> > CORBA? (Directly or using bonobo.) At least, that would shield rawstudio
> > from bad plugins, and would also add network transparency. And the idl
> > file would be a good description of the plugin interface.
>
> Isn't CORBA/bonobo sort of dead?
Well, I haven't followed it closely but I also have the feeling that
bonobo is dying. I cannot imagine CORBA going the same way yet, though.
It's rather "enterprisy" and will probably stick around for quite some
years. Actually, and I'm not even sure what its real contenders are.
Java RMI and DCOM of course, but is there anything else?
But that was just an idea anyway. As long as network transparency is not
a requirement, shared memory (without any ORBish mechanism) is probably
easier. I just tend like clean interface separations when there is
actually a real possibility to have them ;)
By the way; What does Gnome use these days? Surely, object integration
of some kind is still required.
> > What sort of GUI operations do you want to expose to plugins?
>
> I'm not sure I understand this?
I just mean that as a bare minimum you'd need a menu item for each
plugin. And for things that require user input, like the level of noise
reduction, there must be some way to open the dialog box (or whatever
GUI component) to set the values. Plus some way to open it again to
change the value later on. So basically I was just wondering how
"integrated" you'd want the plugins to be in rawstudio per se.
The easiest way is to let each plugin make dialogs for whatever it wants
to do. I guess that is the best way to do it for import/export plugins.
For filters I get a feeling that the best way to incorporate them into
the GUI would be to give each plugin an expander in the tools list. That
way, they actually behave like an integrated part of the program and you
just get a "Noise reuction" expander with a "level" slider beneath the
sharpening tool. This must be done in the same process that runs the
GUI, so the .so file approach would likely be the way of least
resistance.
Ok, I can sum up approximately what I currently feel might be a good
idea. Take it with appropriately large doses of salt, I've not seen the
source code. (I'm particularly focusing on the filtering plugins here
because the import/export is more straightforward.)
- An .so file per plugin, loaded with dlopen(3), where some functions
must be defined:
- initialize_tool_gui() -- Loads the GUI to use in the tools sidebar.
- get_settings() -- To extract the parameters the plugin needs, for
saving or just temporary storage while the user opens another
image.
- set_settings()
- run_filter(*picture, *settings)
- All of these functions, except run_filter is applied in the main
thread. I assume that the same GUI elements are reused when the user
selects a different pictures, so that we'd need to get and set the
parameters of the plugin whenever the user clicks a new image.
- When a plugin must do something, either from a single export or as
part of a batch job, a new process is forked off to start run_filter
on an image. The new process is given access to a shared memory area
where an image is kept, and modifies the image in place. The settings
that should be used are passed as an argument with each invocation so
that the plugin does not need to keep any state by itself.
- When the settings are written to file, a plugin section is added to
the file and each plugin gets its state stored and loaded by the main
program so that the plugin is kept as simple as possible.
Just my $0.02
--
Einar Ryeng
_______________________________________________
Rawstudio-dev mailing list
[email protected]
http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
