Miguel Ibarra wrote:

Here's a patch to add optional libstartup-notification support to The Gimp. This will allow desktop managers as Gnome's to entertain users with a *so* funny clock cursor, while Gimp launches and initializes itself.

I hope the maintainers find this worthy of being included in the main distribution.

If this were ported to 1.3. latest, I'd like to see it considered for includion :)

Cheers,
Dave.

Miguel Ibarra wrote:

Here's a patch to add optional libstartup-notification support to The Gimp. This will allow desktop managers as Gnome's to entertain users with a *so* funny clock cursor, while Gimp launches and initializes itself.

I hope the maintainers find this worthy of being included in the main distribution.

Regards,

------------------------------------------------------------------------

diff -Nru -x '*~' -x '*.o' -x '*.orig' -x '*.rej' gimp-1.2.5.orig/app/Makefile.am gimp-1.2.5/app/Makefile.am --- gimp-1.2.5.orig/app/Makefile.am Thu Feb 13 17:13:11 2003 +++ gimp-1.2.5/app/Makefile.am Thu Jul 24 15:42:13 2003 @@ -464,6 +464,7 @@
-I$(top_srcdir) \
-I$(top_srcdir)/intl \
$(GTK_CFLAGS) \
+ $(STARTUP_NOTIFICATION_CFLAGS) \
-I$(includedir)

gimp_1_2_LDADD = \ @@ -474,6 +475,7 @@
$(GTK_LIBS) \
$(GIMP_THREAD_LIBS) \
$(GIMP_MP_LIBS) \
+ $(STARTUP_NOTIFICATION_LIBS) \ $(INTLLIBS)

gimp-win32res.o : gimp.rc diff -Nru -x '*~' -x '*.o' -x '*.orig' -x '*.rej' gimp-1.2.5.orig/app/app_procs.c gimp-1.2.5/app/app_procs.c --- gimp-1.2.5.orig/app/app_procs.c Thu Apr 3 17:59:30 2003 +++ gimp-1.2.5/app/app_procs.c Thu Jul 24 15:42:31 2003 @@ -349,11 +349,59 @@
static GtkWidget *label2 = NULL;
static GtkWidget *pbar = NULL;

+#ifdef HAVE_STARTUP_NOTIFICATION +#define SN_API_NOT_YET_FROZEN
+#include
+#include
+
+static void
+sn_error_trap_push (SnDisplay *display, + Display *xdisplay) +{
+ gdk_error_trap_push ();
+}
+ +static void
+sn_error_trap_pop (SnDisplay *display, + Display *xdisplay) +{
+ gdk_error_trap_pop ();
+}
+
+static void
+startup_notification_complete(void) +{
+ SnDisplay *sn_display = NULL;
+ SnLauncheeContext *context = NULL; + Display *xdisplay;
+
+ xdisplay = GDK_WINDOW_XDISPLAY(win_initstatus->window); + sn_display = sn_display_new (xdisplay, + sn_error_trap_push,
+ sn_error_trap_pop);
+
+ context = sn_launchee_context_new_from_environment (sn_display, + DefaultScreen(xdisplay)); +
+ if (context != NULL)
+ {
+ sn_launchee_context_complete (context); + sn_launchee_context_unref (context); + sn_display_unref (sn_display); + }
+
+}
+#endif
+
static void
destroy_initialization_status_window (void) {
if (win_initstatus)
{
+ #ifdef HAVE_STARTUP_NOTIFICATION + startup_notification_complete(); + #endif
+
gtk_widget_destroy (win_initstatus);

if (logo_pixmap != NULL) @@ -362,6 +410,7 @@
logo_pixmap = NULL;
win_initstatus = label1 = label2 = pbar = logo_area = NULL; }
+
}

