Re: [Gimp-developer] Finding out what happens when compositing layers

2011-09-16 Thread David Gowers (kampu)
On Sat, Sep 17, 2011 at 8:36 AM, Ofnuts ofn...@laposte.net wrote:

 **
 On 09/16/2011 02:20 AM, David Gowers (kampu) wrote:

 In GEGL, the layer mode code is autogenerated from formula strings -- see
 operations/generated/math.rb

 The opacity behaviour is not documented there, but my understanding is that
 the alpha of the underlying composite is preserved, and opacity only effects
 how much of the layer's COLOR channels are applied (per the standard
 blending formula).

 On Fri, Sep 16, 2011 at 7:09 AM, Ofnuts ofn...@laposte.net wrote:

 I'll trying to find out what happens when a layer is in subtract mode
 with a global opacity not one or zero (i.e. what computations are done
 with the pixels values of the composite image of the layers below, the
 pixel values of the layer, and the general opacity). I have a git
 extract of the Gimp source code (and of gegl  babl) but got lost... Can
 someone help?


 Well, I know that in Normal mode, I have in each RGB channel:

 Composite=Over*alpha+Under(1-alpha)

 (assuming Under is fully opaque), but in Subtract mode, I would have
 several possibilities

 No, you just subtract Over from Under with no multiplication, then you
perform a RGB (not RGBA) Composite of the result and Under, to produce the
final composite.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Finding out what happens when compositing layers

2011-09-15 Thread David Gowers (kampu)
In GEGL, the layer mode code is autogenerated from formula strings -- see
operations/generated/math.rb

The opacity behaviour is not documented there, but my understanding is that
the alpha of the underlying composite is preserved, and opacity only effects
how much of the layer's COLOR channels are applied (per the standard
blending formula).

On Fri, Sep 16, 2011 at 7:09 AM, Ofnuts ofn...@laposte.net wrote:

 I'll trying to find out what happens when a layer is in subtract mode
 with a global opacity not one or zero (i.e. what computations are done
 with the pixels values of the composite image of the layers below, the
 pixel values of the layer, and the general opacity). I have a git
 extract of the Gimp source code (and of gegl  babl) but got lost... Can
 someone help?
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tab in Single Window-Mode

2011-08-15 Thread David Gowers (kampu)
I thought we had cycling by some means.. AH, yes. Alt+Tab.
Also, Alt+[123456789] works to switch to a particular tab, in a similar way
to tabs in Firefox.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [Gsoc 2011] Unified transformation tool

2011-03-27 Thread David Gowers (kampu)
On Sun, Mar 27, 2011 at 3:42 PM, Mohit _ mtan.n...@gmail.com wrote:
 David,

 Thanks for the reply, but in the case of undo group, are the sub components
 of that group still saved individually in some sort of stack or are there
 different stacks for the group, and one general stack for all the groups.

 Also, it would be great if you could point me to the code where it is
 happening.

I have no idea about how the implementation works internally :)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [Gsoc 2011] Unified transformation tool

2011-03-26 Thread David Gowers (kampu)
Hello,

On Sat, Mar 26, 2011 at 8:20 PM, Mohit _ mtan.n...@gmail.com wrote:
 Hi,

 In the undo section it is mentioned that until the final pixel recalculation
 is done user should be able to undo every single step, though after that
 user should be able to undo the aggregate transformation only. Does this
 means that we would have to maintain another action stack just for unified
 transformation tool, or does gimp currently also maintains two different
 stacks, one for the current tool and one global stack for actions. If this
 is the case some reference to where it happens in code would be great.

Although I'm nobody official, I believe that this would happen through
the undo-group mechanism.
That is, when the latest group of undos was not 'closed', we should
undo within the group, and once it is 'closed', we should undo the
group as a unit (undoing an undo group as a unit is what currently
happens in general)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GSoC 2011

2011-03-20 Thread David Gowers (kampu)
On Sun, Mar 20, 2011 at 9:22 PM, Ashok1288 asok1...@gmail.com wrote
 @Alexandre Prokoudine
 Actually I was referring about the algorithm (Existing in current GIMP
 Versions) to get familiar with...

Do you mean the heal tool?

app/tools/gimphealtool.*
app/paint/gimpheal.*

are where you should look for a start!
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] X stuck on to start of all libtool options...

2011-01-11 Thread David Gowers (kampu)
Conclusion:

The issue was, I had somehow managed to install a copy of the various
autotools in /usr/local/
and they were being used instead of the ones in /usr/.

My solution was simply to delete those binaries. GIMP is now happily
compiling :)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] X stuck on to start of all libtool options...

2011-01-09 Thread David Gowers (kampu)
Looks like this is the actual issue:

After removing 'configure', it's apparent that 'autogen.sh' doesn't
regenerate it, instead giving ambiguous errors/warnings..

For anyone else's reference, this occurs with

autoconf 2.68
automake 1.9.6 + 1.11.1
glib 2.26.1
gtk 2.22.1

output log of './autogen.sh --prefix=/usr' follows:


WARNING: aclocal's directory is /usr/local/share/aclocal, but...
 no file /usr/local/share/aclocal/glib-2.0.m4
 You may see fatal macro warnings below.
 If these files are installed in /some/dir, set the
 ACLOCAL_FLAGS environment variable to -I /some/dir
 or install /usr/local/share/aclocal/glib-2.0.m4.

[... (repeats x 4)]

