Re: [Gimp-developer] Handling of transparent pixels
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]
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]
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
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
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
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]
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
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