static void
diff -Nru -x '*~' -x '*.o' -x '*.orig' -x '*.rej' gimp-1.2.5.orig/configure.in gimp-1.2.5/configure.in --- gimp-1.2.5.orig/configure.in Sun Jun 1 22:54:58 2003 +++ gimp-1.2.5/configure.in Thu Jul 24 15:41:48 2003 @@ -748,6 +748,8 @@
*** --disable-print to configure (but you won't be able to print then).]) fi

+dnl This is for startup notification +PKG_CHECK_MODULES(STARTUP_NOTIFICATION, libstartup-notification-1.0 >= 0.5, AC_DEFINE([HAVE_STARTUP_NOTIFICATION],[], [Should we use libstartup-notification]) echo "Building with libstartup-notification", echo "Building without libstartup-notification")

dnl This is for the gimp-perl plug-in AC_ARG_ENABLE(perl, [ --disable-perl do not build perl extension [by default enabled] @@ -931,6 +933,9 @@
AC_SUBST(GIMP_PLUGINS)
AC_SUBST(GIMP_MODULES)

+AC_SUBST(STARTUP_NOTIFICATION_CFLAGS) +AC_SUBST(STARTUP_NOTIFICATION_LIBS) +
dnl Output the Makefiles

AC_OUTPUT([

this sounds really really cool.

can we start with this on the web site (or on the wiki) and make downloadable plugins?

remove some of our favorite plugins, make sure they are tidy, and put them back on line with some *help* and *explainations*?

please?

carol

Hi,

Miguel Ibarra writes:

Here's a patch to add optional libstartup-notification support to The Gimp. This will allow desktop managers as Gnome's to entertain users with a *so* funny clock cursor, while Gimp launches and initializes itself.

GIMP-1.3 does this already. We will not include it in 1.2 since only bug-fixes go into 1.2.

Sven

Sven Neumann wrote:

Miguel Ibarra writes:

Here's a patch to add optional libstartup-notification support to The Gimp. This will allow desktop managers as Gnome's to entertain users with a *so* funny clock cursor, while Gimp launches and initializes itself.

GIMP-1.3 does this already. We will not include it in 1.2 since only bug-fixes go into 1.2.

I'm interested, from a project point of view, why many (a good proportion) of the patches that we get on this mailing list or in bugzilla from 'external' (non-CVS-account) contributors are against 1.2.x.

Are developers not very well aware of the positioning of 1.3.x (development) versus 1.2.x (stable)? Is it too hard to get a 1.3.x build to patch against?

Miguel, or anyone else, can you comment?

Identifying the cause of this weakness would help to smooth the bumps in accepting (very welcome) external contributions.

--Adam

Adam D. Moss wrote:

Sven Neumann wrote:

Miguel Ibarra writes:

Here's a patch to add optional libstartup-notification support to The Gimp. This will allow desktop managers as Gnome's to entertain users with a *so* funny clock cursor, while Gimp launches and initializes itself.

GIMP-1.3 does this already. We will not include it in 1.2 since only bug-fixes go into 1.2.

I'm interested, from a project point of view, why many (a good proportion) of the patches that we get on this mailing list or in bugzilla from 'external' (non-CVS-account) contributors are against 1.2.x.

Are developers not very well aware of the positioning of 1.3.x (development) versus 1.2.x (stable)? Is it too hard to get a 1.3.x build to patch against?

Miguel, or anyone else, can you comment?

Identifying the cause of this weakness would help to smooth the bumps in accepting (very welcome) external contributions.

--Adam

maybe he doesn't have cvs access ....

carol

Carol Spears wrote:

maybe he doesn't have cvs access ....

That by no means stops anyone from submitting a patch against 1.3.

--Adam

Am Sam, 2003-07-26 um 16.39 schrieb Carol Spears:

maybe he doesn't have cvs access ....

Doesn't make sense from three perspectives: - One doesn't need CVS to develop a patch - Everyone can get at least anoncvs
- There are frequent releases and other means of getting the source

I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally.

FWIW I think we're far to strict with what should go into 1.2 and not, especially given the huge development cycles between new major stable releases.

On Sat, 26 Jul 2003, Adam D. Moss wrote:

Sven Neumann wrote:

Miguel Ibarra writes:

Here's a patch to add optional libstartup-notification support to The Gimp. This will allow desktop managers as Gnome's to entertain users with a *so* funny clock cursor, while Gimp launches and initializes itself.

GIMP-1.3 does this already. We will not include it in 1.2 since only bug-fixes go into 1.2.

Some projects are not so strict and would allow something like this because it is quite unlikely to have any unwanted side effects.

Also if someone goes to the trouble of providing a patch the rejections needs to be less abrupt if you want people to keep making that effort.

I'm interested, from a project point of view, why many (a good proportion) of the patches that we get on this mailing list or in bugzilla from 'external' (non-CVS-account) contributors are against 1.2.x.

There has been too long a space between stable releases, I expect many people are blissfully unaware that GIMP 1.3 even exists (and will remain unaware until a new release ships with a major Linux distribution).

Are developers not very well aware of the positioning of 1.3.x (development) versus 1.2.x (stable)? Is it too hard to get a 1.3.x build to patch against?

Miguel, or anyone else, can you comment?

Identifying the cause of this weakness would help to smooth the bumps in accepting (very welcome) external contributions.

I am optomistic that there will be an increase in outside contributions when 2.0 comes out.

(I dont think a CVS account has anything to do with this, there is anonymouse CVS access and I doubt a Ximian employee would have much difficulty getting a CVS account if he wanted it).

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

Adam D. Moss wrote:

I'm interested, from a project point of view, why many (a good proportion) of the patches that we get on this mailing list or in bugzilla from 'external' (non-CVS-account) contributors are against 1.2.x.

I think there are a few reasons for this. The biggest of them is that setting up a gimp 1.3 compile environment is very time consuming. Usually to be able to build from CVS, you need to upgrade/install automake, autoconf, libtool, gettext, intltool to start with, then get all the modules (png, jpeg, etc) installed with headers, then get a working devel environment of gtk+ with pangoft2, freetype2, fontconfig and the rest. Then finally you can start autogening and making the gimp.

When GNOME2 becomes more or less ubiquitous on distributions, and it is easily installable off distribution CDs with devel packages, and fontconfig gets onto pretty much every linux box, then it'll be easier to get up & going for the gimp. As it is, to get a gimp 1.3 build environment for most people means passing several hours installing packages you don't have and probably don't particularly want. Plus, in the past that build environment has changed pretty drastically several times with no real prior notice, which puts people off maintaining a working build.

At least, that's my theory :)

Identifying the cause of this weakness would help to smooth the bumps in accepting (very welcome) external contributions.

I agree. I think we need to do a little more to get developpment gimps built by more people. Exactly what, I don't know. Wait for GNOME2 to take over the world, perhaps?

Cheers, Dave.

David Neary wrote:

I think there are a few reasons for this. The biggest of them is that setting up a gimp 1.3 compile environment [..]

> automake, autoconf, libtool, gettext, intltool [..] > (png, jpeg, etc) [..] gtk+ with pangoft2, freetype2, fontconfig [..]

At least, that's my theory :)

It's a good theory, being the mysterious reason why my own patches are made against 1.2.x and then blindly forward-ported to 1.3.x (it's why my commits are usually coupled with a bugzilla comment like 'could someone please check that CVS HEAD now actually compiles' :) )

But I was hoping that the reasons for other developers diffing against 1.2.x are even more mundane and fixable, since everyone except me lives in a fairytale world of supported rpms and debs and magical stuff like that.

Identifying the cause of this weakness would help to smooth the bumps in accepting (very welcome) external contributions.

I agree. I think we need to do a little more to get developpment gimps built by more people. Exactly what, I don't know. Wait for GNOME2 to take over the world, perhaps?

If the hegemonising swarm of sub-mediocrity that is GNOME ever succeeds in taking over the world, then I'm going to move up to the mountains and become a hermit or a kung-fu monk or a hermit kung-fu monk.

--Adam

Adam D. Moss wrote:

David Neary wrote:

I think there are a few reasons for this. The biggest of them is that setting up a gimp 1.3 compile environment [..] utomake, autoconf, libtool, gettext, intltool [..] png, jpeg, etc) [..] gtk+ with pangoft2, freetype2, fontconfig

[..]

At least, that's my theory :)

It's a good theory, being the mysterious reason why my own patches are made against 1.2.x and then blindly forward-ported to 1.3.x (it's why my commits are usually coupled with a bugzilla comment like 'could someone please check that CVS HEAD now actually compiles' :) )