aclocal:configure.ac:425: warning: macro `AM_GLIB_GNU_GETTEXT' not
found in library
aclocal:configure.ac:450: warning: macro `AM_PATH_GLIB_2_0' not found in library
aclocal:configure.ac:479: warning: macro `AM_PATH_GTK_2_0' not found in library
configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
/usr/local/share/aclocal/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is
expanded from...
/usr/local/share/aclocal/libtool.m4:5560: AC_LIBTOOL_PROG_LD_SHLIBS is
expanded from...
/usr/local/share/aclocal/libtool.m4:2783: _LT_AC_LANG_C_CONFIG is
expanded from...
/usr/local/share/aclocal/libtool.m4:2782: AC_LIBTOOL_LANG_C_CONFIG is
expanded from...
/usr/local/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
/usr/local/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
/usr/local/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
/usr/local/share/aclocal/libtool.m4:6548: AM_PROG_LIBTOOL is expanded from...
configure.ac:157: the top level
configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
/usr/local/share/aclocal/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is
expanded from...
/usr/local/share/aclocal/libtool.m4:2864: _LT_AC_LANG_CXX_CONFIG is
expanded from...
/usr/local/share/aclocal/libtool.m4:2863: AC_LIBTOOL_LANG_CXX_CONFIG
is expanded from...
/usr/local/share/aclocal/libtool.m4:1908: _LT_AC_TAGCONFIG is expanded from...
/usr/local/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
/usr/local/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
/usr/local/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
/usr/local/share/aclocal/libtool.m4:6548: AM_PROG_LIBTOOL is expanded from...
configure.ac:157: the top level
configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
/usr/local/share/aclocal/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is
expanded from...
/usr/local/share/aclocal/libtool.m4:5560: AC_LIBTOOL_PROG_LD_SHLIBS is
expanded from...
/usr/local/share/aclocal/libtool.m4:4177: _LT_AC_LANG_GCJ_CONFIG is
expanded from...
/usr/local/share/aclocal/libtool.m4:4176: AC_LIBTOOL_LANG_GCJ_CONFIG
is expanded from...
/usr/local/share/aclocal/libtool.m4:1908: _LT_AC_TAGCONFIG is expanded from...
/usr/local/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
/usr/local/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
/usr/local/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
/usr/local/share/aclocal/libtool.m4:6548: AM_PROG_LIBTOOL is expanded from...
configure.ac:157: the top level
configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
aclocal.m4:369: _LT_AC_SYS_LIBPATH_AIX is expanded from...
aclocal.m4:5554: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from...
aclocal.m4:2789: _LT_AC_LANG_C_CONFIG is expanded from...
aclocal.m4:2788: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
aclocal.m4:86: AC_LIBTOOL_SETUP is expanded from...
aclocal.m4:66: _AC_PROG_LIBTOOL is expanded from...
aclocal.m4:31: AC_PROG_LIBTOOL is expanded from...
aclocal.m4:6542: AM_PROG_LIBTOOL is expanded from...
configure.ac:157: the top level
configure.ac:157: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: 

Re: [Gimp-developer] X stuck on to start of all libtool options...

2011-01-09 Thread David Gowers (kampu)
'export ACLOCAL_FLAGS=-I\ /usr/share/aclocal'

before running the './autogen.sh --prefix=/usr',
solves the problem.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] X stuck on to start of all libtool options...

2011-01-09 Thread David Gowers (kampu)
actually no, it only allows the autogen to complete successfully,
silliness like:

/bin/sh ../libtool --tag=CC --mode=link gcc  -Os -Wall
-Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winit-self -Wpointer-arith
-Wold-style-definition -Wmissing-format-attribute -Wformat-security
-o gimptool-2.0  gimptool.o -pthread -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lm -lcairo -lpng14 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
-lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
../libtool: line 869: X--tag=CC: command not found
../libtool: line 902: libtool: ignoring unknown tag : command not found
../libtool: line 869: X--mode=link: command not found
../libtool: line 1036: *** Warning: inferring the mode of operation is
deprecated.: command not found
../libtool: line 1037: *** Future versions of Libtool will require
--mode=MODE be specified.: command not found
../libtool: line 2281: X-Os: command not found
../libtool: line 2281: X-Wall: command not found
../libtool: line 2281: X-Wdeclaration-after-statement: command not found
../libtool: line 2281: X-Wmissing-prototypes: command not found
../libtool: line 2281: X-Wstrict-prototypes: command not found
../libtool: line 2281: X-Wmissing-declarations: command not found
../libtool: line 2281: X-Winit-self: command not found
../libtool: line 2281: X-Wpointer-arith: command not found
../libtool: line 2281: X-Wold-style-definition: command not found
../libtool: line 2281: X-Wmissing-format-attribute: command not found
../libtool: line 2281: X-Wformat-security: command not found
../libtool: line 2450: Xgimptool-2.0: command not found

Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.


Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.




still happens.

Haven't found a solution, yet.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] X stuck on to start of all libtool options...

2011-01-09 Thread David Gowers (kampu)
On Mon, Jan 10, 2011 at 10:44 AM, Liam R E Quin l...@holoweb.net wrote:
 On Mon, 2011-01-10 at 09:59 +1030, David Gowers (kampu) wrote:
 actually no, it only allows the autogen to complete successfully,
 silliness like:
 [...]
 ../libtool: line 869: X--tag=CC: command not found

 http://openmoko-public-mailinglists.1958.n2.nabble.com/quot-X-tag-CC-command-not-found-quot-td1577166.html
 suggests, [[
 It turns out that this
 happens if the directory containing the sources already has files
 generated by previous build processes.
 ]]
 and also a possible libtool version mismatch.

 THey were on ubuntu, if you're on OSX it might be unrelated.

Thanks for that tip Liam, I've tried 'make clean;./autogen.sh
--prefix=/usr', it seems to make no difference, so I will look into
libtool..
(I'm running Arch Linux, FWIW)

libtool 2.4 is installed (since a few months ago). Gimp reports 1.5.26 (?)
I'm trying 2.2.10 now... running 'make clean;git clean
-xf;./autogen.sh --prefix=/usr'..
no, same problem as before.. I'll try reinstalling 1.5.26
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] X stuck on to start of all libtool options...

2011-01-09 Thread David Gowers (kampu)
I've just tried compiling BABL, with similar results.


compiling GLib says, point blank,


You must have libtool = 2.2 installed to compile GLib.
Install the appropriate package for your distribution,
or get the source tarball at http://ftp.gnu.org/gnu/libtool/



so, it looks like recent Arch Linux libtool setup is somehow FUBARed
(In a way I can't fix by recompiling+installing the official  source
over the top.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] X stuck on to start of all libtool options...

2011-01-08 Thread David Gowers (kampu)
Hi,

After running
'./autogen.sh --prefix=/usr' then './configure --prefix=/usr',
when I run 'make' on git HEAD (7057487...), the libtool
options/execution seem to get mangled in a strange way:



make  all-recursive
make[1]: Entering directory `/home/ion/dihinai/st/xra/gimp'
Making all in m4macros
make[2]: Entering directory `/home/ion/dihinai/st/xra/gimp/m4macros'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ion/dihinai/st/xra/gimp/m4macros'
Making all in tools
make[2]: Entering directory `/home/ion/dihinai/st/xra/gimp/tools'
make[3]: Entering directory `/home/ion/dihinai/st/xra/gimp/tools'
/bin/sh ../libtool --tag=CC --mode=link gcc  -Os -Wall
-Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winit-self -Wpointer-arith
-Wold-style-definition -Wmissing-format-attribute -Wformat-security
-o gimptool-2.0  gimptool.o -pthread -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lm -lcairo -lpng14 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
-lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
../libtool: line 869: X--tag=CC: command not found
../libtool: line 902: libtool: ignoring unknown tag : command not found
../libtool: line 869: X--mode=link: command not found
../libtool: line 1036: *** Warning: inferring the mode of operation is
deprecated.: command not found
../libtool: line 1037: *** Future versions of Libtool will require
--mode=MODE be specified.: command not found
../libtool: line 2281: X-Os: command not found
../libtool: line 2281: X-Wall: command not found
../libtool: line 2281: X-Wdeclaration-after-statement: command not found
../libtool: line 2281: X-Wmissing-prototypes: command not found
../libtool: line 2281: X-Wstrict-prototypes: command not found
../libtool: line 2281: X-Wmissing-declarations: command not found
../libtool: line 2281: X-Winit-self: command not found
../libtool: line 2281: X-Wpointer-arith: command not found
../libtool: line 2281: X-Wold-style-definition: command not found
../libtool: line 2281: X-Wmissing-format-attribute: command not found
../libtool: line 2281: X-Wformat-security: command not found
../libtool: line 2450: Xgimptool-2.0: command not found

Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.

Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.



(it continues compiling if I instead run 'sudo make'.
I expect the end result would be wrong or strange, though) ..

another strange message:


../libtool: line 5228: Xgcc-o
@OUTPUT@ test-clipboard.o -pthread  -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lm -lcairo -lpng14 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
-lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0: command not found


Has anyone else here encountered this ??
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Dropping Scheme with gimp 2.8?

2010-12-16 Thread David Gowers (kampu)
IIRC there was some discussion of this idea - script-fu ending up as
an independent plugin rather than one maintained within the GIMP code
base. Basically, script-fu ending up in the position that PyGimp has
been in -- an optional extra rather than part of the core
installation. That's the idea.

There has only been discussion. No concrete plans have been made.

On Fri, Dec 17, 2010 at 12:24 PM, Andreas_P kyel...@yahoo.com wrote:
 In the German Gimp Forums I've had a little discussion with Michael Schumacher
 and houz (don't know real name for now)

 schumaml wrote: I would give Python a go, instead of Scheme...

 schumaml; wrote:

 Mittelfristig fliegt Scheme eher raus, und alle Skripte in GIMP werden in
 Python sein.

 Die einzige Hürde dafür ist noch die Verfügbarkeit für Microsoft Windows - 
 dort
 ist der typische Nutzer nicht in der Lage, Python und drei Module zu
 installieren - aber das wird sich spätestens mit den 2.8-Installerpaketen
 geben.

 On the longterm, Scheme isn't going to stay, and all scripts in GIMP will be
 written in Python.

 The only hurdle against it is, the availability for GIMP on MS-Windows - the
 typical (dumbnut user) can't install Python and three modules for using GIMP -
 but this thing will be history - ultimately with the installer packages within
 2.8...

 I would be glad when Aliens were behind it, it seems more serious.

 Schumaml; was one of the first persons to push a python integration into GIMP 
 on
 Windows...
 And he has some sort of credibility when saying... Scheme isn't to survive
 here

 and later houz wrote: It is a thing of parting ressources, Scheme would be
 wasting them, we (GIMP Dev-Team) cannot support every backend for scripting.

 So, your turn GIMP-Dev Community (Hopefully I am soon good enough to get my 
 code
 accepted within git)

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Cage transform questions

2010-11-06 Thread David Gowers (kampu)
On Sat, Nov 6, 2010 at 11:29 PM, Rob Antonishen
rob.antonis...@gmail.com wrote:
 Another 'bug' is that the cage tool doesn't work on indexed images.  Not that 
 I would expect it to.  Can it be disabled for indexed images?

Doesn't work how? It works for me.. just not 100% like I want it to.
(ie. interpolation is not helpful). I'm using
git master (31aa09a11f2a2486c4cf9ab69104019d97c1d68a)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Cage transform questions

2010-11-06 Thread David Gowers (kampu)
On Sun, Nov 7, 2010 at 2:45 AM, Rob Antonishen rob.antonis...@gmail.com wrote:
 Doesn't work how? It works for me.. just not 100% like I want it to.
 (ie. interpolation is not helpful). I'm using
 git master (31aa09a11f2a2486c4cf9ab69104019d97c1d68a)


 I just did a pull make/make install.  I don;t know how to get the git
 master number :(

type git log in your shell
Providing you haven't added additional patches or switched to an
alternate branch, the hash belonging to the topmost entry will be the
one you want.


 I started with this image: http://gimpchat.com/files/196_funnydog1.png

 And using a simple (4 point) cage deform get this:
 http://www.majhost.com/gallery/ffaat/gimp/more2/196_funnydog1.png

Aha! I can reproduce this! The interpolation is actually completely
borked in all indexed cases (it interpolates as if the indices were
grayscale values).. but if the image color map is sorted by
brightness, this often produces approximately correct results anyway.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Cage transform questions

2010-11-05 Thread David Gowers (kampu)
Hi,
I've just been trying out the cage tool (recently merged into GIT head)
I really like that I can just sketch up something like
http://img.photobucket.com/albums/v449/neota/tech/1.png
and gooily bend it into something like:
http://img.photobucket.com/albums/v449/neota/tech/2.png

I have two questions...

* What does 'Fill from first point' do?
('first point' is likely the first point you clicked when defining the
cage.. but if fill from first point is NOT checked, where does the
cage code fill from?)

* Are there any plans to provide an option to use nearest-neighbour
sampling? The interpolating sampler works well for photographic
images; for indexed or low-color images, I so far find that the
interpolation makes the result uglier than the original, due to a)
destruction of intentional hard edges or b) colors being remapped
after interpolation

Curious,
David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Cage transform questions

2010-11-05 Thread David Gowers (kampu)
Also (should I file a bug report for these?)

* Frequently, when closing the cage by clicking on the first point,
the point that was just placed ends up next to the first one
* When =1 point is outside image bounds, pixels outside the resultant
shape become black (regardless of the current BG color). For greyscale
images, mid-grey is the color which appears
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Indexization seems to be broken

2010-11-01 Thread David Gowers (kampu)
Just messing around with GIT head, I found that indexized images
appear to be displayed in grayscale (ie as pure index-values rather
than colors.)* Hopefully this is an intentional temporary measure and
not an accidentally caused bug.

* saving an image and then reloading it makes it display properly in color.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Detecting closure of selection

2010-10-09 Thread David Gowers (kampu)
On Sun, Oct 10, 2010 at 7:47 AM, Ofnuts ofn...@laposte.net wrote:
  Assume I have a selection on small area (for instance a 20px circle),
 and I invert it. Now, if I grow the selection by a sufficient amount
 (10px in this case), everything gets selected.

 Is there a practical, fast way, to detect this case, i.e, that the
 selection covers the whole layer (or image?) and that no pixels remain
 unselected? I assume that inverting the selection again and testing for
 empty would work, but that would be two selection inversions in the
 normal case and that may be a bit costly.
Testing for empty and for full are the same operation (an empty sel is
equivalent to a full one)

HTH
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Dummy Layer with particular dynamic effect

2010-08-29 Thread David Gowers
On Sun, Aug 29, 2010 at 4:24 AM, Jacopo Corzani corz...@gmail.com wrote:

 Well, adjustment layers is what GIMP developers seem to refer to as
 layer abuse :)

 There are different ways to implement non-destructive editing. Would
 you be interested to find out more?

 Alexandre Prokoudine
 http://libregraphicsworld.org




 Hi Alexandre,
 i could agree with your consideration of layer abuse but adjustment
 layer is a quick and robust solution to manage effects whenever i want.
 Changing a curve (or any other effect) dynamically without duplicate
 layers would be a great.
 Sure,i'm interested to find another quick way to handle effects during
 time without do an layer abuse, but i don't have any ideas that speed up
 work like adj layers... :)
 Thanks for your response.

Peter Sikking has already expressed a way of doing this: you attach a
list of effects to a layer or layer group.

http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html

As he observes, this avoids the problem of 'adjustment layers' not
actually being layers in any normal sense (that is, their lack of
content) while allowing the same or greater functionality.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Getting new layer modes fit for inclusion

2010-08-24 Thread David Gowers
On Wed, Aug 25, 2010 at 6:41 AM, Sven Neumann s...@gimp.org wrote:
 Hi,

 On Tue, 2010-08-24 at 02:52 +0200, Rupert Weber wrote:

 The patch is here. Now, and it works. The conversions add 17k of code.
 Once GEGL takes over, they'll simply removed again. No one gets hurt.

 Well, the problem with your patch is that it adds new public API to
 libgimpcolor.
Actually, AFAICS the latest version of the patch does not.
It adds the API in it's own file in app/composite/ , which as I noted,
should make adopting it to babl painless, and doesn't expose it to
plugins.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Getting new layer modes fit for inclusion

2010-08-23 Thread David Gowers
On Tue, Aug 24, 2010 at 10:22 AM, Rupert Weber g...@leguanease.org wrote:
 On 08/22/2010 02:45 PM, Sven Neumann wrote:
 New code in GIMP should use babl for pixel format conversion. There's no
 need to introduce new API for that as we have babl which is available to
 the core and plug-ins and provides a much superior API.

 The short answer is: No. I won't do that.
 For the long answer see further down below. (Sorry if this post becomes
 a bit longish)

 First about the current state of affairs:
 I posted the last update to the patch to
        http://bugzilla.gnome.org/attachment.cgi?bugid=325564

  From my point of view, it is now done.

 Some performance numbers, comparing redraw times of legacy modes to the
 new LCH modes and to current GEGL LCH modes:
 (Tested with a very large picture to get measurable numbers; still these
 are ca. numbers, obtained with a stop watch)

 Mode         | Legacy | New LCH | GEGL/babl
 -++-+--
 Hue          |  3.6   |   6.4   |   396
 Saturation   |  4.6   |   6.2   |   405
 Color        |  4.7   |   4.1   |   431
 Value/Lightn.|  3.5   |   4.1   |   416

 So I'm in the ball park of the legacy modes, Color is even a little
 faster. Compared to current GEGL/babl the new modes are about 60 to 100
 times faster. (Yes, no typo)

I hope you're not associating the quite suboptimal way in which GIMP
currently uses GEGL, with BABL's speed or lack of speed.

BABL just processes raw pixel buffers. A converter function just
accepts a source and a destination pointer, along with a pixel count,
and should convert that number of pixels. It doesn't have any heavy
architecture or processing, aside from what may be in each individual
converter function

looking at your code in gimpcolorspace.c, making that code work with
BABL looks like it's pretty much a case of cut+paste, modify the way
the input is referred to, add some registration code.

(getting your layer mode code to USE that, is a different issue, and I
agree that would be non-trivial, although you might get significant
speed gains from it because of greatly reduced function call overhead
-- probably about as much as you describe for inlining below.)


 As to accuracy, these are the round-trip pixel errors for Lab and LCH
 conversions:
 Error after round-trip [in 8bit RGB space]:
  L*a*b*                          L*C*H*
  0:   16561783 (  98.716%)      0:   16527659 (  98.513%)
  1:     214941 (   1.281%)      1:     248244 (   1.480%)
  2:        492 (   0.003%)      2:       1313 (   0.008%)
  3:          0 (   0.000%)       3:          0 (   0.000%)

 The worst we get are off-by-two errors. You won't notice without
 diff'ing two layers.
 If you don't just stack no-op layers on top of each other, out-of-gamut
 errors will be *far* greater than these.

 So, as I already said, I consider the patch done now.

 Things I will still be glad to change:
 - Location/name of new file, name of exported functions, etc.
 - Any bug fixes, of course.
 - The open issues I had mentioned earlier (file formats,
   GIMP_COMPOSITE_BLEND et al.)

 Things I won't change:
 - Optimization. I currently see no further optimization potential
   without uglifying the code.
   - As to putting the conversion outside the loop: Yes it can be done,
     but even if it is done, it doesn't belong in this patch.
     The current implementation in gimp_composite_generic.c is symmetric
     to the existing layer modes. So any such un-looping would be a
     general change to that file, not specific to the new layer modes.
   - Inlining: Brutally inlining everything can be done and gives some
     12%-15% performance increase. -- But I don't want to get my hands
     dirty with that.. :o)

 And then there is babl.
 I feel very bad about that request. Because I expect it to be the first
 step in a relatively short sequence of if-we-do-that-why-don't-we's that
 will end with these modes not getting in but rather be added to the GEGL
 agenda.
 As that is effectively what you are asking me to do: work on the GEGL
 modes instead (or duplicate them, which would be even sillier).

GEGL modes are something else. I believe what Sven was suggesting is
to implement your conversion code in a BABL extension, and use that to
do color conversion in the layer modes; Not to use GEGL for that whole
thing.

That said...

 But that is not what I signed up for. The idea was to get something done
 and usable now. Not something that will be great in some uncertain future.

 When this is done I will be glad to take a look at babl and see if the
 conversions can somehow be integrated. But I don't expect that to be a
 trivial task.

 The patch is here. Now, and it works. The conversions add 17k of code.
 Once GEGL takes over, they'll simply removed again. No one gets hurt.

I absolutely agree that this patch should be applied promptly.
It implements much-wanted functionality in an effective and efficient way.
Separating the new color conversions into their 

Re: [Gimp-developer] new layer modes patch posted

2010-08-15 Thread David Gowers
On Sun, Aug 15, 2010 at 3:22 AM, Rupert Weber g...@leguanease.org wrote:
 I posted a new version (v3) of the layer modes patch (split in two) to
        http://bugzilla.gnome.org/show_bug.cgi?id=325564

 The libgimp functions and the layer mode stuff are each in a separate
 patch now.

 [The message I wrote there is misleading. along with the other v3
 patch was just supposed to mean that it accompanies the first patch.
 There is no third patch missing.]

Works quite well (and fast!) IMO. Infinitely better than the old modes :)

I noticed when I tried to pull the latest changes from GIT HEAD, that
the automatically-generated changes to :

app/base/base-enums.c
libgimp/gimpenums.h
tools/pdbgen/enums.pl

(which, while being auto-generated, also change infrequently enough
that they *are* version-controlled),
have not been included. That means, after applying the 2 (or 3)
patches and rebuilding GIMP, these outstanding changes prevent you
from pulling the latest changes.

I suggest merging these changes with the patch to libgimp, since that
is the one that introduces the new enums.
Actually, I can do that..
But you might still want to know how..

1. Create a commit containing the missing changes
2. Use 'git format-patch' to generate a patch from it
3. Rewind to just before your first patch ('git reset --hard commit id')
4. Apply the libgimp patch, then the patch created in step 2
5. 'git rebase -i commit id' to rewrite part of your local history
(where commit id is the hash of the commit immediately before the
libgimp commit)
6. change the line  relating to the commit created in step 1, to say
'squash' instead of 'edit', save, and exit.
7. 'git format-patch HEAD~..HEAD'. This will output the amended libgimp patch.

I'll attach the amended patch to bug #325564.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] layer modes - open questions

2010-08-15 Thread David Gowers
On Mon, Aug 16, 2010 at 4:46 AM, Rupert Weber g...@leguanease.org wrote:
 There are still some issues that I either blissfully ignored or took the
 least-cost route on:

 (3) paint-funcs layer modes
 Is the layer mode code in app/paint-funcs ever used?

grepping the entire codebase only lists paint-funcs.c as a user of
dissolve_pixels() and of layer_*_mode() [therefore *_pixels() are
dependencies too]

AFAICS the code in paint_funcs.c which depends on the layer-modes.c
code is used indirectly by:
 * the merge-down code [app/core/gimpimage-merge.c]
 * the projection code [app/core/gimplayer-project.c]
 * the fade code [app/core/gimpdrawable-combine.c]
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 2.7.3 Performance

2010-08-11 Thread David Gowers
On Thu, Aug 12, 2010 at 7:24 AM, Alexia Death alexiade...@gmail.com wrote:
 On Wednesday, August 11, 2010 06:04:36 David Gowers wrote:
 On Wed, Aug 11, 2010 at 12:12 PM, David Gowers 00a...@gmail.com wrote:
  On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR fam...@infernal-iceberg.com
  wrote: GIMP is a jerk (I get
  cases where I draw a curve and the middle of it gets flattened into a
  straight line); But I haven't been painting anything with GIMP
  recently so I don't know whether it's also a jerk with XAA.

 It is. Looks like I have a bug to file.
 Not with GIMP. Its a bug in the wacom driver. Top end of the pressure scale
 ends up with pressure 0. And I have a vague memory thats fixed somewhere in
 development pipeline.

I have the fixed version already.(0.10.8)

Believe me, after experiencing THAT problem, I would know about it.
Generally that problem resulted in the stroke ending and no more
drawing until I eased off on the pressure.

This is a different bug  (and, MyPaint also uses the GTK+ input code
and does NOT experience this bug at all no matter how fast I move)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)

2010-08-10 Thread David Gowers
On Tue, Aug 10, 2010 at 5:58 PM, LightningIsMyName
lightningismyn...@gmail.com wrote:
 Hello,

 On Tue, Aug 10, 2010 at 9:27 AM, Martin Nordholts ense...@gmail.com wrote:

  2. We need to define a usable plugin browser. One of the features I'm
  missing the most, is a preview image. Plugins should have an option to
  register a preview image of their effect (probably by having the image's
  binary data embedded in them). This also relates to the feature request
  of having a logo script browser...

 I don't think registering a fixed preview image is good enough, it

 Believe me, I really want a dynamic preview on the current image :-)
 But, it's not practical as some plugins take way too long to operate -
 trying to create a preview on the current image might take way too
 long to be any good.
Create the previews in an idle handler (ie. let the user select the
operation even when the preview is not rendered, and cancel any
pending preview rendering when a selection is made)
We could combine this with the stored previews idea: show the stored
preview with an overlay that indicates rendering of the preview for
the current image is in progress...


 On Tue, Aug 10, 2010 at 3:31 AM, David Gowers 00a...@gmail.com wrote:
 On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName
 lightningismyn...@gmail.com wrote:
 Hello,

 I recently re-read all the GSoC suggestions for 2010, and I found this
 interesting one about making the menus searchable:
 https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility


 The reason I made the description above is that the plugin browser is
 very limited.. you cannot activate non-plugin menu items (for example,
 I'd like to be able to access 'scale image' and 'scale layer' via a
 search -- I don't use them enough to warrant keyboard shortcuts, but
 enough that some acceleration is warranted.
 The same thing goes for virtually all GIMP-GAP operations).

 Sorry for my bad phrasing of the question - let me rephrase it: what
 is left other than exposing the searchbox from there?

Supporting '*' wildcards would be helpful IMO, but I agree that the
shortcuts search is pretty adequate for this, when connected to
activating the chosen action.

 The searchbox there allows to find non-plugin actions, and these are
 very neatly organized under several categories. When you search, the
 categories are already expanded so you can see all the results,
 organized, right away.
That aspect is certainly good.




 What I suggest, it is possible to embed binary data in script-fu
 scripts, but it's not easy/fun/simple. What I suggest is that as a
 part of the refactoring process of the plugin system, we will allow
 procedures to register a sample procedure. This procedure will be
 called once to generate a preview image. But this procedure is
 probably a bad idea (since generating the preview will take time, and
 this can be long...)
 The other option is to ship example images with script-fu scripts and
 to allow them to return a pointer to that image for their preview.
 This sounds more reasonable to me.
Yes. However IMO, if we do that, we should not stop at previews for
script-fu. We should provide a directory for general storage of these
previews for any plugins. That way,  it is much easier for ordinary
users to provide improved previews for their most used plugins.


 One of the things we should remember is that we should still have some
 sort of seperation between the plugin/script browser and between the
 general procedure browser. Because if we want things like preview for
 every action, it would be rather useless to have previews for internal
 operations such as raise layer.

Certainly; there are actually four classes of actions:
1. actions owned by plugins, which have a menu item
2. actions owned by the GIMP core, which have a menu item (eg 'Raise layer')
3. actions owned by the GIMP core, which don't have a menu item (eg.
'Increase Aspect')
Mostly we will want to search the union of 1 and 2, IMO.
And sometimes, we will want to search 3 (eg. I would use this for
tweaking the color picker radius, setting the brush scale to default
(=1.0))
. That  is possible without any need to change current code.

I would like to point out anyway, that the PDB browser and the current
keyboard shortcut dialog search, search different things...
PDB browser searches PDB entries, KB shortcut dialog search searches
action internal names+ user-visible names. It's definitely important
to make that distinction apparent to the user, so that they don't
expect to see PDB entries popping up in the action search box which is
the subject of current discussion.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 2.7.3 Performance

2010-08-10 Thread David Gowers
In view of what Alexia just said:

Your problem is interesting, because its contrary to what I would expect and
experience myself. For me GIT version performs about twice as good as 2.6,
especially with large brushes, and thats with compositing on. To get the 25px
round brush to lag at all I have to move lightningfast. and then it usually
catches up in under 2 seconds. My hardware configuration is admittedly 
slightly
better than yours... But 25px brushes really shouldnt be a problem anywhere.


I am suspecting your Xorg server version, config, or video hardware
has changed as well as your GIMP version.
I found myself, that redraws in paint programs were intolerably slow
until I added the

Option  AccelMethod XAA

to the video card config in my xorg.conf.
(EXA is the default, and makes 3d performance much better, but
unfortunately seems to cripple 2d painting performance on my card. XAA
might effect compositing (as in WM compositing) speed significantly
instead.)

Perhaps you could try the above option and see if it makes any difference.

FYI, I have an ATI Radeon 9800 or thereabouts. I've read that this
problem does not occur on NVidia cards and newer ATI cards.

[incidentally, 2.7 uses Cairo more for display related things (not for
rendering brushes IIRC, but of course in order to see the rendered
brush strokes, the area must be displayed). It's possible that this
impacts your system significantly while using the default EXA
acceleration. So it could be a combination of a change in GIMP and
annoying hardware/driver misconfiguration.]

HTH,

another Dave :)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 2.7.3 Performance

2010-08-10 Thread David Gowers
On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR fam...@infernal-iceberg.com wrote:
 Hi,
 00a...@gmail.com (2010-08-11 at 0928.56 +0930):
 I found myself, that redraws in paint programs were intolerably slow
 until I added the

 Here it was general. GIMP's interface took a couple of seconds to
 redraw, but so did FF while scrolling (slideshowing would describe it
 better).

         Option      AccelMethod XAA

 to the video card config in my xorg.conf.
 (EXA is the default, and makes 3d performance much better, but
 unfortunately seems to cripple 2d painting performance on my card. XAA
 might effect compositing (as in WM compositing) speed significantly
 instead.)

 Perhaps you could try the above option and see if it makes any difference.

 FYI, I have an ATI Radeon 9800 or thereabouts. I've read that this
 problem does not occur on NVidia cards and newer ATI cards.

 Other thing to try is keeping EXA but with:
 Option          MigrationHeuristic greedy

I've just tried this and it works for me. MyPaint becomes is just as
responsive as with XAA, except for the panning. GIMP is a jerk (I get
cases where I draw a curve and the middle of it gets flattened into a
straight line); But I haven't been painting anything with GIMP
recently so I don't know whether it's also a jerk with XAA.
3d performance in Blender is fairly poor (but noticably better than with XAA)

Panning in both MyPaint and GIMP (and Firefox) is still noticably
slower. Fast smooth panning is important to me, so I will switch back
to XAA.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 2.7.3 Performance

2010-08-10 Thread David Gowers
On Wed, Aug 11, 2010 at 12:12 PM, David Gowers 00a...@gmail.com wrote:
 On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR fam...@infernal-iceberg.com 
 wrote:
 GIMP is a jerk (I get
 cases where I draw a curve and the middle of it gets flattened into a
 straight line); But I haven't been painting anything with GIMP
 recently so I don't know whether it's also a jerk with XAA.

It is. Looks like I have a bug to file.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)

2010-08-09 Thread David Gowers
On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName
lightningismyn...@gmail.com wrote:
 Hello,

 I recently re-read all the GSoC suggestions for 2010, and I found this
 interesting one about making the menus searchable:
 https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility

 As far as I know, menus are searchable and the best example is the keyboard
 shortcuts dialog which has a searchbox to find the GIMP action you'd like to
 use.

However, that action is not immediately activateable.
What I personally envision is something like the completion dialog
that you can find in GTKTreeViews (for example, typing something in
when the file list in a file selection dialog is focused, offers you a
choice of the possible items. And upon selection from that sub-list,
the file is immediately chosen.)

 So I asked on #gimp and I was told there was a discussion on IRC about
 finding a more usable replacement to the plugin browser.

The reason I made the description above is that the plugin browser is
very limited.. you cannot activate non-plugin menu items (for example,
I'd like to be able to access 'scale image' and 'scale layer' via a
search -- I don't use them enough to warrant keyboard shortcuts, but
enough that some acceleration is warranted.
The same thing goes for virtually all GIMP-GAP operations).


 So, to get a formal record of this discussion, I'm starting it on the
 mailing list again.

 Here are points which should be considered:

 0. How do we want the search to work? A user can bring a search dialog up?
 Will the search be based on a string? A tree?

one or more strings, per your Tags suggestion.

 1. GEGL ops should really be integrated in the GIPM menus. As

What's a GIPM ? :D
 someone said,
 it's like the old script-fu menu - it was wrong. We don't have to force the
 user to remember what's a GEGL op (which will be accessed using the GEGL
 tool) and what's a regular plugin/script.
 It's a bit offtopic, but we should find a way to implement gegl plugins with
 a custom GUI, and register them like regular plugins in the menus. Having a
 search that will once point to a plugin and once activate the gegl tool, is
 a very bad idea...

Though we need to consider, that a GEGL op can do much more than
simply be applied to the image once, destructively. If we make GEGL
ops available in the menus, we should aim to do so in a way which does
not trap us in a corner if, for example, we want to in the future be
able to add that op into the image as a non-destructive effect on the
current layer/layer group.


 2. We need to define a usable plugin browser. One of the features I'm
 missing the most, is a preview image. Plugins should have an option to
 register a preview image of their effect (probably by having the image's
 binary data embedded in them). This also relates to the feature
I agree with you, but believe that we need to be more definite than
that: previews should show clearly the before and after. I favor
GMIC's horizontally split preview style for this -- it avoids wasting
space, and instead of tiling two complete images next to each other,
you get to see half of the image as it would be if it were filtered.
In some cases, the vertically split style may be more appropriate.

request of
 having a logo script browser...

Well, if we did what you outline here, how would Script-Fu scripts
handle the necessary embedding of binary data (I don't mean to imply
that they couldn't, just that I do not know exactly how well they can
handle this kind of binary string literal).

 4. Another option, instead of categories and sub-categories, is tagging -
 like the brushes work in 2.7 (unlike categories - there are no sub-levels,
 and each plugin can be in many places)
The current api allows this, minus the 'no sublevels' criteria, since
a procedure can register in multiple menu paths.

I like the tagging concept, especially if it turns out to be a cheap
solution to menu editing (If I could make my own tag, tag all the
stuff I use most with it, and assign a shortcut to bring up that menu,
that would really help my efficiency...
Or, if I could remove the 'FILE' tag from the 'Print' menu item, I
would no longer have to contend with a menu item that I never ever
use. Note that if we could untag, we need a virtual 'tag' that items
without a tag could belong to.. '-' or '!' possibly.)

I think we should tag, and predefine a tag set that should be adequate
for most existing plugins. User tagging is important because plugin
authors may not always be available or be willing to add this
information. [this sort of ties into the 'Get Hot New Stuff'
proposition -- it would be nice to be able to distribute the task of
correct plugin tagging across users via a web interface)

Hope I've given you something to think about :)

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Please fix Color and/or Value transfer mode

2010-07-28 Thread David Gowers
On Wed, Jul 28, 2010 at 4:20 PM, Charlie De charlieco...@yahoo.com wrote:
 Since we released stable  versions with this broken behavior we now have
 to maintain backward  compatibility to it. It is considered very
 important that you can open your  old XCF files in a new version of GIMP
 and get the same result as in the  version you created them in.


 I suggest that implementing the improved functionality is of much higher
 priority than backwards compatibility with the old.  Particularly in a project
 such as GIMP, where development resources are as precious as they are.




 You can tackle this with a marketing thought experiment: if you were to ask 
 a
 group of GIMP users what they would prefer, speedy fixing of broken features, 
 or
 insistence on backwards compatibility, which would the majority vote for?

This is an erroneous dichotomy, because a failure to preserve
backwards compatibility is itself a 'broken feature'
GIMP is the definitive loader of XCFs. Any other format, it is nice if
it supports perfectly, but hardly needed. Its own format, it MUST
support perfectly, however it achieves that.
It must load any sane XCF in such a way to produce just the same
result as it ever did.
Otherwise you create a situation where you are silently changing the
meaning of people's XCF images. It's like you changed the symbol '2'
to mean 'twice twice twice one' (that is, 8); People will still expect
2+2 to equal 4, not 16. Some people will notice that their maths comes
out weird, some people won't. Regardless, it's just not reasonable to
indirectly change the meaning of people's creations in this way.

 Besides, the appropriate and established way of addressing backward
 compatibility is through the handling of old files, not by refusing to 
 implement
 improvements.  Reading some of the discussions among the GIMP development team
 in relation to the issue of broken Color transfer mode was the first time I
 encountered the argument that it was preferrable to keep the broken
 functionality over fixing it, because a user might want to keep old rendering 
 in
 the new version.  What a nonsensical argument!

Implausible, rather.

Almost all of the improvements we could look at would be much more
readily coded and tested with solid GEGL integration. This is
something that we do not currently have, it's more like a
well-constructed Frankenstein, with some systems having an option to
use GEGL, others not, and none with GEGL as the default/only rendering
system.
Really solid and complete GEGL integration, IMO, would be far more of
an asset to GIMP than any one other user-visible improvement, because
of it's major synergistic effect on our ability to quickly write and
test new image manipulation operations / combinations of operations.

Old file handling only goes so far: XCF is not only GIMP's fileformat,
but represents the way GIMP conceptualizes the notion of a complex
image. When basic concepts change, it is normal to not be able to map
the old information 100% accurately onto the new format.
(that time is not yet, though.)


 Has there been a single user outside the dev team who expressed this view?

 At this stage I'd prefer to avoid the argument and let the team focus on the
 positive task of bringing out the next version.  However, there will be bugs 
 in
 new stable releases, in 2.8, 2.10 and beyond.  So the argument of how those 
 bugs
 are to be dealt with and what priority backward compatibility is to have will
 not go away.  We might as well tackle it as we go along instead of delaying 
 it.

My understanding is that breaking compatibility is on the table for
3.0, *and no earlier*.  Because of the change of paradigm between
classic GIMP and GEGL-based GIMP,  GIMP 3 XCFs would naturally be
quite a different beast to GIMP 2 XCFs. This makes it a natural point
to break compatibility at, since users will need to learn to do quite
some things differently anyway. Before then, GIMP won't work
differently enough to flag to the users that hey, things may not work
quite the same as you're used to.
If GIMP 2 can load GIMP 2 XCFs 'perfectly', and GIMP 3 loads GIMP 3
XCFs 'perfectly', then this is straightforward from a user point of
view, no? OTOH if we change in the middle of a major version, it is
not:
GIMP 2 XCFs would be loadable by, say GIMP =2.8, and GIMP 2.8 would
load GIMP 3 XCFs. That's unfriendly behaviour and much harder to
remember.

tl;dr version: There are good user-friendliness and
programmer-efficiency reasons for leaving compatibility breakage until
GIMP 3, and you have not presented any particularly compelling reasons
for breaking compatibility earlier

Have a nice day.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Please fix Color and/or Value transfer mode

2010-07-28 Thread David Gowers
On Thu, Jul 29, 2010 at 12:28 AM, Liam R E Quin l...@holoweb.net wrote:
 Having said all that... I'd wondered myself why that photoshop trick of
 blurring a layer in mode colour didn't work well in gimp, but I don't
 know that this means gimp is wrong here. The right answer is to work
 out what the behaviour should be, for each mode, and do some tests to
 see if the implementation matches expectations. Be the same as
 some-other-program is not, of course, a goal for GIMP. And of course it
 would be nice to be able to fix camera noise, especially from lower-end
 and older cameras, in this way!

BTW, of course this method requires a plugin, but GMIC can do this
quite well (the a / b smoothness sliders in the LAB mixer can
effectively smooth the coloration without effecting brightness; the
denoising filters like 'anisotropic smoothing' also may be set to
operate only on AB channels)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] about getting involved in developing Gimp

2010-07-22 Thread David Gowers
On Thu, Jul 22, 2010 at 1:49 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote:
 On Wed, Jul 21, 2010 at 5:43 AM, Michael Grosberg
 grosberg.mich...@gmail.com wrote:
 xianghang liu xianghangliu at gmail.com writes:


 Hi,

 I am very interested GIMP and want to join the Gimp project as C
 developer. I am a first-year PhD
 student in computer vision. I would like to start with fixing some
 bugs and then implement new
 features and my final objective is gsoc 2011.
 Do you have any suggestions?

 Xianghang Liu


 This is just a suggestion from a user, so I have no idea how difficult or 
 easy
 it might be - but if you are interested in adding a very helpful feature to 
 Gimp
 please consider working on implementing automatic layer boundary management.

 I'll explain:
 currently a layer's boundary is managed by the user. after you create a 
 layer,
 if you move it, say 100 pixels to the left, there will be a 100 pixel wide 
 area
 on the canvas that you can't paint on. The user then has to set the layer
 boundary himself to include all the canvas.
 It would be great if this was managed by the software, so that whenever a 
 user
 wanted to draw on an area outside the layer boundary, it would be 
 automatically
 enlarged to allow him to do that.


 I've presented GIT master for a large audience today (200+ people)  -
 after the presentation, the most requested feature at questions
 time, was also this one.

Just noting that we still need the option to manage layer bounds ourselves.
In particular, it seems common to paste something with the expectation
that after anchoring it will be cropped to the underlying layer
bounds, rather than expanding it. That should be straightforward.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Question about tools (and other) icons in GIMP.

2010-07-14 Thread David Gowers
On Thu, Jul 15, 2010 at 3:30 AM, Эллина Петухова ellinestu...@gmail.com wrote:
 Hello everybody. I want to sorry for my English because it's not my
 native language and i am not familiar with it.

 Also i am not a serious developer so if i talk something wrong or even
 bother you please tell me about that.

 Since i migrate to open-source programs  i am using GIMP often and
 everything is great (and i am very much obliged to you).
 But one thing that has been distracting my attention at work is a bright
 and coloured icon theme. Searching the way to change them i founded a
 source code and icons inside in uncompiled form. It seems to be very
 good and i am tried to change them and compile package.

 So it works but it's not the way to share them with somebody. (and even
 install them convenient)
 I found some information about which compiled files are responsible for
 icons here:
 http://www.gimpusers.com/forums/gimp-developer/1-Gimp-Toolbar-Icons.html#msg56152
 (it seems like your correspondence)

 And it's indicate that icons contained in the gimp-stock-pixbufs.h,
 gimp-core-pixbufs.h and gimp-wilber-pixbufs.h as i remember.
 But i can't find even one of them in my system. And there i get stuck.
 I think you understand that i want to find some files which are
 responsible for icon themes to be able to replace them.
 Adwise me please if it is not prevented and if it possible at all.

 P.S.: if you interested in what i want to do here is the example:
 http://gimper.net/viewtopic.php?f=1t=7764
 http://gimper.net/viewtopic.php?f=1t=7764.

 Thank you very much and good luck!

For an example of what Sven's talking about, see
http://jimmac.musichall.cz/log/?p=30

Jimmac has made a Grayscale icon theme for GIMP, though it is probably
somewhat out of date now, you can still see how the icon theming
works.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Windows snapshot of 2.7 - possible?

2010-04-09 Thread David Gowers
On Fri, Apr 9, 2010 at 6:51 PM, LightningIsMyName
lightningismyn...@gmail.com wrote:
 Hello Tor,

 I forgot to include the actual sources with my build (they were way to
 big and I forgot I had to do this), so I removed my build. Thanks for
 reminding me =)

Did you modify the GIMP source?
If not, you don't need to include the source itself; you just need to
provide a up-to-date link to somewhere the source can be obtained. The
GPL is specific on this point.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIT crash changing gradient

2010-03-22 Thread David Gowers
On Mon, Mar 22, 2010 at 11:44 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Mon, Mar 22, 2010 at 2:42 AM, Michael J. Hammel wrote:
 I ran into a bug that causes a crash while working out of git.  I didn't
 see it in Bugzilla.  It's easy to reproduce:

 1. Choose Gradient Tool
 2. Change the active gradient in the Tool Options dialog.

 Confirmed :(

Also confirmed.
Wasn't sure if it was just me, since I had some local changes relating
to gradients. I usually want to select FG to transparent (at the top
of the list, in the Lojban/jbo i18n at least) and it always crashes
when I do.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Wrong font size

2010-03-15 Thread David Gowers
On Tue, Mar 16, 2010 at 11:20 AM, bruno brunomend...@gmail.com wrote:
 Hi all,

 I am web designer and I trying Gimp 2.6.8 in Debian Lenny (2.6.26-2) and
 Ubuntu Karmic (2.6.31-14).

 I found that, when I set font size to X pixels, Gimp converts it into
 wrong size, i.e. 16 px at 72 ppi are 12 px, 16 px at 96 ppi are 12 px,
 16 px at 300 ppi are 12 px, ... What's wrong?

 Is it a bug?

 I can understand that if Gimp use 72 ppi for fonts when I set 16 px it
 converts it into 12 px. But what about other cases?

In Gimp 2.6, font sizes are based upon your monitor ppi, not the ppi
of the image. There is a section in Preferences ('Display', if I
recall correctly), which allows you to override this. This could be
regarded as a bug (particularly for anamorphic images (ie. those that
do not have square pixels.. like: 48x96ppi)

In recent development versions of GIMP, I understand that text size is
proportional to image ppi.

Hopefully that helps. I found your email confusing, as in my opinion,
if you input 16px, then what you should get is always 16px. However,
there are also other factors -- many fonts seem to be badly adjusted
(baseline too low, overall scale too small,...), so that you must
request much larger sizes to get the ordinary size you want (not only
in GIMP, but in all programs.). Have you checked your results with
different fonts?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Adding ability to reverse curves dialog

2010-03-09 Thread David Gowers
On Wed, Mar 10, 2010 at 8:19 AM, Jay Smith j...@jaysmith.com wrote:
 On 03/09/2010 04:39 PM, Jon Senior wrote:
 On Tue, 09 Mar 2010 16:30:58 -0500
 Jay Smith j...@jaysmith.com wrote:

 I am not sure where the standard that you mention comes from.  I had
 never seen black at bottom left (by default) until I started to use
 Gimp.

 Is there some actual scientific standard underlying that?  Or just
 majority of programs?  Or the programs you have used?  Or?

 Maybe the programs I have used in the past were backward.

 I would suggest that they were. The curves are graphs plotting value
 in (x) against value out(y). Traditionally a graph starting at 0 for
 both axes would be drawn with the origin in the bottom-left.

 This naturally leads to a curves graph where black (0) is in the
 bottom-left and white (255/1023/...) is in the top-right.

 What programs have you used where this situation was reversed?

 Jon

 Jon,

 That is certainly possible.

 The one that most comes to mind is Photoshop 5.x.

 I have no idea what modern Photoshop and successors do.

http://www.adobe.com/designcenter/photoshop/articles/phscs2at_learncurves_02.html

White on the right, Same as GIMP, PSP, etc.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init (David Gowers)

2010-03-05 Thread David Gowers
 On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote:
 I agree with Joao S. O. Bueno and disagree with David Bowers.

Well, I'm glad you don't disagree with me, but who is that?


 Its better to make plugins meet the normal expectations of Python
 programmers (you can import any Python file to use pieces of it) than to
 add new conventions and directories for shared Python plugin code.
 Simpler is better?

The normal expectations of Python programmers are that the main loop
will be guarded.
This is exactly the thing that allows you to import otherwise
executable modules;
without it, no guarantees can be made that the code you are importing
will not interfere with global state in a way which causes your plugin
to crash. You can depend on a specific version of a plugin which has
known behaviour; In that case you prevent the user from upgrading that
plugin, and you rely on knowledge of the internals of that plugin,
which is very likely to get you into trouble if you ever need to
upgrade it.

The same principle applies to python scripts that are unguarded:
importing them will, at the least, have significant side effects.
Often they are entirely incapable of being cooperative.

Hence, it's not practical to import a plugin module unless it
specifically indicates that it is fit to be imported (by guarding the
main loop)


 Often, authors don't plan their code will be useful to others.  It's
 just serendipity.  If authors don't plan to share code and put it in
 these new directories, it thwarts serendipitous reuse and
 experimentation.

 It is inconsistent for a duplicate call to register() to be harmless
 with a warning while a duplicate call to main() is fatal.

Currently, the latter is serving the function of preventing the
previously mentioned possibility of side effects of importing a plugin
in this way.

If there is another way of preventing that problem, then we could look
at removing that aspect of main() calls.
Otherwise, we absolutely must not.


 Also, new conventions and directories does not solve my wish to call
 pydoc on plugins (which is not very important.  I hope to download a
 prototype Inspect plugin to gimp registry soon.)  But it illustrates
 that you can't always anticipate what people will want to do.

I wanted to do that too.
Just because you want to do something, doesn't mean it's wise to do so.

Calling pydoc on unguarded python modules is just as unpredictable as
importing unguarded python modules. Why? Because the way it gets the
documentation is by first importing the module in question.
Furthermore, all GIMP plugins' dependency on the 'gimp' (and/or
gimpfu, etc..) modules mean that even if they are in the module search
path, pydoc's attempt at importing them will fail (because the gimp
and gimpfu,etc.. modules are only available to Python scripts that are
being run by GIMP).Changing the mechanics of main() would not effect
that.

If you don't believe that, it's easy to check; set PYTHON_PATH to your
plugins directory (full, absolute path like
/home/llkk/.gimp-2.7/plugins), start Python, and try to import one of
those plugins as a module.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init

2010-03-03 Thread David Gowers
On Wed, Mar 3, 2010 at 10:16 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote:
 On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann s...@gimp.org wrote:
 On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote:

 I wonder if importing a plug-in from another plug-in is really something
 that we want to support. If the goal is to share code, then perhaps the
 code that is worth sharing should be factored out into a Python module
 that the plug-ins can import.


 Every Python program is also able to be a python module that plug-ins
 can import. We should preserve this feature of the language.

 (For example, one can implement an app with a comand line interface,
 and then just add a GUI in another file that uses the functions
 defined on the stand-alone first file).

I've considered this problem a fair bit, and my opinion is that if you
want this functionality, you should simply guard your register()s. We
cannot safely 'co-opt' python plugins that are not written with this
functionality in mind, as they are designed to be run always in an
independent process (hence they may do initialization which confuses
the calling program, or vice versa); there is no modification to GIMP
which could permit that, it is a logistical problem not a technical
one.

Allowing python plugins to make separate modules available on
installation, similar to Sven's suggestion, seems to me the most
practical suggestion. This means we would add two items to sys.path --
one the site modules* directory, and the other the modules* directory
belonging to the specific user, which the installation of the plugin
package could put modules into.

We could further postulate that the normal python modules directory
should be the destination of modules that do not require GIMP running
in order to function, and only GIMP-requiring modules would be
installed in it's modules* directory.
I make this distinction because there are various good reasons not to
install gimp-dependent modules in the global namespace (for example,
pydoc and the general help() facility get confused because the imports
of gimp modules fail.. so you can look up a specific module, but not
search.)

* I realize 'modules' is a term already used in the gimp directory
structure. This is meant as a placeholder for something
else...python-modules?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] moving windows in the git version

2010-02-17 Thread David Gowers
On Wed, Feb 17, 2010 at 6:07 PM, Olivier oleca...@gmail.com wrote:
 For several weeks now (I compile the git version every Monday), the windows
 in normal mode (i.e. multi-window mode) behave in a weird way: I place them
 where I want them on one virtual screen, and then I move to another one
 virtual screen. When I come back, the windows have moved to a different
 place, always the same.

 I'm with Debian testing and GNOME.
I can confirm this (although I'm using Arch Linux + AwesomeWM) : I put
the toolbox over at the right edge of the screen.
When I come back, it's squashed ridiculously narrow near the left edge
of the screen.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] paint dynamics

2010-02-16 Thread David Gowers
On Wed, Feb 17, 2010 at 8:24 AM, LightningIsMyName
lightningismyn...@gmail.com wrote:
 Hello

 On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death alexiade...@gmail.com wrote:
 2. The painting of the matrix as showed in the specifications seems
 very hard, and I doubt it worths it. We can easily implement different
 colors for each row, and users will have to settle for a little border
 between the columns.

http://www.pygtk.org/docs/pygtk/class-gtktreeview.html

Looks like it is possible to disable cell borders (and I think it may
be necessary when the cells are small like this-- we want to avoid the
borders visually overwhelming the cell content.

 If we agree to give up the proposed matrix
 painting and choose what I suggested, it can be done with GtkTreeView
 without any special changes, but it will leave the simpler GtkTable
 our of the question (which is fine with me).
 3. Adding the images with the link's color should be a bit tricky, but
 I assume that it can be done dynamically (by drawing those images
 after acquiring the link's color, instead of embedding ready bitmaps).
 4. Popup window: Part 1 - the curves widget. This can definetly be
 stolen from the curves tool, no need to work twice. The only needed
 modification is that we can show some other curves at the background,
 and that we add min and max arrows.
 5. Popup window: Part 2 - switching the tabs. This doesn't seem to
 bad, especially since we already have similar functionality in the
 curves tool.

 only two things seem problomatic:
 A treeview widget can't have a bitmap in it's header, And adding the
 bitmaps as the first row is ugly and probably not the right way to do
 this. The guys on the GTK mailing list will probably be able to help
 us out here.
 And another questions is, why do we have the same header images at the
 bottom? Adding a footer to a GtkTreeView isn't possible. Do we really
 need that? Here i'm defintly sure it's not worth the coding amount
 that it will require, and I personally find it confusing.

I believe that this kind of measure is usually taken when the number
of input variables is anticipated to increase (so perhaps you won't be
able to see the top and bottom at the same time)



 I haven't seen anything that scary in here, but I doubt that I'll have
 time to touch it in this month. If I implement something like this on
 a dummy GtkWindow (instead of hacking GIMP's source code, which I
 don't excel at) as a stand-alone Gtk application, will it help?
 If so, I'll try to give it a shot.
 If you want to see how to use the TreeView and the CellRenderer, the
 gtk-demo program (which comes with GTK) has a nice example under Tree
 View/List Store. The code is very simple and in one of the columns
 you'll see the Toggle renderer.

 for example, one dock needs to hold 2.5 distinct views
 I haven't understood that sentence. Can you please explain (or, have I
 referred to it already)?

I think I understood it: one dockable must hold
a) the matrix,
b) the input mapping, and
c) the output mapping

I thought this was a fairly simple problem in GTK terms.

1. Put the matrix inside its own VBox. Pack it at the start of the window.
(This may require nesting inside another VBox.)
2. Put the input and output mapping in another VBox (one they share.)
in the following manner:
  1. Presets (shared between input and output)
  2. Inputs selector
  3. Outputs selector
  4. Curve display (shared?)
  5. 'Inputs' label
  6. 'Outputs' label
  7. Inputs treeview
  8. Outputs treeview
  9. 'Show current INPUT NAME input'
3. When switching modes, we:
  1. If switching to matrix mode, hide the input/output vbox. Show
the matrix vbox. Done.
  2. If switching away from matrix mode, hide the matrix vbox.
  3. If switching to inputs or outputs mode, we need to iterate
over the widgets in the VBox; Hide any widgets not specific to the
mode in question.
 I think there is a widget grouping mechanism in GTK that
allows for this kind of distinction.

That is in fact somewhat ugly.
There is probably another solution involving packing the input/output
widgets on the fly. That would be neater code-wise, and somewhat
slower.

I don't know whether the above would argue with the dockable's idea of
how tall it ought to be. That might be what Alexia was talking about.

 Just one offtopic comment: Some of the icons seem very unintuitive -
 even as an old GIMP user I'm still confused by the fifth one from
 the left. What does it stand for?

It looks like it's probably meant to be 'random'. I got that from the
list, not the graphic, though.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread David Gowers
On Sat, Feb 13, 2010 at 5:22 PM, Jon Cruz j...@joncruz.org wrote:
 However, the answer to the base question is Yes, X and Gtk support that to
 a very good degree, and all the low-level API's support delivering all the
 required information.
 and No, X does nothing with the colorspaces. It is left to the application
 to implement
 It also is more of a per-monitor issue, rather than per-pixel. So one
 generally will have to deal with a small set of rectangles (two being the
 most common) to adjust. So it's not *quite* up to the complexity of a purely
 per-pixel problem.
 I also would question the assertion that it is an uncommon use case. Those
 most likely to be working seriously with images are generally much likely to
 have two (or more) monitors. They also have a higher chance of caring about
 color fidelity.

I agree; GIMP windows should support color management for individual
image windows according to these atoms, absolutely;
What it would be of little use to do, is to support showing the SAME
image in a single window spanning multiple monitors, with different
colormanagement for each monitor-segment of that Single window.
As I understand, that is what Christopher was requesting and yahvuu
was accurately describing as an uncommon use case, rather than the
general case of one image window on this monitor, one on that, and
they are color managed differently because of it.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-12 Thread David Gowers
On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira
shirakawa.ak...@gmail.com wrote:
 On 2010-02-09 19:52, Martin Nordholts wrote:
 GIMP is nearly flawless in its color handling, but there is one
 problem. It forgets to convert copy and pasted image content.

 Also don't forget that the various color picker/selectors aren't color
 managed at the moment, so selected colors (FG/BG colors) will look
 differently when painted on a color managed image.

I think color management of individual colors and color selectors is a
tricky subject.

* Color selector colors must be stored in a profile independent
colorspace (LAB?[1]). This ensures that we can paint any color onto
any image and get the right result. Otherwise, we'd have to know the
profile that the color was specified in, in order to use the correct
color on the image we're painting in now.. which makes color storage
way too heavyweight.

* We should consider improving the color history system.
  MyPaint has one with the property that I think is important here: A
color gets added to the history once it is 'read' (in Mypaint's case,
when you paint with it;
   In GIMP's case, this would also be if it was read via the PDB (ie
plugins or scripts)). And the previous color is shown in the color
selector side-by-side to
the color you're now adjusting. This makes it easier to do color
comparisons, which are pretty important to get right when the previous
color and current color are based on different color profiles.

* We should be able to a) specify colors outside of the color profile gamut
  and b) clip the current color to the limits of the current color
profile when painting, previewing etc.
  b) should probably be a toggle, then it could be quite helpful in
quick soft-proofing

* Some of the color selectors are already quite slow (eg. the 'scales' one).
  We should avoid making them slower if possible.

[1] correct me if I'm wrong here... scRGB might do the job okay, I'm
not 100% sure.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] TAB in single-window mode

2010-02-05 Thread David Gowers
I decided I couldn't quite submit a gimp-brainstorm item with this
little content:

TAB normally toggles the visibility of the docks, including toolbox.
In single window mode it doesn't (and IMO it would be good if it did
-- single non-fullscreen window is a lot more cooperative with other
app windows than simply toggling fullscreen is.).
I wanted to mention that in case it was simply overlooked rather than difficult.

 Looking at the code in display/gimpdisplayshell-callbacks.c and
widgets/gimpdialogfactory.c, I found it difficult to tell.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP 2.8 schedule

2010-01-12 Thread David Gowers
On Wed, Jan 13, 2010 at 8:57 AM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On 1/11/10, Martin Nordholts wrote:

 Then the ETA of GIMP 2.8 becomes 2010-12-02 which is more
 reasonable.

 And still somewhat scary :)

 The plan however does not seem to mention Python scripting
 improvements branch. (which will make estimations only scarier :))

I thought that had already been merged.
Was it only a partial merge?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] PF_FILE of the register function in python plugins with 'new file' support (Scott)

2010-01-12 Thread David Gowers
On Wed, Jan 13, 2010 at 5:52 PM, Mathias Lindner mathias.lind...@web.de wrote:
 My way around this was to use a PF_DIRNAME immediately above the PF_STRING
 and combining them for the total path.

 Ah, thank you very much. I wasn't aware of PF_DIRNAME. It's missing in the 
 GIMP Python docs. This way I have a nice workaround which totally fits my 
 needs.

 What else PF_ data types are missing in the docs? Or the other way around: 
 Where can I read about all currently existing types?

/usr/lib/gimp/2.0/python/gimpfu.py defines the types on a standard
Linux install of GIMP. I think
all except PF_DIRNAME are documented, though. (there's no steady
maintainer for PyGimp or its documentation, so making sure it's up to
date is currently somewhat a matter of luck)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] gtk-doc 1.13 problem with recent gimp git (+solution)

2010-01-06 Thread David Gowers
Recently I found that GIMP from git would not compile, as it couldn't
get past the ./autogen.sh step..
It would produce quite a few errors, like this:


gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
devel-docs/app/Makefile.am:116:   `gtk-doc.make' included from here
gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL
devel-docs/app/Makefile.am:116:   `gtk-doc.make' included from here
gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
devel-docs/libgimp/Makefile.am:64:   `gtk-doc.make' included from here
gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL
devel-docs/libgimp/Makefile.am:64:   `gtk-doc.make' included from here
gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
devel-docs/libgimpbase/Makefile.am:52:   `gtk-doc.make' included from here
gtk-doc.make:58: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL
devel-docs/libgimpbase/Makefile.am:52:   `gtk-doc.make' included from here
gtk-doc.make:53: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
devel-docs/libgimpcolor/Makefile.am:46:   `gtk-doc.make' included from here


