[Gimp-developer] configure: Eeeeeeeeeeeeeeeeeeeeek! Missing dep: appstream-glib >= 0.7.7

[richard brown via gimp-developer-list]

Hi all,



The latest git pull of 2.99 won't build.  It gives me the error

"configure: Ek! Missing dep: appstream-glib >= 0.7.7"


Ah, but I have appstream-glib >0.7.7 installed; built it from source and 
installed it into the prefix I use for gimp.




Any ideas?
___
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] ufraw-gimp support?

[Richard Brown]

Ooh, I did miss a memo, thanks.  Didn't know about nufraw.  Nor the little
hack.  Works now.
:-)

On 25 Sep 2017 5:25 pm, "Partha Bagchi" <parth...@gmail.com> wrote:

Are you building the plugin yourself? RAW handling had changed in recent
master updates.

I suggest you do the following:

1. Download the nufraw source from https://sourceforge.net/
projects/nufraw/files/
2. Open nufraw_main-gimp.c and add this line around Line 84 (in the
HAVE_GIMP_2_9 section)
gimp_register_file_handler_raw ("file_nufraw_load");
3. Compile nufraw against GIMP 2.9 and install.

Then you should be good to go. Now you can select nufraw in the preferences.



On Mon, Sep 25, 2017 at 12:07 PM, richard brown <richardbened...@gmail.com>
wrote:

> Hello,
>
>
> The most recent builds of gimp don't seem able to run the ufraw-gimp
> plugin.  This is a shame, as ufraw supports Sigma X3F files pretty well.
> The message is:
>
>
> There is no RAW loader installed to open 'Raw Sigma X3F' files
>
> GIMP currently supports these RAW loaders:
> -darktable, at least 1.7
> -RawTherapee, at least 5.2
>
>
> Have I done something silly, or have I missed a memo?
>
>
>
> R.
>
> ___
> 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] ufraw-gimp support?

[richard brown]

Hello,


The most recent builds of gimp don't seem able to run the ufraw-gimp 
plugin.  This is a shame, as ufraw supports Sigma X3F files pretty 
well.  The message is:



There is no RAW loader installed to open 'Raw Sigma X3F' files

GIMP currently supports these RAW loaders:
-darktable, at least 1.7
-RawTherapee, at least 5.2


Have I done something silly, or have I missed a memo?



R.

___
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] missing babl fast path and lt-gimp-2.9 segfault

[richard brown]

On 07/08/17 03:00, Carol Spears wrote:



On Sun, Aug 6, 2017 at 7:00 PM, Carol Spears <carol.spe...@gmail.com 
<mailto:carol.spe...@gmail.com>> wrote:





On Sun, Aug 6, 2017 at 5:30 PM, richard brown
<richardbened...@gmail.com <mailto:richardbened...@gmail.com>> wrote:



On 06/08/17 21:20, Carol Spears wrote:



On Sun, Aug 6, 2017 at 1:49 PM, richard brown
<richardbened...@gmail.com
<mailto:richardbened...@gmail.com>> wrote:

No-one?


Asking me?

The babl fast path is probably not the problem, at least it
is not a problem here. Actually, I kind of like it because I
can watch it to know where some of the other plug-ins are at
in their progress.

The last time I had a segfault like that, I was instructed to
install gdb (https://www.gnu.org/software/gdb/
<https://www.gnu.org/software/gdb/>) because the regular
stack trace is not so helpful.

That has been a few years now, so maybe my advice is outdated.


Thanks.  I tried it, and it doesn't like the "gimp-2.9" script
    that launches the program.

"/home/richard/Software/gimp-git/gimp/app/gimp-2.9": not in
executable format: File format not recognised

gdb is going to want to be started from the command line.

It is weird to me that you are running this from the source file. 
You don't install into /usr/local or /opt or some such?  If you

have been building and using gimp from there for a long while,
that would not be the problem but I would have thought that this
could cause problems, like gimp finding the plug-ins it brings, etc.

Here is a how-to that doesn't mention anything I remember when I
used gdb:
http://web.eecs.umich.edu/~sugih/pointers/summary.html
<http://web.eecs.umich.edu/%7Esugih/pointers/summary.html>

I remember using "bt" something like 'gdb bt /path/to/binary/gimp-2.n'

If you could get a good output from that, perhaps you could file a
bug report and maybe the real hackers are there


After some thought, (and unfortunately no reading) I suspect that the 
"bt" was typed during the stack trace.


Perhaps there is some reliable advice in the mail list archives

Carol



Got gdb working with it:

[New Thread 0x7fffaeffd700 (LWP 18150)]
[New Thread 0x7fffae7fc700 (LWP 18151)]
[New Thread 0x7fffbcbb0700 (LWP 18152)]

Thread 1 "gimp-2.9" received signal SIGSEGV, Segmentation fault.
g_type_check_instance (type_instance=type_instance@entry=0x1de98880) at 
gtype.c:4131
4131  TypeNode *node = lookup_type_node_I 
(type_instance->g_class->g_type);



But, I checked 'Preferences' and I was running 4 threads, and there's a 
warning there about instability.  So, I tried putting that to 1, and, so 
far, no crash.


>*Schoolboy error*<

But thanks for your help.


(The non-standard prefix stuff that I use to run gimp was outlined here 
if you're interested:


http://ninedegreesbelow.com/photography/build-gimp-in-prefix.html)


___
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] missing babl fast path and lt-gimp-2.9 segfault

[richard brown]

On 06/08/17 21:20, Carol Spears wrote:



On Sun, Aug 6, 2017 at 1:49 PM, richard brown 
<richardbened...@gmail.com <mailto:richardbened...@gmail.com>> wrote:


No-one?


Asking me?

The babl fast path is probably not the problem, at least it is not a 
problem here.  Actually, I kind of like it because I can watch it to 
know where some of the other plug-ins are at in their progress.


The last time I had a segfault like that, I was instructed to install 
gdb (https://www.gnu.org/software/gdb/) because the regular stack 
trace is not so helpful.


That has been a few years now, so maybe my advice is outdated.

Carol


Thanks.  I tried it, and it doesn't like the "gimp-2.9" script that 
launches the program.


"/home/richard/Software/gimp-git/gimp/app/gimp-2.9": not in executable 
format: File format not recognised


___
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] missing babl fast path and lt-gimp-2.9 segfault

[richard brown]

No-one?

___
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] missing babl fast path and lt-gimp-2.9 segfault

[richard brown]

I've no idea if they're related; but gimp-2.9 is currently crashing with:

*WARNING*: missing babl fast path(s) between formats "R'G'B'A u16" and 
"A double"
*WARNING*: missing babl fast path(s) between formats "R'G'B'A u16" and 
"HSVA float"
*WARNING*: missing babl fast path(s) between formats "R'G'B'A u16" and 
"HSVA float"
*WARNING*: missing babl fast path(s) between formats "R'G'B'A u16" and 
"HSVA float"
*WARNING*: missing babl fast path(s) between formats "R'G'B'A u16" and 
"HSVA float"
*WARNING*: missing babl fast path(s) between formats "HSVA float" and 
"R'G'B'A u16"
/home/richard/Software/gimp-git/gimp/app/.libs/lt-gimp-2.9: fatal error: 
Segmentation fault
/home/richard/Software/gimp-git/gimp/app/.libs/lt-gimp-2.9 (pid:21497): 
[E]xit, [H]alt, show [S]tack trace or [P]roceed: s
#0  0x7f676f440f7b in waitpid () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#1  0x7f676f975ed3 in g_on_error_stack_trace (
#2  0x7f676f976054 in g_on_error_query (
#3  0x0049467e in gimp_eek (
#4  0x004948a6 in gimp_fatal_error (message=)
#5  0x00494fd7 in gimp_sigfatal_handler (sig_num=)
#6  
#7  g_type_check_instance (type_instance=type_instance@entry=0x400f290)
#8  0x7f676fc96d5e in g_signal_emit_valist (instance=0x400f290,
#9  0x7f676fc9800f in g_signal_emit (instance=,
#10 0x7f6770fd4c93 in delayed_emission (data=0x7f672c0008e0)
#11 0x7f676f9a0a9a in g_main_dispatch (context=0x18b74b0) at 
gmain.c:3148
#12 g_main_context_dispatch (context=context@entry=0x18b74b0) at 
gmain.c:3813

#13 0x7f676f9a0e40 in g_main_context_iterate (context=0x18b74b0,
#14 0x7f676f9a1162 in g_main_loop_run (loop=0x3e747e0) at gmain.c:4082
#15 0x004943f2 in app_run (full_prog_name=,
#16 0x00493d25 in main (argc=, argv=0x17fb6c0)


I've tried with all the latest pulls of glib, babl, gegl, and gimp; as 
well as with babl-0.1.28



The crash occurs every time I try and stretch HSV contrast.

___
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] AppData additions required for the software center

[Richard Hughes (semi-automated)]

Hi again!

First, apologies for the direct email. I'm emailing you directly as you've been 
listed as the update contact in one or more AppData files.

We've been busy building an awesome software center, and we've been adding more 
and more metadata fields that upstream authors can set. The software center is 
now being used in Fedora, Opensuse, Ubuntu, Debian and Arch, with many millions 
of happy users.

Some of the newest features include a way to make it easy for translators to 
contribute new translations of your applications by specifying a URL in the 
gimp.appdata.xml AppData file that tells them where to start looking. This can 
be specified by adding:

http://the-web-site-with-translation-instructions/

Another useful tag to add is to tell end-users where to donate, for instance:

http://www.gnome.org/friends/

Also, by including keywords into either the desktop file or the AppData file 
you can increase the number of search matches you get in the software center. 
Adding application-specific keywords like "editor" or "vhdl" means that we can 
provide better search results for common queries. Keywords are also stemmed, so 
searching for "edit" will also match "editor" and "edits" so there's no need to 
add every variant. You can add keywords using:


  something
  anotherthing


If it's been some time since you updated the AppData file (and hey, you've got 
an app to write!) you can get add the latest metadata fields by doing 
`appstream-util upgrade gimp.appdata.xml` and then replacing any FIXMEs in the 
file with actual data. We'll be putting more functionality into the software 
center in the future that uses this extra data, but we need more upstream 
software to opt-in before we can enable features, for instance, providing a 
button for users to donate to specific apps.

You can also use `appstream-util validate-relax` on your AppData file to check 
the various fields meet our style guidelines. If you disagree with any of the 
validation warnings, please let me know!

Of course, you don't have to do a release with these enhancements straight 
away, and if you have a stable branch it would be a good thing to backport this 
as well if it does not add translated strings or you have no string freeze 
policy.

When you've changed the file(s) and committed, please email me back and I'll 
mark your application as completed. If you don't want to hear from me ever 
again just edit the  in the AppData file and change it to 
somebody else. I'm not planning on emailing more than once every 6 months, so 
don't worry about me spamming you with even more work to do.

Thanks,

Richard


___
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] Keywords required for the software center

[Richard Hughes (semi-automated)]

Hi!

First, apologies for the direct email. I'm emailing you directly as you've been 
listed as the update contact in one or more AppData files. In the software 
center we allow the user to search using case-insensitive keywords, for 
instance searching for 'excel' could match Libreoffice Calc or many other free 
software spreadsheet applications. At the moment we use the translated keywords 
set in the desktop file, any extra  entries in the AppData file, and 
then fall back to generating tokens from the name, summary and description 
using a heuristic. This heuristic works most of the time, but a human can often 
do much better when we know what the most important words are. I've noticed 
your application does not have any manually set keywords and thought I should 
bring this to your attention.

So, what do I want you to do? Basically, I would like you to add some keywords 
in the gimp.desktop file or the gimp.appdata.xml AppData file. If you want the 
keywords to be used by GNOME Shell as well (which you probably do), the best 
place to put any search terms is in the keywords section [1] of the desktop 
file. This can also be marked as translatable so non-English users can search 
in their own language. This would looks something like Keywords=3D;printer; 
(remember the trailing semicolon!)

The alternative is to put the keywords in the AppData file so that they are 
only used by the software center and not the desktop shell. You can of course 
combine putting keywords in both places. The AppData keywords can also be 
translated, and would look like this:


3D
printer


Of course, you don't have to do a release with this fix straight away, and if 
you have a stable branch it would be a good thing to backport this as well if 
it does not add translated strings or you have no string freeze policy. Nothing 
bad will happen if you ignore this email, but please be aware that matches from 
keywords are ordered higher in the search results than other partial matches 
from the name or summary. You also don't have to add keywords that are the same 
as the application name or package name, as these are automatically added as 
case insensitive search tokens.

When you've changed the file(s) and committed, please email me back and I'll 
mark your application as completed. If you don't want to hear from me ever 
again just edit the  in the AppData file and change it to 
somebody else. I'm not planning on emailing more than once every 6 months, so 
don't worry about me spamming you with even more work to do. If you don't add 
the keywords then your application will still be visible in the various 
software centers, but it may be harder to find.

Thanks,

Richard

[1] 
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys


___
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] Brush + Paint Dynamic - performance problems and comparison between 2.9 and 2.8.14.

[Richard]

IIRC, this was previously discussed on the mailing list (and bugzilla) and the 
cairo library was identified as a culprit/accessory to the lag -- as some users 
reported downgrading to a previous libcairo fixes the ruler lag.

However, it also appears to have been properly fixed as of mid-August:
https://bugzilla.gnome.org/show_bug.cgi?id=736411#c39

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


> From: jag.rabi...@gmail.com
> Date: Sun, 6 Sep 2015 14:16:26 -0300
> To: dra...@darkrefraction.com
> CC: gimp-developer-list@gnome.org
> Subject: Re: [Gimp-developer] Brush + Paint Dynamic - performance problems 
> and comparison between 2.9 and 2.8.14.
> 
> Michael is necessary write a bug report?
> Thanks
> 
> On Sat, Sep 5, 2015 at 3:30 PM, Americo Gobbo  wrote:
> 
> >
> > On Sat, Sep 5, 2015 at 2:55 PM, Michael Henning  > > wrote:
> >
> >> Does this issue clear up if you disable the rulers (by unchecking View ->
> >> Show Rulers)? If so, it's probably my fault.
> >
> >
> > Yes, without rulers works fine!
> >
> ___
> 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] Brush size slider below the brushes dialog

[Richard]

 Date: Thu, 16 Apr 2015 09:27:51 +0200
 From: joseph.b...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Brush size slider below the brushes dialog
 
 Hi,
 
 I am asking if the slider at the bottom of the brushes dialog can be
 re-activated. I personally find it very convenient to quickly adjust brush
 size, even if there is another size slider in tool options.
 
 Unless there is a good reason why it has been disabled.
 
 Best regards.
 
 Joseph
 ___
 gimp-developer-list mailing list

I'm thinking maybe because the brush size is now set on a per tool basis 
instead of per brush?  However, I agree that having this slider available (even 
if it only maps to the respective setting on the currently active tool) would 
be a plus anyway.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  
___
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] Useability enhancement request: unified/expanded file export dialog