But I was hoping that the reasons for other developers diffing against 1.2.x are even more mundane and fixable, since everyone except me lives in a fairytale world of supported rpms and debs and magical stuff like that.

Being brutally brunt, if a maintainer of several gimp plug-ins and a former core developper can't manage to keep an up-to-date build of CVS going, what chances are there for mere mortals who are just shopping around for a worthwhile cause?

If the hegemonising swarm of sub-mediocrity that is GNOME ever succeeds in taking over the world, then I'm going to move up to the mountains and become a hermit or a kung-fu monk or a hermit kung-fu monk.

You may leave when you can grab the pebble from my hand, grasshopper.

Dave.

On 26-Jul-2003, Daniel Egger wrote:

I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally.

Wrong, Im an artist, and I prefer 1.3 over 1.2.

Hi,

On Saturday 26 July 2003 8:04 pm, Adam D. Moss wrote:

It's a good theory, being the mysterious reason why my own patches are made against 1.2.x and then blindly

Ditto here. There's also a common misconception, dating from the early releases of Gnome 2.0. The first readmes said something about not being able to install the 2.0 packages alongside the older 1.4 packages, so many people, including myself, assumed this really did mean all the packages including GLib/GTK+. Ironically, GIMP was the main program I was unwilling to sacrifice in trying out Gnome 2.0.