I noticed in my pacman logs, I had upgraded gtk-doc recently:

[2009-12-21 10:55] upgraded gtk-doc (1.11-2 - 1.13-1)

So I eventually decided these BUILD_PDF and BUILD_HTML flags were new
in 1.13 (or 1.12 if it exists) and required in configure.ac,
and I hacked around this, by adding

 AM_CONDITIONAL(GTK_DOC_BUILD_HTML, test x$jpeg_ok = xyes)
 AM_CONDITIONAL(GTK_DOC_BUILD_PDF, test x$jpeg_ok = xyes)

after

 AM_CONDITIONAL(BUILD_JPEG, test x$jpeg_ok = xyes)
 AC_SUBST(JPEG_LIBS)

to configure.ac

Of course, that is somewhat nonsensical.. perhaps 'true = xyes' would
work instead of 'test x$jpeg_ok = xyes'.
The above fix allowed me to build GIMP successfully (actually is in
progress now, so I'll check it actually finishes OK.. yep:)

It does seem odd to me that I get the above errors even if building
devel docs with gtk-doc is disabled... Is that a bug in configure.ac?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] new brainstorm...

2009-12-17 Thread David Gowers
On Thu, Dec 17, 2009 at 10:25 AM, peter sikking pe...@mmiworks.net wrote:
 guys,

 I have pushed into service something that I brainstormed
 (no pun intended) ages ago with Roman Joost:

 a brainstorm where anybody can contribute a tip-of-the-day
 for GIMP: http://gimp-totd.blogspot.com/

 I expect this to quickly give a lot of input that (with some
 manageable editing by the docs team) will grow our tips db
 by an order of magnitude (or two).

 when that point has been reached, we can talk again about the original
 plan to give tip-of-the-day a new home in the no-image-window.

     --ps