[Richard]

 Date: Fri, 13 Mar 2015 09:28:43 -0400
 From: ellest...@ninedegreesbelow.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Useability enhancement request: 
 unified/expanded file export dialog
 
 On 03/11/2015 05:05 PM, Ofnuts wrote:
  For current Gimp there is the Save for Web plug-in that lets you
  crop/scale the image. However it's not uncommon to do a little bit of
  sharpening after a downscale, or maybe add some watermark... Better take
  the habit to use ImageDuplicate. This creates an untitled image to
  there is little risk to overwrite the original image with a scaled down
  version(*).
 
 True, usually resizing is followed by adding some sharpening and such. I 
 completely overlooked Image-Duplicate, so thanks! (not the first 
 already there in plain sight GIMP feature that I've overlooked).
 
 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

If my only reason for duplicating the image is to prevent accidentally saving a 
resized/flattened version over the original workfile, I wouldn't mind having a 
checkbox on the Resize dialog to do that automatically.  (For compare and 
contrast:  the Decompose/Compose plugins [necessarily] output their results to 
a new image window)

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  
___
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] Brush size relative to canvas size

[Richard]

 From: jo.y.v...@gmail.com
 Date: Thu, 23 Oct 2014 14:19:26 +0200
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Brush size relative to canvas size
 
 Instead to fiddle around with units, maybe we could to use Brush dynamics ? 
 Alternatives are welcome.


That's an interesting alternative, though it doesn't make much sense to just 
map Zoom as an input to the dynamics grid ... I don't imagine zoom being a 
useful value for anything other than brush size, and it's a multiplicatively 
inverse relationship ... but perhaps on the Size output there can be an option 
to control whether it is considered absolute or (screen) relative 

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  
___
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] Brush size relative to canvas size

[Richard]

 Date: Mon, 20 Oct 2014 15:49:25 -0200
 From: gwid...@gmail.com
 To: jo.y.v...@gmail.com
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Brush size relative to canvas size
 
 . . . Above all, just because Richard steped up with a proposed UI behavior
 for th e proposed feature does not mean, in any way, it would be
 easy to implement -  there would need to be hacks all way down to
 how Units are implemented inside GIMP, and that could affect all code
 using units - just to star with.
 
   js
  --
 

Which is why I put easy in quotation marks :)

It's easy from a -conceptual- standpoint, but in terms of the actual code 
changes required ... well, I can't speak for that

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  
___
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] unified artistic tools

[Richard]

 From: ej...@hotmail.com
 To: golab.przemys...@gmail.com
 Date: Sun, 19 Oct 2014 14:08:31 +0100
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] unified artistic tools
 
 Could have tools combined into one but hotkeys to switch between settings of 
 that tool. Best of both worlds?
 
 ___
 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

A.k.a. definable hotkeys for loading specific presets with a specific tool?  An 
admittedly limited application, but if it's something your workflow uses a lot, 
more power to you.  For example, for times where I'm interested in editing 
image pixels individually, a way to load up the Pencil tool AND a 1x1 size 
preset all in one hotkey would be awesome.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  
___
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] Brush size relative to canvas size

[Richard]

 From: jo.y.v...@gmail.com
 Date: Sat, 18 Oct 2014 14:30:24 +0200
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Brush size relative to canvas size
 
 Hi guys,
 
 some suggestions how to improve brushes:
 Brush size relative to canvas size
 

 would be handy to have a dynamic brush size, like: if i zoom in, the 
brush size adapts to the canvas size and shrinks relative to the zoom 
factor. Vice-versa, if i zoom out, the brush size grows relative to the 
zoom factor.
 

I imagine this could be 'easy' to implement simply by adding a new unit of 
measure for brush sizes: screen pixels (as contrasted to image pixels).  
This might not be a useful feature to have for all measurements, but for brush 
sizes it could indeed be a plus.

For comparison, when you make adjustments in Inkscape the Alt modifier allows 
you to adjust things in terms of screen pixels (using the current zoom level), 
and it's a handy thing to have available.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  
___
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] merging some tools

[Richard]

 From: jo.y.v...@gmail.com
 Date: Wed, 25 Jun 2014 12:11:48 +0200
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] merging some tools
 
 Hi,
 i'd suggest to simplify and clean up with all the tool icons around.
 Merging tools (radio button to change tool behavior in the tool preferences 
 tab)
 
 1) Rectangle/Circle Selection Tool
 2) Scissors/Lasso
 3) color extractor/foreground extractor
 4) Move tool/Align tool 
 5) Clone/Perspective Clone
 
 
 
 regards
 
 Jo
 
 ___
 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

If by 'merging' you mean that the GIMP toolbox groups tools into 'families' 
(preferably with a dropdown menu so you can select the specific tool) then I 
can support this -- in my GIMP I literally removed half the icons from the 
toolbox because (1) they're tools I don't use often at all and (2) I wanted to 
minimize the amount of real estate occupied by the box.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  
___
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] Feature Request(if wrong way to ask, sorry)

[Richard]

 From: tajny...@gmail.com
 Date: Mon, 10 Feb 2014 17:00:24 +0100
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Feature Request(if wrong way to ask, sorry)
 
 I use Gimp for awhile and I simply love it. But I came to idea to repattern 
 something on a picture (change pattern of walls and floor) but as I found out 
 I would need to create pattern as one huge image with right sizes and then 
 use built-in perspective tool to adjust it. Could you please think about 
 adding something like Perspective pattern tool? You would just select area 
 with right perspective and then select fill this area with... . As I said, if 
 this is wrong way to do feature request or it's already doable I want to 
 apologize myself. I was googling as I could but haven't come to any solution. 
 -- 
 Marek Lukáš
 ___
 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

I believe the proper tool is called perspective clone but in my 
experience it does not seem to be able to apply a perspective effect 
when using a pattern as the clone source.

You can however clone from a 
separate layer, so if you manually tile your source pattern and place it
 on a different layer you can specify that as the source and the desired
 layer as the target, and achieve the desired effect.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  
___
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] Making GIMP 1 window instead of 3 for Windows operating System

[Richard]

 Date: Fri, 3 Jan 2014 16:12:17 +0400
 From: alexandre.prokoud...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Making GIMP 1 window instead of 3 for Windows 
 operating System
 
 On Fri, Jan 3, 2014 at 4:05 PM,  nathanialj...@gmail.com wrote:
  Can anyone tell me how to make my GIMP setup just on Window together 
  instead of 3?
 
 In menu: WIndows  Single-window mode.
 
 You need GIMP 2.8.x for that.
 
 Alexandre
 ___
 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

Oh, and this is saved as part of your window options, so if you want GIMP to 
start in single window mode you'll need to save window positions (from Edit  
Preferences) while you have single-window mode enabled.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.



  
___
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] M$ partners claim, they own property rights to GIMP

[Richard]

 Date: Thu, 12 Dec 2013 20:06:50 +0100
 From: schum...@gmx.de
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] M$ partners claim, they own property rights to 
 GIMP
 
 On 09.12.2013 22:34, Dominik Tabisz wrote:
  Hello
  
  Gimp users in Poland have some strange problem: when we leave gimp
  installation files on publicly accessible file sharing services - they
  are removed because of copyright laws.
 
 So what's going to happen now? A possible step for chomikuj.pl would be
 to simply reinstate those files, and tell Marketly that those claims
 lack any credibility.
 
 
 -- 
 Regards,
 Michael
 GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
 ___
 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://gnome.org/archives/gimp-developer-list

In the US at least, doesn't filing a false DMCA claim leave you open to a 
countersuit or something?

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.



  
___
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://gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Quick-edit workflow

[Richard Gitschlag]

 From: pe...@mmiworks.net
 Date: Sun, 10 Nov 2013 02:25:47 +0100
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Quick-edit workflow
 
 I think I can see what Akkana means: when there is no export
 target, the menu items are “Export to” and “Export...”
 that is not ideal. and it’s clear that it irritates people.
 
 note that the export-to item cannot be grayed out in this case.
 ctrl-E just has to work (leading to an Export..., yes, just
 as the first Save is a Save As...)
 
 reviewing the situation, I see that the straightforward solution
 is to relabel
 
 Export... - Export As... (in all states)
 
 “Export to” - Export (when no export target)
 
 you can see that this achieves perfect mirroring of
 Save and Save As...
 
 “Export to foo.xyz” and “Overwrite foo.xyz” stay as-is,
 they work well with Export As...
 
 (just in case you wonder, yes I am giving up on something
 by doing this: in so many other application the label on
 the export menu item is Export... )
 
 --ps
 
 founder + principal interaction architect
 man + machine interface works
 
 http://blog.mmiworks.net: on interaction architecture
 
 
 
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I definitely agree that the labelling of the Export/Export To commands should 
completely mirror the labelling of Save/Save As commands.

PS:  Can we get some accelerator keys put on those menu labels sometime?

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.



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

Re: [Gimp-developer] Quick-edit workflow

[Richard Gitschlag]

 Date: Fri, 8 Nov 2013 20:15:23 -0800
 From: akk...@shallowsky.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Quick-edit workflow
 
 I've found that the new model makes me stop and think every time
 I save or export anything. For one thing, I'm still confused about
 the difference between Export... and Export to -- they seem to do
 the same thing even though one has a ... and the other doesn't, they
 have different shortcuts, and one of them isn't always available.
 And I can never remember in any given session which images can use
 Overwrite versus which ones need an Export... or Export to, so I no
 longer trust any save/export shortcut to be the right one, and
 almost always end up going to the menus instead.

It's just like the difference between Save and Save As in that, during the 
same session, Export uses the settings from the previous export (if any) 
while Export to... always prompts for a filename.  Of course, if you don't 
export very often then the difference is moot because every export happens 
during a different session.

And similar to you, one thing *I* don't get is why Export and Overwrite 
need to be separate commands.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

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

[Gimp-developer] Include exported filename/options in XCF data

[Richard Gitschlag]

This is a tangent related to the matter that the first time you do an export 
command from a GIMP session there is no practical difference between Ctrl+E 
(Export) and Shift+Ctrl+E (Export To).  Now, of course, the first time you do a 
Save command there is no difference between Ctrl+S (Save) and Shift+Ctrl+S 
(Save As) but this is not what makes the export shortcut an issue.

The saved filename is effectively kept between GIMP sessions.
The last-exported filename is not.

If you only ever do one export per GIMP session, you will never see any 
difference between Ctrl+E and Shift+Ctrl+E.  (Likewise, in an import/overwrite 
based workflow there is no difference between Ctrl+E and Shift+Ctrl+E either, 
because Overwrite is not the same command or shortcut as Export.)

So the suggestion here is that when you save your XCF file, the file should 
record a block of data for the last used export filename and its associated 
options.  If you have a workflow where you regularly export to the same target 
filename (but generally only once per GIMP session) this would be an 
improvement over the current behavior because GIMP then does not have to keep 
confirming that you're overwriting a file that exists or keep prompting you for 
export options.



-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Brush from Clipboard: Imperfections with some dynamics

[Richard Gitschlag]

 Date: Mon, 1 Jul 2013 10:58:05 -0300
 From: yafuli...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Brush from Clipboard: Imperfections with some   
 dynamics
 
 In this example:
 http://nsae01.casimages.net/img/2013/07/01/130701034929273527.png
 
 I used the brush from clipboard that you can see in the image, and
 Paintbrush tool with brush Spacing=1. The imperfections that can be seen
 are the blue lines on the red strip, and the red lines on the blue strip.
 The problem occurs with Dynamics Off and some other dynamics.
 I am using GIMP 2.8.6 on Kubuntu Linux.
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Occurs in win32 builds too.

I'm experimenting with it now and I notice that if the clipboard brush is all 
one solid color then the behavior fails to happen - it has to do with brushes 
containing multiple colors.

More interestingly, if the clipboard brush includes transparent pixels around 
its edge then the strange behavior does not happen.  It's like when GIMP needs 
to do alpha-blending around the edge of a clipboard brush, it interpolates 
using edge pixels from both sides (wraparound) instead of that side only 
(stretch).

Either way it definitely looks like a bug to report.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Paths need better display of on-canvas transform tools

[Richard Gitschlag]

 Date: Fri, 28 Jun 2013 09:08:53 +0200
 From: ofn...@laposte.net
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Paths need better display of on-canvas 
 transform tools
 
 If you have  a selection the transform tool handles are on the 
 boundaries of the selection... (the tool will still apply to the whole path)
 
 http://i.imgur.com/ApvhjV0.png

A workaround, I know.  It's just that the transform tool handles need to 
reflect the item that is actually being affected -- they already do that if 
it's the current layer (or selected portion of a layer) or selection mask 
itself.  Paths just need to follow suit.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Request] Improve Stroke Path capabilities

[Richard Gitschlag]

 Date: Tue, 28 May 2013 08:52:04 -0300
 From: yafuli...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] [Request] Improve Stroke Path capabilities
 
 [...] the ability to use gradients [...]
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

That is already doable if you tell it to stroke using a tool AND you have the 
necessary dynamics configured to draw colors from the gradient.  Not exactly 
convenient though

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.



  
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] How Print Size can save pixel density into e.g. png file?

[Richard Gitschlag]

 Date: Wed, 8 May 2013 10:34:29 +0300
 From: andrey.krieger.ut...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] How Print Size can save pixel density into e.g.   
 png file?
 
 I use the feature of changing image print density (in dpi) in GIMP to
 get predictable size of printed image. Now i want to do this
 programmaticaly. I tried to grep the code, but it would take me long
 time to figure this out by myself. Could please somebody describe in
 which way png file carries pixel density information, or point to the
 place in code that actually does this information saving to file.
 Thanks in advance.
 --
 Andrey Utkin
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list


Sounds like you need to look at the PNG specs themselves, not necessarily 
GIMP's method of writing to them:

http://www.libpng.org/pub/png/spec/1.2/PNG-Contents.html
http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html

Specifically, DPI is encoded into the PNG file in the pHYs data chunk, as a 
pair of 4-byte unsigned integers representing pixels per unit along each 
axis, followed by a single byte specifying the unit of measure (note the only 
supported unit is meter, not inch).

http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.pHYs


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] No paint dynamics available blocks tool from drawing?

[Richard Gitschlag]

Really tempted to file this in the bugtracker but I'm going to ask here first.

Current situation:  None of my painting tools actually work.  Every time I try 
to use them, GIMP 2.8.4's statusbar tells me No paint dynamics available.

It's an easy thing to fix locally, and I will be doing that in a moment.  But 
to investigate this a little

Background:
This is partly my own doing, since I went to GIMP's Folder preferences and 
removed the entry for the default Dynamics folder (because I absolutely need 
dynamics to be adjustable on the fly, and the defaults are currently not).  My 
various tool options (as checked via external text editor) mostly reference 
(dynamics Pressure Opacity), which is one of the defaults.  Two tools in 
particular (Paintbrush and Pencil) currently reference (dynamics Dynamics 
Off), also one of the defaults.  Of course, since I de-listed that folder from 
my GIMP preferences, those references are no longer valid.

However, to test this a bit further I temporarily renamed my (per-user) 
Dynamics folder and restarted GIMP, effectively causing GIMP to load with 
precisely zero brush dynamics available whatsoever.  As a direct result of this 
action, none of GIMP's painting tools work.
At all.