It's only recently I've installed GTK2 and got the PangoFT2 bits working - and it is a laborious and painful process.

All the best,

Am Son, 2003-07-27 um 00.19 schrieb Patrick McFarland:

Wrong, Im an artist, and I prefer 1.3 over 1.2.

Good for you. I know at least 6 persons who do not. :) However I'm quite interested in your reasons, would you please elaborate so I can get some feeling what to tell people when they ask me reasons for using 1.3. (Yeah, I'm addicted to (subpixel-)antialiased fonts on LCD, too but I'm sure not many people would sacrify stability and their experience with the older version for it).

On 27-Jul-2003, Daniel Egger wrote:

Good for you. I know at least 6 persons who do not. :) However I'm quite interested in your reasons, would you please elaborate so I can get some feeling what to tell people when they ask me reasons for using 1.3.

Well, the tabbed dialog boxes, "docks", are very nice. They save a lot of desktop room (which is needed when you are editing large images, and arnt willing to zoom out a lot.)

Also, the fact that it has a sane text plugin is nice. (I switched over to a pango based font system, so all my truetype fonts "cant" (read as: Im not willing to add them back to X.) be seen by gtk1 apps.)

Also, the additional layer blending modes are nice. Ive used both Grain modes already in some images, and they are nice additions to plain Addition and Subtraction.