Just a quick note on something you might want to correct:

Send your image to us, put the word ‘GIMP tip’
^ image - tip
:)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Making dockable tab style a global setting

2009-12-07 Thread David Gowers
On Mon, Dec 7, 2009 at 6:48 PM, Martin Nordholts ense...@gmail.com wrote:

 GSR - FR wrote:
  Hi,
  ense...@gmail.com (2009-12-05 at 1330.57 +0100):
  I don't understand who would want a UI where tabs doesn't have the same
  style, what a mess
 
  I use icons for things that have true info in visual sense (colour,
  pattern, brush, palete, gradient) and text for the rest. For me it is
  a matter of less visual noise and more constant interface.

 Is there any particular reason you don't show this information in the
 toolbox (Edit - Preferences - Toolbox - Show brush, patter etc)
 instead of showing it in individual tabs? Wouldn't that decrease the
 visual noise even more?


In my case, the colors display (the only display I'm interested in) occupies
much too much vertical screen space. It's also awkward to have this color
display up there but the color editor below (I know you can edit colors by
double clicking on them. I find that more irritating and prone to be
accidentally triggered, for my usage (in which I constantly want to inspect
hex color codes, so seeing the color swatches is only part of what I want
anyway.))
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Airbrush/Brush Banding Effect At Low Pressure/Opacity

2009-11-18 Thread David Gowers
On Thu, Nov 19, 2009 at 11:17 AM, James Cox jay...@gimp.org wrote:
 Christopher Howard wrote:
 Thinking about this some more, the error diffusion is probably not even
 necessary.  You should be able to get by with some random dithering like
 the following (if it wasn't slower than molasses):

  result = floor(input * opacity + g_random_double());

If you pregenerate a lookup table (say 256 entries), keep a counter
which cycles 0,1,2,255,0,1,2,255, and only add a random
integer to that counter at the start of every dab, you could get that
going at decent speeds.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re branding ....

2009-10-31 Thread David Gowers
On Sat, Oct 31, 2009 at 2:12 PM, vabijou2 vabi...@yahoo.com wrote:


 Christopher Howard-3 wrote:

 Its about having a product you aren't afraid to advertise. . As soon
 as I say GIMP, you can see
 the doubt on their faces, because they associate the word with being
 weak or lame.

 I agree with this.  Many people shy away from using products that aren't
 mainstream, and have little to do with (or knowledge of) open source
I have to agree that Photoshop *is* mainstream to the degree that
image editing is -- as a verb at least.. people use PAINT.NET or
whatever and say they 'photoshopped' it.

I think Patrick is missing that 'mainstreamness' is relative (theres
'mainstream for the culture', 'mainstream for artists in that
culture', 'mainstream for digital artists in that culture',
'mainstream for pixel artists in that culture'.. these levels of
detail nest to produce the overall context in which something can be
said to be mainstream or not.

 software alternatives.  There is nothing about the current name that
 inspires confidence or denotes competence.

Personally I don't recall ever encountering a program whose name
inspired confidence or denoted competence to me, in this
out-of-context way you are talking about.
Except perhaps Lotus 1-2-3.

For example, the following inspire confidence in me and I feel they
are competent. Perhaps they have some common factor, I think it's more
likely that it's just an understanding of how they
work (and that that way is a good way to work) that inspires
confidence and 'denotes' competence

Python IPython PyTables NumPy SciPy Allegro Grafx2 Charm DosBox Lua
Inkscape FontForge SQLite Lynx Midnight-Commander Thunar

It looks like there is a 'Mildly witty' theme going there, along with
a preference for literality and brevity. OTOH it could be simply that
witty, literal-minded people tend to produce software I find
competent.



 I think that the time to change the name would be when a release comes out
 that has an option to run in a single window.  This is a major change that
 people have requested for some time and this new configuration is sure to be
 discussed widely on the internet.  That version could be called something
 like Gimp+.  Over time this might become shortened in blogs, forums, etc.
 to G+,
'jeeples'? lol. I'm sure the FSF people would like it :) How do we
verb it though? jeepling? BWAHAHAHAHAHA. (more seriously, G+ is
extremely close to the name of the gnu C++ compiler, G++)

At the 'G+' point, the major internal renaming would need to take
place, and that would require
far more developers and far more organization than the GIMP project
currently has.
Even simply switching from GIMP to GIMP+ (I'm -1 on 'Gimp+') would
involve considerable effort (mainly in keeping I18N current).

 and then a later major release could use that as the name.  The
 whole time, Wilber the mascot would remain basically the same to provide
 continuity.  I'm no ad wizard so I don't claim this is the best naming
 strategy, but I think it provides an example of how the rebranding process
 could go.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The name Gimp

2009-10-30 Thread David Gowers
On Fri, Oct 30, 2009 at 9:43 AM, Brendan mailingl...@endosquid.com wrote:
 On Thursday 29 October 2009, you wrote:
 On Thu, Oct 29, 2009 at 2:07 PM, Brendan mailingl...@endosquid.com wrote:
  All the above comprise a significant factor in why forks are regarded,
  at best, as a necessary evil. All forks dilute branding, which
  introduces user confusion and repels potential users.
 
  I think it's incorrect to say it repels potential users and leave it at
  that. It will also just as likely ATTRACT new users who were put off by
  the lame name.

 That's speculative. We know from past software history that what I

 The extent is speculative, the same as you. I know an entire office who said
 they would use it if it changed the name, so it's not nearly as speculative as
 you think.
Fair enough.


  Call it the Gnu IMP.

 This has to be facetiousness, doesn't it?

 Most of what I say is at least slightly facetious. If they simplify it
 themselves, that's their problem, and not something that is super-obvious.

If we look at the way the photoshop family of products are abbreviated
by people(PS7/CE4/Elements),and GNU projects (bc, bash, tar, Octave,
etc), just plain IMP is reasonably likely. (in fact, GIMP is an oddity
in that the GNU is actually included in the acronym..
if it were more canonical, people would already be calling it Gnu IMP
or IMP). That's fair enough.. IMP *is* a better name (and people who
object to it on religious grounds probably are terminally humorless),
we just should expect it to still manage to be taken as objectionable.

Actually, I'm in favor of your proposition now, you've convinced me.
Gnu IMP is 'backwards compatible' as you say, more in line with other
GNU projects' naming, and could result
in image* improvement in the future.

As long as it's not a fork -- that is, the renaming would need to be official.

* The kind that doesn't have pixels in it :) but, well, the other kind
too I suppose :)

A list of files that would need modification:

HACKING
NEWS
gimpui.pc.in
[a few utility scripts like gimp-zip]
[most files with 'gimp' in the filename would need renaming. that is
1686 files to rename]
[All enumerations which include 'GIMP' in them]
[.gimp-2.x would need to be migrated to .imp-2.x .. and then symlink
.gimp-2.x to that]
[On Linux, create a symlink 'gimp' pointing at 'imp' (or something like that)]
[We'd need to deliberately avoid changing the XCF and rcfiles format,
which refer to such object types as 'gimp-image-grid',
'GimpDeviceInfo', 'gimp-channel-list'.
Note: some rcfiles include 'gimp' in the names of objects, others do
not. I don't fully understand why.]
[themes would need to be updated to refer to 'imp-*' widget classes
rather than 'gimp-*' widget classes]

All active/'pending' branches would need to be updated to match (this
would be mostly trivial, I expect situations where new enumerations or
files were introduced to be more involved)

This would be quite time-sensitive in order to maintain a functional
GIT repository -- it would need to compile successfully again within 3
days. So it might take a small team just to complete this. Then the
documentation would need to be synchronized with the change
(screenshots, textual references to 'GIMP') fairly promptly after that
-- which is IMO quite hairy due to I18N concerns.

All *gimp* pdb functions would have to be deprecated in preference to
*imp* versions.

.po files would all need to be updated, however this would not need to
be done all in a lump but could be spread over time.

All the above would be best done at the beginning of a development
cycle (eg. when 2.8 has just been released). It would be relatively
free of the potential for invisible bugs -- most problems would show
up as compilation errors.

I believe the above is the minimum required to seriously do that
change. Though of course we could begin with the user-visible things
(binary names, and strings) and progress to the developer side
(filenames and  enumerations).. it would still be vital for it's
success to quickly do the migration on the developer side, which is
the majority of the work involved.

I can see why GIMP developers would want to avoid such a thing. I do
believe that the migration wouldn't require more than a very basic
understanding of the GIMP code base. What it would really need is a) a
great deal of organization and b) an active and moderately large team.
(doing only the user-visible side is a possibility.. but this may
result in confusion where eg. a PDB function is named gimp-* where the
program says it is 'IMP')

PS. 'The GIMP' is anachronistic AFAIK -- GIMP (no 'the') is canonical currently.
PPS. I believe (haven't tested, my GIMP GIT clone is not in working
order currently), that the
option '--program-transform-name=s/gimp/imp/g' to configure would
result in appropriately named binaries (imp-2.7 etc)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU

Re: [Gimp-developer] The name Gimp

2009-10-30 Thread David Gowers
On Sat, Oct 31, 2009 at 8:56 AM, Christopher Howard chow...@indicium.us wrote:
 Alexia Death wrote:
 On Fri, Oct 30, 2009 at 12:40 PM, David Gowers 00a...@gmail.com wrote:
 On Fri, Oct 30, 2009 at 9:43 AM, Brendan mailingl...@endosquid.com wrote:
 A list of files that would need modification:
 ... SINP LONG LIST...

 And all of GIMP code. 98% functions are prefixed as gimp. You can try
 to grep for gimp on gimp source tree. Forget it. Some English speakers
  discomfort at the name is getting a bit ridiculous IMHO.



 A note: The end users don't care what the functions are called. Just the
 name of the binary, the logo, and the title bar.

That's sort of beside the point. Having the developers see things
differently than the users disincentivizes people to be both users and
developers (which is definitely the optimal choice
for ongoing improvement of software quality). If the program is called
imp but all the functions are gimp_, that introduces cognitive
dissonance (which amounts to confusion+annoyance in this case) which
discourages the users from developing.


 The discomfort at the name for me has nothing to do with some moral
 objection. Its about having a product you aren't afraid to advertise.
 When I start extolling the virtues of open source to my buddies, one of
 the first three objections I usually get are but there is no good
 graphics software like Photoshop. As soon as I say GIMP, you can see
 the doubt on their faces, because they associate the word with being
 weak or lame.

 If Mozilla's browser today was name Mozilla Slug, or Bloat Browser,
 how many people do think would be wearing the tee-shirt or showing off
 the desktop wallpaper?

The difference being that slug or bloat are not narrowly-scoped
cultural references: almost everyone knows what a slug is, and a
majority of computer users end up understanding what bloat is. By
comparison, the first time I heard of gimp meaning anything -- except,
well, the program we're talking about! .. was a thread here about this
very same subject. Others have expressed similar sentiments. You're
acting like 'gimp' is a universal English cultural artefact. It's not
(it's mainly an American one).

It seems to me that such threads simply manufacture means of objection
for trolls who don't want to adopt something new, because it's new.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] ceci n'est pas une selection...

2009-10-30 Thread David Gowers
On Sat, Oct 31, 2009 at 10:59 AM, peter sikking pe...@mmiworks.net wrote:
 guys,

 would like to tap the wisdom of this crowd here.

 say I have made a selection in GIMP, done what needed to be done to the
 pixels in the selection and now want to get rid of the selection.

 the obvious way is Select-None.

 how many more ways are there?

1. Use rectangle/ellipse select to select nothing (single click)
2. Activate QMask, drop black on the image, exit QMask
3. Use the Move tool in Selection mode to throw the selection mask off canvas.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] ceci n'est pas une selection...

