Re: [Gimp-developer] Enhancement request policy

[john smith]

On 29 April 2016 at 13:52, C R  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
implementing it.


>> 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  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 
>> > wrote:
>> >
>> >> My point of view is: enchancements should be discussed on the forum,
>> >> not in a bugtracker. Here 

Re: [Gimp-developer] Enhancement request policy

[john smith]

My experience is that GIMP developers don't care what any user would
like to have.
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".
This is in stark contrast to most of the other open source projects
that I work on that gladly take constructive input.

On 23 April 2016 at 09:51, Bill Skaggs  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  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:gimp-developer-list@gnome.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:gimp-developer-list@gnome.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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Export instead save directly

[john smith]

As long as people are putting their hands up, I never save in xcf and
would prefer a workflow that was open, edit, save in same format.

However, rather than try to change the core code to appease those with
a similar thought, I would like to know if it is possible to change
this behaviour with a plugin.
This way both sides are happy.

Is it possible to write a plugin that re-maps core shortcuts and
changes default menu layouts etc?


On 1 March 2016 at 11:00, C R  wrote:
> Sounds good to me. I'm more than capable of choosing the correct file
> extension(s) and settings for myself. I think it's beneficial to have those
> settings already intelligently defaulted to when saving. I believe it will
> save some clicking in most workflows. Also good that it can be turned on
> and off in settings. I'd keep the warning about not having saved an .xcf
> file of the current doc when closing if there is indeed data to be lost.
> That will have the same effect as the current [Sorry, you can't Save to a
> jpeg, please use export instead] warning screen. When I type a file
> extension, GIMP knows what I want to happen. It should do it dutifully,
> then warn me at a later time that I should save my project construction
> file before closing it.
>
> +1 from me.
>
> -C
>
> On Tue, Mar 1, 2016 at 2:52 PM, Simone Karin Lehmann 
> wrote:
>
>>
>> > Am 01.03.2016 um 15:05 schrieb C R :
>> >
>> > If Save intelligently determines the file format that is most likely to
>> be
>> > used to save, Export should not be necessary. Just "Save" and "Save As"
>> > would suffice.
>> >
>> That's nearly exactly what I did with my patched version on
>> http://gimp.lisanet.de
>> I even made this a configurable option in the Preferences dialog.
>> So, if one is interested, have a look at my patches.
>>
>> > We could use the "multi layer" & "layer outside layer boundaries"
>>
>> I'm currently testing only for 'multiple layers' but it's quite easy to
>> add other tests.
>>
>> > convention to suggest that the user save to xcf, as normal to preserve
>> what
>> > they are seeing in the editor. The workflow would just involve flattening
>> > the image (which also gets rid of alpha) first before saving to make the
>> > Save default to the imported file format as a save suggestion. This has
>> the
>> > advantage of being intuitive and changeable merely by typing the required
>> > file extension. For my various workflows, 99 times out of 100, it would
>> not
>> > be necessary to change anything.
>>
>> That was the reason why I did it. And I got a lot of positive feedback
>> from users of my package.
>>
>> >
>> > I'd be lying if I said the current export convention didn't trip me up
>> > occasionally. It's been 6 years since I switched completely from
>> Photoshop,
>> > so in my case, it's not really blamable on convention anylonger. :)
>> >
>> > My 2p.
>> >
>> > -C
>> >
>> >
>> >
>> >> On 1 Mar 2016 8:43 am, "Tobias Ellinghaus"  wrote:
>> >>
>> >> Am Montag, 29. Februar 2016, 23:57:10 schrieb C R:
>>  That would be terrible. Users not understanding the concept would
>> >> suddenly
>>  be
>>  facing images where they can just save to JPEG while others can't, but
>> >> PNG
>>  is
>>  still enabled (because they somehow added an alpha channel), and even
>>  other
>>  images support XCF only (maybe because the layer is bigger than the
>>  image).
>> >>
>> >> (I used "just" in the sense of "without any further actions" and not
>> >> "only".)
>> >>
>> >>> No, that's not what I'm suggesting. If you import a jpeg for example,
>> do
>> >>> your editing, and end up with an alpha channel somehow, the save could
>> >>> still default to the .jpg (the jpeg save dialogue could display a
>> warning
>> >>> that transparency will be lost). That does not prevent the user from
>> >>> requesting a .png (by specifying that extension). It also does not
>> >> prevent
>> >>> the user saving as an xcf either for that matter.
>> >>>
>> >>> When closing the file, if the file is not saved as an xcf, and there is
>> >>> extra data to be lost, well, the warning about it is there anyway.
>> >>
>> >> But that would mean to just go back to the status quo ante, i.e., revert
>> >> the
>> >> save/export dichotomy and bring back saving to arbitrary formats.
>> >>
>> >> [...]
>> >>
>> >>> My 2p.
>> >>> -C
>> >>
>> >> Tobias
>> >>
>> >> [...]
>> >> ___
>> >> gimp-developer-list mailing list
>> >> List address:gimp-developer-list@gnome.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:gimp-developer-list@gnome.org
>> > List membership:
>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> > List archives:   