And with all of this, the image scaling dialog box has linear/cubic right there, so I dont have to go the whole way into preferences to change which scaling mode I want. (Which was a big fucking pain in the ass.) And in addition to that, having editable font boxen is very nice. (Though, Id like a way to force it to be a rendered layer, because when you change the layer, and accidently edit the layer's text, it erases everything you did.)

People who are photoshop fanatics will like the menubar (which I hate since I already use the right click menu.)

The only thing I _dont_ like is there is no gimp-perl packaged for 1.3 in debin sid. (Is it not available for 1.3, or are ari and che not willing to package it?)

On Sat, 26 Jul 2003, Patrick McFarland wrote:

On 26-Jul-2003, Daniel Egger wrote:

I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally.

Wrong, Im an artist, and I prefer 1.3 over 1.2.

"One Swallow does not a summer make".

Normal users in general abhor using anything labelled beta, consider your self extraordinary.

The quality of most proprietary software has even caused users to distrust N.0 release and wait for the first or second service patch.

If you can build from source then you are probably more developer than user anyway.

While it is great that there are GIMP users willing to make the extra effort to use 1.3 I really hope to see GIMP being used by everyone else. The sooner we stamp out piracy of Adobe Photoshop the bettter :)

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

On 26 Jul 2003, at 18:19, Patrick McFarland wrote:

On 26-Jul-2003, Daniel Egger wrote:

I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally.

Wrong, Im an artist, and I prefer 1.3 over 1.2.

Did you prefer 1.3 in January 2001?

On 27-Jul-2003, Branko Collin wrote:

On 26 Jul 2003, at 18:19, Patrick McFarland wrote:

Wrong, Im an artist, and I prefer 1.3 over 1.2.

Did you prefer 1.3 in January 2001?

Did 1.3 exist in january 2001?

If you can build from source then you are probably more developer than user anyway.

This isn't actually so big problem under Redhat 9 or Redhat 7.3 with Ximian Desktop 2.

1. Have proper devel rpms installed. 2. ./configure && make
3. su -
4. cd ...
5. make install

It doesn't seem so hard to me. But I can say that I wouldn't try to build all the dependency libraries by hand esp. because of the autoconf, libtool upgrade needed.

Tom Mraz

So is the current 1.3.x build environment documented in the HACKING file (or elsewhere)?

I'm guessing that the file is probably out of date, or lacking things.

Austin

On 27 Jul 2003, at 23:00, Patrick McFarland wrote:

On 27-Jul-2003, Branko Collin wrote:

On 26 Jul 2003, at 18:19, Patrick McFarland wrote:

Wrong, Im an artist, and I prefer 1.3 over 1.2.

Did you prefer 1.3 in January 2001?

Did 1.3 exist in january 2001?

As far as I can tell (from the Changelog), yes.

The important questions, though, are 'was GIMP 1.2 feature-locked past January 2001?' and 'was GIMP 1.3 at all usable starting January 2003?'.

Hi,

Alan Horkan writes:

Also if someone goes to the trouble of providing a patch the rejections needs to be less abrupt if you want people to keep making that effort.

I'm sorry for the short mail. I was about to leave town for a few days and I preferred a quick reply over no reply.

Sven

Hi,

"Austin Donnelly" writes:

So is the current 1.3.x build environment documented in the HACKING file (or elsewhere)?

I'm guessing that the file is probably out of date, or lacking things.

It is documented in INSTALL, I don't think it is missing things and it certainly is not out-of-date.

Sven

Hi,

Alastair Robinson writes:

It's only recently I've installed GTK2 and got the PangoFT2 bits working - and it is a laborious and painful process.

Could you please explain what's so painful about it? Almost all distributions include packages for it for quite some time already and even compiling from source is pretty much straight-forward.

Please note that during the 1.3 development process we did never depend on the very latest versions of the required libraries. We always assured that even debian testing which is a very conservative distribution has the packages available that are needed to build GIMP-1.3. If we decided to change our dependencies to a newer version, we always checked if this is really necessary.

Sven

On Mon, 28 Jul 2003, Sven Neumann wrote:

It's only recently I've installed GTK2 and got the PangoFT2 bits working - and it is a laborious and painful process.

Could you please explain what's so painful about it? Almost all distributions include packages for it for quite some time already and even compiling from source is pretty much straight-forward.