2009-10-30 Thread David Gowers
On Sat, Oct 31, 2009 at 12:30 PM, Liam R E Quin l...@holoweb.net wrote:
 On Sat, 2009-10-31 at 01:29 +0100, peter sikking wrote:

 the obvious way is Select-None.

 how many more ways are there?

 Save the image as png, quit gimp and restart. :D

 go to channels dialogue, make an empty channel, and do,
 channel to selection. (and then go to layers and select
 a layer in the image)

 use rectangle tool to marquee round the whole image in
 subtract from selection mode, and press Enter

 single-click with rectangle tool, outside the image (or ellipse tool
 probably, but not freehand tool)
It doesn't need to be outside the image, just outside the selected area.


 several others that other people suggested, I generally do
 shift-control-a.

I view that as performing the exact same action as Select-None, which
is why I omitted it.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The name Gimp

2009-10-28 Thread David Gowers
On Thu, Oct 29, 2009 at 5:35 AM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 Worse, I seem to recall the Gimp mascot being referred to as a gimp
 in multiple occasions on the website.

 You got it wrong. Mascot's name is Wilber and he thinks you should apologize.
No, John is correct: GIMP's mascot Wilber(sp?) is a gimp.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The name Gimp

2009-10-28 Thread David Gowers
On Thu, Oct 29, 2009 at 9:25 AM, Christopher Howard chow...@indicium.us wrote:
 John B wrote:
 Well, if it's out of the question, then I guess I'll just shut up
 before this becomes a big argument.
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

 It seems to be out of the question as far as convincing the developers
 here to ever do that. Under the terms of the GPL3, however, there is
 nothing to stop you from forking the code and doing that yourself.

 Probably the best way, I would imagine, would be to keep nearly all the
 code the same, but to add a configure options (like --better-name)
 that causes the logo and title bar name to be replaced. But if you were
 to go to all the trouble, you would want to come up with a really classy
 name and well-designed logo or else no one would care.

 I'm sure that has been mentioned in the archives as well, but I thought
 I'd mention it again in case you actually had the time and interest to
 do it. Personally, I don't like the name GIMP either, as it's not a very
 selling name. I know that annoys many of the (dedicated, hardworking)
 developers, but we all have the right to our own opinion.

It doesn't really matter that much to the developers *what* it is
called, as far as I know.
The point is really the branding... changing name will definitively
LOSE a lot of users, no matter what the current name is or the
intended name is.
There may be solutions to this problem (though commercially,
rebranding seems to involve a lot of expensive advertising). So far,
no-one has proposed one (or demonstrated that the current name is
problematic in an actual provable way -- just assertions that it is
offensive or not offensive in so-or-so region.).

All the above comprise a significant factor in why forks are regarded,
at best, as a necessary evil. All forks dilute branding, which
introduces user confusion and repels potential users.

So I do agree with one thing you said -- If you were to fork the
project you would need to do so really well. This would probably
involve forking the gimp-docs and gimp-gap similarly (and maybe also
FX-Foundry) in order to cover the 'gimp' references in these most
commonly installed accessories. It would also be important to make it
very clear that it is compatible with GIMP plug-ins, and therefore to
search GIMP's global plug-in/resource directories for resources as
well as the fork's plugin/resource directories (identifying and
ignoring duplicate resources). It would require the mascot to be
changed (and therefore also some of the icon set, as they include
Wilber), and also some (all?) of the gimp-docs screenshots, as well as
some of the example images in gimp-docs which use Wilber. It would
require a strategy for dealing with existing .gimp-2.7/ directories.

That's my understanding at a glance. Actually doing it well would be
more involved than the above, I expect. (for example, we use the
phrase 'happy GIMPing!' and similar verb-ing of the GIMP name.. so it
would help to have the replacement name be easily verb-able too)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The name Gimp

2009-10-28 Thread David Gowers
On Thu, Oct 29, 2009 at 10:41 AM, vabijou2 vabi...@yahoo.com wrote:
 So just because some old farts in Scotland may have good associations with
 the word, you think that renders the rest of the English-speaking world's
 interpretation silly?  %-|
Personally, I think the question you just asks renders you silly (and arrogant)
for presuming to speak for 'the rest of the English-speaking world'.
This is an issue on which opinions *are* divided within 'the
English-speaking world'.
I personally have never seen the movie 'Pulp Fiction' on which the
interpretation of GIMP as offensive seems to come, and while I agree
that 'Pulp Fiction' is fairly famous, I believe it's rather
America-centric to assume every English speaker holds that
association.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The name Gimp

2009-10-28 Thread David Gowers
On Thu, Oct 29, 2009 at 12:16 PM, Christopher Howard
chow...@indicium.us wrote:
 Stephen Griffiths wrote:
 When I mentioned forking the project I wasn't thinking of having a
 version of GIMP out there that was actually following a fully separate
 development path with a bunch of disgrunted GIMP developers. Rather, it
 could be the exact same thing except with a patched-in configure option
 or something that allowed rebranding. For example, in Gentoo (a source
 based Linux distribution) when you compile Firefox, you can pass in an
 iceweasel configure option that rebrands it with the Debian logos, or
 you can pass in a bindist option that rebrands it with generic branding.

Sure.. except, I listed the things that would be needed for that. If
you do not do at least most of those things, you would only be doing a
partial rebranding. You would have parts of the overall package
calling itself GIMP rather than the new name. If this would happen,
the confusion caused by it almost certainly would be more 'expensive'
in terms of user confusion/disgruntlement than simply leaving GIMP
branded as.. GIMP.

I'd also like to mention that I find the
iceweasel/icecat/shiretoko/minefield/firefox thing quite confusing. It
seems kind of useful in an abstract sense (minefield is .. dangerous,
iceweasel is strictly FOSS,..). There is significant differentiation
of mascots happening, though, unlike what you seem to be suggesting.

Rebranding could be automatic, but it couldn't IMO be simply a matter
of substituting text strings as you suggest with your 'configure
option' idea.
You would need to also have a different mascot, and consequently
regeneration of images would be needed (using a set of unbranded
screenshots + a set of mascot images).

It just occurred to me: the 'text substitution' would need to rewrite
PO files in order for I18N to function correctly.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The name Gimp

2009-10-28 Thread David Gowers
On Thu, Oct 29, 2009 at 2:07 PM, Brendan mailingl...@endosquid.com wrote:
 All the above comprise a significant factor in why forks are regarded,
 at best, as a necessary evil. All forks dilute branding, which
 introduces user confusion and repels potential users.

 I think it's incorrect to say it repels potential users and leave it at that.
 It will also just as likely ATTRACT new users who were put off by the lame
 name.

That's speculative. We know from past software history that what I
described actually happens.
(I'm not opposed to a rebranding. I just think that it would need to
be done a) really thoroughly and carefully, b) in cooperation with
GIMP developers, and c) released with very calculated timing. And also
that such a rebranding is very far from trivial to achieve.)


 Call it the Gnu IMP.

This has to be facetiousness, doesn't it?
In what parallel universe do you live in, that people will not
simplify 'Gnu IMP' down to 'gIMP'/'GIMP'?
For that matter, how is 'GIMP' (which may be considered offensive by
people who've seen Pulp Fiction, or
by disabled people) better than gIMP (which may be considered
offensive by religious nutcases)? It seems to me that there are far
more people in the latter category.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The name Gimp

2009-10-28 Thread David Gowers
Incidentally, I like Stephen's 'Wilber/ Wilber Image Editor'
suggestion (in another related thread).
I'm envisioning someone using the latest GIT version because they
*have* to be up-to-date with the newest stuff, the program crashing
and destroying their work, and they cry 'No! WIEEE?' :D

/silly

(I do genuinely like that suggestion, just to be clear)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] single-window fix and WMs

2009-10-24 Thread David Gowers
On Sat, Oct 24, 2009 at 6:43 PM, Ilya Zakharevich
nospam-ab...@ilyaz.org wrote:
 On 2009-10-21, Karl Günter Wünsch k...@mineralien-verkauf.de wrote:

 IMHO the move to a single image window with dockables would solve
 quite a lot of interoperability problems. For example there are
 plenty of broken window managers out there. Relying on them (WM
 developers) getting it right in the end for the GIMP is proving to
 be a long wait.

 You are right, somehow I assumed that the problems of GIMP's window
 management would be solved.  Taking into account the history, this was
 a short-sighted assumption.

There are no problems of *GIMP*'s window management.
Your failure to understand this is the reason that people are getting
annoyed at you.


 As desktop environments go the window managers that
 work with the GIMP as intended tend OTOH to be the ones that don't
 play well with KDE for example (if you even have the choice, which
 you haven't really in KDE4). Oh and windows is a beast that isn't
 handled easily as well

 BTW, I see again and again this assumption that the responsibility
 for observed problems of GIMP may be shifted to WM's problems.  I
 never could understand it.

WM is only responsible insofar as having the WM behaves in a
consistent and predictable way is very helpful. On Linux, virtually
all WMs conform to the ICCCM window management standard (the window
management hints in GTK+ were designed based on ICCCM, I think). On
Windows, the management conforms to no recognized standard.

So the WM holds some responsibility in such misbehaviour. The main
responsibility is GTKs.

In the case where I confirmed the TAB behaviour, I suspect that's
because I haven't configured AwesomeWM correctly: in my case it is
focusing the toolbox window when it reappears, instead of keeping the
focus on the image window.. this is what is preventing TAB from
working, and it's definitely outside of both GIMP and GTK+'s scope to
address this. I'm currently looking at how to fix my configuration.


  [Keep in mind that my experience in apps--WM interaction is rather
   minimal - I participated in porting Perl/Tk toolkit from X11 to
   non-X11 system, and watched the corresponding mailings lists for
   slightly more than a decade.]

 Here is the picture as I understand the rare morcels I saw:

  a) on window creation, GIMP registers a few bits of information with GTK++;

  b) the exact meaning of these bits is not documented, and is known
     to vary widely;
Completely false.

http://library.gnome.org/devel/gtk/unstable/GtkWindow.html
http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#GdkWindowTypeHint

Provides comprehensive documentation, even though it may not be in the
language you most easily understand. Missing content for certain
languages is not at all the same as missing content for all languages.


  c) the observed results are most of the time not what one would want;

This is true. Even on the stated standard, Metacity, some odd
behaviour with TAB seems to be happening (Every time the toolbox
reappears, it has moved down and to the right somewhat.)

I'm not sure if there is any problematic behaviour on other WMs like
the KDE window manager, XFCE, fvwm, blackbox/fluxbox/etc,
WindowMaker..


  d) the interpretation is that it's somebody else's fault.
'somebody else'.That's vague. GIMP devs have been specific and
definite about this problem for a long time: it's GTK+'s fault. GIMP
provides specific information, which it is GTK's job to interpret and
pass onto the WM in a way that it can understand. GTK+ currently fails
to translate certain information accurately for the Windows WM.

You can scream until you're blue in the face and it won't make this
any less true.


 Obviously, I'm missing something...  I hate to ask for somebody else's
 time, but I would appreciate a correction (or at least a reference to
 older discussions...).

 the window manager there sucks at managing applications that consist
 of multiple single windows that don't have a proper native
 inheritance structure

 I'm pretty sure that this is NOT how it happens in Windows.  AFAIK,
 there is no window manager; each application is responsible to arrange
 the x/y/z-order of its toplevel windows itself (there is a simple
 callback interface for such arrangements).

There is window management -- otherwise you could not close windows,
or minimize or maximize or move or resize windows (or switch between
windows like with ALT-TAB or clicking). In fact window management
covers more than the initial creation of windows, but also their
movement, resizing, reordering, delivering keyboard and mouse events
to the right windows, etc.

