Re: [Gimp-developer] Handling of transparent pixels

2003-12-18 Thread Raphaël Quinet
On Tue, 16 Dec 2003 20:37:30 +0100, Henrik Brix Andersen <[EMAIL PROTECTED]> wrote:
> On Tue, 2003-12-16 at 17:59, Raphaël Quinet wrote:
> > Basically, the model that we should promote is:
> > - layer mask=> hiding mechanism, reversible
> > - alpha channel => pixels that are cleared have undefined RGB data,
> >not reversible (except for undo)
> > 
> > Breaking this model should be avoided, except in very special cases
> > (i.e. obscure features for hackers). 
> 
> I'm sorry, Raphaël, but I do not agree with you on this issue either. I
> don't see why we should limit the gimp when there is no, at least to me,
> obvious reason to do so.

Of course I see this from a different point of view: by avoiding a
mistake that was recently introduced, I am trying to make sure that
the GIMP will not be limited in the future by the constraints that are
implied by an incorrect perception of the alpha channel.  With the
right model, we can make the GIMP more efficient.

> I think you will have to accept the fact that this proposed change will
> not make it into gimp, at least not at this point in development.

This discussion is not so much about a specific change, but more about
what model or perception we should promote now and in the future.

But as you mention a "proposed change", I will just repeat that this
discussion started because of a change that was introduced during the
feature freeze and that is (IMHO) controversial and goes against the
model that we should try to promote.  I was hoping that more
developers would see that the rest of the world around us (e.g.,
Photoshop) does things in the right way and that we should not
introduce new features that have not be thought out carefully and that
break this model (especially when the same results can be achieved in
a better way, with a different implementation).

> Allow
> me to refer to the minutes of the gimpcon meetings -
> http://developer.gimp.org/gimpcon/2003/minutes-1.html#decisions - where
> we agreed not to continue discussions just for the sake of the
> discussion. I think we have all had a chance to comment on the proposed
> changes at this point, and I suggest that we leave it be.

Yes, I thought about that.  That's why I waited a bit before posting
what will be my last contribution to this discussion (for this year,
at least).  I wanted to be see if anybody would post new arguments.
Interestingly, the only new arguments (from Pedro, about Photoshop)
are actually supporting what I wrote, even if Pedro does not like it.

> I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice
> addition/work around the optimization problem - I have yet to try it
> out, though.

I haven't tried it either, but it could indeed be a nice addition to
the PNG plug-in.  But alas this is far from solving the real problem,
which is a problem of model/perception.  The real problem is that some
GIMP developers and users see alpha as a simple hiding mechanism,
which is wrong (or not always right, depending on your point of view).
Perceptions are unfortunately very hard to change.

As this will be my last message in this thread, I would like to end it
with a question (but I suggest that you do not respond - just think
about it): Why do we need layer masks in the GIMP?  Wouldn't it be
easier to paint directly into the alpha channel and simply get rid of
this intermediate step (mask)?  There are no conceptual differences
between the alpha channel and masks (except for the one at the center
of this discussion) so why do we need both if the same operations
could be performed with both?  Why were masks introduced in the first
place?