So to get to the point:  Why can't GIMP just assume that invalid dynamics 
reference == 'dynamics off'  ?  It can still raise a message in the statusbar, 
but please at least let the tool actually function in the meantime.  Why should 
it need need an external file (Dynamics Off.gdyn) to tell it no dynamics 
please when this can just be assumed implicitly?

And is this something to file in the bugtracker?  If it is I will.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Setting up a win32 compiler [was: Cutting the bloat out of .GDYN files]

[Richard Gitschlag]

From: ccurt...@gmail.com
Date: Fri, 5 Apr 2013 23:27:23 -0400
Subject: Re: [Gimp-developer] Cutting the bloat out of .GDYN files
To: strata_ran...@hotmail.com
CC: gimp-developer-list@gnome.org

On Fri, Apr 5, 2013 at 11:08 PM, Richard Gitschlag strata_ran...@hotmail.com 
wrote:






How easy is it to set up a compiler for GIMP's source on a win32 platform 
again? http://partha.com/articles/groundwork.html



?---

A related question:  is it possible to compile GIMP for win32 from inside an 
IDE (such as MSVC) ?



-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] updating the raw images import to handle partial images

[Richard Allen]

Hi,

Currently(2.9.1), if I open a 'Raw image', and have happened to scroll
past the end of the file, when I try to open it, I'm presented with a
white bitmap( and I see 'fread failed' in the console if I have it
open).

I'd like to change this in the following ways:
A)gimp will import as many pixels file disk as possible, and fill
the remaining pixels with the background of the import preview
B)gimp should directly tell the user if this goes wrong -
currently a user without a console just gets a white image.

I'm happy to implement these, and wanted to check if there was any
guidance on the specifics before I started.

-Richard
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] updating the raw images import preview background

[Richard Allen]

Hi,

Currently(2.9.1) the raw image preview(where one sets
width/height/bitpacking) has a white background. I find this confusing
under two circumstances:
A)Opening a raw bitmap where image border is light(here I'm unsure
where the right edge is)
B)Opening a raw bitmap where the end of the bitmap is not
delineated(here I'm unusre where the bottom is).

I suggest either:
Adding a border delineating the right and bottom edges
Drawing a checkerboard pattern on the background

I'm happy to implement one of these, but wanted to check if there was
any guidance on the specifics before I started.

-Richard
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp gradients

[Richard Gitschlag]

 Date: Wed, 13 Mar 2013 09:18:10 -0300
 From: gwid...@mpc.com.br
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] gimp gradients
 
 To all people complaining about how hard it is today to edit a gradient -
 The most usable way I have to edit gradients in GIMP is actually quite hidden:
 try drag and dropping colors from the color selector into the gradient
 editing window.
 
 What would be  a nightmare of segment splitting, selecting
 left-hand-color-type-of-segment , and so on, is suddenly past!
 
   js
  --
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Dragging and dropping a color onto the gradient editor's preview area adds a 
node at that position with that color.  It IS useful behavior when you are 
initially setting up a gradient, but not when you are tweaking the parameters 
later on.

On the other hand, dragging and dropping a color onto a gradient node handle 
paints both sides of that node that color.  Which is definitely quite useful 
behavior - it does avoid the issue of GIMP not treating node colors as 
contiguous by default (it should, really!) .

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp gradients

[Richard Gitschlag]

 Date: Sun, 10 Mar 2013 13:14:14 -0300
 From: gespert...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] gimp gradients
 
 El 10/03/13 11:10, rafał rush escribió:
  Hi
  Gradients in gimp are very very painful thing. I love gimp and i used it
  a lot but gradients are nightmare. I see that you are making new tools
  and other stuff but the most important thing and the thing that all
  graphic designers using all the time is gradient. To make simple
  gradient i must do hundred clicks. Gradient window is weird and
  difficult for new user. Are you planing make gradient tool more user
  friendly?
 
 A nightmare, a pain? I can agree that editing the endpoints is not as 
 straightforward as it should, but adding stops requires only to drag and 
 drop colors on the gradient editor.
 
 How exactly would you do it more user friendly? Probably in the future 
 when a gradient is a GEGL node the tool could be extended to allow th 
 edit the stops on canvas making the gradient editor almost unnecessary, 
 but right now it's not possible since you have to define the gradient 
 before applying it, and once you did it it becomes pixels.
 
 The gradient editor could use some improvements, of course, but saying 
 it's a painful thing, a nightmare and stating that you have to do 
 hundred clicks is an unnecessary exaggeration.
 Why don't you try describing the parts you think are more problematic 
 and propose how to do it better?
 
 Gez
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I have a mixed opinion about this.  For starters, actually painting the 
gradient is a simple task - make a selection (when/as desired), switch to the 
Gradient tool, then click and drag, and the only flaw in this system is the 
inability to define gradient length for shaped gradients (you still have to 
click AND drag to initiate the painting, but the drag length has no effect on 
shaped gradients.  It would be tons easier to, say, create a simple gradient 
border if you could define the length).

I also agree that editing a custom gradient can be both difficult and annoying. 
 

1 - The gradient editor is segment-based, not node-based.  While I agree that 
some functions (e.g. blending mode and handle) are inherently segment-oriented 
while others (endpoint type/color) are node-oriented, I find it generally 
counter-intuitive.

2 - Making node colors contiguous - the same color on both sides - is not the 
default behavior, when it should be.  (Most gradients utilize contiguous node 
colors anyway.)  Currently you have to manually click the neighboring segment 
and select Load endpoint's color  from neighboring endpoint.  This very 
quickly becomes tedious on the end user.

3 - When using HSV segment blending, greys and whites are assumed to have a red 
hue, which can produce some weird results (because greys and whites technically 
don't have any hue whatsoever).

4 - I can't seem to find a way to make GIMP auto-generate a node's color based 
on its position between neighboring segments (and, where applicable, blending 
modes).  For example, if one segment of my custom gradient starts at 30% grey, 
the next one ends with 80% grey, and a node in the middle is positioned 40% 
away from the left end, the node's default color (based on linear blending) 
would be (40% of the way from 30% to 80%, aka...) 50% grey, but I can't find a 
way to make GIMP calculate and set this color automatically.

5 - I think the context menus for setting the endpoint colors could use some 
tweaking.  Currently they say:
- Color Type 
- - Fixed
- - Foreground
- - Foreground (Transparent)
- - Background
- - Background (Transparent)
- Endpoint's Color  (loads color selector)

Perhaps they could say instead:
- Endpoint's Color 
- - Fixed color...  (loads color selector)
- - Use Foreground
- - Use Foreground (Transparent)
- - Use Background
- - Use Background (Transparent)

6 - And while we're on the subject, it would be nice if GIMP could define 
colors for each endpoint/node in RGBA terms (like Inkscape does) instead of 
just RGB.  But that's probably a bit more intensive

However, I have to disagree that painting a simple gradient is anywhere near 
painful - the two most common gradients I actually paint with are FG to BG 
and FG to Transparent because they don't use predefined colors.  The only 
problem with these gradients is the inability to adjust their handles (which is 
not unique to gradients, all resource types - especially brush dynamics - have 
the same problem).

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org

Re: [Gimp-developer] gimp gradients

[Richard Gitschlag]

BTW, this is my personal usecase scenario where editing a gradient in GIMP was 
unexpectedly a painful thing:

I was trying to create a sepia-like gradient -- a gradient that fades from 
black to sepia (for simplicity, let's just say RGB #804000) to white.  Y'know, 
something I can just Gradient Map onto a grayscale image later on.

This poses several challenges:

1 - Because the endpoints are black and white, any blend between those 
endpoints will only ever produce a greyscale gradient.  This applies in both 
RGB and HSV space (black and white by definition have saturation=0).  Therefore 
I require a node in the middle to specify the desired color.

2 - Because I will be tweaking or changing the color to suit my tastes (there's 
a specific image I'm trying to match), and this gradient is contiguous, I 
constantly have to tell GIMP to Load endpoint's color from  neighboring 
endpoint every time I make the slightest tweak to the node's color.  This 
doubles the number of steps I have to perform just to set one color -- but as a 
small optimization, I can simply tell GIMP to use my foreground color in the 
meantime.  The only problem with doing that, though, is once I'm finished 
tweaking the color I have to set the color type (and remember, on both sides) 
back to fixed before I save the gradient and quit GIMP.

3 - My chosen RGB tone doesn't exactly carry the same luminance as a 50% grey, 
does it?  So I need to apply the equivalent of a midtones/gamma adjustment to 
it.  I set each segment to Curved blending, drag this node to the left, 
brightening the overall appearance of the gradient

4 - But I see another problem - the midpoints between nodes (white handles) 
don't move in  proportion to the overall length of their segment.  So I have to 
adjust them too.  Now instead of just manually positioning one handle, I now 
have to manually position three.

5 - And because this gradient should approximate a curved blend, I can't just 
re-center the handles in their respective segment - if my middle node is 40% 
from the left, each segment's midpoint also has to be 40% from their left 
endpoint too.

6 - And did I mention that I'm alternating between tweaking both the color and 
position as I go along?

7 - Cue banging of head against the keyboard in frustration and having to undo 
whatever steps GIMP may have interpreted those keystrokes as.  (Oh, wait, the 
Gradient Editor doesn't even have its own undo system -- cue banging of head 
against monitor)

Now in some alternate universe where editing gradients is done solely on a 
conceptual level, I could have just:

a - Specified the starting color (RGB black) in HSL values of:  hue = 30°, 
saturation = 100%, luminosity = 0%.
b - Specified the ending color (RGB white) in HSL values of:  hue = 30°, 
saturation = 100%, luminosity = 100%.
c - Assigned HSL color mode to the segment.  (midpoint of segment becomes:  hue 
30°, saturation = 100%, luminosity = 50%, a.k.a. RGB #804000)
d - Specified Curved blending on the segment and adjust the midpoint until I 
get the desired result.
e - Done!

Yeah, that would be nice

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] now: project ideas, was: unified transform tool

[Richard Gitschlag]

 Date: Thu, 28 Feb 2013 11:16:28 -0500
 From: l.elle.st...@gmail.com
 To: pe...@mmiworks.net
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] now: project ideas, was: unified transform tool
 
 One thing I wish Gimp had is a better eyedropper tool for checking
 color values. That is the one thing, practially the only thing, that
 PhotoShop had (and presumably still has) that I wish Gimp had. The
 PhotoShop eyedropper tool simultaneously showed RGB, CMYK, and LAB
 values, at user-settable 8-bit, 16-bit, and 32-bit floating point
 precision. Right now if I want to find a LAB value for a color I have
 to export the image and open it with CinePaint or Krita.

Speaking of LAB, GIMP can decompose an image into LAB layers but (1) the LAB 
decomp has problems with gamma encoding and (2) it's not something you can 
simply eyedrop whenever you want to.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] unified transform tool

[Richard Gitschlag]

 Date: Fri, 22 Feb 2013 18:07:35 -0300
 From: freewande...@rocketmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] unified transform tool
 
 Well, that's something that was puzzling my mind: How an icon for 
 unified transform would look like? I was even trying it out as an art 
 exercise :) If it showed all of the arrows that its related to - scale, 
 rotate, etc. the icon would be a mess. A clever solution for this will 
 be a good art example, I think!
 

