Hi, Here are my two cents on this matter.
I see plug-in infrastructure as a wellcomed feature, but in my humble opinion, it should be implemented only after the last crucial features are included first. What are these crucial features? For me they are (as I have advertized already before): 1) Ability to rename the photos. If you do it in another program you will lose the RS settings for that photo. Without this feature, RS can not be used for continuous photo editing of large amounts of photos. At least not in my work flow method :-) 2) Thumbnail cache, i.e. updating thumbnails. Without this feature (+ renaming the photos), finding a photo takes tooo looong. 3) Sensibility of the Hue-slider is too high. It should be progressive. Usually you need to use only few units of most of it, but the slider is for -180 to +180 units. Small adjustments is difficult to be made. 4) A "hand" that you can use to drag the photo around. It would be much faster to use than to scroll the photo with sliders. It is frustrating of how often I accidentally click on the image and hence accidentally set the white balance and loose all my previous white balance settings. Previously we discussed that ctrl + click would be better. 5) Jpg quality in saving should be able to be changed. And of these 5 suggestions I see the first two as the top of top issues :-) II have not enough programming experience to participate in the coding of the RS core. However, I believe I could manage to write some plugins that I really need. I actually already have some thought of what kind of a plugin I would write... Therefore I see plugins as a wellcomed idea but it should not prevent the last lacking main features from not being developed as the writing of plugin-architecture would probably take quite some time. With best regards, Olli 2008/9/21 Anders Brander <[EMAIL PROTECTED]> > Hi everyone, > > I have been thinking a lot about plugins lately - well, actually for the > last two years or so. I think we need plugins. > > I see the following reasons for a (simple) plugin-infrastructure in > Rawstudio: > 1. We keep getting requests for exotic and specific ideas that > doesn't belong in the Rawstudio core, but many are very > valid feature requests. > 2. We need to do something to limit interdependencies inside > Rawstudio. We're not far from spaghetti-code. > 3. 3rd party developers could contribute easier. > 4. We need an easy path from idea to implementation, as of now > it's a long and hard walk to implement even a simple filter. > > 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. > > 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 think a roadmap could be something like: > - Move as much as possible of Rawstudio into librawstudio. > - Implement some sort of plugin manager. > - Move basic features from Rawstudio into seperate in-tree plugins. > - Party with beer! > > I would really like some feedback on this. > - Is this totally insane? > - What do packagers and distributions have to say about this? > - What is the best way to implement this GModule? dlopen()? > - Is this even needed? > > /abrander > > > > _______________________________________________ > Rawstudio-dev mailing list > [email protected] > http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev >
_______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