Please note that during the 1.3 development process we did never depend on the very latest versions of the required libraries. We always assured that even debian testing which is a very conservative distribution has the packages available that are needed to build GIMP-1.3. If we decided to change our dependencies to a newer version, we always checked if this is really necessary.

Very glad to hear that you keep to the highest development standards and only upgrade when really necessary.

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

Hi Sven,

On Monday 28 July 2003 4:55 pm, Sven Neumann wrote:

Could you please explain what's so painful about it? Almost all distributions include packages for it for quite some time already and even compiling from source is pretty much straight-forward.

OK, maybe "painful" was an exaggeration; really it was just time-consuming; I'm using SuSE 8.0, and don't have -devel packages for even gtk+-1.2 packages on the original CDs.

The point I was trying to make was that needing full devel packages for all of the GTK2 stuff, including Pango-FT2 (and hence FreeType itself and Xft2/FontConfig) does constitute a barrier-to-entry (especially with a 56K dialup net connection), and is not something I'd go through just to play with the latest version of one particular app.

Doing it for a specific purpose (i.e. adapting my patch for the latest version of GIMP) is a different matter entirely, but in the first instance a patch will be developed because someone saw a need in a piece of software they were using - and in most cases that will be the Stable version. The release of 2.0 will make a big difference, because binary packages will become standard in distributions, so people will be using 2.0 when they recognise a particular need...

Please note that during the 1.3 development process we did never depend on the very latest versions of the required libraries. We always assured that even debian testing which is a very conservative distribution has the packages available that are needed to build GIMP-1.3. If we decided to change our dependencies to a newer version, we always checked if this is really necessary.

Yes, I wasn't complaining of bleeding-edge requirements as such - merely attempting to explain a phenomenon that had been noted, and to which I had contributed :)

Ultimately though, GTK2 build environments are still not as common as GTK1 build environments, so for many people, building the stable version is less hassle.

All the best,

Am Die, 2003-07-29 um 01.06 schrieb Alastair Robinson:

OK, maybe "painful" was an exaggeration; really it was just time-consuming; I'm using SuSE 8.0, and don't have -devel packages for even gtk+-1.2 packages on the original CDs.

Interesting, I'm pretty sure I put the devel packages on the CD. Is this personal or professional and if the latter CD or DVD? Have you tried the ftp sources?

Hi,

Patrick McFarland writes:

to that, having editable font boxen is very nice. (Though, Id like a way to force it to be a rendered layer, because when you change the layer, and accidently edit the layer's text, it erases everything you did.)

Yes, we should probably have "Convert to Pixels" for text layers. Since internally we wouldn't really convert, should we perhaps even stick a "Convert to Text Layer" menu entry to any ex-text-layer so it can be converted back if necessary?

Of course the problem you mention will become be a lot less severe as soon as undo for text operations is properly working.

I wouldn't mind if you or someone else filed bug-reports for these two issues...

Sven

On 29-Jul-2003, Sven Neumann wrote:

Yes, we should probably have "Convert to Pixels" for text layers. Since internally we wouldn't really convert, should we perhaps even stick a "Convert to Text Layer" menu entry to any ex-text-layer so it can be converted back if necessary?

Actually, you probably should really convert. "Convert to Pixels" would infact destroy the "text" object, and make it a real image. And of course, while destroying the "text" object, you can no longer edit the text.

As we say in my land, her e I come ¨selling my fish" again. :-) Back to the Custom Layer Mode.

On Saturday 26 July 2003 9:44 pm, Patrick McFarland wrote:

Also, the additional layer blending modes are nice. Ive used both Grain modes already in some images, and they are nice additions to plain Addition and Subtraction.

So...just wait until the custom layer modes are put to work in a usable way. :-)
You will just love it.

