Hi, Michael Schumacher wrote: >> Von: Dave Neary <dneary@xxxxxxx> > >> > Hi all, >> > >> > I have registered the GIMP as a mentoring organisation for the Summer of >> > Code (I had been in contact with Google before the announcement), we >> > should be up on the page over the next couple of days. > > It would have been nice to know this a bit earlier. As you can see in the > other thread, we were already preparing stuff... I was away for the weekend, when the announcement was made, but the contact I made was last year when the GIMP wasn't in the mentoring organisations, because no-one had asked. This year, I got in early. I'm not taking this over, by any means. I'd like to have as little as possible to do with it, but I'm happy being an initial point of contact. Bill Skaggs said: > Thanks Dave for taking the initiative. Does this mean that you are > volunteering to be the "coordinator", as described in the SoC FAQ? I'm the "coordinator" - I have received the information we need to sign up mentors, and anyone who would like to be a mentor for an SoC project should contact me. The role of mentors is to be present in the soc groups during the start-up phase, commenting on GIMP project ideas, helping people refine those ideas, and after project selection, to supervise someone's work, be their shoulder to cry on when things are going badly, their wall to bounce ideas off, their interface to the greater GIMP community. We will need 3 or 4 of these, at least, perhaps more. > We should settle on half-a-dozen well-defined project ideas, because > having too many choices leads to brain freeze, and people who > want to work with GIMP but don't like any of the suggestions are > always free to come up with ideas of their own. And it would be > nice to put them on a page on the developer web site as opposed to > the Wiki. It is much the same thing - the important thing is to have the ideas available quickly. Either way is fine with me. I would go for 10 or 12 decent ideas. I would rule out anything that starts "finish...". Outside of that, there's no need to provide specs, and ideas are there to inspire. They should be realistic, but make people go "wow" at the same time. > I think this timeline is unrealistic, and that it would be better > to aim for the results of the student projects being incorporated in > the 2.4 release. You're probably right. But we'll need to be a bit slushy about hardening features - 2.4 will be feature frozen when SoC finishes. We can release a slightly buggier than usual 2.4 of course. > 2) Resource management. Currently resources such as brushes, gradients etc > are shown to the user in an unstructured way, which greatly limits the number > of items a user can deal with. People love to make collections of things, > so this would greatly enhance the user experience. This and a decent plug-in distribution system are great ideas. Sven Neumann said: >> > - Plug-ins: Save for web for example (too small to be a project, >> > but could be part of one) > > IMO "Save for Web" is complex enough for a project. I may be underestimating the effort involved, but I think I could throw together a prototype fairly quickly. >> > - Effect layers - I think this is fairly straightforward with the >> > GIMP as it is, it's a nice chunk of a project, and would be a nice >> > feature for users > > How is this fairly straightforward with the current architecture? I > would rather say that it is currently almost impossible to implement > sanely. Ah, but I'm insane. Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer. We'd need to evolve the xcf version number, and it probably wouldn't be possible to do anything useful with the effects layers in earlier versions of the GIMP (ignore seems about the best option). > I don't see why we should wait with GEGL integration. There are people > waiting for the 2.4 release to start this work. It would be a huge > mistake to postpone this. The amount of GEGL integration that is > planned for the next release is small anyway and is unlikely going to > delay the 2.6 release. I'm not proposing delaying gegl integration. I'm just saying that to get the most benefit out of SoC, you need to release people's code soon after the Summer, and the gegl integration isn't going to ship until next Summer probably. So it seems sane to me that gegl integration start on a branch (made straight after 2.4), and gets merged back into HEAD *after* we ship a stable release with SoC projects included. That said, Bill suspects that 2.4 might not get released until after the Summer (seems pessimistic to me, but I'm a bit far from things to be able to say for certain), and in that case, he has a point. Cheers, Dave. -- David Neary bolsh@xxxxxxxx _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