The callback interface is not unique (in fact GTK implements it in a
way that works on all platforms and WMs I've tried, which are many, so
the 'callback' behaviour appears to be ubiquitous rather than unique
to Windows.). With most WMs, the client program has a high degree of
control over the particular behaviour of the 

Re: [Gimp-developer] Icons for layer modes

2009-10-23 Thread David Gowers
On Sat, Oct 24, 2009 at 9:48 AM, Ilya Zakharevich
nospam-ab...@ilyaz.org wrote:
 On 2009-10-21, yahvuu yah...@gmail.com wrote:
 The analogy was given to show why the the current interface to blending
 (i.e. choosing among a discrete set of layer modes) is a poor one:

 And my message was intended to show why the current interface is a
 very good one...

 it is both limited and mostly non-intuitive.

 IMO, non-intuitive is 100% fault of GIMP developers.  The current
 documentation is plain insulting...

At this point I support banning you from this list for your repeated
insults and self-righteous attitude towards people who are freely
volunteering their time and effort.

Further, insulting people who have very little to do with the subject
is even worse (GIMP documentation is managed by different people,
there is very little overlap between GIMP docs development and GIMP
development)


 Layer modes is a very simple and intuitive concept.  The only thing
 missing is documentation (I'm going to address it in more details when
 the waves from my previous posts would subdue...)

The documentation of layer modes is outstandingly clear and thorough
-- this is largely due to 'scb' and later 'j.h's excellent work, as
you can see in the comments.

http://git.gnome.org/cgit/gimp-help-2/tree/src/concepts/layer-modes.xml

The only thing I would change about that documentation if I knew how,
is make the images showing the effect of specific layer modes change
to the base image on mouse-over so you can easier discern the exact
effect.

Rather than better documentation, I believe better visualization is
the path to improvement of user understanding:
Using the layer thumbnails (and GEGL cache?) to build a 'preview'
composited thumbnail for each mode and show it  (next to the text or
as a tooltip) would help the user to understand at a glance the
general working of a layer mode they are considering. The composite
thumbnails could be generated on-demand and otherwise in idle time (so
the person who knows exactly which layer mode they need would not be
impacted -- they could select layer mode just as fast as before, and
if they did need the thumbnails, they'd only need to wait a fraction
of a second longer.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Would single-window fix usability nightmares?

2009-10-22 Thread David Gowers
On Thu, Oct 22, 2009 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote:
 On Thu, Oct 22, 2009 at 12:54 AM, Ilya Zakharevich
 nospam-ab...@ilyaz.org wrote:
 I can see how a John Do can blame GIMP for GTK+ issues, but I don't
 see why GIMP developers should bother about John Do's misconceptions
 about software development.

 These are not misconceptions.  Software does not modularize; at least
 not in the sense of dilution of responsibility.  If you use a library,
 its bugs BUG YOU.

 I think that it is one of the STRENGTHS of FOSS that if there's a bug
 in a component users of that component do not try to hack round it,
 but expect the bug to be fixed at the source benefiting everyone.

 I'm sorry to say this, but your attitude is starting to piss me off.
 Your attack mentality and complaining are not helping. Perhaps you
 should stop that and do something that would actually help, like
 contribute some code.

 We work on gimp for FUN. Most of us do not use Windows(I don't have
 one for my personal use) and those that do are not skilled enough to
 do GTK development on that platform. We do what we can. I personally
 got involved in the project by hunting a bug that ended up being in
 GTK. It got fixed. True, the bug was specific for Linux, but that's
 the platform I do my development on. I done have neither the will nor
 skills to do that. You can do it on windows if you want.


This :).

You said all the things I wanted to say but didn't figure out how to express.

I won't say anything else to avoid being inflammatory.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Would single-window fix usability nightmares?

2009-10-20 Thread David Gowers
On Wed, Oct 21, 2009 at 1:42 PM, Ilya Zakharevich
nospam-ab...@ilyaz.org wrote:
 On 2009-10-21, Tor Lillqvist t...@iki.fi wrote:
 It is pointless to describe the misbehaviour of GIMP windows on
 Windows to GIMP developers, as they don't use Windows themselves.

 Let me restate it:

  it is pointless to fix bugs/problems on windows, since they do not
  happen (and if they happen, developers do not want to see reports).

No, it means the bugs are in GTK+, not GIMP, and it requires GTK+
developers who run Windows to fix these bugs (or a GIMP developer who
runs Windows and has some knowledge of GTK+ and an inclination to fix
these bugs). Do you seriously think a person running Linux is going to
be able to reliably fix a bug that only shows up on Windows?


 Are you sure that the situation is as you describe it?

 To see GIMP behave as it is supposed to, you need to use it on Linux.
 The reference window manager is metacity, as far as I know, but also
 other window managers might work well enough.

 Sorry, but I find this attitude as misplaced as one in the previous
 paragraph...

Your expectations that GIMP will exert such extreme control over the
window management are also unreasonable. Your window manager manages
your windows, GTK+ communicates to the window manager what window
behaviour GIMP is asking for, GIMP communicates to GTK+ what window
behaviour it wants. The particular 'communications breakdown' is
between GTK+ and the Windows window manager, GIMP is not involved in
the problem, only a casualty of it.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Would single-window fix usability nightmares?

2009-10-20 Thread David Gowers
On Wed, Oct 21, 2009 at 11:22 AM, Ilya Zakharevich
nospam-ab...@ilyaz.org wrote:
 On 2009-10-02, peter sikking pe...@mmiworks.net wrote:
 However, I do not see how much this would affect the (AFAIK) main
 complaint about multi-window GIMP: that having several windows with
 several possibilities of what is focused requires many extraneous
 mouse clicks and/or keypresses.

 the introduction of a single window mode is in no way related to that.

 Good to know; so let me refine: is there ANYTHING in the move to
 single window which would not be achieved by

  a) restricting the maximal size of image window to the gap between
     two toolboxes; and

  b) making z-order changes syncronized between the main window and
     toolboxes?

 (I mean: whenever z-order of main GIMP window changes *wrt non-GIMP
 windows*, the z-order of dependent windows changes accordingly.
 Same for toolboxes: similar changes in THEIR z-order should be
 reflected in the z-order of the current image window)

 When the windows are merged into one, STILL only one of subwindows has
 a focus?  So how does this improves the current nightmares (e.g.,
 keyboard shortcuts not working - especially when most needed ;-)?

 that is a serious bug.

 in what version(s) of GIMP does this happen?

 2.6.6.  Tested on Windows.  Examples:

 a) Press TAB (toolboxes disappear);
   Press TAB (toolboxes  reappear, focus on Layers);
   Press TAB - now you navigate Layers toolbox.

I can reproduce this very annoying behaviour. I have to refocus the
image window in order to get TAB to work again, and basically gave up
on using TAB at all. Platform: Arch Linux (i686), GTK 2.16.5, Window
Manager: AwesomeWM 3.3

I believe my WM always focuses the newly shown window, which may
reflect on this behaviour.


 b) Focus to Layers.  Press F11.  Nothing.  Press o.  Nothing.  Press 4
   (user configured to 1:4 zoom).  Nothing.

I can't reproduce this; all keyboard shortcuts work as expected,
except where they conflict (for example, when a text-entry field like
palette or color name is in focus, you have to be able to type o as an
ordinary letter). May be Windows-only.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] We should go for a single-window mode in 2.8

2009-09-20 Thread David Gowers
On Sun, Sep 20, 2009 at 8:30 PM, jolie S for...@gimpusers.com wrote:
 Also I've slept on it and given it some more thought and I'd like to ask
 again if you would please give having multiple images open at the same time
 some more thought.
 IMO being able to work on more images at the same time is VITAL for a
 professional image editing program. (just think of cloning to name 1 example)
 Please give your users the options to do so in both modes, single and multiple
 windows.

Peter's specification does give the option to have multiple images open at once.
Perhaps you mean having multiple images both visible and workable-upon
at once. That's certainly important for things like cloning, as you
said.

Perhaps a split-panel option for single window mode would resolve
this. (I believe we could still only reasonably show a maximum of 2
images at once; this is simply a limitation of the single-window
format AFAICS.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] We should go for a single-window mode in 2.8

2009-09-20 Thread David Gowers
On Sun, Sep 20, 2009 at 8:57 PM, Liam R E Quin l...@holoweb.net wrote:
 On Sun, 2009-09-20 at 20:51 +0930, David Gowers wrote:

 Perhaps a split-panel option for single window mode would resolve
 this. (I believe we could still only reasonably show a maximum of 2
 images at once; this is simply a limitation of the single-window
 format AFAICS.)

 Do you mean that the windows would be too small, e.g. on a 30
 cimena display or with 5 LCD monitors :), or do you mean
 that the toolkit only supports two panes??
Too small (except on a 30 single display. 5 LCD monitors is not a
situation in which I can reasonably imagine you would want to use
single-window mode; feel free to contradict me if you have experience
with this.)

There are no relevant GTK+ limitations. However I understand that with
the current GUI setup of GIMP, horizontal splits like
|IMG|IMG|
are easier to implement in terms of visual organization.


 For cloning you only need a tiny part of the source visible...

This is only true IMO if the source auto-scrolls as you clone.
Otherwise, especially when you need to be reasonably precise, you may
need a relatively large display (for example, 150x150 area @ 300% zoom
= 450x450)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Bug #164774

2009-09-13 Thread David Gowers
On Fri, Sep 11, 2009 at 6:54 PM, peter sikking pe...@mmiworks.net wrote:
 second try sending this...

 Liam wrote:

 On Thu, 2009-09-10 at 00:00 +0200, peter sikking wrote:
 [///]
 grab the top-left square where the 2 rulers cross and drag+drop it
 anywhere on the canvas.
 the place that currently gives a pop-up menu?


 damn. yes.

 can somebody tell me why we have a tiny replacement for the menu bar
 right
 below the menu bar?


The obvious answer here is that it's visible when the menubar is not.
(being that it belongs to the rulers)
Not that that is a good reason. I think it's confusing being able to
access menus 3 different ways, and the tiny icon is really not very
easy to click.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included

2009-09-12 Thread David Gowers
On Sun, Sep 13, 2009 at 10:22 AM, Rob Antonishen
rob.antonis...@gmail.com wrote:
 Peter-

 To clarify, you are suggesting the on screen pointer icon/sprite could
 show the actual brush as it would look painted with a single mouse
 click, but once painting/holding the mouse down it would render as a
 cross hair?  And once the mouse is released it would turn back to a
 static sprite?

 That should keep the response faster when painting then, right?

 That would great for a mouse user, but would it work for a size
 dynamic tablet user?

As a tablet user, the above is exactly what I want; I certainly don't
want an outline while painting (may not be completely accurate, and I
tend to move too fast for the outline to have any real use)

When using a mouse, visual response to movement tends to be
predictable enough that I don't really gain anything from the brush
outline during painting either.

+1 on crosshairs-only during painting
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tags on presets.

2009-08-24 Thread David Gowers
On Mon, Aug 24, 2009 at 3:28 PM, Martin Nordholtsense...@gmail.com wrote:

 I immediately thought of Akira Shirakawa's proposition to move a
 majority of paint tool options into the concept of brushes. IMO doing
 that and using the already existing tagging for brushes would simplify
 the user interface and also the user experience.

 I have also thought a bit on how to clean up the concept of brushes, and in
 my mind, we could do it like this:

 We make a brush be just a bitmap/svg/whatever (possibly also an
 animation). Note that a brush would not even have a spacing as the current
 GIMP gbr brushes.

Right, so what you call a brush here is really more like a 'tip shape'
(assuming that tip shapes can change over time, which seems
reasonable)
definitely +1 on the transferral of spacing -- that illogicality is
really annoying of having that lone option there.
This would mean that we would also need to transfer the concept of
ranks -- that is, a tip shape could specify what ranks it specified,
and the actual meaning of those ranks would be specified in the other
part you specified (the one I'm tempted to call 'tool tip')
Mind you, I'm not sure that the flexibility of GIH brushes is a good
tradeoff for the increase in complexity introduced by essentially
multidimensional arrays of brush images; If it is, then it would help
a lot to have a better way to lay them out (layer grouping
functionality sounds like a good fit here -- one grouping level per
rank.


 A brush preset is a brush + dynamics, and this is actually what the user
 typically picks. If we would have tags for brush presets, we would be one
 step closer to make brush options be part of the brush, so to speak.

.. and I can't help thinking of this as a 'tool tip' :)

This sounds like the best idea yet on this subject.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tags on presets.

2009-08-23 Thread David Gowers
On Mon, Aug 24, 2009 at 5:06 AM, Martin Nordholtsense...@gmail.com wrote:
 On 08/22/2009 05:48 PM, Christophe Buffenoir wrote:
 Hello,

 I use the GPS set of presets and I think that tags system will be good
 on presets and not only on brushes.

 Nothing is done yet, the screens are just fakes to show my purpose. But,
 even if I've not enough spare time to do it quickly, I can code it.

 I think tagging of presets makes sense, in particular since brush
 dynamics keep getting more and more sophisticated.


I immediately thought of Akira Shirakawa's proposition to move a
majority of paint tool options into the concept of brushes. IMO doing
that and using the already existing tagging for brushes would simplify
the user interface and also the user experience. (like I've mentioned
before in reply to Akira's topic, We have an example of how to make
this work very well in MyPaint; the way MyPaint treats brushes really
'fits my brain' IMO and makes painting processes simple to think
about, uncomplicated, and quickly done.)

IMO tagging is sort of a patch over the real problem: part of the
qualities influencing a brush are in the brush itself, with others in
the tool options. Maybe we need tagging, but for the current
situation, tagging would make the separation less ugly, while leaving
the disjunction of 'brush' meaning in place.

http://www.nabble.com/Improved-brush-editing-interface-mock-up-td24628609.html
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Does Hue, Saturation, Value layer modes need HSV? How about CIE LCH instead?

2009-08-02 Thread David Gowers
On Sun, Aug 2, 2009 at 7:49 PM, SHIRAKAWA Akira
shirakawa.ak...@gmail.comwrote:

 Martin Nordholts wrote:

  Does anyone see any problems with using CIE LCH instead of HSV for these
  layer modes? We can ignore backwards compatibility issues for now.

 I very rarely use layer modes (and I'm not a GIMP hacker so I'm probably
 missing something), but if using internally CIE LCH for image processing
 instead of HSV leads to more correct results, then I wouldn't see any
 reason to not use it.

 Except for the final results, will there be any change at a user
 interaction level? Or any practical drawback resulting from this?


LCH processing is definitely slower than HSV or HSL (whether optimized or
not), so this may have an impact on display update speed (and consequently
on user experience)

There are a few different ways of applying a 'Color' like operation, varying
in quality and speed.
LCH is certainly the best quality, Yiq is lesser quality but faster, HSL is
even lesser quality and very fast, HSV is the fastest (but so inaccurate
it's laughable)

Since GEGL provides a number of operations that are inherently expensive (eg
bilateral-filter), it may be worth considering the idea of graphs with
quality controls built in. For example, while you are painting on your Color
layer, it switches from paint application using LCH to Yiq (which is a nice
compromise and has been used for heavy-duty tasks with good results -- see
http://www.cs.huji.ac.il/~yweiss/Colorization/).
When you stop painting, it updates with the actual LCH results.
This would allow more responsive painting (and could also be applied to
paint modes)


Martin: I have made use of GIMP Value mode in the esoteric kind of way you
mention. I agree it is not worthwhile to support such uses (imo more like
abuses -- this kind of use is really begging for the use of PIL or NumPy on
a chunk of image, not the application of an image *editor*)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Does Hue, Saturation, Value layer modes need HSV? How about CIE LCH instead?

2009-08-02 Thread David Gowers
On Mon, Aug 3, 2009 at 5:13 AM, Martin Nordholts ense...@gmail.com wrote:

 The input I've gotten so far removed any remaining doubt about porting
 those layer modes to LCH, so I've done that now:

 commit 18603ac192493296b191197a3e2b62c710398afd
 Author: Martin Nordholts mart...@src.gnome.org
 Date:   Sun Aug 2 21:35:10 2009 +0200

   Bug 401754 – Port Hue, Saturation, Value to CIE LCH

   When using GEGL for the projection, use CIE LCH for the Hue,
   Saturation and Value layer modes, just as we already do for the Color
   layer mode. The Value layer mode will later be renamed to Lightness
   since that is the semantics it has now.


oh, BTW, since LAB already separates the color element (AB) from lightness,
it's probably better to just use LAB for that -- it should produce identical
results, faster.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] What would be a better set of default resources?

2009-07-28 Thread David Gowers
On Tue, Jul 28, 2009 at 5:11 PM, Jason van Gumster 
ja...@handturkeystudios.com wrote:


 Sparr spa...@gmail.com wrote:

  Circle and Fuzzy Circle should be two brushes.

 I've been following this conversation with a bit of interest, but I've
 noticed that a lot of discussion has echoed this sentiment. Why should
 there be two circle brushes? Couldn't there be a single circular brush
 with fuzziness as an attribute of that brush that you could adjust
 with a percentage slider?

..
You can already do that for any circle brush. The attribute is called
'Hardness'
We would not seriously consider such a level of reduction because it's bad
for usability -- it's much more painful for the user to adjust a slider each
time they want to paint with different hardness, than to just switch between
two brushes.

I personally think there should be a few different brushes in a basic set.

* 'fill' brush (large, hard edge) -- because often painting is more
convenient than select+fill
* 'sharp' brush (moderate size -- say 25px (== radius 12), hardness 1.0)
(general purpose)
* 'fuzzy' brush (for blending)

If we moved towards Akira's idea of moving brush-related tool options into
brushes themselves, I would also suggest
* a single pixel, Hard Edge (as in, pencil-style sharp rendering) brush for
pixel.precise adjustments.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Improved brush editing interface mock-up

2009-07-24 Thread David Gowers
I think this is a very good idea -- moving the 'different ways of painting'
into brushes so that we don't need Paintbrush, Pencil, Airbrush but just one
: 'Paintbrush'. I use GIMP mainly for pixel art, and I find that I really
want the paintbrush/pencil/airbrush tool distinction to go away, so I can
just select 1px hard edge brush and not care about tool, and be assured that
I paint with hard edges and will therefore not smudge the picture.

Mypaint (http://mypaint.intilinux.org) does it like you suggest and it works
very well -- especially the way that you can toggle erasing, I think that is
a very useful improvement to workflow.

It's true that 'much more could be added' -- MyPaint gives an extreme amount
of brush settings, but it is not punishing to the user because you do not
need to negotiate these options most of the time (nor do they occupy any
screen space usually).

I would like to see the possibility to make specific brushes for erasing or
anti-erasing. My experience with MyPaint suggests that this is a very simple
and effective way to do erasing.

One issue I have found in MyPaint is that of committing changes -- say I
select the 1px brush, and change the spacing to 50%. should that be
automatically saved to disk, or discarded at the end of the session?
(MyPaint opts to discard these changes at the end of the session. I think
GIMP should visually indicate 'dirty' brushes and give the option to save
changes)

MyPaint also makes Opacity into a property of brushes. My experience is that
this often makes it much easier to quickly get to work.

I am very interested to see more.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Improved brush editing interface mock-up

2009-07-24 Thread David Gowers
 - Leave the old tool selection concept to the new taggable brush
 selection window

 With a new generic brush system in most of the brush behavior is
 described by the brush settings, it's possible to leave the old tool
 selection concept to the new (and possibly even more improved)
 taggable brush presets window.

What do you mean here? I think we need at least these paint tools:

Paint (this would be able to do all of what Pencil, Paintbrush, and Airbrush
do currently, and perhaps also Eraser), Ink (this does not use 'brushes'),
Clone (also Heal?) , Perspective Clone , Blur/Sharpen, Dodge/Burn, Smudge.
Do you really have a proposition to unify all of those, or do I
misunderstand you?

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] What would be a better set of default resources?

2009-07-22 Thread David Gowers
2009/7/22 Fredrik Alströmer r...@excu.se

 On Wed, Jul 22, 2009 at 14:12, Alexandre
 Prokoudinealexandre.prokoud...@gmail.com wrote:
  On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote:
 
  Easy enough, just unset the 'global-brush' property. I am not sure
  though if that would make a good default for the average user.
 
  So far I only heard from users thanks, but why is it not by default? :)

 I guess you wouldn't hear from people who like it the way the default
 is set, would you? :)

Well you can hear from me: I like the global-brush setting; if it is
accidentally turned off I find it very annoying, having to reselect brush
between tools... usually I *do* want to keep just the same brush between
tools. When I think about it, I wonder whether such users ever get to using
GIMP with any level of frequency or intensity, as IMO with the global-brush
option off, there is an unavoidable mental 'thunk' to accommodate for the
possible change of brush as you change tool; global-brush == off seems in
this way to inherently slow the user's workflow (regardless of what workflow
they use -- having to think 'oh, what is the brush of this tool' ==
slowdown.)

A related issue is the difficulty of reliable brush selection. ideally I
would hit a shortcut (say CTRL+B) and then type part of a brush name and hit
enter to select it. The current brush selection methods either require
direct pointing, are inaccurate, or only allow relative selection (ie. next
brush, prev brush)

(note: you can do absolute brush selection by this method IIRC: make sure
your brushes dialog is set to List,
then when you want to select a brush by name, hit [the shortcut for the
brushes dialog], then CTRL+F and type the name fragment. This has two
downsides - a) it's too much keyboard work for a common operation, b) it
changes the focus, which means I have to mouse back to the image window or
ALT-TAB before I can continue as before (say, adjusting the drawing opacity
before I start painting))