Speaking of looks, when I saw the design mockup for what the tool overlay may 
look like (http://gui.gimp.org/index.php/Image:No_parallel.png) and what 
regions you click on to do what kind of transform - my first immediate 
impression was too many handles!  Recipe for misclicks, especially the way 
scale and perspective handles are inset/outset on the same corners.  I'm 
personally partial to Inkscape's method of displaying transform handles - 
simply click on the selection repeatedly and it cycles through which set of 
handles (scaling, shear/rotate) it shows the user.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Selection lost while working on multiple images (GTK #694060)

[Richard Gitschlag]

 Subject: Re: [Gimp-developer] Selection lost while working on multiple images 
 (GTK #694060)
 From: mi...@gimp.org
 To: gespert...@gmail.com
 CC: strata_ran...@hotmail.com; gimp-developer-list@gnome.org
 Date: Tue, 19 Feb 2013 19:37:32 +0100
 
 On Tue, 2013-02-19 at 14:22 -0300, gespert...@gmail.com wrote:
  2013/2/19 Richard Gitschlag strata_ran...@hotmail.com
  
So the question that remains is - if you switch between images and do
   another select with the same tool, why does GIMP need to Undo the first 
   one
   at all?  It's got to be a bug.
  
  
  No doubt it is a bug.
  
  According to the documentation:
  When an image is stored as an XCF file, the file encodes nearly everything
  there is to know about the image: the pixel data for each of the layers,
  the current selection, additional channels if there are any, paths if there
  are any, and guides. The most important thing that is *not* saved in an XCF
  file is the undo history.
  
  The XCF format stores selections, so I think it's pretty clear that every
  file should have its own selections and switching between open images
  shouldn't destroy them.
 
 This is all totally unrelated to the actual bug here, so was the entire
 thread.
 
 The bug is that rect and ellipse select are modifying the selection
 on the fly, and abuse the undo system to do their stuff.

 Aborting the current tool operation when switching images is however
 completely normal and is not going to change, sorry.
 
 --mitch

I totally understand this when it comes to selectors that require multiple 
steps to complete one operation (e.g: Freehand, Foreground, and Scissors) - if 
you don't provide all the necessary information then of course it must abort 
its operation.

But not all selectors belong to that group.  Floodfill (fuzzy/by color) 
selectors are different - one click, one action, tool's done.  Rectangle and 
Ellipse selectors are different too - one click+drag and the shape is already 
there in your image's selection channel (and undo history) - there is nothing 
to abort.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Selection lost while working on multiple images (GTK #694060)

[Richard Gitschlag]

 Date: Sun, 17 Feb 2013 21:12:22 +0100
 From: kolbjo...@stuestoel.no
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Selection lost while working on multiple 
 images. Missing feature or bug?
 
 Den 17.02.2013 20:22, skreiv Tobias Oelgarte:
  Hello,
 
  I open two images in Gimp 2.8.4 and create an selection (for example 
  rectangle selection) for the first image. If i now switch to the 
  second image and do an selection as well, then the selection on the 
  first image is gone if i switch back. Is this intentional or a bug? 
  From the user perspective it would be nice to have independent 
  selections for individual images/documents.

 I do not know whether it is intentional or not but I guess it is.
 As long as you are able to resize the first selection it is in fact not 
 created. The selecting tool is engaged making the selection. Trying to 
 create another selection will therefore close the former attempt.
 
 If the selection is finished it is another task. The tool is ready for 
 another job.
 Try: Create a selection in image one. Click another tool in the toolbox. 
 Then move to image two, activate the selection tool again and create a 
 new selection. The selection in image one is still there.

I just discovered something interesting -- REALLY interesting.

1 - Create any two convenient images.
2 - Make a Rectangle selection on the first image.
3 - Look at the image's Edit menu.  Obviously, it says Undo Rectangle Select 
and (can't redo).
3 - Make a Rectangle selection on the second image.
4 - Go back to image 1 and check your Edit menu again.  Now it says (can't 
undo) and Redo Rectangle Select.

Why can't you Undo the first selection anymore and where did this Redo 
entry suddenly come from?  Your selection didn't just vanish - it got UNDONE.  
All you have to do is Redo it, and you get your selection back (minus the 
handles) in a heartbeat!

This is actually quite instructive -- it implies that whenever you adjust a 
rectangle or ellipse selection via handles, what GIMP does internally is Undo 
the selector action from its old position and then re-apply it at the new 
location.  (Which is corroborated by another observation - create a Rectangle 
select, adjust it via handles, then Undo it.  Instead of returning to the 
selection's previous size/position, as would be the case with separate Undo 
steps, the rectangle disappears in a single step!)

So the question that remains is - if you switch between images and do another 
select with the same tool, why does GIMP need to Undo the first one at all?  
It's got to be a bug.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Selection lost while working on multiple images. Missing feature or bug?

[Richard Gitschlag]

 Date: Sun, 17 Feb 2013 21:12:22 +0100
 From: kolbjo...@stuestoel.no
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Selection lost while working on multiple 
 images. Missing feature or bug?
 
 Den 17.02.2013 20:22, skreiv Tobias Oelgarte:
  Hello,
 
  I open two images in Gimp 2.8.4 and create an selection (for example 
  rectangle selection) for the first image. If i now switch to the 
  second image and do an selection as well, then the selection on the 
  first image is gone if i switch back. Is this intentional or a bug? 
  From the user perspective it would be nice to have independent 
  selections for individual images/documents.

 I do not know whether it is intentional or not but I guess it is.
 As long as you are able to resize the first selection it is in fact not 
 created. The selecting tool is engaged making the selection. Trying to 
 create another selection will therefore close the former attempt.
 
 If the selection is finished it is another task. The tool is ready for 
 another job.
 Try: Create a selection in image one. Click another tool in the toolbox. 
 Then move to image two, activate the selection tool again and create a 
 new selection. The selection in image one is still there.

Then shouldn't the selector commit to the first image before getting itself 
engaged on the second?  Current behavior is that it aborts the first 
selection, which is NOT desirable behavior.

Do this:

1 - On any convenient image, create a selection.  Note the asterisk that 
appears in the title bar (image dirty).
2 - Try to close the image and GIMP will prompt to save changes.  Cancel.
3 - Toggle QuickMask to view the selection channel.

Notice that as of step 2, even though the selector is still engaged it is 
treated as a change to the image status (because changing a selection channel 
does this).

Now do this:

0 - Create any two convenient images.
1 - Create a selection on image 1.  Note the asterisk in the title bar (image 
dirty)
2 - Try to close the image and GIMP will prompt to save changes (cancel this).
3 - Go directly to image 2 and create a selection.
4 - Notice how (in multiwindow mode) the asterisk disappears from the title bar 
on image 1.
5 - Close image 1.  This time, Gimp does NOT prompt to save changes like it did 
in step 2.

That is totally a bug, but it gets even better.  Replace step 5 with something 
stupid (like a Hurl noise filter) and notice how it affects the whole image 
instead of only the area selected in step 1 (which, as step 2 verified, WAS 
present).

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Minor enhancements in the export dialog

[Richard Gitschlag]

 Date: Wed, 5 Dec 2012 00:31:06 -0300
 From: gespert...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Minor enhancements in the export dialog
 
 I'm adding an extra item to the list:
 I also had several of reports about people choosing the file filter 
 dropdown (in the export dialog) by mistake, thinking it was the format 
 selector.
 
 A label saying show only: or something like that could help.
 
 Also the widget is too prominent and it drags your attention to it 
 before the file format selector, which is usually more important than 
 the file filter dropdown.
 
 Gez

In comparison, win32's native dialog box combines the two dropdowns - 
there's only the file format selector and it automatically filters the 
list by whatever you select.  (If you want to filter it otherwise, you 
just enter the appropriate *.whatever as a filename)

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Minor enhancements in the export dialog

[Richard Gitschlag]

 Date: Sun, 25 Nov 2012 19:55:26 +0200
 From: alexiade...@gmail.com
 To: gespert...@gmail.com
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Minor enhancements in the export dialog
 
 Current order in git is for format AFAIK:
 1. last export of this image
 2. imported extension
 3. last export of any image
 4. png
 

So then the issue is that out of that priority chain none of steps 1 thru 3 are 
saved between GIMP sessions.  (Okay, step 1 and 2 can't, as they're 
image-specific, but step 3...) If you simply start GIMP up and select the 
Export command, the default extension is PNG when that may not be desired.  And 
the suggestion is for a slightly expanded priority chain:

1 - Last export of current image
2 - Extension of current imported image
3 - Last export of any image
4 - User preferences setting
5 - PNG if all else fails


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Save/export, option to go back to old behaviour

[Richard Gitschlag]

 Date: Fri, 16 Nov 2012 18:50:33 +0400
 From: alexandre.prokoud...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Save/export, option to go back to old behaviour
 
 This has been discussed a dozen of times. One of these days I'll
 really finish the new FAQ so that we could prevent yet another I'm
 not here to reignite the discussion about the new save/export
 behaviour, don't worry. :-) thread.
 

Yeah,
 this topic really does need a highly-visible FAQ entry.  Preferably 
something that mentions / links to the user-developed alternatives (like
 the plugin and fork).


 From: r...@alum.mit.edu
 To: alexiade...@gmail.com
 Date: Fri, 16 Nov 2012 11:33:58 -0500
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Save/export, option to go back to old behaviour
 
 On Fri, 16 Nov 2012 17:20:47 +0200, Alexia Death wrote:
  On Fri, Nov 16, 2012 at 5:14 PM, Matthew Miller mat...@mattdm.org wrote:
  To run with this analogy: the problem is when you *frequently* need
  something that is more than nano provides. In the specific case of Gimp, I
  don't think there's anything else that offers layers, curves, and a healing
  brush. I use those things all the time in quick JPEG editing. (The layers
  only temporarily, of course -- I'll be looking forward to adjustment layers
  when that work is done.)
 
  If we had a whole toolbox of photo editing tools at our disposal in Linux,
  I'd be less sad.
 
  There is quite a lot. Darktable and Digikam integrated editor both
  offer most of this(I thin latest digikam even had some healing) and
  are the breadknives of this workflow. Both can directly load RAW too,
  afaik
 
 Actually, that's the problem -- there *are* so many editors, and each
 one has a different interface and different limitations.  I much prefer
 to just use one editor that has all the capabilities I need.
 

To reference the scalpel-vs-breadknife analogy that was brought up, can I just 
add three words?

Swiss.
Army.
Knife.

Sure, there are many tools out there whose efficiency derives from their 
specialization to a dedicated task -- but sometimes the user wants something 
that is competent on a variety of multiple tasks, if only because it's less 
stuff for them to lug around all the time and manage.

For example, I don't know about your usecases for one of these, but when I pull 
out my Victorinox 90% of the time it's because I need either a flatblade 
screwdriver or pair of scissors (which are no doubt more efficient for the 
task, but would require three or four times the pocketspace to be lugging 
around all the time, or a separate trip to the toolbox).  As for the remaining 
10% when I actually do need a knifeblade?  It's because I'm trying to open some 
stupid plastic-shell packaging -- you know, the type of stuff that not even a 
nuclear bomb can open otherwise.

So it's not a perfect tool for every job, but it is an acceptable tool for many 
jobs, and especially for jobs that might otherwise require constantly switching 
between 3-5 different, separate tools every few minutes to get done.

And while I'm on the subject, before trying GIMP (2.2) for my first time, my 
image 
editing apps basically amounted to MS Paint.  My dad had an image editor
 called iPhoto Plus from back in the Windows 3.x days which had TWAIN 
scanner access, levels adjustment and scaling/rotating/shear with linear
 resampling but its painting tools were barely any better than MSP.  During the 
Windows
 95 days I found a lightweight program called LView Pro (which has since gone 
trial/timerware, I think) that could input
 and output almost every file format of the day (barring animated GIF), 
but its editing features were otherwise far less than iPhoto and it basically 
lacked any editing capability beyond global 
image adjustments, many of which weren't that useful for me to begin with 
(though one exception was a YCC-based luma inversion called Negative!, which 
I found 
highly interesting).  
So GIMP had effectively the functionality of all those three apps, and 
more (like support for animated GIFs).

 Date: Fri, 16 Nov 2012 09:58:44 -0500
 From: nicolas.robid...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Save/export, option to go back to old behaviour
 
 If such an option ever sees the light of day, I think the button should 
 show a poison symbol (skull and crossbones).

 .or should it be a swastika?
 
 :)
 
 -

Oh, a Mr. Godwin called while you were out, said something about suspending 
your debate license? 

;)


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] bad link on http://developer.gimp.org/bugs.html

[Richard Allen]

From
http://developer.gimp.org/bugs.html

the weekly summary link doesn't work.

-Richard
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] gimp 2.8 export, after save as keeps old files name

[Richard Gitschlag]

I'm going to direct this to the gimp-developer mailing list instead of just 
gimp-user for further explanation.

What is the method by which GIMP decides the default filename in the Export 
dialog?

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


 Date: Wed, 3 Oct 2012 13:38:03 +0200
 From: for...@gimpusers.com
 To: gimp-user-l...@gnome.org
 CC: t...@gimpusers.com
 Subject: [Gimp-user] gimp 2.8 export, after save as keeps old files name
 
 Hello again, does anyone have interest to solve this problem? How can i 
 communicate with gimp developers, is writing on this forum not the proper way 
 to ask something about gimp?
 I think it is senseless to keep old file name for export after saving as your 
 image with different name?
 
  Date: Wed, 19 Sep 2012 03:48:15 +0200
  From: for...@gimpusers.com
  To: gimp-user-l...@gnome.org
  CC: t...@gimpusers.com
  Subject: [Gimp-user] gimp 2.8 export, after save as keeps old files name
  
 
  Hello, i have a question, when i open a new file and export it with 
 ctrl+e, the gimp 2.8 exports the file with the current file name as 
 expected but after i save  (with save as)  file with a new file name, 
 ctrl+e exports the new file with the old file name, and i think it has 
 to be changed, because it is an absolutely new file and it is senseless 
 to keep the old file name for exporting the new file... 
  Is this a bug or did developers do this feature intentionally?
  
  -- 
  realbezo (via gimpusers.com)
  ___
  gimp-user-list mailing list
  gimp-user-l...@gnome.org
  https://mail.gnome.org/mailman/listinfo/gimp-user-list
 
 More specifically:
 
 1 - Open any convenient (non XCF) image file.  E.g. filename.png
 2 - Access the Export command.  The default filename shown is 
 filename.png (e.g. whatever the source filename was).
 3 - Access the Save As command.  The default filename shown here is 
 filename.xcf.
 4 - Save the image as an XCF but with a different filename, e.g. 
 filename.different.xcf .
 5 - Access the Export command again.  The default filename is now 
 filename.different.png, not filename.png.
 
 Why is that?
 
 -- Stratadrake
 strata_ran...@hotmail.com
 
 Numbers may not lie, but neither do they tell the whole truth.
 
 Yes, this what i tried to ask. We create a new file with save as and it 
 keeps exporting with the old file name and overwrites file exported before, 
 this doesn't make sense to me.
 
 
 -- 
 realbezo (via gimpusers.com)
 ___
 gimp-user-list mailing list
 gimp-user-l...@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-user-list
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Can I use textures made in GIMP for a project such as a game?

[Richard Allen]

What about images like the gimp pepper?
On Sep 28, 2012 3:57 PM, drawoc dra...@darkrefraction.com wrote:

 Go ahead! Any images that you make using the clouds generator, or
 other similar filters are entirely your property, so feel free to do
 what you want with them.

 (If you wanted to use the source code of the filter, then that would
 be a different story, but just using the images is fine.)

 P.S. note that IANAL.

   -- drawoc

 On Fri, Sep 28, 2012 at 1:45 PM, Joe r madcat2...@gmail.com wrote:
  Hi,
 
  Can I use textures that I make in GIMP, such as the using the cloud
 effect
  to make a grass texture, in a game that would be sold? The texture would
 be
  made without any photographs, would it still be ok to sell them with a
 game
  (The textures would be a part of the game)
 
  Many thanks.
 
  ___
  gimp-developer-list mailing list
  gimp-developer-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gimp-developer-list
 
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Library of image test-files?

[Richard Allen]

Is there a library of test-images for gimp? I'm working on one of the
file-loaders and didn't have source material on-hand to test. Is this
something we should add?

-Richard
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP bug with RGB565 images and raw loader

[Richard Allen]

https://bugzilla.gnome.org/show_bug.cgi?id=673315

A patch is posted to fix this by splitting 'RGB565' into
'RGB565-BigEndian' and 'RGB565-LittleEndian'.

Another patch adds BGR565(both endians), which I've dealt with in
embedded system a few times, so I'd love to have it supported by gimp
directly ( although I suppose I could load it with RGB565 and swap the
channels later)

-Richard

On Sun, Mar 11, 2012 at 3:34 PM, Richard Allen rsa...@gmail.com wrote:
 Hello,

 Suspected Bug:
 I think I've found a bug when loading raw RGB565 data. If you load it on a
 big-endian machine, it produces garbled output. If you load it on a
 little-endian machine it works fine. If you swap the bytes in the file by
 hand, it appears to work fine. The bug is located in several places in
 source-root/plugins/common/file-raw.c.

 Proposed Fix:
 I think what we need is two modes - RGB565-LittleEndian(enum mode:
 RAW_RGB565LE), and RGB565-BigEndian(enum mode: RAW_RGB565BE). This would of
 course, require another menu entry and possibly a translated string.

 What I would like to do about it:
 If this sounds good to the group, I'll happily cook up the required patches,
 and test images.

 Why it affects me:
 As an embedded developer, sometimes we use screens that are the opposite
 endianness of the display. For newer ARM devices with rev16 support, this
 isn't much of an issue, but I still like to use GIMP to check our bitmap
 packer and sometimes our firmware images.

 You guys are awesome:
 Thank you for writing GIMP.

 -Richard Allen
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] [Request] Do not confirm closing if unsaved image was exported/overwrited ?

[Richard Gitschlag]

No.  GIGO applies here - GIMP assumes that the state of the image when you hit 
Save is exactly what you want to be saved to disk, so that's precisely what it 
does.  In cases where it's not (such as with resizing the whole image) GIMP has 
no way to tell know better.

However, a resize-during-export could make an interesting feature request

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


 Date: Sun, 16 Sep 2012 08:58:20 -0700
 From: w...@ieee.org
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] [Gimp-user] [Request] Do not confirm closing if 
 unsaved image was exported/overwrited ?
 
 This sounds to me like a bug - possibly a specification error?
 
 Certainly adds some possibly useful context to the longlasting (and 
 unfortunately overly acrimonious) dispute about the save-export behavior in 
 2.8.
 
 In my experience, it is extremely difficult to apprehend all the varieties of 
 ways people like to use complex tools, especially in a world environment 
 enamored with the famous Steve Jobs aphorism - things should 'just work' - 
 and 
 adapting - even when necessary - is uncomfortable, and often painful.
 
