Re: [Gimp-developer] New Image/Color Management option

2016-05-20 Thread Elle Stone 

On 05/20/2016 02:45 PM, Alexandre Prokoudine wrote:

On Fri, May 20, 2016 at 9:37 PM, Jason van Gumster wrote:


But perhaps the artists that create these maps are not covered in the audience
specified in GIMP's vision statement.


They are.

Alex


And the needs of artists who create these maps are NOT better met by the 
new bogus and highly misleading color management options.


The new options to uncheck color managing an image do NOT disable color 
management.


Best,
Elle

___
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] New Image/Color Management option

2016-05-20 Thread Elle Stone 

On 05/20/2016 02:37 PM, Jason van Gumster wrote:


Elle Stone  wrote:


I can't think of a single use case for trying to edit a non-color-manged
image in an ICC profile color-managed editing application such as GIMP.


I think I can think of one: creating displacement/bump maps (often used as
textures in 3D graphics). Often in that case, pixel values aren't treated as
color, but a numeric non-color data (i.e. it's an instruction to displace
geometry---or other pixels---by this numeric mapping value).

But perhaps the artists that create these maps are not covered in the audience
specified in GIMP's vision statement.

In point of fact, the new GIMP color management options do NOT disable 
ICC profile color management.


If you want to disable color management, go into "Edit/Preferences/Color 
Management" and for "Image display mode" select "No color management".


Or you can achieve the same effect by assigning your monitor profile to 
the image file.


However, for your particular use case, you don't really care what the 
image looks like. And with color management disabled what it looks like 
depends on your monitor's display characteristics.


So you might as well leave color management enabled and use the GIMP 
built-in sRGB profile as the image profile.


You can assign the GIMP built-in sRGB profile using "Image/Color 
Management/Assign".


You don't need the new and HIGHLY MISLEADING "Image/Color Management" 
options to assign the GIMP built-in sRGB profile.


Best,
Elle
___
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] New Image/Color Management option

2016-05-20 Thread Alexandre Prokoudine 
On Fri, May 20, 2016 at 9:37 PM, Jason van Gumster wrote:

> But perhaps the artists that create these maps are not covered in the audience
> specified in GIMP's vision statement.

They are.

Alex
___
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] New Image/Color Management option

2016-05-20 Thread Jason van Gumster 

Elle Stone  wrote:

> I can't think of a single use case for trying to edit a non-color-manged 
> image in an ICC profile color-managed editing application such as GIMP.

I think I can think of one: creating displacement/bump maps (often used as
textures in 3D graphics). Often in that case, pixel values aren't treated as
color, but a numeric non-color data (i.e. it's an instruction to displace
geometry---or other pixels---by this numeric mapping value).

But perhaps the artists that create these maps are not covered in the audience
specified in GIMP's vision statement.

  -Jason

/me scurries off to a corner
___
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] Contributing To Gimp

2016-05-20 Thread Alexandre Prokoudine 
On Thu, May 19, 2016 at 8:15 AM, pawandeep singh wrote:
> Hello,
>
> My name is Pawandeep Singh. I want to contribute to Gimp. I was looking for
> issue list for Gimp on Github at https://github.com/GNOME/gimp but I could
> not find any issues button. Can anyone please tell me where to find issues
> list for Gimp.

Hello Pawandeep,

The Git repo on GitHub is a copy we didn't even create. The real deal is here:

https://git.gnome.org/browse/gimp

Here's the full list of reported issues:

https://bugzilla.gnome.org/buglist.cgi?quicksearch=product%3A%22GIMP%22

But you probably want sorting through them somehow, so I'd suggest
visiting https://bugzilla.gnome.org/page.cgi?id=browse.html=GIMP
amd maybe starting with the ones that should be fixed before we can
release 2.10:

https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_id=125490=GIMP_milestone=2.10

Alex
___
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] Contributing To Gimp

2016-05-20 Thread pawandeep singh 
Hello,

My name is Pawandeep Singh. I want to contribute to Gimp. I was looking for
issue list for Gimp on Github at https://github.com/GNOME/gimp but I could
not find any issues button. Can anyone please tell me where to find issues
list for Gimp.

Thank you
___
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] Gimp standalone C apps

2016-05-20 Thread Oleksiy Druzhynin 
Dear Gimp developers.


Is it possible to re-use Gimp-functionality in own C-code? I have already a 
image processing pipeline and want to just apply to my image bitmap 
GIMP_TYPE_BRIGHTNESS_CONTRAST_CONFIG in ope of pipline's stages.


Is it possible to convert bitmap to drawable and put in into this code (as in 
?gimp/app/pdb/color-cmds.c):


  GObject *config = g_object_new (GIMP_TYPE_BRIGHTNESS_CONTRAST_CONFIG,
  "brightness", brightness / 127.0,
  "contrast",   contrast   / 127.0,
  NULL);

  gimp_drawable_apply_operation_by_name (drawable, progress,
 C_("undo-type", 
"Brightness-Contrast"),
 "gimp:brightness-contrast",
 config);


Is it any examples of standalone apps, which are using Gimp functionality?


Regards,


Oleksii
___
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] Can hitting Enter/Return twice apply changes made in popup dialogs?

2016-05-20 Thread C R 
>
> In workflow, it makes sense to focus the dialog on the next likely action,
>> so if the user is filling out a form, focus would naturally be on the next
>> blank field that needs to be filled in.
>>
>  Are you arguing that having a global key to accept+dismiss the current
> dialog has no value? Even if you have focus-chasing logic, that does not
> preclude the accept+dismiss binding.
>