Also,
Alexandre says:
Clear separation of default settings for different tools is such an obvious
thing...
I agree with that. Unfortunately, having sensible, different defaults for
different tools is in direct conflict with having an efficient,
un-surprising workflow (and everyday workflow takes priority IMO.. A person
remains a newbie for only so long, but the general consistency of workflow
is something they will need to deal with as long as they use GIMP --
including any bureaucratic lumps such as (global-brush == off))

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] What would be a better set of default resources?

2009-07-22 Thread David Gowers
On Wed, Jul 22, 2009 at 10:47 PM, Alexandre Prokoudine 
alexandre.prokoud...@gmail.com wrote:

 2009/7/22 David Gowers wrote:

  tools. When I think about it, I wonder whether such users ever get to
 using
  GIMP with any level of frequency or intensity, as IMO with the
 global-brush
  option off

 Don't wonder -- they do. And I do too :)

 (Speaking of which, the fact that tools presets don't save/restore
 scale value isn't helpful either.)


AFAICS that isn't a generally true fact. Works for me -- I just checked by
choosing 1.06, saving that as a preset,
setting it to 0.01 and loading the preset (which correctly reset scale to
1.0).
What version are you using (I'm using a recent git version, I'd guess that
if there was a bug, any 2.7 version would have it fixed.)
I guess also it is possible that one of your preset files is corrupt and
causing problems.



 Clear separation of default settings for different tools is such an
 obvious
 thing...
  I agree with that. Unfortunately, having sensible, different defaults for
  different tools is in direct conflict with having an efficient,
  un-surprising workflow

 Contrary to that I would yell every time I switched from Paintbrush to
 Eraser if I didn't have global brush disabled. It's way too convenient
 to use e.g. smaller eraser *automatically*


Hmm, I tend to forget that there are people who use mice for general GIMP
work. I can see how this could actually save time then, if you only ever use
Eraser with one or two different fixed brushes instead of
switching a lot.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] How far away from watching other colorspaces in real time?

2009-07-22 Thread David Gowers
On Thu, Jul 23, 2009 at 11:41 AM, Martin Cracauer craca...@cons.org wrote:

 Martin Nordholts wrote on Thu, Jul 23, 2009 at 12:40:06AM +0200:
  On 07/23/2009 12:27 AM, Martin Cracauer wrote:
  Do I understand that correctly that you will move to
  single-floats/color?
 
 [...]
 
  If you in the yet not officially released GIMP 2.7 do View - Use GEGL,
  then the layers will be composited using GEGL. In other words, we have
  the layers etc ported to a GEGL graph. It is worth mentioning that it is
  technically trivial to insert non-destructive nodes in the graph, but
  our focus now is getting GIMP 2.8 out.

 I use the git version of last week.  Lost my tablet (probably due to
 some dbus API issue) but works otherwise.

 Let me just poke some more.

 And does all this survive layer copying and other changes?