-- Burnie
 
 On 09/16/2012 08:10 AM, Richard Gitschlag wrote:
 
   From: l...@holoweb.net
   To: ofn...@laposte.net
   Date: Sat, 15 Sep 2012 20:23:36 -0400
   CC: gimp-user-l...@gnome.org
   Subject: Re: [Gimp-user] [Request] Do not confirm closing if unsaved 
   image 
  was exported/overwrited ?
  
   On Sat, 2012-09-15 at 23:12 +0200, Ofnuts wrote:
[...] saving as XCF
by accident may make you lose some time, but will never make you lose
data, because you can always save the JPG again from the XCF.
  
   This isn't always true.
  
   For example, after working on a photograph I scale it down e.g. to 600
   pixels across, and export a jpeg. If at that point I save the xcf file,
   I will lose data, because xcf does not store the undo history.
  
   Yes, I could use ImageMagick to scale the image, but (1) I do want to
   see the jpeg preview, as it often needs some extra work in curves or
   sharpen, and (2) I'm already in gimp :)
  
   Liam
  
   --
   Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
   Pictures from old books: http://fromoldbooks.org/
   Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
  
   ___
   gimp-user-list mailing list
   gimp-user-l...@gnome.org
   https://mail.gnome.org/mailman/listinfo/gimp-user-list
 
  That is unfortunately true, GIMP has no ability to automatically scale-down 
  the image to a different size as part of the export process.  When you hit 
  Save GIMP records everything necessary to recreate the image *as it was 
  when 
  you hit Save*, whether it is the preferred way of storing your overall 
  project 
  file or not.  The XCF is not a full version repository logging everything 
  that 
  happened to the image since its creation - I imagine that should be the 
  role 
  of an XCF subformat so that the user has per-file control over whether or 
  not 
  they need that extra information taking up extra hard drive space.
 
  -- Stratadrake
  strata_ran...@hotmail.com
  
  Numbers may not lie, but neither do they tell the whole truth.
 
 
 
  ___
  gimp-user-list mailing list
  gimp-user-l...@gnome.org
  https://mail.gnome.org/mailman/listinfo/gimp-user-list
 
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gimp suggestions and maybe a bug

[Richard Gitschlag]

 Date: Sun, 9 Sep 2012 02:11:38 -0700
 From: m351...@rtrtr.com
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Gimp suggestions and maybe a bug
 
 Hello , leave suggestions for the good Gimp
 
 - when save/export a photo that have exif/iptc/xmp tags if we save/export to
 formats that do not support tags is useful open a warning window that notify
 this situation every time to user for default (optionally deselectable from
 settings), tell something like this warning: your photo/file have .. Tags
 but your selected saving format do not support tags, all tags will be lose.
 if you overwrite your file all tags are erased

It can be safely assumed that when you export to a standard file format you can 
be expected to know something about what kind of metadata that file format does 
or does not support.  This is not like JPG's lossy compression where we can 
safely assume that if you're exporting back to the same file you will be 
degrading the image quality.  So I don't see an issue here, and adding back a 
warning about only potential loss of metadata (most of which is non-essential 
to the interpretation of stored image pixels anyway) does more harm than good.

 - extend preserve write exif/iptc/xmp tags support to TIFF format (and/or
 another lossless format). 
 Tiff already support exif/iptc/xmp tags, for example Xnview preserve/write
 tags on tiff (but probably also other free tools). maybe ask xnview
 developer if want donate tiff writing code and contribute with gimp :)
 For professional/advanced use It's really important have tags preservation
 in at least one lossless format (tiff, xcf, or another), for use it for
 multiple editings without have quality loss, or without need use every time
 exiftool for rewrite tags.

Last I heard, the problem with TIFF metadata is that GIMP's TIFF loader doesn't 
actually inform GIMP about unrecognized metadata tags in the file that could be 
lost if the user exports back to the same target.  It only loads the image 
pixel data and any metadata it supports, other file tags are effectively 
removed and there's little to no way (at present) to change this behavior.  


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Shape layers for GIMP?

[Richard Gitschlag]

 Date: Sat, 8 Sep 2012 11:34:00 +0100
 From: ad...@game-point.net
 To: gimp-developer-list@gnome.org; gegl-developer-l...@gnome.org
 Subject: [Gimp-developer] Shape layers for GIMP?
 
 I've looked around and it looks like GIMP doesn't have anything like 
 Photoshop's shape layers.  Shape layers are really cool because they're 
 a path tied to a normal layer whose purpose is simply to ummask that 
 normal layer.  Photoshop then gives you a live preview of what that 
 unmasked layer looks like when the path is closed, and automatically 
 updates that preview as you edit the path's nodes.  In addition, 
 Photoshop offers the option to apply layer effects live (updated each 
 time you edit the nodes in the shape layer's path).
 
 Although you can do this in GIMP, you have to do it all manually (create 
 path, convert to selection, fill selection) so it's much slower and it 
 isn't a live preview.  Are there any plans to introduce something like 
 this for GIMP?

There's a slightly faster manual way:  Stroke the path onto a layer mask, this 
keeps the shape of the layer separate from its actual content.  True, you 
still have no live preview (you have to fill inside/outside of selection with 
0% and 100% to set the mask) linked to a path object, but it's non-destructive 
to the layer's constituent pixels.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Shape layers for GIMP?

[Richard Gitschlag]

 Date: Sat, 8 Sep 2012 19:02:53 +0100
 From: ad...@game-point.net
 To: strata_ran...@hotmail.com
 CC: gimp-developer-list@gnome.org; gegl-developer-l...@gnome.org
 Subject: Re: [Gimp-developer] Shape layers for GIMP?
 
 On 08/09/2012 18:29, Richard Gitschlag wrote:
  There's a slightly faster manual way: Stroke the path onto a layer mask,
  this keeps the shape of the layer separate from its actual content.
  True, you still have no live preview (you have to fill inside/outside of
  selection with 0% and 100% to set the mask) linked to a path object, but
  it's non-destructive to the layer's constituent pixels.
 
 Destroying the constituent pixels isn't really what's taking up the 
 time.  What's taking up the time is going through the following process:
 
 1. Delete previous applied effects layers.
 2. Modify path.
 3. Convert path to selection.
 4. Fill selection with colour.
 5. Apply inner shadow to layer.
 6. Apply inner glow to layer.
 7. Apply gradient to layer.
 8. [etc...]
 
 With a shape layer, assuming it had been set up already with the desired 
 effects, the above steps would change to the following:
 
 1. Modify path.
 
 -- 
 Best regards,
 Jeremy Morton (Jez)

Then the issue here is not with shaped layers itself, but layer 
post-processing effects in general.  From those steps I assume you're telling 
Photoshop that the shadow and glow are live effects that Photoshop applies 
for you automatically, and re-applies whenever you change the path source.  
GIMP indeed can not do that and probably won't be able to for some time.

Otherwise, the fastest GIMP steps I can come up for managing a layer clipping 
path are this:

1 - Create desired path shape.
2 - Path to selection.
3 - Add layer mask, initialized with selection.

Then if/when you need to change the layer shape, you simply:

1 - Modify path object.
2 - Same path to selection.
3 - Delete layer mask.
4 - Add layer mask, initialized with selection.

This does not include other effects, of course, only the layer shape itself.

(And perhaps we really need a command to reinitialize the layer mask.  I spot 
no easy way of telling GIMP to copy from selection mask channel to layer mask 
channel...)

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] File - Page Setup missing in 2.8, why it matters

[Richard Gitschlag]

 From: oleca...@gmail.com
 Date: Sun, 5 Aug 2012 19:28:12 +0200
 Subject: Re: [Gimp-developer] File - Page Setup missing in 2.8, why it 
 matters
 To: strata_ran...@hotmail.com
 CC: gimp-developer-list@gnome.org
 
  1 - Unable to specify Landscape orientation.
 
 Second tab of the Print dialog.

Shall we compare screenshots then?  Attached is all I have at my disposal:

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  attachment: gimp-print-settings-280.png___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] File - Page Setup missing in 2.8, why it matters

[Richard Gitschlag]

From: blender3dart...@gmail.com
Date: Mon, 6 Aug 2012 11:22:47 -0400
CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] File - Page Setup missing in 2.8,  why it 
matters

Ey, don't bring Macs into this, we're doing just fine.

On Mon, Aug 6, 2012 at 11:04 AM, Alexandre Prokoudine 
alexandre.prokoud...@gmail.com wrote:


On Mon, Aug 6, 2012 at 6:57 PM, Richard Gitschlag wrote:



  1 - Unable to specify Landscape orientation.



 Second tab of the Print dialog.



 Shall we compare screenshots then?



Shall we compare operating systems then? :)



Works just fine on Linux. Could be anything on Windows and Mac.



Alexandre Prokoudine

http://libregraphicsworld.org

___

gimp-developer-list mailing list

gimp-developer-list@gnome.org

https://mail.gnome.org/mailman/listinfo/gimp-developer-list



So it really is specific to Windows GIMP, then.  That's as informative as it is 
unfortunate.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Fedback and personal comments about Gimp 2.8

[Richard Gitschlag]

 I.2. Two-faced sliders, usability
 
 I have nothing against coarse and fine grain tuning for brush sizes but the
 sizes I generally work with (i.e. 1-100px) (and I'm sure I'm not the only 
 one) confine the usable range to 1-10% of the whole slider area!
I agree that the current slider behavior is rather strange and, even after you 
realize and get used to how it works, it's very difficult to make fine 
adjustments to brush size, small brush sizes very especially.  Here's my two 
Abe Lincolns for the pot:

1 - If you click within a few pixels of the slider's current setting, this 
ALWAYS means fine-grain tuning relative to the current value (matches current 
behavior on lower half of slider).
2 - Click anywhere else within the slider range always results in coarse tuning 
across the slider's whole range. (matches current behavior on upper half of 
slider).

(This behavior logic is very comparable to a standard scroll bar, where 
clicking on the position nub yields fine adjustments while clicking on the 
margin yields coarse adjustments.)

Also, fine grain should be defined as a percentage of the current brush size. 
 Currently it is not, which makes it impossible to make very fine adjustments 
to very small brush sizes.  Say 1% of the current value (current defined as 
prior to drag operation start, not the actual current value) per pixel 
moved; e.g. a 50-pixel drag translates to a 50% increase or decrease.  Brush 
size 1 = increments of 0.01 .  Brush size 50 = increments of 0.5 .  After all, 
0.01 increments for a brush that is a few hundred pixels wide won't even make a 
visible difference, but vice versa, 5/10 increments for a brush that is only 
1-2 pixels wide is NOT fine grain control.

In the meantime, at least the spinbutton part of the slider works.

 II.1. Brush dynamics, usability and friendliness
 
 I have no idea why, all of the brush dynamics in Gimp 2.8 cannot be 
 changed. I need to create a custom dynamics and use it whenever I need to 
 change the dynamics parameters... Wait a minute: so you're now telling us 
 *all* we need to do is clone a dynamics preset and edit that? And we 
 just need to delete it when done? Why not reboot the computer twice while 
 we're at inventing oddities?

I also mentioned this issue in a previous discussion.  With GIMP 2.8 making 
brush dynamics into their own resource, you lose the ability to make 
impromptu edits to mapping matrix or pressure curves and more often than not 
this is a Bad Thing for the end user.

