Hello,

I'm an applicant for GSoC 2010. I got inspired by the "menu search" idea and proposed the "user friendly plug-in browser" that would allow users to find the plug-in they want by seeing the effect on an example image. The whole thing is to browse through images rather than through text. The reason is that the names of plug-ins say nothing to many of the users (including me) and they hesitate to try them. But by seeing the effect of the plug-in they will be more willing to use it.

Could you please give me some feedback on my proposal? I would like to know if this idea is feasible. Are there any aspects I didn't think of?

Thanks,
Avgoustinos Kadis

Proposal: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/avgoustinos/t127081249399

I understand (about the good architecture). It should be designed carefully to support all the sources (I was aware only of the plug-ins). Does this object model you use for C allows inheritance?

About the preview calculations. I was thinking that it might be faster to pre-calculate all the plug-ins/core/GEGL on 2-3 fixed sample images [300x300] (ex. an apple, a person, a building and a sunset) and store them on the user's machine. Each time he opens this feature browser, if there is a new feature without a sample image, it'll be calculating it and storing it on hard disk. It should still happen in a separate thread of course but I think it would speed up things.

What do you think about it?

Avgoustinos

On Sat, Apr 10, 2010 at 11:00 AM, Martin Nordholts wrote:

On 04/10/2010 11:26 AM, Avgoustinos Kadis wrote:

Hello,

I'm an applicant for GSoC 2010. I got inspired by the "menu search" idea and proposed the "user friendly plug-in browser" that would allow users to find the plug-in they want by seeing the effect on an example image. The whole thing is to browse through images rather than through text. The reason is that the names of plug-ins say nothing to many of the users (including me) and they hesitate to try them. But by seeing the effect of the plug-in they will be more willing to use it.

Could you please give me some feedback on my proposal? I would like to know if this idea is feasible. Are there any aspects I didn't think of?

The idea makes complete sense and has been discussed every now and then. There are a couple of requirements that a design would have to fulfil:

* The preview calculations needs to support different sources, most notably GIMP legacy core, plug-ins, and GEGL, so a good architecture is necessary

* Preview calculations needs to be done in a lazy on-demand manner to make the UI responsive. That is, preview calculations needs to happen outside of the UI thread so one can browse around freely without being forced to wait for previews to finish rendering

 / Martin

--

My GIMP Blog: http://www.chromecode.com/
"GIMP 2.8 development still under control"

If using the current image will be better (more desired by the user) then we could focus on this one and find ways (multiple threads, resize before applying the plugin etc) to make it fast. It sounds more challenging this way :)
Great!
Thanks,
Avgoustinos

On Sat, Apr 10, 2010 at 1:55 PM, Martin Nordholts wrote:

On 04/10/2010 01:03 PM, Avgoustinos Kadis wrote:

I understand (about the good architecture). It should be designed carefully to support all the sources (I was aware only of the plug-ins). Does this object model you use for C allows inheritance?

GIMP uses GObject which supports inheritance.

About the preview calculations. I was thinking that it might be faster to pre-calculate all the plug-ins/core/GEGL on 2-3 fixed sample images [300x300] (ex. an apple, a person, a building and a sunset) and store them on the user's machine. Each time he opens this feature browser, if there is a new feature without a sample image, it'll be calculating it and storing it on hard disk. It should still happen in a separate thread of course but I think it would speed up things.

Always using the same images is the easy way, using it on the current image is the harder but better way. If you go for the easy way I think you should plan for introducing the hard way later, just to make sure that the solution scales.

 / Martin

--

My GIMP Blog: http://www.chromecode.com/
"GIMP 2.8 development still under control"

Thanks Sven, very important to know that! How feasible are these options?

1. Randomly pick a value for each parameter. From what you said (that it depends a lot on the parameters) this wont give us the best results but at least we will have a preview.

2. Modify PDB so it can store default parameters and enter their values in the plug-ins (maintained in one place only)?

Avgoustinos

On Sat, Apr 10, 2010 at 8:23 PM, Sven Neumann wrote:

On Sat, 2010-04-10 at 10:26 +0100, Avgoustinos Kadis wrote:

I'm an applicant for GSoC 2010. I got inspired by the "menu search" idea and proposed the "user friendly plug-in browser" that would allow users to find the plug-in they want by seeing the effect on an example image. The whole thing is to browse through images rather than through text. The reason is that the names of plug-ins say nothing to many of the users (including me) and they hesitate to try them. But by seeing the effect of the plug-in they will be more willing to use it.

Could you please give me some feedback on my proposal? I would like to know if this idea is feasible. Are there any aspects I didn't think of?

I think the idea is nice, but very hard, if not impossible, to implement. All plug-ins have a number of parameters and the output depends a lot on the values chosen for these parameters. That makes it very hard to automatically create reasonable previews of all filters. Also the PDB currently does not support default parameters, so there is no way to automatically select reasonable default values for plug-ins. The "user friendly plug-in browser" would have to have a hard-coded data-base of parameters. That would be a pain to maintain.

IMO it makes much more sense to concentrate on selecting plug-ins based on a search in their names, descriptions and help texts.

Sven