Re: [Gimp-developer] Toolbar For Common Actions

[john smith]

On 25 January 2016 at 15:14, Sven Claussner  wrote:
> On 25.01.16 at 8:23 PM Sven Claussner wrote
>
>> I'm not sure whether this idea would make it to the roadmap.
>
>
> A discussion in our IRC channel #gimp clarified that this is
> very probably not going to happen.
> In 2008 we already had such a discussion and our former
> user interaction architect voted against it, see
> http://article.gmane.org/gmane.comp.video.gimp.devel/13881
>
>> For the time being I suggest the keyboard shortcut solution as mentioned
>> above. Here you find keys and mouse quick references to memorize the
>> shortcuts: http://docs.gimp.org/
>
>
> So, this is our solution.
>
> Greetings
>
> Sven
>
>
> --
>

Thanks for the clarification.

It is a shame that it couldn't be added as an option in the preferences though.
You could ship with a good set of defaults with optimum vertical
space, then people could have the option of adding it if they so
desired.

Or, as mentioned it could just be another toolbar on the sides.

Anyway, just my 2 cents. I'll try to memorize the shortcuts for now.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Toolbar For Common Actions

[john smith]

There are certain commands that I use rather more frequently than others.
It would be convenient if I could put them in a user defined toolbar.

I would prefer the toolbar to be docked horizontally under the Menus
but the option to float it or dock it to other sides would probably be
preferential to other people.

Is that a possibility for a future road map?

Thanks

John
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Line Lengths

[john smith]

On 24 December 2015 at 06:28,  <jcup...@gmail.com> wrote:
> On 24 December 2015 at 10:55, john smith <kingstonf...@gmail.com> wrote:
>>
>> I had a read of https://github.com/GNOME/gimp/blob/master/HACKING but
>> there is no mention of line length in the style guide.
>
>
> GIMP uses a lightly modified GNU style, so 80 characters line length.
>
>> However, I can't help feeling that the code might be more readable
>> with a slightly longer line length.
>
>
> Perhaps! But it's all 80 and is very unlikely to be changed. If you submit a
> patch which breaks the 80 rule you'll probably be asked to reformat.
> Consistency trumps almost all other considerations in a large project.
>
>> Is the code auto-formatted or done by hand?
>
>
> There's no auto format on commit.
>
> There are lots of tools which can format GNU style, for example the standard
> "indent" filter defaults to GNU. It will sometimes mess up comment
> formatting though. Google have a very fancy code reformatter which might do
> a better job.
>
> (I'm not actually a gimp dev, but that's my understanding of the situation,
> corrections pls.)
>
> John


Fair enough.

Or 
http://www.commandlinefu.com/commands/view/6558/indent-all-the-files-in-a-project-using-emacs
... :D
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Line Lengths

[john smith]

I had a read of https://github.com/GNOME/gimp/blob/master/HACKING but
there is no mention of line length in the style guide.

This looks like it is roughly 80
https://github.com/GNOME/gimp/blob/master/app/menus/plug-in-menus.c

However, I can't help feeling that the code might be more readable
with a slightly longer line length.

e.g
https://github.com/GNOME/gimp/blob/master/app/menus/plug-in-menus.c#L162-L167
  menu = g_strconcat (dgettext (locale_domain,
path->data),
  "/",
  dgettext (locale_domain,
plug_in_proc->menu_label),
  NULL);

Here we have a function that takes 4 parameters and has been wrapped.
However, 2 of the parameters are inline functions and have been
wrapped as well.

Wouldn't this be clearer with each parameter to the original function
on its own line?:
  menu = g_strconcat (dgettext (locale_domain,path->data),
  "/",
  dgettext
(locale_domain,plug_in_proc->menu_label),
  NULL);

Is the code auto-formatted or done by hand?
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] What Would It Take To Add Native Dialogs?

[john smith]

The GTK Open/Save Dialogs look really odd on a Windows system.

What would it take to put an if statement in the code that checks for the
OS and delegates to the Win API if it was a Windows system?
https://msdn.microsoft.com/en-us/library/bb776913%28v=VS.85%29.aspx

It looks like there is already platform specific builds
https://git.gnome.org/browse/gimp/tree/build/windows
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list