Although it really is more of a design flaw than a bug, IMHO this is NOT 
something we should have to wait for 2.10 to see addressed - 2.10 may be 
another 3-5 years in the future and some users will not be able to endure the 
current behavior until then ('Mayan apocalypse' permitting).  I would love to 
see a quick hack on the matter included in some 2.8.x patch, and much better 
sooner than later.  (Like a certain meat sauce: yes, it's that important.)

I also use Alexia's current workaround.  I have one -- just ONE -- custom brush 
dynamics (named Adjustable), exclusively for the purpose of being able to 
make impromptu, seat-of-your-pants changes to the mapping matrix or pressure 
curves.  And if I want to make copies, I can duplicate that.  In fact, I think 
I'm going to go remove the default dynamics folder from my GIMP preferences 
right now.  I never used them anyway ... I really do have almost zero need to 
map pen pressure to tool opacity.

 My suggestion: make *all* of those dynamics preset editable! Just like 
 Gimp 2.6. And I honestly don't give a damn whether they store my 
 modifications or forget them as soon as I quit Gimp. I just don't want to 
 battle each time I need to get around a new feature that's been placed in 
 my way!

One of the alternatives I suggested in the previous discussion was exactly 
this.  In detail:
1 - Do not lock controls on the Dynamics editor.
2 - EVER.
3 - Add a button to revert the current dynamics back to their saved values on 
disk.
4 - If you try to save dynamics to a readonly preset, GIMP instead duplicates 
it and saves that instead.  The readonly file (as required) remains unchanged.

 III.1. Tablet-specifics, Pen/Eraser consistency
 
 First thing I noticed in 2.8 is that I now need to select the eraser tool 
 when I flip my pen to use the eraser. I didn't have to do that in 2.6.

This may be a WORKSFORME issue, because my GIMP 2.8 properly associates (in my 
case) Paintbrush with pen tip and Eraser with eraser tip, no extra clicks 
required.  Provided GTK actually detects the tablet (see bug #549839) during 
GIMP startup ... if GIMP doesn't actually detect the tablet, then it won't know 
that there actually are pen and eraser tips available.  Check your Device 
Status tab and if it only lists Core Pointer, that is your problem (try 
restarting GIMP).


 Tablets tend to slip a micron during clicks and that registers to GTK
 as a drag. Not much we can do about it. Isn't GTK's minimum drag 

Re: [Gimp-developer] What about switching from Gtk+ to Qt

[Richard Gitschlag]

 Date: Fri, 3 Aug 2012 22:23:27 -0700
 From: phorg...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] What about switching from Gtk+ to Qt
 
 On 07/29/2012 05:17 AM, Mukund Sivaraman wrote:
  On Sun, Jul 29, 2012 at 02:51:44PM +0300, Shlomi Fish wrote:
  Do we need to change to CMake?  Nobody has given
  reasons so far, just assumed that we'd like to switch to CMake.  It
  would substitute one hell for another.
  Well, I have given many reasons here:
 
  http://www.shlomifish.org/open-source/anti/autohell/
 
  You should have followed and read the link.


 When I see terms like autohell I assume it's flame baiting and don't
 read it.  I don't have time for un-civility.  If someone can't make a
 point without using an ad-hominem attack I automatically assume they
 have no real point.
 
 Patrick
 

I'm not sure it's (technically) ad hominem, but you're right that the epithet 
sounds more like flamebait than actual discussion.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.  
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Multiply blend mode in GIMP

[Richard Gitschlag]

Date: Mon, 9 Jul 2012 21:21:46 +0200
From: calculemus1...@gmail.com
To: gimp-developer-list@gnome.org
Subject: [Gimp-developer] Multiply blend mode in GIMP

I am reading this: docs.gimp.org/en/gimp-concepts-layer-modes.html

and I wonder why is the formula for Multiply, E = (M * I) / 255?


Why divide with 255, that is the part that confuses me.
Should it not be just M * I and then clamp the result in range 0 to 255?

Thanks


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list


Other people have answered it already, but an alternate way of looking at the 
Multiply formula is:



E = M * (I / 255)
...or...
E = (M/255) * I



Where M (the multiply layer) values are expressed in a 0...255 range, 
therefore, (M/255) yields a 0-1.0 percentage and that is exactly the behavior 
we need.

The documentation could probably be phrased just a little better.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Merge Save a Copy with Export As [was: Ditch the Save a Copy command (really)]‏

[Richard Gitschlag]

Date: Sat, 23 Jun 2012 16:06:47 -0400
Subject: Re: [Gimp-developer] Ditch the Save a Copy command (really)
From: ccurt...@gmail.com
To: pe...@mmiworks.net
CC: strata_ran...@hotmail.com; gimp-developer-list@gnome.org

That Save does not lose information seems natural, but that Export must 
lose information seems contrived.

Chris---

I agree.  To the end user, whether or not Export loses any information is 
different with each and every image.  A single-layer image with no transparency 
and no metadata (paths, masks, EXIF, color profile, etc.) can be safely written 
to over a dozen assorted image formats with nothing of value lost.  Yes, JPG is 
lossy and GIF is inherently indexed, but the target user knows that already, 
they'll pick a file format appropriate for what they need.

Out of curiosity, I tried typing an XCF file into the Export dialog yesterday 
and got that non-negotiable warning that GIMP won't let you do that.  Um ... 
why?  I see no practical reason why the Export command should be prohibited 
from outputting an XCF file to disk when it already outputs every other image 
format GIMP has any support for.


 Date: Sun, 24 Jun 2012 13:23:48 +0200
 From: tobias.oelga...@googlemail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Merge Save a Copy with Export As [was: 
 Ditch the Save a Copy command (really)]
 
 I personally never use save a copy. I just use save as and append a 
 new version number to the document. If i look at Blender then they did 
 go even a step further. There are small nice buttons + and - to 
 increase/decrease the version number without typing.
--- 

I am also the type to use a versioned file naming scheme (kinda), every time 
I would want to Save a Copy of my project I actually just hit Save As and 
increment my filename - the previous filename is never touched again and 
automatically becomes the backup copy.  So yes, reason number four would be 
that my personal workflow has no use for Save a Copy either.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP 2.8 less productive than GIMP 2.6 (too many dialogue boxes)

[Richard Gitschlag]

Date: Thu, 21 Jun 2012 06:05:07 -0700
From: doodoodee...@yahoo.com
To: gimp-developer-list@gnome.org
Subject: [Gimp-developer] GIMP 2.8 less productive than GIMP 2.6 (too many  
dialogue boxes)

---
To: GIMP devs and users

Having recently made the upgrade to GIMP 2.8, it's immediately obvious to me as 
a long time user that GIMP is now a far less productive application. Some 
aspects that I find particularly obtrusive:

- The Export vs Save implementation: this alone already made me go back to 
2.6, at least until this feature is made optional or removed from GIMP 
altogether. Previously, all I had to do to save an image in any desired format 
after editing it, was to use Save as exactly as I would in any other program; 
now I have to go through multiple dialogue windows and manually select the same 
options ALL THE TIME (such as the dreadful Do Not write colour space 
information for BMPs), since they aren't assumed by GIMP for future 
operations. Even
 something that should be as simple as a quick modification followed by a 
CTRL+S to overwrite the same image in its own native format has become an 
headache.



I'm not particularly fond of the save/export distinction ... in its current 
form.  I can agree that the distinction is generally a positive one, as in, 
used correctly there are decidedly fewer dialogues to wade through for writing 
a non-XCF file to disk than there were in 2.6.

BUT I think there are some minor things that completely ruin productivity for 
certain styles of workflow.  For example, the fact that Export (Ctrl+E) and 
Overwrite (no default shortcut) are two separate commands.  I believe this is 
a horrible design decision when the only pertinent difference between them is 
whether or not the current image session originated from a non-XCF file.

If I'm creating a single-layer composition and choose to store it on disk as a 
PNG.  Okay, so Save is intended for XCF now, use Export instead, that is a bit 
of a speed-bump but the Export commands are on the same menu and they even have 
similar keyboard shortcuts set up.  Ctrl+E it is, first it asks me for a 
filename (just as the Save command would with a new file), but subsequent uses 
just writes the file to disk in a single keystroke with no further prompts 
(also just like the Save command would do with an XCF).

That is, UNTIL I come back later in a new GIMP session.  Now it is considered 
an 'imported' image, so the 'Export' is replaced by 'Overwrite', and I have no 
keyboard shortcut for writing changes back to the file NQA.  If I hit Ctrl+E 
(which for some reason still remains invokable) I have to go through all the 
usual Export prompts as if I've never exported the file before, but including a 
new prompt asking whether to overwrite the existing file.  THIS is the real 
productivity-killer.

It is not GIMP's place to judge the merits of its user's individual workflow.  
It is GIMP's job to do what they tell it to do, to the best of its ability 
(i.e. within the scope of its design vision).  I always viewed GIMP as being 
able to accommodate a wide variety of different workflows ... is that now 
saying that GIMP has a multiple-personality disorder?  I think not.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Ditch the Save a Copy command (really)

[Richard Gitschlag]

 Subject: Re: [Gimp-developer] Ditch the Save a Copy command (really)
 From: pe...@mmiworks.net
 Date: Sat, 23 Jun 2012 00:50:33 +0200
 CC: gimp-developer-list@gnome.org
 To: strata_ran...@hotmail.com
 
 Richard Gitschlag wrote:
 
  Seriously -- I propose that the Save a Copy... command should be removed 
  and its functionality merged into the Export As... command.
 
 seriously... how can you write that? when the core of the discussion
 (that you are actively following) is that Save does export anymore, and 
 Export does not save.
 
 --ps
 

Save a copy does not save either.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bring back normal handling of other file formats

[Richard Gitschlag]

 From: pe...@mmiworks.net
 Date: Wed, 20 Jun 2012 17:58:33 +0200
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Bring back normal handling of other file
 formats
 
 Richard Gitschlag wrote:
 
  So if I may throw an echo into the room and ask why the particular message 
  box CAN NOT provide a yes/no prompt, with Yes transferring control to the 
  Export box and No cancelling back to the Save dialog?
 
 as I said before: no trip through Save if it is not safe.
 it is simply not allowed to ‘feel’ safe. seriously.

 in the long run (and that is how I am thinking) going cold turkey
 on this, with no fudges, is in the best interest of users.
 
 no gotchas.
 no fudging.

Except for the cold-turkey part, I disagree.

But thanks for the answer, I must've missed it in all the discussion.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bring back normal handling of other file formats

[Richard Gitschlag]

Now I remembered what I wanted to say earlier.  I can't remember in response to 
whom exactly, but here goes.

Save must record everything that is part of the document; that is the law.

That law also works in reverse.

If you write to a file format that cannot support everything in the 
open image (i.e. any format but XCF), this means the open image contains
 still-unsaved elements, and thus, the image as a whole is still dirty.  In 
GIMP 2.6, the only situation in which you lost work by saving a file as a 
non-XCF is if you saved and quit without saving an XCF copy in the meantime.  
It is not the saving vs. export that resulted in loss of work, it was GIMP 
wiping the image state clean again regardless of whether or not everything in 
the open image was stored on disk.

Consider what happens in 2.6 if an image is first saved as XCF, some changes 
are made, then saved as a PNG.
If you Save A Copy... as PNG, then:
- current image still associated with the XCF file, not the PNG
- current image still dirty.
- GIMP asks to save changes to the associated (XCF) file

But if you Save As... PNG, then:
- current image becomes associated with the PNG file
- current image marked clean
- GIMP does not ask to save changes
- Even if GIMP does, it saves changes to the PNG file, not the XCF

And it is easy to see how this can become a problem.

In 2.8, an image's clean/dirty state is decided only in respect to saving as an 
XCF.  If you saved an XCF then quit, everything's good, no lost work, XCF 
contains everything (even the current selection!).  If you export and quit, 
whether you're losing any work that couldn't be written to the desired file 
format is on your head alone, GIMP is not responsible for that, but GIMP asks 
anyway just to be on the safe side, because only by saving as an XCF can it be 
guaranteed that absolutely nothing in the current session will be lost if the 
image is closed.

So if we evaluate the (improbable) hypothesis where the Save and Export 
functionality is expressed using a single set of menu commands (as in 2.6), it 
should also hold true that (as in 2.8) only saving as an XCF will clean the 
image state.  If you save to a non-XCF file and quit, the image is still dirty 
and GIMP must still ask whether to save changes.  In XCF.  Only XCF is 
guaranteed to save all data.
But this creates a logical inconsistency where if the Save filepicker appears 
in the context of selecting it from the menu you can select any format (as in 
2.6) but if it appears in the context of a close/quit prompt the only format 
available is XCF?

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bring back normal handling of other file formats

[Richard Gitschlag]

 Date: Wed, 20 Jun 2012 09:22:43 +1000
 From: grae...@argyllcms.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Bring back normal handling of other file
 formats
 
 Simon Budig wrote:
  This discussion really boils down to a matter of taste and there are
  arguments for both ways. Unfortunately in your case you're taste weighs
  less than the taste of Peter to the developers.
 
 If it was purely taste, I wouldn't bother commenting.
 It's a lack of logic though - just because there are
 situations where loss of information that the user values
 can occur, doesn't mean that every situation is like that.
 
  Sorry, sometimes we can't make it right for everyone.
 
 And that's my point - it could be made right for everyone.
 
 Graeme Gill.
 ___
 gimp-developer-list mailing list

Agree wholeheartedly.  There are parties on both sides of the debate, and we 
certainly know which side's opinions have (pun totally intended) more volume.

The (as someone so pithily phrased it) Ha ha ha - No way am I letting you do 
that manner in which GIMP informs you of the Save/Export distinction can be 
anything from merely harmless to downright offensive, depending on your 
individual workflow (and peculiar temperament).

So if I may throw an echo into the room and ask why the particular message box 
CAN NOT provide a yes/no prompt, with Yes transferring control to the Export 
box and No cancelling back to the Save dialog?

- It could be maybe three lines of program code and one string resource, tops
- It would NOT in any manner affect users who do a lot of XCF work and/or 
prefer the new save/export model in any manner.  They're not likely to get the 
distinction mixed up.
- It would accommodate users who have difficulty adjusting to the save/export 
distinction, reducing the number of extra clicks by up to three.

What is there that makes this not desirable?

As an analogue:  If I typed a word like hotmali into Google, the search 
engine has no reason to assume that maybe I was trying to type hotmail 
instead and got my keys mixed up by mistake.  But it does.  Its keyword 
database knows that this could be a plausible misspelling of a much more 
popular search query, so it searches for the more popular term but also 
discloses that it did so (with an option to search for the keyword as 
originally spelled, in the case that actually was what I wanted).

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Richard Allen]

 As a software developer, I see parallels within Integrated Development
 Environments. Gimp exporting to a lossly format is akin to building
 software. Gimp saving is akin to saving the project and source files back
 to disk. If my IDE ever let me save the compiled binary without updating
 the project/makefile(s)/sources or a big warning that it was going to do
 so, that would be bad.


 So I see this the same situation applied to Gimp.

 For people doing minor edits or simple rescaling (my use case), maybe it
 makes things a little more complicated. For someone who has put a week of
 work into a video game box cover, that would be terrible.


 One idea would be similar to IDEs - the XCF is the source, and
 JPEG/PNG/thumbnails are the output. The export button effectively becomes
 'build' then and generates everything you've listed.


-Richard
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bring back normal handling of other file formats

[Richard Gitschlag]

 Date: Thu, 14 Jun 2012 10:03:41 +0200
 From: g...@catking.net
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Bring back normal handling of other file formats
 [...]


 Gimp's inability to work with standard formats is becoming a major PITA.

 

 Perhaps gimp was not such a bad name for it after all, its functionality 

 is becoming crippled.




Ouch, that is an awesome pun.



IMHO, limiting Save to XCF only invariably sends the conceptual message that 
GIMP is 
no longer the GNU Image Manipulation Program -- it is now the GNU Image 
Making
 Program.

I still believe GIMP should, instead of merely informing the
 user that Save operates in XCF only, offer an export/save 
xcf/cancel option which would alleviate the need to go back and use a 
different dialog as a separate step.  (You never know if a user might actually 
WANT 
to save their GIMP file under a non-XCF filename)

I doubt that would 
violate the terms of the Save/Export spec that the dev team swears by.



-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.



  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bring back normal handling of other file formats

[Richard Gitschlag]

 Date: Thu, 14 Jun 2012 10:03:41 +0200
 From: g...@catking.net
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Bring back normal handling of other file formats
 
 AT this point, I often need to check the resulting file size.
 
 If I go to Image | Properties I find the file name and file size empty. 
 Ah-ha! it has not been saved yet. Of course if I had saved it I 
 would just be seeing the size of the bloated xcf not the of the file I 
 am trying to work with.




BTW, I was going to post this to Bugzilla but I cannot actually duplicate the 
behavior in my GIMP 2.8 .



- Import image - Image Properties = shows imported filename/size

- new image - save XCF - Image Properties = shows XCF filename/size

- new image - export - Image Properties = shows exported filename/size




-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.



  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bring back normal save

[Richard Gitschlag]

 Date: Wed, 13 Jun 2012 19:21:47 -0400
 From: ke...@ve3syb.ca
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Bring back normal save
 
 On 12-06-06 12:21 PM, � wrote:
  Btw, why can we open a JPG but not save a JPG, if we export to
  JPG should we than not has import JPG files to keep the logic?
 
 That does seem like an inconsistency at first but a lot of other programs 
 just use open for other file formats they can read instead of import.
 

The term Import also has the connotation of adding another file into the 
current document, instead of opening it as a completely new document entirely.  
GIMP's command for that purpose is Open Image As (new layer/etc.) .

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

[Richard Gitschlag]

 Date: Mon, 4 Jun 2012 20:48:40 +0200
 From: gfx.u...@online.de
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] feature: Set exclusive layer visibility within 
 groups
 
 Hi,
 
 I posted descriptions of the current behaviour and the proposals in the 
 wiki. Now it's on you ;-)
 
 Best regards,
 
 grafxuser

I cannot seem to register a username on the wiki (or edit the page without 
one).  The Login / create account message only shows the Login panel, not 
showing the registration panel.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Incorrect Hue-Saturation results in obscure cases

[Richard Gitschlag]

 Date: Mon, 4 Jun 2012 09:43:39 -0300
 Subject: Re: [Gimp-developer] Incorrect Hue-Saturation results in obscure 
 cases
 From: gwid...@mpc.com.br
 To: strata_ran...@hotmail.com
 CC: gimp-developer-list@gnome.org
 
 Hi Richard --
 
 Could you open a bug report at bugzi...@gimp.org about this issue, and
 attach the example images ?

Already filed as bug #644032 and as a comment on #527085.  Example screenshot 
is attached to the first one:

