Hi,

On Sat, 2007-01-13 at 14:17 -0800, Hal V. Engel wrote:

I have noticed that recent CVS builds will issue the following error when opening some files with embedded profiles:

Please give us a link to an image that shows this problem so that we can investigate.

Sven

Hal V. Engel writes:
> I have noticed that recent CVS builds will issue the following error when > opening some files with embedded profiles:

How recent? Could this be the problem fixed by:

2007-01-03 Tor Lillqvist

* plug-ins/common/lcms.c (run): Fix mixup in retrieving the filename parameter.

(Which fixed a crash in lcms for me.)

--tml

Hi,

On Mon, 2007-01-15 at 12:02 -0800, Hal V. Engel wrote:

I just tried CVS to make sure that the problem was still there (it is). An image with an embedded profile that causes the problem is located here:

http://lprof.sourceforge.net/images/targetscanvelvia-profile.jpg

Works fine for me. Did you really try CVS as you wrote? That might explain it because the GIMP source has been migrated to Subversion. So if you are still checking out from CVS, you don't have the latest version.

Sven

On Tuesday 16 January 2007 03:45, Hal V. Engel wrote:

3. The file dialog does not have a way to show hidden directories that I have been able to find other than typing in the path.  This is probably a GTK issue rather than a GIMP issue.

Just right-click on the file list and you'll see a pop-up menu showing an option to let you display or not hidden files.

This *is* a GTK issue ;o)

Hi,

some of these things will be fixed for 2.4. But we can't delay the release any further and this means that color management is not going to be fully functional and usable in 2.4. We plan to have 2.6 out shortly after so I am currently postponing pretty much everything related to color management to the 2.6 release.

Perhaps in the next development cycle, there will not only be people who point out problems and request features but also someone who wants to do the coding. Otherwise it might taken even longer before a full CM workflow is implemented.

Sven

On 1/16/07, Sven Neumann wrote:

We plan to have 2.6 out shortly after so I am currently postponing pretty much everything related to color management to the 2.6 release.

Is 2.6 going to be bugfix release or a first stable version using GEGL/babl?

Alexandre

Hi,

On Tue, 2007-01-16 at 11:16 +0300, Alexandre Prokoudine wrote:

We plan to have 2.6 out shortly after so I am currently postponing pretty much everything related to color management to the 2.6 release.

Is 2.6 going to be bugfix release or a first stable version using GEGL/babl?

2.6 has an even minor version number so it's obviously a stable release series. It will most probably use GEGL at a few places internally, but the users are not likely going to notice that. Currently the plan for 2.6 is to finish some stuff that wasn't completed in time for 2.4 and to start porting the core to GEGL. Perhaps we should also start porting the display code to Cairo. But that depends on whether someone wants to work on this or not.

Sven

On 1/16/07, Sven Neumann wrote:

2.6 has an even minor version number so it's obviously a stable release

Obvious only to people who don't need to ask.

series. It will most probably use GEGL at a few places internally, but [...] 2.6 is to finish some stuff that wasn't completed in time for 2.4 and to start porting the core to GEGL. Perhaps we should also start porting the display code to Cairo. But that depends on whether someone wants to work on this or not.

Something to consider, I think, is momentum. I think that people want to be part of a vibrant developer community. If a project does not have this, it may be beneficial to create an artificial one by increasing the number of releases. To this end, it may be wise to make future releases more "bite-sized": 2.6 implements CMS workflow and fixes 2.4 problems. 2.8 introduces Cairo rendering. And then 3.0 can integrate GEGL.

GEGL of course has the same problem (limited developers) so it may be wise to do some partial integration where reasonable through the 2.x series to help keep that project going - people want to see the results of their efforts. More releases furthers this goal, and also entices new users to try the new features. This can create a nice feedback loop where lots of little changes can be cleaned up across each release. I don't think that additional stable releases further this goal because the GIMP generally just works. Bug fixes here and there just aren't exciting.

Now, I'm not trying to be so bold as to propose a schedule, but it seems that if there were three or four releases this year - 2.4 now, then 2.6, 2.8, and maybe a 2.10 - that's roughly four months per release. Asking people to "wait for the next release to include your plugin" doesn't sound so severe then. The biggest burden I think would fall to the translators, which is something that developers just need to be sensitive to.

The 3.0 release doesn't have to be so quick, assuming that GEGL integration upsets things. If timed properly, it may be wise to adapt a schedule to the Google summer of code program. The implication then being that this would complete summer 2009. Of course, that also means that this has to be a reasonable SoC project.

Finally, in relation to my first comment, every mailing list has its share of hostile people. If developers truly want a large and vibrant development community, somebody needs to be a welcoming beacon. Condenscending remarks (blah blah is _obvious_) are damaging to that goal. There needs to be a consistent voice that welcomes masses of newbies asking "dumb questions" in hopes that some kernel within that mass are new GIMP developers that just need a little nurturing. (If it _should_ be obvious to someone, replying privately is better because the tone of the list matters.)

Also, and this is related to above, I think we (all) should recognize the growing numbers of people running free software on non-free platforms and realize that they are important parts of the user base. Linux, for example, is not as scary to people who are already familiar with and use its software. But in order for them to use that software, it has to be a good experience on that non-free platform. "You mean if I buy a computer with Linux it already has the GIMP installed? Great!"

For your consideration, Chris

Hi,

On Wed, 2007-01-17 at 09:45 -0500, Christopher Curtis wrote:

Something to consider, I think, is momentum. I think that people want to be part of a vibrant developer community. If a project does not have this, it may be beneficial to create an artificial one by increasing the number of releases. To this end, it may be wise to make future releases more "bite-sized": 2.6 implements CMS workflow and fixes 2.4 problems. 2.8 introduces Cairo rendering. And then 3.0 can integrate GEGL.

That's what we are targeting for with 2.6. It will be a short development cycle with only very few changes. But there are people waiting to be able to commit GEGL code into the GIMP tree. So we will definitely not wait with that. The transition to GEGL will take a while anyway and the user won't notice in the beginning anyway.

Now, I'm not trying to be so bold as to propose a schedule, but it seems that if there were three or four releases this year - 2.4 now, then 2.6, 2.8, and maybe a 2.10 - that's roughly four months per release. Asking people to "wait for the next release to include your plugin" doesn't sound so severe then. The biggest burden I think would fall to the translators, which is something that developers just need to be sensitive to.

Four releases per year is impractical. We wouldn't get anything done because we would be busy preparing releases all the time. Even the two releases per year schedule that GNOME is running is considered to be too short by most developers.

And we can't release 2.4 now. It may even take another four months before we are there. Have a look at the bug reports on milestone 2.4. A few of them can be postponed but there are still some major ones that absolutely have to be addressed.

Sven