According to the books that I read (or just browsed) about Photoshop
and other programs, a similar question can be easily answered for
those programs: although both the alpha channel and the masks
influence the opacity of the pixels, a mask is usually associated with
visibility while alpha is usually associated with presence (and one
cannot increase the presence of something that is not there).  That's
why the masks are there, to allow the user to increase or decrease the
visibility of the pixels at will without any loss of information.
But if any changes are commited to the alpha channel, then the opacity
of the pixels cannot be increased anymore (except by painting over
them or undoing their removal).  The authors of these programs
(especially Photoshop) were very careful about applying this model in
a consistent way throughout the application.  That's why masks are not
treated in the same was as the alpha channel.  That's why one is not
encouraged to edit the alpha channel directly (there are ways around
that if you know how to do it).  If you think about it, I believe that
it makes a lot of sense.  Also, instead of promoting an "anti-erase"
mode, someone invented an "undo brush" that can perform the same
functions and even much more in most cases.  They carefully avoided to
break this model (masks for visibility/hid

[Gimp-developer] Re: [PATCH] Gradient-Fu Rev. 2 [was Re: [PATCH] Start of aGradient Scripting Support]

2003-12-18 Thread Shlomi Fish
On Thu, 18 Dec 2003, Sven Neumann wrote:

> Hi,
>
> Shlomi Fish <[EMAIL PROTECTED]> writes:
>
> > Well, here is the up-to-date patch according to the commentary from
> > the core developers that I received on the IRC.
>
> Please see my comments on the patch and put a revised version to
> Bugzilla.
>
> > +{
> > +  GimpGradientSegment *seg;
> > +  int i;
> > +
> > +  if (i < 0)
> > +{
> > +  return NULL;
> > +}
>
> I think you want to check index here, not the uninitialized variable
> i.  Better make this a g_return_val_if_fail() though. In general you
> should add such checks for all assumptions you make about function
> parameters.
>

You are right - it was a bug. Fixed.

>
> > +void gimp_gradient_get_segment_left_color  (GimpGradient *gradient,
> > +GimpGradientSegment *seg,
> > +GimpRGB * color)
>
> Please try to follow the coding style and align function parameters
> the same way all other GIMP functions do it. The same comment applies
> to the declarations in the header file.
>

Done.

> > +  gimp_data_dirty (GIMP_DATA(gradient));
>
> Please insert a space before the opening bracket.
>

OK.

This fixes will be incorporated in the next version of the patch, which
will also have position set/get routines.

Regards,

Shlomi Fish



--
Shlomi Fish[EMAIL PROTECTED]
Home Page: http://t2.technion.ac.il/~shlomif/

An apple a day will keep a doctor away. Two apples a day will keep two
doctors away.

Falk Fish
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [PATCH] Gradient-Fu Rev. 2 [was Re: [PATCH] Start of a Gradient Scripting Support]

2003-12-18 Thread Sven Neumann
Hi,

Shlomi Fish <[EMAIL PROTECTED]> writes:

> Well, here is the up-to-date patch according to the commentary from
> the core developers that I received on the IRC.

Please see my comments on the patch and put a revised version to
Bugzilla.

> +{
> +  GimpGradientSegment *seg;
> +  int i;
> +  
> +  if (i < 0)
> +{
> +  return NULL;
> +}

I think you want to check index here, not the uninitialized variable
i.  Better make this a g_return_val_if_fail() though. In general you
should add such checks for all assumptions you make about function
parameters.


> +void gimp_gradient_get_segment_left_color  (GimpGradient *gradient,
> +GimpGradientSegment *seg,
> +GimpRGB * color)

Please try to follow the coding style and align function parameters
the same way all other GIMP functions do it. The same comment applies
to the declarations in the header file.

> +  gimp_data_dirty (GIMP_DATA(gradient));

Please insert a space before the opening bracket.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Problem starting gimp-1.3.23

2003-12-18 Thread Sven Neumann
Hi,

Frank Wittemeier <[EMAIL PROTECTED]> writes:

> (gimp-1.3:1395): GLib-GObject-WARNING **: specified class size for type 
> `PangoXftFontMap' is smaller than the parent type's `PangoFontMap' class size

This indicates that something is severely broken with your Pango
libraries. 'make clean' in Pango and rebuilding it should fix the
problem.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Problem starting gimp-1.3.23

2003-12-18 Thread Frank Wittemeier
Hi,

I have a problem starting gimp 1.3.23. I compiled it with no problems after 
installing all the necessary libraries. When I start gmip I get the follwing 
error:

[EMAIL PROTECTED]:~> gimp-1.3
This is a development version of The GIMP.
Debug messages may appear here.

gimp_composite: use=yes, verbose=no +mmx -sse -sse2 -3dnow -altivec -vis

(gimp-1.3:1395): GLib-GObject-WARNING **: specified class size for type 
`PangoXftFontMap' is smaller than the parent type's `PangoFontMap' class size

(gimp-1.3:1395): GLib-GObject-CRITICAL **: file gobject.c: line 615 
(g_object_new): assertion `G_TYPE_IS_OBJECT (object_type)' failed
gimp-1.3: fatal error: Speicherzugriffsfehler
gimp-1.3 (pid:1395): [E]xit, [H]alt, show [S]tack trace or [P]roceed:


gimp 1.3.7 worked well before. I compiled the libs and gimp several times but 
no help.

Can someone help me please?

Thanks
  Frank
-- 
Frank Wittemeier
Krugweg 1
32 602 Vlotho

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] gimp-help-2 - TODOs and ideas

2003-12-18 Thread Roman Joost

On Thu, Dec 18, 2003 at 12:44:16AM +0100, Daniel Egger wrote:
> Am Mit, den 17.12.2003 schrieb Roman Joost um 21:30:
> 
> >   1. Renaming of the current XML files, that the corresponding help ids:
> >   app/widgets/gimphelp-ids.h.  This is mostly done by me. I'll check the
> >   changes in as soon as possible.
> 
> Huh? Probably it's just me being dense...
Heh - no. I shouldn't write mails during a lecture ... The existing XML
files are renamed to the name of the help ids in
$GIMP/app/widgets/gimphelp-ids.h, eg: airbrush.xml is now:
tool-airbrush.xml

> 
> >   2. Adding XML files for all the other help ids, especially for the
> >   plugins. This would help the gimp developers to test the help browser.
> >   The content should look like the one in: src/not_yet_written.xml.
> >   The structure of each document should look like:
> > a) a phrase like: "this document has not been written"
> > b) author name
> > c) plugin name, additional information, etc
> > d) an email adress and a contact person, where a person can send as
> > (plain) documentation 
> 
> This has caused quite some gripes back in the good ol' times. What about
> using xinclude tricks to supply the content of one template document as
> the source for yet-to-be written files? This approach is documented in
> http://www.sagehill.net/docbookxsl/ however I haven't had the time to
> verify that it works with xsltproc yet.
>
I'll have a look at it ...

> >   3. This item was not discussed on the IRC, but maybe an interesting
> >   thing to add: an example how to use a tool|documented item. This
> >   should look like eg. "How do you make a rectangular selection". By
> >   explaining this example step by step, i think, it'll make the life
> >   much easier for the user.
> 
> We talked about this earlier and seemed to have agreed that this is a
> nice idea. :)
> 
Okey - added this to the WIKI ... 

> >   We've now only a TODO list on the WIKI. Every gimp-help-2 developer
> >   can pick a term and solve it. This reminds me to bugzilla. Well, this
> >   implies, that someone feels responsible for his part on gimp-help-2
> >   (writing content or something else) and can use bugzilla. How do think
> >   other gimp-help-2 members about this? Maybe the project needs a bit
> >   more contributors, for making sense...
> 
> I don't think it makes sense to have formal assignments of specific
> topics as this would take away most of the fun a volunteers project
> should make.
> 

Merry Christmas, 
-- 
Roman Joost
www: http://www.romanofski.de
email: [EMAIL PROTECTED]


signature.asc
Description: Digital signature


[Gimp-developer] [PATCH] Gradient-Fu Rev. 2 [was Re: [PATCH] Start of a Gradient Scripting Support]

2003-12-18 Thread Shlomi Fish

Well, here is the up-to-date patch according to the commentary from the
core developers that I received on the IRC.

Regards,

Shlomi Fish


--
Shlomi Fish[EMAIL PROTECTED]
Home Page: http://t2.technion.ac.il/~shlomif/

An apple a day will keep a doctor away. Two apples a day will keep two
doctors away.

Falk Fish--- ../gimp-1.3.23/tools/pdbgen/Makefile.am 2003-10-05 15:16:51.0 +0200
+++ gimp/tools/pdbgen/Makefile.am   2003-12-12 21:00:22.0 +0200
@@ -15,6 +15,7 @@
pdb/font_select.pdb \
pdb/fonts.pdb   \
pdb/gimprc.pdb  \
+   pdb/gradient_edit.pdb   \
pdb/gradient_select.pdb \
pdb/gradients.pdb   \
pdb/guides.pdb  \
--- ../gimp-1.3.23/app/pdb/Makefile.am  2003-10-05 15:16:14.0 +0200
+++ gimp/app/pdb/Makefile.am2003-12-12 20:57:07.0 +0200
@@ -20,6 +20,7 @@
font_select_cmds.c  \
fonts_cmds.c\
gimprc_cmds.c   \
+   gradient_edit_cmds.c \
gradient_select_cmds.c  \
gradients_cmds.c\
guides_cmds.c   \
--- ../gimp-1.3.23/tools/pdbgen/groups.pl   2003-09-07 22:57:12.0 +0300
+++ gimp/tools/pdbgen/groups.pl 2003-12-12 20:45:20.0 +0200
@@ -13,6 +13,7 @@
 font_select
 fonts
 gimprc
+gradient_edit
 gradient_select
 gradients
 guides
--- ../gimp-1.3.23/tools/pdbgen/pdb/gradient_edit.pdb   1970-01-01 02:00:00.0 
+0200
+++ gimp/tools/pdbgen/pdb/gradient_edit.pdb 2003-12-18 16:48:22.0 +0200
@@ -0,0 +1,212 @@
+# The GIMP -- an image manipulation program
+# Copyright (C) 1995 Spencer Kimball and Peter Mattis
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+sub pdb_misc {
+$author = $copyright = 'Shlomi Fish';
+$date = '2003';
+}
+
+sub _gen_gradient_search_for_segment_code
+{
+my $action_on_success = shift;
+
+return <<"CODE";
+{
+  if (strlen (name))
+{
+  gradient = (GimpGradient *)
+gimp_container_get_child_by_name (gimp->gradient_factory->container,
+  name);
+}
+  else
+{
+  gradient = gimp_context_get_gradient (gimp_get_current_context (gimp));;
+}
+
+  if (gradient)
+{
+  GimpGradientSegment * seg;
+  seg = gimp_gradient_get_segment_by_index (gradient, segment);
+  if (seg)
+{
+  /* Success */
+  $action_on_success
+}
+  else
+{
+  success = FALSE;
+}
+}
+  else
+{
+  success = FALSE;
+}
+}
+
+CODE
+}
+
+sub other_side
+{
+my $side = shift;
+
+return ($side eq "left") ? "right" : "left";
+}
+
+sub _gen_gradient_set_side_end_color
+{
+my $side = shift;
+
+my $other_side = other_side($side);
+
+$blurb = "Retrieves the $side endpoint color of the specified gradient and 
segment";
+
+$help = <<"HELP";
+This procedure retrieves the $side endpoint color of the specified segment of
+the specified gradient.
+HELP
+
+&pdb_misc;
+
+@inargs = (
+{
+name => 'name',
+type => 'string',
+desc => 'The name of the gradient to get the color from',
+},
+{
+name => 'segment',
+type => '0 <= int32',
+desc => 'The index of the segment from to which the endpoint belongs',
+},
+{
+name => 'color',
+type => 'color',
+desc => "The color to set",
+},
+{
+name => "opacity",
+type => '0 <= float <= 100.0',
+desc => "The opacity to set for the endpoint",
+},
+
+);
+
+@outargs = (
+);
+
+my @blend_params = ("&color","&(seg->${other_side}_color)");
+if ($side eq "right")
+{
+@blend_params = reverse(@blend_params);
+}
+
+%invoke = (
+vars => [ 'GimpGradient *gradient = NULL' ],
+code => &_gen_gradient_search_for_segment_code(<<"CODE"),
+  color.a = opacity / 100.0;
+  gimp_gradient_set_segment_${side}_color (gradient, seg, &color);
+CODE
+);
+}
+
+
+sub _gen_gradient_get_side_end_color
+{
+my $side = shift;
+

Re: [Gimp-developer] gimp-help-2 status

2003-12-18 Thread Roman Joost
Sorry for replying a bit late, but i didn't looked in my gimp mailinglist
folder ...

On Thu, Dec 11, 2003 at 08:08:55AM +0100, Daniel Egger wrote:
> Am Mit, den 10.12.2003 schrieb Roman Joost um 22:55:
> 
> > With Raymonds help i'm now be able to build the help with UTF-8 encoded
> > XML files, which are "xincluded" in the gimp.xml file.
> 
> Cool. Incidently I've also been working on this and my Mac really has
> troubles when trying to compile such files with xsltproc; it will slowly
> suck up all memory and finally explode. Was this your problem, too? How
> did you solve it?
Hm.. i didn't had any memory problems with XInclude. If the encoding was
wrong, the xsltproc throw an error and nothing more ...

> > The manual itself looks promising. We got some additional writing power
> > for the english content. Daryl Lee takes care about the english content
> > and Niklas can produce (or better: is producing) swedish content. We,
> > Niklas and i, ran into bit trouble lately, when we tried to produce
> > the manual with some swedish content. It seems, that docbook doesn't
> > have any swedish support?!
> 
> DocBook doesn't need to. :) But I verified that the stylesheets do have
> Swedish translations so there shouldn't be any problems. The language
> code is 'sv' for Svenska.
This is "fixed" :)

Thanks and greetings,
-- 
Roman Joost
www: http://www.romanofski.de
email: [EMAIL PROTECTED]


signature.asc
Description: Digital signature