http://bugzilla-attachments.gnome.org/attachment.cgi?id=215132

And the second case was specifically introduced by the way #527085 got patched, 
which is why I didn't file it as a new bug (yet).  I haven't taken a screenshot 
of it, but I can do that pretty easily.

I've attached a patch that implements the reworked algebra (interpolate first, 
then map to pixel), but I cannot actually test to verify if it works as I do 
not have an installed C compiler at this time. :(  But it should fix both 
issues if it works.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


   js
  --
 
 On 3 June 2012 17:30, Richard Gitschlag strata_ran...@hotmail.com wrote:
  (Apologies if this is a duplicate post; I tried sending it the other day but
  it didn't seem to go through)
 
  I've found some obscure conditions under which the Hue-Saturation tool
  produces incorrect results up to and including current 2.8.0 .
 
  The first one I encountered in the wild sometime in 2.6:  I had recently
  finished a pencil drawing and scanned it into an image file, but the pink
  areas of the drawing were not a warm enough shade for my preference.  At the
  time I felt the easiest method to fix this was via Hue-Saturation tool, so I
  went to the tool, slid the Overlap to 100%, then adjusted the Magenta hue by
  about +10º.  (I chose the Magenta range instead of Red because the image
  also contained colors in the red/orange region, and I didn't want them
  affected.)  Suddenly my pink pixels were now magenta and blue!  As if GIMP
  was calculating it around the wrong side of the HSV wheel, but that was
  apparently reported, patched and fixed four years ago (bug #527085) so the
  explanation can't be that simple.
 
  I've also found another condition that, while it's so improbable a user
  might never encounter it in the wild, it is still incorrect:
 
  - Adjust the Cyan channel hue by +100º ( - Magenta/blue)
  - Adjust the Blue channel hue by -100º ( - Cyan/green)
  - Set Overlap to 100%
 
  So if a hue falls between Cyan and Blue ranges, it should get mapped to a
  Magenta - Blue - Cyan - Green range, right?
  But instead, GIMP maps them to a Magenta - Red - Yellow - Green range;
  here it IS going the wrong way around the circle.
 
  This is because of the way GIMP calculates the hue adjustment:
 
  mapped_primary_hue = (input_hue + primary_hue_adjustment)
  mapped_secondary_hue = (input_hue + secondary_hue_adjustment)
  ...
  final_hue = (mapped_primary_hue * primary_intensity) + (mapped_secondary_hue
  * secondary_intensity)
 
  A.k.a. it maps both ranges independently then interpolates the result
  between them.  Meanwhile, GIMP ensures that mapped_primary_hue and
  mapped_secondary_hue are kept inside the (0.0 - 1.0) range, and if there is
  more than a 180º difference between them, GIMP wraps mapped_secondary_hue
  again to yield a shortest circle route.  This is correct 99% of the time,
  but in the above case, it fails because there's a 200º difference between
  mapped_primary_hue and mapped_secondary_hue (regardless of the actual input
  value or master hue adjustement); GIMP assumes it is going the wrong way
  around the HSV circle when it actually isn't (the actual difference between
  blue and cyan after these adjustments is 140º, not 200º).
 
  Another testcase to confirm why it's a bug:
  - Cyan hue +90
  - Blue hue -90
  Result: Correct (overlap fades from magenta/blue - cyan/green).
 
  - Cyan hue +91
  - Blue hue -91
  Result:  Incorrect (overlap fades from blue/magenta - red - yellow -
  green/cyan)
 
  Who knew a humble 2º made such difference?  The patch that fixed #527085
  cannot tell whether a difference of  180º is due to crossing the
  red/magenta wraparound or if that was deliberate on the part of the user.
  (And it's not the tool's job to question whether the user's adjustments are
  sane.)
 
  I can submit a patch for this that may fix the issue permanently - but let
  me know if my algebra is correct first:
 
  Given that:
   mapped_primary_hue = input_hue + (master_hue_adjustment +
  primary_hue_adjustment)
   mapped_secondary_hue = input_hue + (master_hue_adjustment +
  secondary_hue_adjustment)
   (primary_intensity + secondary_intensity) = 1
 
  And:
   final_hue = mapped_primary_hue * primary_intensity + mapped_secondary_hue *
  secondary_intensity
 
  THEN:
   final_hue = (input_hue + master_hue_adjusment + primary_hue_adjusment) *
  primary_intensity + (input_hue + master_hue_adjusment

Re: [Gimp-developer] Export issues

[Richard Gitschlag]

 Date: Sun, 27 May 2012 17:28:53 +0200
 From: lis...@jesusda.com
 To: gimp-developer-list@gnome.org
 Subject: [Gimp-developer] Export issues
 
 Another issue appears when open a JPG image, edit it and close.
 Instead of saving the image using the same original formt and 
 parameters, Gimp try to SAVE as XCF. If I want to SAVE, be sure I will 
 clic SAVE. If I clic close (without saving) is cause I want to save the 
 image exactly as I load it.

Unfortunately that is the whole point of the distinction - Save is
 now intended strictly for XCF.  Me, I would like to see an option where
 instead of just displaying a message to use Export for non-XCF 
formats that message box should have Export / Cancel buttons to make 
the transition easier.

This does, of course, mean that Exporting as a non-XCF file no longer 
resets the saved state of the image.  GIMP will now constantly ask you 
to Save changes? if you haven't saved an XCF copy (even in workflows 
where there is no need to have one) of the image.


And you do know JPG to JPG in general is not a good workflow to be using due to 
it being a non pixel perfect (lossy) compression?  (Okay, if part of your 
workflow involves resizing it to a smaller resolution then this alleviates the 
matter - I do it a lot myself.)

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [enhancement] Improved layer-visibility icons

[Richard Gitschlag]

Whoops, had a suspicion I was forgetting something on my previous message.

Attached is another mockup illustrating some improved(?) eye icons.

- Right column shows what the icon would look like with the slash trimmed 3px 
from each end.
- Second row has the slash lightened by 50% (now grey instead of black), but 
the rest of the icon is unchanged.
- Bottom row has the entire icon lightened by 50%.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  attachment: GIMP-layer-visibility-icons-2.png___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

[Richard Gitschlag]

 Date: Sat, 26 May 2012 11:21:35 +0200
 From: gfx.u...@online.de
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] feature: Set exclusive layer visibility within 
 groups
 
 It's a bit hard to understand what you mean exactly in your further 
 writing. Can you write down a state chain, please?
 

Give an example?  Sure.  Let's say I have an image with the following layer 
tree:

* - G1
* - - L1
* - - G2
* - - - L2
* - - - L3
* - L4

* - G3
* - - L5
* - - L6


If I Shift+Click on L3, GIMP should toggle between all items and ONLY item 
L3.  Specifically:
1 - The path to the clicked item in this case is G1 - G2 - L3.  Therefore, 
G1, G2, and L3 shall all be made visible.
2 - All direct siblings to any of G1, G2, or L3 shall be made non-visible.  
This means:
3a - On the top level, G1's siblings are L4 and G3.  L4 and G3 shall be hidden.
3b - G2 has one sibling: L1.  L1 shall be hidden.
3c - L3 has one sibling: L2.  L2 shall be hidden.
4 - L5 and L6, the descendants of G3, are not relevant and shall not be 
affected -- we already hid G3 and that is sufficient.
5 - L3 is now the only visible item in the entire image.
6 - If I Shift+Click again, steps 2 and 3 are repeated, but with siblings made 
visible.


Or say I Shift+Click on G2, GIMP should toggle between all items and ONLY 
item G2:
1 - The path in this case is just G1 - G2.  Even though G2 is a group 
containing child items (L2 and L3), those items are NOT of interest right now 
because I am acting on G2 as a whole.
2 - G1 and G2 shall both be made visible.
3 - Any siblings to G1 or G2 shall be made hidden:
3a - L4 and G3 are siblings to G1; they shall be hidden.
3b - L2 is sibling to G2; it shall be hidden.
4 - G2 is now the only visible item in the entire image.
5 - If I Shift+Click again, steps 2 and 3 are repeated, but with all siblings 
made visible.

Note what happens if I click on a top-level item, say, L4:
1 - The path is now simply L4.  L4 shall be the only item made visible.
2 - All direct siblings of L4 (G1 and G3) shall be made hidden.
3 - Any items inside G1 and G3 are NOT of interest and shall NOT be 
individually affected.
4 - L4 is now the only item actually visible in the entire image.
5 - If I Shift+Click again, repeat step 2 but with siblings made visible.

This last case neatly duplicates our current behavior in 2.8.0 by affecting 
only top-level layers.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.



  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Problems with brushes

[Richard Gitschlag]

 Date: Mon, 21 May 2012 20:12:09 +0200
 From: martin...@gmx.ch
 To: strata_ran...@hotmail.com
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Problems with brushes
 
 hi Richard
 
 The opacity problem (stroke opacity vs dab opacity) can be fixed
 mathematically.  Grep for OPAQUE_LINEARIZE in the mypaint source code.

The last time I reported it (bugzilla #588984) I was told Not A Bug but also 
discuss on mailing list.  I did not have access to said mailing list that 
time ago - but I do now.  So yes, let's.

If I set my tool to 50% opacity I want the visible end result of a single 
(non-overlapping) stroke to be 50% opacity.  Whether or not I have incremental 
mode enabled should make absolutely no difference in this context; it should 
only make a difference when parts of a stroke overlap or intersect each other 
(such as shading one area back-and-forth).

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] feature: Set exclusive layer visibility within groups

[Richard Gitschlag]

I have a little gripe about setting exclusive visibility (shift+click a 
layer's visibility icon) in an image.  Now that we have layer groups in GIMP 
2.8, it only functions on the top level of the layer stack -- it seems 
impossible to toggle exclusive visibility inside a group.

Since a layer group can itself be a complex combination of layers (apparently 
including other layer groups!), we should have some ability to toggle exclusive 
visibility with respect to other members in that group only.

For example, the current behavior could be expanded from a simple on/off toggle 
to an iterative loop somewhat like this:

1 - When toggling exclusive visibility, first note the full path from image 
root to the selected item (inclusively) and begin iterating through it.
2 - IF at any point along this path there are any visible sibling items, THEN 
hide them, leaving only the selected item visible, and break and return.
3 - Otherwise, if we have traversed the entire path without finding any visible 
siblings, then selected item is the only visible item in the whole image.  
(Whether the selected item is itself a layer or group is irrelevant.)  
Therefore, traverse the selected path again and ensure that any and all sibling 
items at any point along the path are made visible.

This would establish a toggle chain of all items - selected group - 
(subgroup, etc.) - selected item in group - all items.

It could also be reversed; all items - selected item in group - selected 
group - (parent group, etc.) - all items, but I'm not exactly sure how that 
logic would pan out.

Note that in the simple case of an image with no layer groups, this quickly 
reduces to the current behavior of all items - selected layer - all items.  
(This also applies when setting exclusive visibility on a top-level group, 
because in that case we DO want to act on the group as a whole).

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Problems with brushes

[Richard Gitschlag]

 From: oleca...@gmail.com
 Date: Sun, 20 May 2012 15:09:18 +0200
 To: gimp-werkst...@gmx.de
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Problems with brushes
 
  4. The mapping matrix for the dynamic settings of the bushes is not
  editable. How can I edit this map to use on my own brushes?
 
 You have to define a new paint dynamics. Use the second or third
 button in the bottom of the Paint Dynamics dockable dialog.

This is the biggest problem with making Brush Dynamics their own resource type, 
and from the end user's perspective, an unwanted regression compared to how 2.4 
through 2.6 allowed you to edit the mapping matrix at any time.  It's like if 
you went to the Curves dialog and loading a preset means you can't make further 
adjustments to fine-tune the graph.

In the meantime, make sure you have created one New brush dynamics resource 
even if it's solely for the ability to edit the matrix.

  6. The Gimp Tool Options  Smooth stroke and Incremental don't show any
  affect on the stroke of any brush. Do they only effect brushes using a
  tablet?
 
 Set the opacity of your brush to 50%, and try it with or without
 Incremental to see what it means.

Incremental means that every application of paint in a stroke layers on top 
of the previous one.  I recommend never using it outside special cases - most 
brushes have a spacing of 10-15% or so which means that any given pixel along 
the stroke area will end up 'painted' up to 5-7 times over.  Normally this is a 
moot point but with incremental option this means that the opacity will end up 
being applied 5-7 times over too -- you lose the ability to get a stroke with a 
predictable OVERALL opacity value (even an opacity setting of 10%, if 
incremental, yields an end result up to 40-50% opacity).  This is as 
technically correct as it is utterly undesirable, but it's a limitation in how 
GIMP handles painting actions internally so it's virtually impossible to fix.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails

[Richard Gitschlag]

 Date: Sat, 19 May 2012 00:18:56 +0300
 From: d...@shadowdrama.net
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Feature request: Improve the Open file dialog 
 thumbnails
 
 On 2012-05-18 23:45, Cristian Secară wrote:
  The Windows Inkscape version uses Windows native file open and save
  dialog, so some solution appears to exists already.
 
 It does use it, but that doesn't mean it works. Save as and export
 bitmap default to empty file names, not the current filename or a
 variation of it.



An application can request what filename is shown in the filepicker's 
text input field before calling it, so this may or may not be a bug.  (If it 
is, go to the Inkscape bugtracker and report it already!)  In Inkscape 0.48.2's 
case the 
default filename for the Save dialog appears to be drawing (the lack
 of an .svg extension is a moot point because Inkscape can and will append the 
extension associated with the selected filetype when necessary, which is 
standard and accepted behavior for pretty much all apps using the native win32 
filepicker) and the default filename for the Export dialog is bitmap.png 
when exporting an entire page/drawing/custom area, or (selection_id).png if 
exporting selected objects only.

Speaking of this, Inkscape saves the export name with the SVG file so you only 
have to name an export file once.



 Also files that have different extensions aren't visible in the view



Not only is this NOT a bug, but GIMP's filepicker works the exact same 
way.  Ever notice how the default setting for GIMP's filter is 
all Images and not all Files ?  You will never see, say, .TXT files 
listed in the Open/Save dialogs unless you specifically select a filter 
that allows them.



Also of interest, Win32 style shortcuts -- .lnk files -- are always 
shown in the native dialog whether they match the filetype filter or 
not, however it is the application's responsibility to tell the 
filepicker whether it's allowed to follow (dereference) them.  Otherwise
 they get treated like any ordinary file (and, obviously, neither GIMP nor 
Inkscape
 can load them).


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails

[Richard Gitschlag]

From my perspective, what kind of filepicker dialog an application uses goes a 
long way in making it look like a native app for its target platform.  
Allowing the Windows version of GIMP to incorporate the native Win32 
filepicker dialog would be a huge improvement at least in platform-specific 
aesthetics and user convenience -- if nothing else -- but functionally 
speaking it would also give GIMP the ability to follow Win32 style shortcuts 
(.lnk files), because that's part of the filepicker functionality.  And GIMP 
would still be able to customize the dialog box with a GIMP-specific thumbnail 
panel (which, as noted, more frequently skips generating a thumbnail than not) 
-- that is what you see in current versions of Inkscape's Win32 platform, 
Inkscape being another GTK+ app.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


Date: Fri, 18 May 2012 09:35:32 -0400
From: ccurt...@gmail.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Feature request: Improve the Open file dialog 
thumbnails

On Fri, May 18, 2012 at 9:01 AM, Jernej Simončič jer...@ena.si wrote:

Err, why? I find the Windows dialog boxes infinitely more usable than
GTK+'s (especially after the latest improvement with the Recent

list).

The GTK+ file chooser does seem to be horrible, and I'm not sure why.  Here's a 
usage scenario that continually drives me crazy in GIMP:
1) Create a new image
2) Select File-Save- The Save File dialog opens3) Navigate to the correct 
directory4) Type the filename to save
Expected result: The highlighted part of Untitled in Name: Untitled.xcf is 
replaced with what you type.