No, I'm arguing we shouldn't need another global hotkey just to get rid of
the current workflow bottleneck. If we implement my proposed solution
(which is the way people are used to accepting+dismissing dialogs in nearly
all popular graphics editors), the need for a global accept-dismiss hotkey
should vanish (of we do it right).

-C
___
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] Can hitting Enter/Return twice apply changes made in popup dialogs?

2016-05-20 Thread Christopher Curtis 
On Fri, May 20, 2016 at 2:29 AM, C R  wrote:

> In workflow, it makes sense to focus the dialog on the next likely action,
> so if the user is filling out a form, focus would naturally be on the next
> blank field that needs to be filled in.
>
 Are you arguing that having a global key to accept+dismiss the current
dialog has no value? Even if you have focus-chasing logic, that does not
preclude the accept+dismiss binding.

Chris
___
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] Can hitting Enter/Return twice apply changes made in popup dialogs?

2016-05-20 Thread Liam R. E. Quin 
On Thu, 2016-05-19 at 19:03 +0100, C R wrote:
> And yet hitting Enter/Return key to commit/save is standard here too,
> which
> is why there's a popup warning on overwrite in cases of overwriting a
> file.

Yes. (sorry for not being clear)

Whether enter commits the action in those cases depends on the focus
and autocomplete status, unfortunately.

I'd favour something like shift-enter doing the default action - still
one hand and not easily done accidentally.

I am not sure why Enter doesn't move from one text field to the next in
e.g. the Rotate dialogue - tab is needed instead. The Sun and AT UI
research led to the idea of pressing enter focussing each entry in turn
until you got to the OK button, and then applying it, but they didn't
study advanced image editors.

Liam




-- 
Liam R. E. Quin 
___
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] Can hitting Enter/Return twice apply changes made in popup dialogs?

2016-05-20 Thread C R 
Please ignore this bit, it's really beside the point, and is just me
thinking out loud. >

> It makes little sense to then have to change your hand position to apply
> the change with another hotkey, since we have already decided to focus it
> instead of the first item in the dialog, especially when the default when
> you press enter again is to do absolutely nothing. Also two shift keys are
> not always present, and tab works fine to move focus, so there's not much
> point in having Enter/Return focus the next box, instead of applying the
> change, which is intuitive. After all, enter commits the value, so it makes
> sense enter again will commit the dialog.
>

Thanks. :)



> On 20 May 2016 1:49 am, "Liam R. E. Quin"  wrote:
>
>> On Thu, 2016-05-19 at 19:03 +0100, C R wrote:
>> > And yet hitting Enter/Return key to commit/save is standard here too,
>> > which
>> > is why there's a popup warning on overwrite in cases of overwriting a
>> > file.
>>
>> Yes. (sorry for not being clear)
>>
>> Whether enter commits the action in those cases depends on the focus
>> and autocomplete status, unfortunately.
>>
>> I'd favour something like shift-enter doing the default action - still
>> one hand and not easily done accidentally.
>>
>> I am not sure why Enter doesn't move from one text field to the next in
>> e.g. the Rotate dialogue - tab is needed instead. The Sun and AT UI
>> research led to the idea of pressing enter focussing each entry in turn
>> until you got to the OK button, and then applying it, but they didn't
>> study advanced image editors.
>>
>> Liam
>>
>>
>>
>>
>> --
>> Liam R. E. Quin 
>>
>
___
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] Can hitting Enter/Return twice apply changes made in popup dialogs?

2016-05-20 Thread C R 
In cases where you are unlikely to change every single option, it's still
much faster to handle it exactly like originally stated, and is why other
very popular graphics software applications use the convention. In
workflow, it makes sense to focus the dialog on the next likely action, so
if the user is filling out a form, focus would naturally be on the next
blank field that needs to be filled in.

The reason for auto focusing to the history combo box is for speed on
repeating the last used settings. It makes sense that the next focus should
be the OK button for these dialogs. In which case the Enter key would
function as requested, to press the OK button and commit changes.


The logic:

1. If you have chosen a history item from the combo box, you most-likely
want to apply the changes immediately following, so the OK button is
focused.

2. Hitting Enter/Return presses the button and completes the workflow for
this result.


If it's desired, I can do some workflow comparisons to show the difference
in various workflows with this "new" convention. :)

I believe most workflows will benefit from this change without the need to
add more non-standard hotkeys to GIMP.

-C




It makes little sense to then have to change your hand position to apply
the change with another hotkey, since we have already decided to focus it
instead of the first item in the dialog, especially when the default when
you press enter again is to do absolutely nothing. Also two shift keys are
not always present, and tab works fine to move focus, so there's not much
point in having Enter/Return focus the next box, instead of applying the
change, which is intuitive. After all, enter commits the value, so it makes
sense enter again will commit the dialog.
On 20 May 2016 1:49 am, "Liam R. E. Quin"  wrote:

> On Thu, 2016-05-19 at 19:03 +0100, C R wrote:
> > And yet hitting Enter/Return key to commit/save is standard here too,
> > which
> > is why there's a popup warning on overwrite in cases of overwriting a
> > file.
>
> Yes. (sorry for not being clear)
>
> Whether enter commits the action in those cases depends on the focus
> and autocomplete status, unfortunately.
>
> I'd favour something like shift-enter doing the default action - still
> one hand and not easily done accidentally.
>
> I am not sure why Enter doesn't move from one text field to the next in
> e.g. the Rotate dialogue - tab is needed instead. The Sun and AT UI
> research led to the idea of pressing enter focussing each entry in turn
> until you got to the OK button, and then applying it, but they didn't
> study advanced image editors.
>
> Liam
>
>
>
>
> --
> Liam R. E. Quin 
>
___
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