Re: [Gimp-developer] Google Summer of Code 2014

[Alexandre Prokoudine <alexandre prokoudine gmail com>]

On Tue, Jan 28, 2014 at 12:44 AM, scl wrote:

> 1) Do we want to participate this year, again?

Yes.

> 2) If yes, which programming tasks do we want to offer?
>
> In my opinion, we should stick with the GEGL/OpenCL ports and
> integration of the results of former GSoC projects.

Yes for the former, no for the latter. Hiring a new student to
complete the work of another one would be a horrible PR move. It means
we failed to do our job in the first place.

> Yes, it might sound boring, but on the other hand the GEGL
> and OpenCL ports have been our high priority for many years
> and there's still something to do, see the [GEGL Porting Matrix].

Both GEGL ports _and_ speeding up GEGL has to be done, but I'm not
sure if the latter is GSoC material.

We also have tons of usability issues, such as:

- with the existing Text tool implementation, you can't select font in
the on-canvas toolbar and start typing with it;
- with transformation tools, the layer you are transforming blocks the
view of layers beneath it, so you end up guessing what you are
actually doing;
- when you change brush size/rotation with a slider using a Wacom pen
or a mouse pointer, you can't preview the changes;
- the whole floating selection thing.

A project that would focus on fixing usability issues could make a
nice GSoC project. It would mean a lot for the community, especially
for the most vocal part of it :) Of course, it only makes sense, if
Peter can/wants to join us for the summer.

Building and prioritizing a list of  most notorious usability issues
that could be fixed as part of a GSoC project is perfectly doable.

Personally, I think that GIMP GAP is in need of help. Animation is a
rather popular topic among GIMP users, but GAP's UI  scares the living
daylight out of people (me included) and being implemented as a set of
plugins doesn't really help there. I don't think I've seen a well
formulated opinion on GAP becoming part of GIMP (last time I  asked,
some developers were against, others were indifferent), but some
streamlining of user experience regarding basic animation could be
both useful and GSoC material. Of course, that's just my personal
opinion, and besides, upcoming frame-by frame animation in Synfig
could render the whole idea obsolete.

> 4) What can we learn from the former GSoCs: what have we done well,

Historically, students who performed best were the ones who joined
early to study the code and maybe send a couple of patches, sticked
around on IRC and were generally open about their work. They were also
the students who came up with an idea of their own or even had done
some prior work (last year's N-Point deformation tool is one such
example).

> what could be improved?

Off top of my head:

1) Even more explicitly encourage original thinking and genuine
interest in a proposed project. Implementing something that stems from
a cool SIGGRAPH paper is good, competing against 5 other students for
a slot that isn't even all that critical for GIMP -- not so much :)

2) Make 100% sure that students are familiar with the code. Inkscape
has a two-patches rule to even start considering a submitted
application. We didn't want to do that before, but we did have
disappearing students in the past. Something to think of, IMO.

3) Demand public weekly reports on progress, sent to
gimp-developer@/gegl-developer@, no excuses.

4) Only allow UI-related projects if we have a usability person to
design new interaction/UIs. Last year's selection tools project is why
we need that.

Alexandre