Unfortunatelly I got a new project at work and will have even less time to write it. So it will probably not get ready to feature freeze. :-( Not final use ready, but maybe it gets working sans a good UI.

Under the custom layer mode, one would not have to wait for a GIMP major release to get the grain modes.

For example, this is the line in current gimp code that does the "merge mode" :

sum = src1[b] + src2[b] - 128;

It will be doable by typing: ED = E1 + E2 -0.5;

as the custom layer mode. (E stands for "every channel". A is already used for alpha - I myself dislike the "every", and will accept other suggestions)

The advantadges? Even the above formula throws information away - it kees a better average than ADD layer mode. With the custom layer mode, you willbe able to adjust the cnstante factor for every layer on every image.
Thus if it is too light, with large white only areas, one will just have to edit the layer mode expression from the above to: ED = E1 + E2 -0.7; , for instance.

Cheers,

JS ->

On 28-Jul-2003, Joao S. O. Bueno wrote:

It will be doable by typing:
ED = E1 + E2 -0.5;

as the custom layer mode. (E stands for "every channel". A is already used for alpha - I myself dislike the "every", and will accept other suggestions)

The advantadges? Even the above formula throws information away - it kees a better average than ADD layer mode. With the custom layer mode, you willbe able to adjust the cnstante factor for every layer on every image.
Thus if it is too light, with large white only areas, one will just have to edit the layer mode expression from the above to:

I have no issues with E. It might also be nice to have YUV (independant of the image's mode).

On 29-Jul-2003, Sven Neumann wrote:

I wouldn't mind if you or someone else filed bug-reports for these two issues...

The Convert To Pixels bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=118547

Hi,

Patrick McFarland writes:

Actually, you probably should really convert. "Convert to Pixels" would infact destroy the "text" object, and make it a real image. And of course, while destroying the "text" object, you can no longer edit the text.

The text layer is always a real layer, but rest assured, you won't notice the difference at the user interface level. It's just a fact that we could include the possibility to restore the text later and I wonder if we should do that.

Sven

Hi,

"Joao S. O. Bueno" writes:

For example, this is the line in current gimp code that does the "merge mode" :

sum = src1[b] + src2[b] - 128;

It will be doable by typing: ED = E1 + E2 -0.5;

as the custom layer mode. (E stands for "every channel". A is already used for alpha - I myself dislike the "every", and will accept other suggestions)

The advantadges? Even the above formula throws information away - it kees a better average than ADD layer mode. With the custom layer mode, you willbe able to adjust the cnstante factor for every layer on every image.
Thus if it is too light, with large white only areas, one will just have to edit the layer mode expression from the above to: ED = E1 + E2 -0.7; , for instance.

I don't want to discourage you and it's certainly a nice expert/geek feature but I doubt that the casual GIMP user wants to type in any formulas.

Sven

On 29-Jul-2003, Sven Neumann wrote:

I don't want to discourage you and it's certainly a nice expert/geek feature but I doubt that the casual GIMP user wants to type in any formulas.

No, but I doubt the casual GIMP user cares about a feature they arnt smart enough to use yet. AFAIK this isnt a replace ment for all modes, just an additional mode.

On Tuesday 29 July 2003 1:25 am, Patrick McFarland wrote:

On 28-Jul-2003, Joao S. O. Bueno wrote:

It will be doable by typing:
ED = E1 + E2 -0.5;

as the custom layer mode. (E stands for "every channel". A is already used for alpha - I myself dislike the "every", and will accept other suggestions)

The advantadges? Even the above formula throws information away - it kees a better average than ADD layer mode. With the custom layer mode, you willbe able to adjust the cnstante factor for every layer on every image.
Thus if it is too light, with large white only areas, one will just have to edit the layer mode expression from the above to:

I have no issues with E. It might also be nice to have YUV (independant of the image's mode).

I have implemented R G B, H S V, and A besides E. BTW, E doesn't affect the alpha channel - as the majority o f the fixed combination modes do not.

-