GEGL graphs are completely non-destructive (of course, you can flatten part
or all of a graph  to destroy information at any time.)
The plan for GIMP here is that it will only modify the graph in the course
of usual operations, which will enable the option of fully non-destructive
workflow.
In this system, we simply have to decide the way to present this ability to
insert arbitrary nodes at arbitrary positions to the user.
The idea I regard as most sensible here is simply treating nodes like a
container -- that is, the input being made up of 1 or more node outputs
composited together. With this idea, you would be attaching an effect to a
group of layers (and effects

There are issues with the above (primarily, I oversimplified -- we need to
deal with nodes that simply produce, like eg. checkerboard, constant color,
as well as filtering nodes), but that's a reasonable overall way to think
about it for now.
IMO GIMP is heading towards providing a fairly thin abstraction layer over
the abilities of GEGL graphs, which in general is good news for anyone
concerned about possible leaky abstraction (does all this survive layer
copying and other changes) -- thick abstraction layers tend to be much
leakier (for example, Photoshop's Adjustment Layers idea -- they are only
layers in an absurdly broad sense (so broad as to be nearly meaningless), so
they tend to disobey common-sense rules followed by other types of layer.)


In short:

the capacity for inserting arbitrary nodes is available in GEGL, but GIMP
does not currently adulterate the constructed layer graph in any way; When
some ability to control the graph in a finer way (like I described) is
implemented, we ought to have moved on to the next-generation file format,
which should support it in a straightforward way

Even shorter:
A completely theoretical yes, since such functionality is currently
available in GEGL, not leveraged by GIMP or presented to the user yet.



 Let's use an example: I like to use the levels tools with a
 non-destructive adjustment first and although 2.6/2.7 allow me to take
 the levels I found right to curves I usually don't do this.  I prefer
 to commit the level change, then duplicate the layer and mess with the
 curves in the new layer.  This, of course, causes me losses from
 interpolation with the 8-bit channels, where it would not if I would
 edit levels and curves in the same moment without committing levels
 first and start over with curves.  Does current 2.7 carry floating
 point layers through all of this?


There are no floating point layers yet. During the composition, the layer
pixels are automatically converted to floating point, and converted back
after composition. to display the finished projection. Thus, the difference
in the resulting image is minimal.

During the application of a color tool, a similar thing happens: pixels are
converted to float, the change is applied, and pixels are converted back.
Eventually, using a color tool will just modify the image graph rather than
directly writing pixels; at this time,
floating point values will be preserved through that operation (and
presumably most subsequently operations -- obviously if there is an explicit
'convert to 8bit' operation in use,  floating point values are not going to
last beyond that.



 I just tried this and I get the same teeth in the histogram in 2.7 no
 matter whether I asked it to use GEGL or not, but I'm not sure I
 activate it the right way.  This was just on a layer originating from
 a JPEG.

 Does 2.7 as is support storing and reloading the floating point format
 in *.xcf files?

Again, floating point currently has nothing to do with the normal
representation of image in the GIMP, yet.
This should answer your question.
I believe we are planning to move to a new native image format for 3.0,
which will address such problems as: metadata support being bolted on rather
than a standard part of the file format, more sophisticated ICC support,
support of higher bitdepths, support of different color models (LAB, YCbCr
etc)...

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU

Re: [Gimp-developer] New color mode

2009-06-28 Thread David Gowers
I'm pretty sure Emil refers to the Color drawing /layer mode and the
way that it tends to 'burn out' colors -- the result of applying a
colorization is often far more vivid than could reasonably be
expected; Basically the same as the bug regarding improvement of Color
mode cf. Photoshop. A few theories have been advanced on how Photoshop
does it; they both agree that an RGB-based application such as the
current HSL application is incorrect, and IIRC argue for either LAB or
YIQ/YCbCr based color application. In my opinion LAB is higher
quality, however YIQ/YCbCr get the job done with acceptable quality
and higher speed.

I can do some visual comparisons sometime soon if needed.

 Exactly what do you mean by color mode here?

 Do you mean that the default RGB - CMYK conversion produces too
 saturated colors?

 Best regards,
 Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hacking GIMP - Gimp top level menu

2009-06-16 Thread David Gowers
toolrc

On Wed, Jun 17, 2009 at 11:00 AM, Jordan
Stinsonjordan.stinso...@gmail.com wrote:
 Thanks for the quick response. It looks like this will get me closer to what
 i'm actually after. When I use this method to add the hue saturation tool to
 the toolbox, it persists after I close gimp and reopen it. Could anyone tell
 me what file it's saved to?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Toolbar should dock to screen edge

2009-06-15 Thread David Gowers
Hi peter,

On Mon, Jun 15, 2009 at 8:34 PM, peter sikkingpe...@mmiworks.net wrote:
 maybe it is simply too early to spend effort on this. GIMP currently
 ships with a 6-column toolbox, (informally) kept that wide by the
 tool options. This gives you an edge speed-up for 1 in 6 tools.
How? In all configurations I have tested, padding prevents this: i
must jump to the edge then slide back a little in order to click on
the tool icon rather than a little padding pixel column of the
toolbox.


 I am working on the long term UI goal to have GIMP ship with a 2-column
 toolbox, which on larger screens could be stretched to single-column.
 this includes reducing the overall number of tools and one of the most
 challenging interaction design problems of GIMP: what to do with the
 tool options.
Good to hear.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [PATCH 1/4] Tile caching performance patches

2009-06-02 Thread David Gowers
I'd like to mention also that there are also some minor problems with whitespace


i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0002*.patch
Applying Add additional profiling to tile usage in order to analyze
efficiency and behavior of the tile cache. Profiling includes run-time
indication of idle swapper activity.
.dotest/patch:193: trailing whitespace.
  guint zorched : 1;/* was the tile flushed due to cache pressure
.dotest/patch:255: trailing whitespace.
#endif
.dotest/patch:304: trailing whitespace.
#ifdef TILE_PROFILING
.dotest/patch:318: trailing whitespace.

.dotest/patch:319: trailing whitespace.
#ifdef TILE_PROFILING
warning: squelched 12 whitespace errors
warning: 17 lines add whitespace errors.
i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0003*.patch
Applying Replace two list 'flush clean first' cache strategy with an
LRu strategy. Although the clean-first strategy gives fast light-load
performance, it also degrades catastrophically under moderate cache
pressure. LRU is not as efficient under light load, but degrades more
gracefully under moderate and heavy load.
.dotest/patch:148: trailing whitespace.

.dotest/patch:191: trailing whitespace.

.dotest/patch:196: trailing whitespace.

.dotest/patch:202: trailing whitespace.

.dotest/patch:205: trailing whitespace.

warning: squelched 8 whitespace errors
warning: 13 lines add whitespace errors.
i...@gbubuntu:~/st/gimp2/gimp$ git-am /tmp/0004*.patch
Applying Correct startup flaw in idle swapper start: Don't watch only
UI idling, but also watch that the cache itself is idle. Previously it
would start during transforms and long pyramid rendering ops and toss
writes and large seeks into the tile cache while it was potentially
under heavy pressure.
.dotest/patch:149: trailing whitespace.

.dotest/patch:157: trailing whitespace.

.dotest/patch:158: trailing whitespace.
  if(count=IDLE_SWAPPER_TILES_PER)
.dotest/patch:186: trailing whitespace.

.dotest/patch:194: trailing whitespace.

warning: squelched 1 whitespace error
warning: 6 lines add whitespace errors.

(patch 0001 applies with no problems.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] PyGIMP question: saving PNG and XCF versions of the same image

2009-05-29 Thread David Gowers
On Fri, May 29, 2009 at 3:59 PM, Ryan Krauss ryanli...@gmail.com wrote:
 Thanks David.  I stumbled onto that solution just before I checked my email
 :)

 This does the trick of creating the file to go to PNG:

     pdb.gimp_edit_copy_visible(img)
     img2 = pdb.gimp_edit_paste_as_new()

 It does work nice and doesn't seem to take too long.

 So, my script does almost everything that I want.  One last annoyance is
 that I can't seem to get the window title to change from Untitled-N.0 after
 the XCF save to the XCF filename.  Neither of these seem to set the window
 title:

 pdb.gimp_xcf_save(1, img, drawable, xcf_path, xcf_path)
 pdb.gimp_file_save(img, drawable, xcf_path, xcf_path)

Neither of the above set the filename.
You should do this.
image.filename = xcf_path


 It makes me a little nervous to close windows that don't have the filenames
 in the title and are not marked clean (no *).  I can do this at the end of
 the script

 pdb.gimp_image_clean_all(img)

 but the docs seem to say I shouldn't and that still doesn't set the window
 title.

 How should I save an XCF from a Python script (I assume either of the pdb
 save methods above) and how do I set the window title?

Saving XCF -- either of the methods you mentioned is fine.
You don't set the window title (except indirectly, as above)

  Should the image
 automatically be set as clean?
Yes, since you've saved in XCF. That is, setting it clean makes sense,
since that's what the GUI code does at the equivalent point in the
normal Save process.

The recently introduced Export framework may end up simplifying your
situation.. It considers a file 'clean' only when it has just been
saved to XCF (or xcf.gz, etc) format, and introduces a separate
'Export' action for producing a 'rendered result' in eg. PNG format.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] PyGIMP question: saving PNG and XCF versions of the same image

2009-05-28 Thread David Gowers
Hello Ryan,

On Fri, May 29, 2009 at 1:48 PM, Ryan Krauss ryanli...@gmail.com wrote:
 I have a Python Gimp question.  I don't know if it belongs on the user or
 developer list, but my feeling is that the people with the knowledge are
 more likely to read this list.  Let me know if this is the wrong list to
 post to.

 I have written a script to create PNG and XCF versions of an image I want to
 save.  I have a certain layer whose visibility I want to turn off before I
 save the PNG but I also want the XCF to give me more editting power if I
 want to alter the image later.  I have this working fairly well, but the
 problem is that when my script finishes, I am looking at the flattened PNG
 version of the image.  At that point, I would need to close the PNG and
 re-open the XCF if I want to edit the file.  This is less than ideal.  I
 think it could be solved by simply doing one undo step after saving the PNG
 (since flattening was the last thing I did), but I don't see in the
 procedural database a way to undo from a script.  Is there a way to save a
 flattened PNG and then save an unflattened XCF of the same image and leave
 the XCF open?

Duplicate the image and do your flattening on the copy. It's more
efficient than you might think -- the main time involved in
duplicating a moderate sized image seems to be actually in setting up
its GUI window rather
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] enhancement for eraser/brush tools: resurrect erased/cleared

2009-05-26 Thread David Gowers
On Tue, May 26, 2009 at 4:52 PM, Alchemie foto\grafiche
fotocom...@yahoo.it wrote:



 How does this differ from the current anti erase tool
 option
 (quickly enabled also by holding Alt key)?

 Maybe does not differ

 BUT there is a Problem

  there is not any documentation in the help on a anti-erase option or tool 
 so i believe almost only who contribute to implement it know about it

This is simply not true.

http://docs.gimp.org/2.6/en/gimp-tool-eraser.html
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Please, Please Bring Back Old GIMP.

2009-05-25 Thread David Gowers
On Tue, May 26, 2009 at 9:00 AM, Sue for...@gimpusers.com wrote:
 Hi GIMP Developers,

 I am a longtime GIMP fan, and I am highly disappointed with the Version 6.6
 UI.  One thing I have always enjoyed about this program is the fact it was not
 like Photoshop, because I could multitask with other programs (I could be
 searching for other pictures in the background in the Windoze file explorer),
 minimize what I wanted, detach windows whenever I wanted (veery nice), and
 resize the brush in the Brush Editor on will, and minimize it when I needed.

 Now I can't do those things, and it looks like Photoshop.  I find it
 irritating now that I've got keep the Brush Editor open all the time and it
If you just use the Brush editor to resize the brush, I suggest you
begin using the Brush Scale slider in the tool options instead; It's
probably faster.

 resets its size whenever I re-open it.  I find the new Navigator tool
 disorienting to use, and I can't be as precise either when I need to go to the
 exact pixel on the corner because the thing moves.  I also don't like not
 having control over my windows anymore.

Not having control over your windows is not caused by GIMP. I
certainly have all the control over GIMP windows I need, and
individual dockable windows keep their size and position as you seem
to desire.
Of course, if you close a dockable, you are saying 'throw away all
information about this dockable', so in that case, naturally when you
open a dockable of the same kind, it is simply put in a default
position and size.
However, with the various systems (which have been there  before 2.0
even), like TAB and F11, you should usually not ever need to close a
dockable. Especially if you dock them together to form a joined window
or a set of tabs.

Also, you might be thinking of the change of a default preference,
which effects whether dockables are shown on top of all other windows.
This change occurred somewhere after 2.4, I think. Anyway it does not
impede you -- just change the preference back.

GIMP 2.6 is also not single-window. It's a minimum of two windows
(image window + toolbox), and can be much more according to how many
images you open at once or dockables you open.
There are plans to allow a full single-window interface, however this
behaviour is
a) not implemented yet... at all, really
b) intended to be completely optional, allowing you to use either a
single or multi-window setup according to your preference.
c) not ever going to be Window-inside-Window as some people claim to
want. Some people even perceive 2.6 to be Window-inside-Window, but
it's not (as demonstrated eg. when you move the toolbox)

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Please, Please Bring Back Old GIMP.

2009-05-25 Thread David Gowers
On Tue, May 26, 2009 at 9:41 AM, Sparr spa...@gmail.com wrote:
 I disagree with of course and naturally.  When I close [child/sub]
 windows[/tabs] in most applications, then reopen the [functionally]
 same window, I expect it to come back in the same state it was in when
 I closed it.  I regularly open and close the dockable windows, and
 add/remove things to them, and the amnesiac nature of all apsects of
 this process is very annoying.
This issue was actually discussed before -- IIRC it was decided that
implementing this behaviour would cause even more confusion
(essentially because the 'functionally' same dockable is not actually
the same dockable. The other technical problem is that there can be
more than one instance of some dockables instantiated, in which case
there is no clear way to decide which 'old' positioning and parameters
to use.. this would certainly be very confusing.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Procedural call to undo?

2009-05-12 Thread David Gowers
Hi,

On Tue, May 12, 2009 at 6:48 PM, David Hodson hods...@ozemail.com.au wrote:
 On Mon, 2009-05-11 at 12:57 -0700, Stuart Axon wrote:
 Even if you don't have undo as such, it would be useful from  a
 scripting point of view to save checkpoints, which you could
 revert to within the script.

 Exactly. A more accurate description of what I was looking for would be
 mark this point in the undo stack and revert to the marked undo
 point. (With an error code if the undo point no longer exists.)

This approach seems more reasonable -- if the point to undo to must be
explicitly identified (in the same manner that each version of a GIT
repository has a unique id), there is no ambiguity involved; you are
undoing a specific known part, and if that was already undone, a clear
error can be raised.

In order to do this, each undo step should have a unique ID.
Currently, the GimpUndo structure includes a 'time' field; This might
be sufficient as a unique ID if it is precise enough (eg. measured in
microseconds)

Photoshop has a similar feature called 'snapshots' which is
user-accessible. I'm not sure whether that kind of thing is a wise
thing to implement. Providing an API to programmatically do such
things seems fairly uncontroversial to me, though.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Procedural call to undo?

2009-05-10 Thread David Gowers
On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au wrote:
 I can find the functions in the pdb to manipulate the undo stack - is
 there a function call that just does an undo?

No.
Although this might conceivably change in the future as GIMP integrates GEGL.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Procedural call to undo?

2009-05-10 Thread David Gowers
Hi David,

On Sun, May 10, 2009 at 10:34 PM, David Hodson hods...@ozemail.com.au wrote:
 On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote:
 On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au wrote:
  I can find the functions in the pdb to manipulate the undo stack - is
  there a function call that just does an undo?

 No.
 Although this might conceivably change in the future as GIMP integrates GEGL.

 What does it have to do with GEGL? There's already an undo button there,
 it just needs to be connected to the API.

No it doesn't (in fact, I'm sure a few GIMP developers might argue
that it definitely needs to NOT be connected to the API (ie. stay as
it currently is)). This has come up before, to the response
essentially 'why would we court trouble by implementing such a thing?'


While it *could* be connected to the API, that would introduce
various logical inconsistencies (for example, plugins could not rely
on having a sensible image state because other plugins (running
concurrently, or called by the plugin itself) might roll back the
image state. Then the user can still make sense of the image state,
but the plugin has no idea what it is, it could be anything. This is
particularly bad if a crash is happening, as it also reduces your
ability to correctly deduce the cause of the crash.)

GEGL would allow a graph-based image structure, in which conventional
plugins might not be needed (rather, new GEGL Operations could be
implemented via a much simpler type of plugin.) This might help
address the above concerns, as well as helping to support more
sophisticated undo/versioning structures than our current 'piece of
string' model, like trees.

Hmm, I take it back, GEGL would not help the likelihood of such a
thing being implemented.. it's just a Bad Idea. For just the same
reasons that Global Variables are a bad idea.

As the Zen of Python says:

Explicit is better than implicit.
Complex is better than complicated.
In the face of ambiguity, refuse the temptation to guess.
If the implementation is hard to explain, it's a bad idea.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save + export spec essentials implemented

2009-05-07 Thread David Gowers
On Thu, May 7, 2009 at 7:54 AM, Martin Nordholts ense...@gmail.com wrote:
 Hi

 I have been working on implementing the Save + export spec [1] for a while.
 Since it will affect the workflow for basically everyone it would be nice
 with getting some testing and comments before we finalize, merge and push to
 GNOME master. The patches are attached to the bug report
 http://bugzilla.gnome.org/show_bug.cgi?id=581655 . Quick-guide to apply and
 test:

   cd ~/source/gimp
   tar -zxvf save-plus-export-2009-05-06.tar.gz
   git checkout -b save-plus-export-2009-05-06 master
   git am save-plus-export-2009-05-06/*

 this will create and switch to a new branch based on top of your local
 master branch, and apply the patches to that branch. Then you build and
 install as usual.

This doesn't seem to work -- patch #0010 fails:


Applying app: Add an 'export' mode to the file save dialog
error: patch failed: app/dialogs/file-save-dialog.c:138
error: app/dialogs/file-save-dialog.c: patch does not apply
Patch failed at 0010.

The patch appears to be offset by about 10 lines.

I applied it manually, and then ran git-am --skip
Patch 0011 applied ok,
Patch 0012 had problems:
Applying app: Improve save and export error messages
error: app/dialogs/file-save-dialog.c: does not match index
Patch failed at 0012.

Applied that manually,
Patches 013..017 applied OK.
018 says :
Applying app: Remember last export URI for each image
error: app/dialogs/file-save-dialog.c: does not match index
error: patch failed: app/file/gimp-file.h:27
error: app/file/gimp-file.h: patch does not apply
Patch failed at 0018.

Done manually,
019 fails similarly, done manually,
same for 020, 021
022 applied ok.

It's possible that I didn't understand how to 'resolve' a problem (
now I think it is, apply the patch manually, 'git add' the relevant
files, and 'git am --resolved')

I'm now trying to build it..
Trying it out..

This works REALLY well! I 3 it! It behaves much more comfortably than
the old setup,
I anticipate no longer needing to awkwardly 'save copy' so frequently
simply to get a web-usable version of the image.

I like how, if I hit 'revert', it properly reverts to the source image
(eg 12.gif rather than the working document 12.xcf)

I was confused by how 'export to foo.png' was only usable once the
image became dirty (ie. I changed it ). If that is considered
appropriate behaviour, then your ability to 'save' should also depend
on the dirtiness of the image


David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Background color property for GIMP images

2009-04-30 Thread David Gowers
Hi Jon!

On Thu, Apr 30, 2009 at 4:35 PM, Jon Senior j...@restlesslemon.co.uk wrote:
 On Thu, 30 Apr 2009 11:01:08 +0930
 David Gowers 00a...@gmail.com wrote:
 X could work almost unchanged (just, pressing X multiple times in
 quick succession would move back through the 5-slot color history,
 rather than just swapping the two newest slots. So your current usage
 of X would be unchanged, but you could use it to switch between more
 than 2 colors)

 So far, no one has given any feedback on the idea, or indeed any
 acknowledgement of it. This disappoints me, as it really does fit
 neatly into the 'holes' of yahvuu's proposal and would make those
 areas even more effective than GIMP currently is before implementing
 yahvuu's proposal alone.

 I didn't understand it at first, and believed that the idea was that 'x' 
 would cycle through the colours in a palette. Meaning that the user would 
 press 'x' once to change to a new colour and another four times to go back to 
 the original. Looking at your animated gif it all makes a lot more sense, 
 although I suspect that the timings will be critical. I would also (as a 
 user) want some method of adjusting or loading those five colours, either 
 via 5 swatches in the tool box, or a single choose colours dialog.

Thanks for the feedback ! :)

I envision that you would just choose colors whenever you want, and
that new color would enter slot #1, and push back the other items
(knocking the item in the old slot #5 out).

This is how it works in MyPaint, and it's pretty effective. However,
this may take some consideration as to when to adjust the color
history, as the color selection dialog of GIMP allows you to tweak
colors continuously, with no clear indication of when you're 'done'
selecting a color.
I guess we'd store a copy of the color which was in slot #1 before
changing it, and then adjust the history (slots 2,3,4 - slots 3,4,5;
stored color - slot 2; new color = slot 1) after a certain time
delay(1.5 seconds?). In this way slot 1 would always be current, while
avoiding overpopulating the history with minor tweaks of a single
color.

In the case of clicking to sample colors from gradients, the history
ought to update each time the user releases the left mouse button.
(Note:  my understanding is that there is a distinct lack of users who
are aware they can left-click to sample colors from gradients, sadly.)

In the case where the popup dialog, or palettes, or eyedropping, or
drag-n-dropping colors, is used, no delay is necessary (because the
user is explicitly specifying when the color is 'ready'; the meaning
of their actions is entirely unambiguous.)

If you wanted to fill all 5 slots with 5 specific colors from the
image, you'd just ctrl+click 5 times (assuming you're currently using
a paint tool), or click one after another on 5 colors in your palette,
or one of the other methods I mention above (that currently only
effect the FG color). Simple. With that, I believe there is no need to
edit anything other than a single color (slot #1, the current color)

On a related note: The popup color editing dialogs have color history
(A ColorNotebook?)
(for example, doubleclick on a palette color)
This is slightly different in nature to the kind of history I'm
suggesting -- the popup history list is like a list of 'colors I like'
(10 long; colors are only added explicitly with the '' button),
whereas my history list of course is of 'colors I'm using right now
(or recently)'.
These two lists would not interact in any way, due to their
fundamentally different application.

It's important to depict these two color histories in a differing way,
so that there is no confusion between the two types of history
(semi-permanent vs transient)


 If we maintain a strict visual order (eg. newest at right -- see my
 GIF above), this could work better than naming it 'current' -
 'previous'

 It does also resolve a question that was floating around in my head as to 
 what the new non-background colour would be called. The gradient tool is an 
 obvious example of one where the foreground/background naming convention is 
 strong, and easy to understand. This might require that the choose colours 
 dialog allows a method for swapping the colour order, because having to do it 
 using only 'x' could get annoying when arranging two colours for use in a 
 gradient.

Again, a maximum of two eyedroppings/ your method of choice should
easily arrange the color history appropriately.

Also, my experience with MyPaint is that needed keypresses are few --
remember, you would only have to press X a maximum of 8 times to get
any two colors to the front.
The '8' example comes from if you want slots #5, #4 transferred to #2,
#1. You press X four times to select #5, and wait a short time
(1.5s?); then press X another four times to select #4 (which became #5
after your previous selection).
the history looked like this  (letters represent colors rather than
slots) ABCDE and after the first step it looks

Re: [Gimp-developer] Background color property for GIMP images

2009-04-30 Thread David Gowers
On Thu, Apr 30, 2009 at 9:13 PM, yahvuu yah...@gmail.com wrote:
 Hi David,

 here's a mockup idea on your proposal; might or might not help
 to identify the current-previous color pair... just brainstorming.

 I hope you're not bothered i'm sending private mail - it's just
 i can't contribute anything generally useful on the topic,
 much along the lines of what Martin said.
When Martin said that, I thought that just means it's inappropriate
for us to make the decisions. It doesn't mean we shouldn't do research
-- in fact, I'm sure Peter Sikking would appreciate it.

Hence, I've CCed this to the list.

 All i know (or imagine to know ;) is that the only tool which requires
 the background metaphor is the eraser, including the 'selection erasers'
 delete and cut. I don't even see a conflict with bg-color-layer, despite
 that's where i started to question the bg color swatch..

 So from my point of view, everything is open for the tool box, be it
 mypaint style, or even mypaint+bg color, color swatch plugins,
 left-right+bg color, you name it.

I've looked at your image, and I'm not sure what it's supposed to be.
A layout for the OSD? or a toolbox status display? Or something else?

When you say 'toolbox' I'm also not sure whether you mean the optional
colors display at the top of the toolbox, or the 'Colors' dockable (or
both)

Have you looked at MyPaint? It doesn't *have* a status display :) It
allows you to edit the current color (via a shortcuttable menu item)
and move through the color history; that's the only time you see the
color history, via the Onscreen Display. The OSD I mocked up before is
pretty close to what MyPaint's OSD looks like, though.

I've created a mockup of my own idea of a toolbox status display. It's
based on the old color display (I think we should try to take the same
amount of space as before).. It's attached. I believe it makes the
current + immediately previous color obvious, while clearly
prioritizing the current color, and showing the other indication.
I left the 'reset' and 'swap' icons there, because they still make some sense.

In the OSD I mocked up, the current + previous color are always the
rightmost color , and the color immediately next to it. So IMO no
further indication is needed in the OSD.

 many thanks for taking the time for discussion
 and all the great work on GIMP,

Thanks for starting this thread that so much interesting discussion
has come out of :)

David
attachment: toolbox-color-mockup.png___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Background color property for GIMP images

2009-04-30 Thread David Gowers
On Thu, Apr 30, 2009 at 10:36 PM, Rob Antonishen
rob.antonis...@gmail.com wrote:
 I just ran through my scripts.

 In the .scm files distributed with gimp, there were:
 38 files containing gimp-context-set-foreground
 65 files containing gimp-context-set-background

The ones I have looked at, mainly set background and then do a
edit-fill with BG or a drawable-fill.


 looking at the scripts I have installed in my home directory, there were:
 49 files containing gimp-context-set-foreground
 29 files containing gimp-context-set-background

 This is my no means a thorough assessment.  Perhaps the individual
 operating the gimp plugin registry could grep all the plugin files and
 give a better count of the third party scripts using these calls.

There is no question of removing either of the above PDB functions,
AFAICS. It's just a matter of what to do to emulate the old FG / BG
behaviour. In the case of my proposition, FG would remain (as slot #1
-- 'current') and BG would map to slot #2 ('immediately previous').
However, one side effect is that setting FG could change BG (through
the normal history cycling mechanism). Erk.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Background color property for GIMP images

2009-04-29 Thread David Gowers
Hello,
On Wed, Apr 29, 2009 at 11:17 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote:
 guys,

 here is sort of a review of what has been discussed here:

 To take this top-down: I can only see this change as an UI
 improvement if it means getting rid of the bg color swatch.

 How is one supposed to paint on mask without bg/fg color swatch?

That's not included in yahvuu's proposal, but I proposed something
that could neatly solve that, and address gradient issues: replace the
FG/BG color concept with FG + cycleable 4-long color history. In this
situation, you could still press a single key to swap between two
colors (you would be swapping the previous color with the current
color). Pressing it multiple times could cycle further back (in both
cases you could get a simple OSD -- see MyPaint for example.).
'previous color in the color history' still can have roughly the same
usage, we would just not be giving that color special treatment by
labelling it 'BG'. The 'FG to BG' gradients still make sense in this
context,
they could just become 'Current to old color' (and usage patterns
should be virtually identical.)

Peter's done a good job synthesizing the 'BGcolor' with the
requirement to specify whether alpha channel is desired in any
exported/flattened image, and also notices similar problems to you.

The problems brought up by both of you, Alexandre and Peter, are
addressed neatly by my proposal above. Perhaps it needs a mockup.. I
feel it fits very well into yahvuu's proposition, turning its
weakpoints into strong points.

Something that hasn't been brought up, BTW: Flatten Image vs Merge
Visible layers. Not exactly the same, but would become closer to each
other if Peter's description was implemented. Maybe we need to attempt
to rationalize that.

The behaviour of Sample Merged seems fairly obvious here, but I'm
bringing it up also, just in case.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Background color property for GIMP images

2009-04-29 Thread David Gowers
On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly fil...@gmail.com wrote:


 2009/4/29 peter sikking pe...@mmiworks.net
 but some crucial things depend on the bg color.
 the gradient tool being the big show-stopper for me.
 the tool needs a redesign, but up to then the fg-bg
 type of interaction looks to be the most (universally)
 usable to me.



 Unless you make a ease and nice way of swathing (or alternating) colors, I'm
 against it.
 When you are painting (making a digital painting or painting on a mask...)
 in the current version you just hit X to alternate between bg / fg colors.
 Its just ease that way.

I've already made a proposal that thoroughly addresses this twice in
this thread. It is based on a system MyPaint
(http://mypaint.intilinux.com) uses, so I've already tried a very
similar system and found it very effective.

It's simply a 5-slot color history, with X selecting from it (when a
color is 'chosen', it goes into slot #1 in the history (slot #1 == FG/
actual painting color), the old color moves into slot #2, and the rest
of the items are moved back if needed. Just standard history
operation.)

X could work almost unchanged (just, pressing X multiple times in
quick succession would move back through the 5-slot color history,
rather than just swapping the two newest slots. So your current usage
of X would be unchanged, but you could use it to switch between more
than 2 colors)

So far, no one has given any feedback on the idea, or indeed any
acknowledgement of it. This disappoints me, as it really does fit
neatly into the 'holes' of yahvuu's proposal and would make those
areas even more effective than GIMP currently is before implementing
yahvuu's proposal alone.

In case people have read it and simply not understood what I meant,
I'll provide an animated GIF,
and perhaps submit a derivation of the GIF to gimp-brainstorm.blogspot.com

http://img.photobucket.com/albums/v449/neota/alphazero/animation.gif

I'm not sure whether or not Yahvuu was alluding to my proposal when he says

 i think the gradient tool would work equally well if
 the swatches were named left - right.

If we maintain a strict visual order (eg. newest at right -- see my
GIF above), this could work better than naming it 'current' -
'previous'

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


  1   2   3   4   5   >