Hi! On Wed, 2008-09-24 at 12:18 +0200, Einar Ryeng wrote: > Since I've never submitted a single line of code to rawstudio, I'm > getting a feeling of discussing the colour of the bikeshed here, but > what the heck, here are my thoughts on the subject.
You're welcome - code submitted or not. > On Sun, Sep 21, 2008 at 06:41:57PM +0200, Anders Brander wrote: > > I have formulated three requirements for plugins: > > A. Plugins should be buildable outside the Rawstudio tree. > > B. Plugins should be loadable at runtime. > > C. Plugins should consist of a single .so-file as far as > > Rawstudio knows. > > 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..? > > I see at least four types of plugins: INPUT plugins: Raw-loader, > > jpeg-loader, live-capture, ... FILTER plugins: > > Exposure/saturation/etc, sharpen, ... OUTPUT plugins: Savers, > > previewers, printing, ... TOOL plugins: Geo-tagging, red-eye-removal, > > special effects, ... > I like the way the .rawstudio/ folders let me reproduce pictures and > look at the settings that were used for a specific image. There must be > some way for plugins to store information there so that noise filtering > or whatever the plugin does can also be repeated the next time you open > the program to export the same image. Ohh, True! > > 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? > What sort of GUI operations do you want to expose to plugins? I'm not sure I understand this? > > - Is this even needed? > In the long run it may be needed, so I guess this is the time to start > thinking about it. No need to rush it, though. No need to rush it, but I think we must address this soon if we want to keep evolving Rawstudio. /abrander _______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
