On 29 April 2016 at 13:52, C R <caj...@gmail.com> wrote:
>> My experience is that GIMP developers don't care what any user would
>> like to have.
> Clearly untrue. We have the Unified Transform Tool, hardware acceleration,
> Mypaint brush engine, and (up to) 64bit colour depth, and linear light
> blending modes to look forward to in the next release, the freakishly
> awesome Handle Transform tool, a proper on-canvas warp-tool, and so so many
> more awesome things that users (including myself) have been asking for, and
> anxiously awaiting.
> There are things that I've asked for that didn't get implemented, but the
> minute I start feeling bad about GIMP, and where it's going, or that one
> thing I consider a priority over all others, I take a step back and and go
> use other image editors for a while. I'm usually back to GIMP within a day
> or so. :)
> Better yet, if I think my idea is really good, I could go about getting more
> of the community behind it with mockups and hanging out in the irc channels
> and asking/answering questions. Sitting silent on the gimp-developer mailing
> list and only poking my head up to offer up some ill-timed tautological
> criticism does zero good for anyone, I've found.
Spotted the lurker having a bad day :)
> There are some topics that just go round and round, which is why you will
> find devs (and the community) going with a previously established answer.
> Everyone's really sick of arguing about these things, and you can tell right
> away witch ones they are, because they are in the FAQ on GIMP.org, and you
> can feel the tension around the question and answer like a thick soup. No
> one wants that soup, so generally we send it back when someone offers up
> another helping of the same. :)
>> The general response is "we have previously decided that we want to do
>> it like this and we aren't interested in how the end user might find
>> something useful".
> Ah "The End User". One end user's "might find something useful" is another
> user's horrendous workflow bottleneck. If it was previously decided on,
> there's likey a good reason for it. Could probably ask what the reasons are
> for enlightenment.
You say that noone wants that soup and are sick of arguing it, but
surely the logic follows that if the users DIDN'T want it, they
wouldn't keep bringing it up.
However, they do and the arguments ensue, which highlights my point
about devs not being receptive.
A good example of this where it is not just one user is the
export/save as, which can be followed in the list history.
These sorts of clashes can be resolved much more easily by putting
configuration options in.
Sure it adds an extra test to be covered in your code but you are now
catering to both sides.
Another historical example is the single window mode and how popular
GimpShop was when it came out and how long core devs resisted before
>> This is in stark contrast to most of the other open source projects
>> that I work on that gladly take constructive input.
> GIMP is a huge program with lots of end users, of which every one has their
> own priorities, workflow preferences, etc.
> GIMP also has very few developers, so a set list of priorities matter all
> the more.
There seems to be a more aggressive stance here though on what are
priorities and what is just denials.
You don't see a response that often saying "thats an interesting
proposal for our UI but we are focussing on this core algorithm right
now so it will have to go on the back burner".
You are more likely to get an argument about the idea and how it
doesn't fit with the vision.
> Thanks to everyone who works on GIMP. The current batch of new features in
> trunk are going to make waves in the community. It's a tremendous gift, and
> should be treated as such.
> My 2p
Having said all this, you make a good point about all the new features
and it is much easier to complain than add these features!
>> On 23 April 2016 at 09:51, Bill Skaggs <weska...@gmail.com> wrote:
>> > The great advantage of the bug-tracker is that it allows requests to be
>> > handled in a structured way. It is easy to find specific types of
>> > enhancement requests in the bug-tracker and examine the priority they
>> > have
>> > been given and the discussion that followed them. Getting this
>> > information
>> > from a forum is usually much more difficult.
>> > It is quite reasonable to bring up enhancement ideas in a forum and
>> > discuss
>> > them there until they are reasonably specific and coherent, but once
>> > that
>> > has happened it is helpful to have an enhancement request created in the
>> > bug-tracker. If the developers don't like them, they can always be
>> > classified as WONTFIX or NOTABUG.
>> > On Sat, Apr 23, 2016 at 1:40 AM, Euri Pinhollow <pinh...@gmail.com>
>> > wrote:
>> >> My point of view is: enchancements should be discussed on the forum,
>> >> not in a bugtracker. Here is what DispCalGUI has:
>> >> https://hub.displaycal.net/forums/
>> >> Mailing list is not exceptionally convenient for many people (myself
>> >> included. I just mailed topic starter instead of mailing to the list
>> >> thinking that replying to mail will get it done. I now pressed "reply
>> >> to all") but may be still better than discussing enchancements in
>> >> bugtracker.
>> >> Imgaine that every user wants something new. Because of number of
>> >> users being magnitudes larger than number of developers (who are not
>> >> paid) and those willing to contribute the project is guaranteed to
>> >> drown in requests.
>> >> Bugtracker is for developers and they should pick doable tasks from
>> >> forum themselves.
>> >> _______________________________________________
>> >> gimp-developer-list mailing list
>> >> List address: email@example.com
>> >> List membership:
>> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> >> List archives: https://mail.gnome.org/archives/gimp-developer-list
>> > _______________________________________________
>> > gimp-developer-list mailing list
>> > List address: firstname.lastname@example.org
>> > List membership:
>> > https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> > List archives: https://mail.gnome.org/archives/gimp-developer-list
>> gimp-developer-list mailing list
>> List address: email@example.com
>> List membership:
>> List archives: https://mail.gnome.org/archives/gimp-developer-list
gimp-developer-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list