Actual result: The dialog assumes you want to destroy a file already in the 
directory and starts selecting from them until you type something that can't be 
completed using the files in the directory.  Then, another little window 
appears showing you what you're typing.  When you finish typing the name you 
want to save as and hit Enter, the dialog prompts you to overwrite the file 
that last matched what you were typing.

I'm not sure if the GTK+ file chooser really is this stupid, or if GIMP isn't 
setting some kind of save mode flag.
Chris


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list  
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gimp 2.8.0 - flawed export/overwrite behavior [was: Saving in .jpg or .png hmmmmm]

[Richard Gitschlag]

Going to split this because it really NEEDS some wider discussion.  There's no 
nice way of phrasing it - in the current GIMP this distinction is a total snafu.

 To: gimp-developer-list@gnome.org
 From: grosberg.mich...@gmail.com
 Date: Fri, 18 May 2012 06:45:22 +
 Subject: Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hm
 
 Here's the problem - overwrite only works once. Then it becomes export.
 And you can't assign the same keyboard shortcut to both.
 You'll have to assign two shortcuts, and remember to use one shortcut the
 first time, and the other shortcut the second, third etc.
 That is indeed a strange behavior - a command that only works once per file.
 
 Say what you will about save vs. export but this has to be fixed.
 

When I filed bug #675385 about the export/overwrite distinction the overall 
response was notabug, but Michael Natterer did also comment that:

 Michael Natterer


  [GIMP developer]







  2012-05-05 17:05:25 UTC
 There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu
 entry is hidden. I fixed that in git, it will be in 2.8.1.

Unfortunately this will only exacerbate the problem -- when all you need to do 
is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this 
means that your Ctrl+E will either work only once per image session (if 
assigned to file-overwrite) or not at all (if assigned to file-export).  In 
order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned 
to the third command.

But why should a third shortcut even be necessary in the first place?  This 
whole distinction between overwrite and export was fundamentally flawed 
from the start; there is no reason GIMP should need three functions to perform 
what are essentially only two commands:

- Export... - Analogous to the Save As command, but for non-XCF formats.  
Intended for first-time exports and other situations where you want to export 
an image to a different filename.  You are prompted for a filename and format 
options before it actually writes to file.
- Overwrite - Analogous to the Save command, but for non-XCF formats.  
Intended for exporting back to the original (non-XCF) file; whether or not 
there was a previous export within the current session is simply irrelevant.  
If the file was neither imported nor exported, then it will trade off to the 
Export... command (also analogous to the Save / Save As distinction).

Remember, at any time GIMP only displays two export options in its menu:  The 
first may be called Export to [filename] or Overwrite [filename] but 
regardless of whichever one is currently shown, it performs ultimately the same 
function:  Exporting back to the same non-XCF file with no questions asked.  
Why does there even need to be two different internal functions (file-export 
and file-overwrite) to handle this ONE behavior?


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] [feature] Merge Colormap Editor into Palette Editor?

[Richard Gitschlag]

Just today while toying around with GIMP 2.8.0-RC1 I noticed that whenever you 
have an indexed image open, its colormap appears at the top of GIMP's Palettes 
list as a virtual palette.

This is awesome.  I don't recall it being that way in 2.6, was it?

But there's one thing missing:  The virtual palette is treated as read-only, so 
in order to change anything on it you have to switch to the Colormap editor 
instead.  Can these two be merged at some point in the future?

E.g. if I'm editing indexed image A and my current palette is Colormap of 
Image A, then the Palette Editor should allow me to change its color entries 
(with the changes reflected in A's actual colormap).  On the other hand, if I'm 
currently working on indexed image B, the Colormap of Image B palette will be 
editable while the Colormap of Image A palette will act in a read-only manner.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Edge-sensitive painting?

[Richard Gitschlag]

 Date: Tue, 7 Feb 2012 12:27:47 -0600
 Subject: Re: [Gimp-developer] Edge-sensitive painting?
 From: cr33...@gmail.com
 To: strata_ran...@hotmail.com
 CC: gimp-developer-list@gnome.org
 
 On Tue, Feb 7, 2012 at 12:09 PM, Richard Gitschlag
 strata_ran...@hotmail.com wrote:
  Say for example that I am digitally coloring an inked linework (black lines,
  white background).
 
 1. Set blending mode on ink layer to multiply.
 2. Create new layer with white fill and move it below *below* ink layer.
 3. Paint on new layer.
 
 Does that not work?
 
 Chris

I'm already aware of how to use layer blending modes (etc.) for this purpose, 
thank you, but that's not what I was talking about.

One of the minor, but slightly annoying (and minor annoyances are always the 
worst) things about digitally inking underneath any outline layer is what 
happens when your brush strays very close to the lines you're inking inside of. 
 If your brush size is large enough to pass completely through that line onto 
the other side, or you just hit a bad stroke somewhere, then naturally the 
brush will end up painting (or as I phrased it, bleeding) onto both sides of 
the line, which you probably didn't want -- you have to take time cleaning it 
up later.

I've attached a simple JPG to supplement what I'm talking about - on the top 
half is your existing behavior where stray too close to a line and your brush 
will pass through underneath it and end up painting on both sides.  On the 
bottom half is the suggested edge-sensitive behavior, where as long as you 
remain on the same side of a line, the brush area stops at that line and does 
not pass through.

For an analogue, compare a simple coloring book to those toy-section fuzzy 
posters.  One requires a reasonably steady hand and conscious effort to remain 
within the lines; the other enforces it for you.

To be fair, there are other ways to achieve the desired end result (selection 
masks, etc.); but I'm suggesting, could it be possible as a checkable option in 
the actual painting tools themselves?

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


  attachment: gimp_painting_example.jpg___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Non-incremental painting

[Richard Gitschlag]

Cedric, the problem is that the only vibe your intiial post gave off is a this 
is wrong and a this is totally wrong.  You need to explain the problem in 
detail (e.g. provide a contrived scenario to demonstrate it) and then suggest 
(again, in detail) what the proper result should have be instead.  You did 
neither.

As for me, the one problem I have with the incremental tool option is that it 
does not mix with alpha-blending.  If I specify an opacity of  50% and use the 
incremental option, (due to the way GIMP internally processes brush strokes) 
the end result is brush strokes painted with 99% or so opacity because, with 
the default brush spacing of 15%, the pixels within the stroke area are 
receiving about 6 strokes of 'paint'.  Yes this is technically correct 
behavior, but the end result is neither correct nor intuitive (bug #588984) in 
the eyes of the end user.  This is less of an issue when you are painting with 
100% opacity to begin with, but it
 still means that fuzzy brushes end up with very hard edges because along the 
brush's edge those same pixels are getting painted several times over.


Non-incremental painting is at least intuitive:  The entire stroke receives a 
specified, uniform opacity (brush dynamics notwithstanding) and if you 
need to make multiple strokes over the same area then you can do so in, well, 
separate strokes.


I, too, would like to see an option where you can paint strokes that are of a 
predictable opacity (as non-incremental painting already does) but 
simultaneously allows them to overlap with previous strokes, a la Corel 
Painter.  But I'm at a loss, even conceptually, on how that could be done.

On a tangent, one trick I found with painting straight lines is that since you 
need to click to set a starting point before using the Shift modifier, if you 
Undo the initial click you can still use the Shift modifier to paint a straight 
line with a single stroke without that original poin being applied to the 
canvas.  This can be useful in some cases for single lines at a time

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


 Date: Sat, 28 Jan 2012 17:51:40 +0100
 From: man...@gmx.net
 To: alexandre.prokoud...@gmail.com
 CC: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] Non-incremental painting
 
 Mitch  Dude,
 
 I did not ask for your generousity. I reported this flaw on the
 bugtracker, was asked to bring it up on the list, did so, and, frankly,
 don't give a tiny bit about how emotionally sensitive you are over it.
 
 And if you are unable to discuss the point at hand and are only capable
 of returning insults, be my guest, but don't expect any response other
 than this because I've better things to do with my time than leading
 this kind of stupid argument.
 
 Anyone else willing to comment on the actual technical issue,
 irrespective of how arrogant I sound or how much my tone sucks, I'd
 welcome it.
 
 However, Michael is maintaining this list and politely asked me to
 leave, hence, I will only reply to you in private for not to offend him
 any further.
 
 On Sat, Jan 28, 2012 at 07:39:35PM +0400, Alexandre Prokoudine wrote:
  On Sat, Jan 28, 2012 at 6:33 PM, Cedric Sodhi wrote:
  
   If anyone can think of a usecase where that non-intuitive, unpredictable
   painting mode is actually useful, please prove me wrong.
  
   Until then, I interpret the mere existance of that painting mode as an
   excuse to not admit one of the most serious flaws in gimp with regard to
   painting.
  
   To be blunt, as long as there is no way for a painter to properly
   anticipate the color in which he draws unless he draws in short,
   non-self-overlapping strokes (which, admittedly, is typical for
   water-color et al), gimp may be a powerful graphics-editor but remains
   nothing but a toy for painting (and all efforts related to painting such
   as providing well-designed presets remain futile).
  
  Dude,
  
  Replacing lack of technical expertise with trolling doesn't work. Not
  everyone is as generous as las to spend two friggin hours explaining
  you how automation on MIDI events works, while facing your, frankly
  speaking, arrogant behaviour. The trick isn't going to work every
  time, and definitely not in GIMP lists.
  
  You are more than welcome to ask question and even question decisions,
  but don't expect everyone to just rush having a conversation with you.
  
  Alexandre Prokoudine
  http://libregraphicsworld.org
  ___
  gimp-developer-list mailing list
  gimp-developer-list@gnome.org
  http://mail.gnome.org/mailman/listinfo/gimp-developer-list
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gimp-developer-list
  ___

Re: [Gimp-developer] Luminosity in LAB does not agree with Wikipedia or Matlab

[Richard Gitschlag]

Date: Mon, 19 Dec 2011 08:52:39 +1030
From: 00a...@gmail.com
To: stecnico0...@hotmail.com
CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Luminosity in LAB does not agree with Wikipedia 
or Matlab

What
 you have not quite said, Richard, is that this adjustment is the one 
that you would need in order to correct linear RGB to standard sRGB -- 
so the output of GIMP is not gamma corrected. IMO this is correct, since
 gamma-correcting would introduce inaccuracies and also reduce precision
 (which in this case is already limited to 1/256.). The wikipedia images
 are based on converting the L to rgb by treating the AB channels as if 
they were zeroed. This produces an image that *looks* accurate but is 
mathematically inaccurate.

  

That is the part I was not sure about, but I erred on avoiding speculation and 
chose to just make observations as I came across them.

Out of curiosity I looked through the C source for the decompose plugin and 
noticed that the LAB decomp actually performs a cube root (and offset) of its 
input values during its calculations, which is why a linear input gradient 
produces a nonlinear result.

But as stated by the original poster this behavior is incompatible with the 
results produced by Adobe Photoshop or Matlab using their LAB color modes -- 
Wikipedia states that uniform changes in L*a*b* components should correspond 
to uniform changes in perceived color -- not the absolute color intensities, 
but its perception.  IMO, if you take a greyscale gradient that looks linear 
and uniform in GIMP's native RGB space and decompose it to LAB, the L channel 
should still look linear.

Perhaps there can be an additional L*a*b* color option added to the plugin that 
incorporates the gamma correction into its processing?  Performing it manually 
after the decomp does lose some quality in the color channels for obvious 
reasons, but if it could be included as part of the plugin's execution then it 
would not.


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.

  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] suggestion for new versions of GIMP

[Richard Gitschlag]

 Date: Sun, 27 Nov 2011 10:20:08 +0100
 From: tobias.oelga...@googlemail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] suggestion for new versions of GIMP
 
 Maybe the focus
for sliders should react the same way like the sliders in Blender
do? They don't steal the focus as long you don't really
 use it to enter a number/value.


More like, if you type something that the focused control doesn't fly as valid 
input, it automatically passes that keystroke event to the parent event 
handler.  So if your focus is on the slider's text box, number keys will input 
numbers to the box, other keys pass through and can be recognized as general 
shortcut keys.  (A long time ago when I toyed around with some VB6 I remember 
configuring one app to have the main form window handle all keypress events so 
I could make centralized, context-sensitive decisions about when a keypress was 
to be interpreted as text input or as a key shortcut)

This is one of my longstanding minor gripes about GIMP myself -- many of the 
keyboard shortcuts only work when the current Image window has focus, and if 
something else has snagged the focus then the user ends up doing a double-take 
as the shortcut doesn't appear to be working at all.

 Date: Sun, 27 Nov 2011 11:33:10 +0100
 From: thebod...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] suggestion for new versions of GIMP
 
 I think it's more a call for some specific defaults than for ability  to edit 
 keyboard shortcuts.

I can agree with that.  I have some preferred shortcuts of my own which are not 
the default in GIMP, but definitely work better for me personally.

 Don't take it as a challenge, but I was wondering for some time where
 these concepts really differ (from the user point of view).Non-destructive 
 Adjustment Layers, for one (not present as of 2.6, but planned and coming).  
 The last time I used a Photoshop it seemed like all color/brightness 
 adjustments could only be done via Layers, which was a major stumbling block 
 for me because I couldn't find any way to do those same adjustments directly 
 upon the layer.

 Date: Sun, 27 Nov 2011 14:35:04 +0100
 From: thebod...@gmail.com
 To: gimp-developer-list@gnome.org
 Subject: Re: [Gimp-developer] suggestion for new versions of GIMP
 
  I could easily write a blog post stating why I feel GIMP is in position

  to be a better program than photoshop for most people in ten years time.

  Summarised it would be:  It's focus is smaller and targetted to what

  counts,

 

 This narrow focus is a double edged blade. And, as for what counts 

 it's highly subjective matter.



Indeed, very much so.  I have to roll my eyes every time I hear the free 
software does not 'compete' with commercial software argument getting rolled 
out in a discussion because it does.  At least terms of its general 
capabilities because otherwise there is no reason for users to want the free 
option to begin with.  Even so, users also end up making squeaky wheel 
comparisons about the little subtleties that don't affect its overall 
capabilities, but nonetheless differ between products.

Like one thing I currently wish for:  Grouping the Brushes lists by 'brush 
family', very analogous to the idea of grouping fonts by font family.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.




  ___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list