Re: [Gimp-developer] Could someone add the CVS modules to the develpage?
Joao S. O. Bueno wrote: The information about the CVS modules on the web is this bit (from http://www.gimp.org/devel_cvs.html ) (...) I know from at least gimp-gap and gimp-perl more, maybe there are a couple I have not heard about. There are libart_lgpl, atk, and pango at least - a build of the gimp also requires fontconfig, freetype2 and probably others that I have forgotten. All of this information is in the INSTALL file, located at the root directory of your gimp tarball, and also of CVS. Possibly tehre is a fair easy way to know about the modules using CVS itself. But by knowledge on CVS is close to zero. :-( sorry about that. Nope - CVS does not support specifying interdependencies - it knows nothing about file structure. It versions files, period. Luckily, that's all it has to do :) We use good old text files to specify interdependencies. Hope this helps, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Could someone add the CVS modules to the develpage?
On Fri, Jul 25, 2003 at 08:37:24AM +0200, David Neary wrote: The information about the CVS modules on the web is this bit (from http://www.gimp.org/devel_cvs.html ) (...) I know from at least gimp-gap and gimp-perl more, maybe there are a couple I have not heard about. There are libart_lgpl, atk, and pango at least - a build of the gimp also requires fontconfig, freetype2 and probably others that I have forgotten. All of this information is in the INSTALL file, located at the root directory of your gimp tarball, and also of CVS. Possibly tehre is a fair easy way to know about the modules using CVS itself. But by knowledge on CVS is close to zero. :-( sorry about that. Nope - CVS does not support specifying interdependencies - it knows nothing about file structure. It versions files, period. Luckily, that's all it has to do :) We use good old text files to specify interdependencies. There is actually a good old text file in CVSROOT: modules. You can specify aliases for modules there and also group several modules together. It needs careful checking though - it's easy to mess things up this way. If the modules file is set up correctly, you can even run cvs -c to get a list of available modules. This is very useful IMO. Ah, I see, it actually works for GNOME cvs: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome co -c There's no gimp-gap nor gimp-perl though. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Could someone add the CVS modules to the develpage?
Tino Schwarze wrote: On Fri, Jul 25, 2003 at 08:37:24AM +0200, David Neary wrote: CVS does not support specifying interdependencies - it knows nothing about file structure. It versions files, period. Luckily, that's all it has to do :) We use good old text files to specify interdependencies. There is actually a good old text file in CVSROOT: modules. You can specify aliases for modules there and also group several modules together. It needs careful checking though - it's easy to mess things up this way. If the modules file is set up correctly, you can even run cvs -c to get a list of available modules. This is very useful IMO. Ah, I see, it actually works for GNOME cvs: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome co -c There's no gimp-gap nor gimp-perl though. Up until pretty recently, GNOME CVS had a habit of creating a module as an alias for a directory... I suppose this was so that the aforementioned cvs co -c would work... there is actually no way to know what directories exist in a cvs repository other than looking, I think. Either with a gui tool, or with a file browser. I may be wrong, though. Anyway, listing the modules in GNOME CVS doesn't get us any further along the way towards knowing what modules the gimp HEAD depends on, which is what I understood of the question. Although I guess (now that I'm reading the info file) tyhat it would be possible to create a gimp_container module which had the following in the modules file... gimp_container gimp gtk+ glib pango atk libart_lgpl etc... But then how could one specify a particular branch to be taken, in the case whete the GIMP doesn't build against HEAD? I'm guessing that we're going to build against GTK+ 2.2 from now on, if we're in feature freeze, that means not taking the HEAD branch from several modules. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Could someone add the CVS modules to thedevel page?
Am Fre, 2003-07-25 um 09.31 schrieb David Neary: Up until pretty recently, GNOME CVS had a habit of creating a module as an alias for a directory... I suppose this was so that the aforementioned cvs co -c would work... there is actually no way to know what directories exist in a cvs repository other than looking, I think. Either with a gui tool, or with a file browser. I may be wrong, though. http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] Could someone add the CVS modules to the develpage?
Daniel Egger wrote: Am Fre, 2003-07-25 um 09.31 schrieb David Neary: Up until pretty recently, GNOME CVS had a habit of creating a module as an alias for a directory... I suppose this was so that the aforementioned cvs co -c would work... there is actually no way to know what directories exist in a cvs repository other than looking, I think. Either with a gui tool, or with a file browser. I may be wrong, though. http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome This is what I was looking for, thanks. The cvs co -c command had some missing, notably gimp-gap, gimp-perl, gimp-data-extras. As for the dependencies, I was not asking about that. INSTALL, HACKING and the output of ./configure say enough about those. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Could someone add the CVS modules to the develpage?
Hi, I've added a list of GIMP related CVS modules to http://developer.gimp.org/cvs.html Could needs some stylesheet tweaking though... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: gimp-plugin-template 1.3.1
Hi, going hand in hand with the 1.3.17 release, there's now an updated version of the gimp-plugin-template available from ftp://ftp.gimp.org/pub/gimp/plugin-template/ The template has been relicensed to a less restrictive X11-style license (thanks to Adam for his patch) and was updated to follow the GIMP-1.3 API changes. It requires at least GIMP-1.3.17. If you want to write a larger plug-in for GIMP 2.0, this package should give you a good start. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Custom layer mode combination
[EMAIL PROTECTED] (2003-07-24 at 2031.28 -0300): The basic idea is that besides the normal addition darken only layer modes, to implement a custom mode. In it, the user gets to type a c-like expression of what to do with the pixel values in each channel when combining the layer. IMO you are forgeting a kind that users will like a lot more: call other GIMP functions, specially some like levels or curves (in this case, using the layer to control strengh in a channel by channel basis, or maybe using value (V in HSV) to get a single number and work like a selection mask, you should have to checke what makes sense). I guess users will find more use to those than playing around with formulas. I used the filter that lets you do math formulas to test ideas, but dunno how many people would like to use that daily. The formulas are nice, I am not saying you should drop that, but you should find a way to cover both if you can, formula and PDB. If you are going to get dirty, make it really worth it. Maybe even you can do the PDB way only, and provide a new call that does formulas (sounds simpler to me, more generic). Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only, which is what you need for auto bevel or auto drop shadow when working with text, ie. Last case would be more like having a layer hidden as input and a visible one as output, and recalculate output one only when input changes, not every time layers below change. In any way, all are interesting ideas to explore. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Hi. I do not know the X11 license, but changing the license of the plugin template recalls me of one thing: If the GIMP is under the GPL, with no exceptions listed were appropriate, them it is ilegal for non GPL-compatible plugins to be installed. This is quite clear on the GPL-FAQ. And for great that it may seen for some people to have some proprietary plugins developed for the GIMP, that otherwise would not, we get better respecting the GPL or __else__. To allow for non gpl-compatible plugins to run with the GIMP, the license of the GIMP itself must include an exception note, stating that. Sven Neumann wrote: Hi, going hand in hand with the 1.3.17 release, there's now an updated version of the gimp-plugin-template available from ftp://ftp.gimp.org/pub/gimp/plugin-template/ The template has been relicensed to a less restrictive X11-style license (thanks to Adam for his patch) and was updated to follow the GIMP-1.3 API changes. It requires at least GIMP-1.3.17. If you want to write a larger plug-in for GIMP 2.0, this package should give you a good start. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: gimp-plugin-template 1.3.1
great to see a new development release again, i will definately update my GTK in order to build this one :) i played around with the Wilber Construction kit some time ago and added some shiny higlights, i've just uploaded it to http://gug.sunsite.dk/gallery.php?artist=123 if you want to have a look and maybe use it if you like the additions. Phil. Hi, going hand in hand with the 1.3.17 release, there's now an updated version of the gimp-plugin-template available from ftp://ftp.gimp.org/pub/gimp/plugin-template/ The template has been relicensed to a less restrictive X11-style license (thanks to Adam for his patch) and was updated to follow the GIMP-1.3 API changes. It requires at least GIMP-1.3.17. If you want to write a larger plug-in for GIMP 2.0, this package should give you a good start. Sven _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Manish Singh wrote: The libraries needed for a GIMP plug-in are licensed under the LGPL. The way the architecture is now, plug-ins don't link against the app directly. Quite so. However, from the GPL FAQ (I presume this is the root of Joao's excitement): http://www.gnu.org/licenses/gpl-faq.html#MereAggregation This implies that it *may* be quite plausible for the GIMP core to be considered as part of a plugin (or vice versa). Considered by whom, though, is another question. As I said, the ones to take umbrage at this binary coupling would be us, the developers, and we clearly don't intend to. But it probably worth making this clear as an explicit exemption in the LICENSE (this isn't an unusual action, for example GCC's libstdc code is GPL-licensed with exemptions for the resulting binary so as not to GPL-infect every C program built with with GCC[1]). --Adam [1] Except for GCC versions circa 3.1 where they forgot to exempt some portions of the code that ends up in the installed libstdc so the aggregate libstdc and hence almost all C programs built with that compiler are *technically* GPL- infected -- but still, their intent is clear, that this was simply an oversight and they have no intention of asserting the GPL on their users. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
[s/libstdc/libgcc/g, sorry.] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Joao S. O. Bueno wrote: I do not know the X11 license, but changing the license of the plugin template recalls me of one thing: If the GIMP is under the GPL, with no exceptions listed were appropriate, them it is ilegal for non GPL-compatible plugins to be installed. The GPL doesn't care which licence is used before it gets it, as long as it is consistent with the terms of the GPL (that is, as long as the program can be released under the GPL without breaching the opriginal licence). This is the case with the X11 licence. Many people like the idea of their work being used by the greatest number of people possible, regardless of the conditions in which it's used. These people choiose a licence which is more liberal than the GPL. This is quite clear on the GPL-FAQ. And for great that it may seen for some people to have some proprietary plugins developed for the GIMP, that otherwise would not, we get better respecting the GPL or __else__. The X11 licelce is GPL compatible. That means that X11 code can be released under the GPL, and there's nothing the original authors can do about it. So there is no problem with code which is licenced under the X11 licence being included in the gimp. To allow for non gpl-compatible plugins to run with the GIMP, the license of the GIMP itself must include an exception note, stating that. And this is horse-bucky. The GIMP provides an interface (the PDB) via which plug-ins communicate with the gimp core. Nothing obliges those plug-ins to be released under the GPL. They link against libgimp (which is lgpl). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Startup Notification support...
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,
--
Miguel Ibarra [EMAIL PROTECTED]
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 libsn/sn-launchee.h
+#include gdk/gdkx.h
+
+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([
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
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. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Layer movement independent of layer mask
Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=91941 This feature request is for a way to de-couple layerr movement and layer mmask movement (more details in the bug). The idea would be that you could draw a mask, and if you positioned it incorrectly at the start, you could just move it. Currently, the only way is to convert the mask to a float, move it, and then anchor it again. It seems fairly straightforward, but it includes a gui change which would involve a little UI work, and a little testing :) Anyone feel like taking this one? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Thumbnail PDB API for Plug-Ins
Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=113033 This is a request for PDB functions to manipulate (delete, update, access) thumbnails. This seems mostly done, but there are still some bit to be argued out (mainly whether gimp_file_load_thumbnail works, as far as I can tell). There's a patch attached. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Curves Enhancement
Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=71633 Someone has requested that a histogram be shown for the curves dialog to show what the histo will look like after the curve application. Of course, we need someone to code it. There's a mock-up attached so that you can see the intended effect. I believe the screenshot is referring to the subsection Analog gain control. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Adding ICC support
Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=78265 The requested feature is a plug-in which encapsulates the behaviour of the ICC, that is does colour conversions. This would get us a long way towards CMYK support in 2.0, as well as removing the need for custom colour transform code in lots of places in the core. Of couyrse, without the ability in a GimpImage to store and access CLYK natively, we're not going to have native support for multiple colourspaces, but this is a decent start for save routines, for example. Definitely needs some coding (and some ideas) soon otherwise it's definitely getting bumped. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Edge detection plug-in should have more edge detection algorithms
Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=98326 This is a really easy one - there's a plug-in with source code for about 5 diufferent edge detection algorithms, they're all coded, all that needs to be done is to write some interface code to allow the user to choose which algo they want to use, and add the code to the existing edge detection plug-in. I'll leave this open to discussion - if someone else wants to do it, I'm more than happy to let them. If no-one's claimed it by Sunday, I'll do it. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Add optional motion constraints to the Move Tool
Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=78730 It would be nice if the Ctrl modifier did for the move tool what it did for other tools and constrained movement to 22.5 degree directions. The feature needs doing. Who wants it? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Some plug-in settings should be persistent accross sessions
In another bug report (which I am having difficulty finding) a users complians of being asked too many questions during Save. To solve this i suggested that there should be a section in Preferences allowing you to set save options on the basis that you dont need to set these options every time you save, usually you will want to use the same ones most of them. There would also need to be an [Options] button in the save dialog to access it quickly and change a save option when needed. I would be very much in favour of having a Prefernces section Export (and possibly Import). Hopefully I can help recommend how this might be added. I would be inclined to push the feature request to Future. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Original message included below: [and list digest options finally changed to MIME so i can reply to stuff properly in future] From: David Neary [EMAIL PROTECTED] To: Gimp Developer List [EMAIL PROTECTED] Subject: [Gimp-developer] [FEATURE] Some plug-in settings should be persistent accross sessions Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-15 MIME-Version: 1.0 Precedence: list Message: 11 Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=63610 Notably the Gif and Jpeg plug-ins have defaults which people change fairly frequently. It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal preferences dialog (this might be handy enough although Sven might have something to say about it). Basically some discussion is needed. Currently, the jpeg defaults suck. I would suggest following the advice in this bug and changing the default quality to 85%. Currently this is hard-coded in the plug-in. If someone were to spend a bit of time figuring out how we could do this better (and reporting here, and claiming the bug) that would be great. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Adding ICC support
David Neary wrote: Definitely needs some coding (and some ideas) soon otherwise it's definitely getting bumped. Hi David. Thanks for all the QA work lately. Personally I think that we've got to be really brutal at this point. 2.0 freeze is DAYS away, for one thing (heck, until a few weeks ago 2.0 was going to be RELEASED at Camp). And as maintainers know, a pending freeze should NOT equate to arrghh, quick quick, shovel in the features before the freeze, We'll Fix Them Up Real Good Later. If it even vaguely smells like a feature and there's not already a patch for it (or it just involves tweaking some constants), IMO it must miss the 2.0 train. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Add optional motion constraints tothe Move Tool
On Fri, 2003-07-25 at 22:27, David Neary wrote: Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=78730 It would be nice if the Ctrl modifier did for the move tool what it did for other tools and constrained movement to 22.5 degree directions. The feature needs doing. Who wants it? The thing changed in 1.3 and now the Ctrl modifier is used to toggle the behaviour of the tool from pick to move current. So this may only mean using Shift for the constraint. However this is a little inconsistent. I would suggest we go back to how 1.2 was in this particular tool and try to use Shift where Ctrl is being used in 1.3 (I have absolutely no idea how much work this is): Selection tools: --- no change (both Shift and Ctrl toggle the mode) Zoom tool: -- use Shift to toggle in/out. Move tool: -- use Shift to toggle pick/move current use Ctrl for movement constraint Crop tool: -- use Shift to toggle crop/resize perhaps use Ctrl for keeping either 1:1 aspect ratio or the aspec ratio of the whole image (new feature) Transform tools: no change Flip tool: -- use Shift instead of Ctrl Text tool: -- This is a little complicated. Currently if a text layer exists and is selected, one can click on a pixel that has text on it. Now the tool options change the text attributes. Clicking on it again brings up the edit window. Now let's see if this is better: Selecting a text layer with the text tool active will automatically make any changes to the tool optins apply to the text layer. Clicking anywhere on the layer will bring up the edit dialog with the text loaded. A Shift modifier will toggle edit_current/new_text_layer behaviour. Setting default text tool parameters can be done on a non-text layer. I apologise Sven for thinking about this too late :/ Fill tool: -- There's currently no modifier to fill with patterns. Now that we have RGBA patterns and the feature is actually useful ;) it would be nice to have a similar toggle as the select tools. Shift to toggle BG fill and Ctrl to toggle pattern fill. The option dialog could have nice little buttons with a FG rectangle, BG rectangle and active pattern rectangle, just like the selection tools have. Gradient tool: -- Shift could toggle the reverse gradient. Ctrl remains. Clone, Pen, Pencil, Airbrush, Dodgeburn, Blursharpen, Smudge and Eraser: Although Ctrl is used to toggle to picker tool, I'd leave it as it is, since Ctrl is used for constraints after shift is pressed. Ink tool: --- no change *Important mental shift* ;) === One last thought - we got rid of Alt+ shortcuts, because alt is reserved for access keys (mnemonics). However in poptatoshop for example Alt is used as a toggle key (zoom in/out, clone tool's pick area/draw...). That could be an option too, so that the paint tools make more sense (Alt to toggle paint/pick color, Shift for lines,Ctrl for constraints). Kinda late, but worth a thought? cheers -- Jakub Steiner [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
pspi (was: Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template1.3.1)
Nathan Carl Summers writes: Gimp plugins do not link with the Gimp and thus do not fall under Gimp's licence. Gimp plugins do link with libgimp*, which is licensed under the LGPL. Are there any licensing issues, BTW, with the pspi plug-in? (The GIMP plug-in that interfaces to Photoshop plugins.) It is currently licensed under the GPL. (I am the copyright holder, so I could change its license if necessary.) The Photoshop plugins that it is able to load (as DLLs) are of course in general totally proprietary software. Is there any problem with this? (I don't distribute any Photoshop plugins.) (Photoshop plugin here de facto means 3rd party Photoshop plugins, as Adobe's owns aren't useable by other PS plugin hosts than Adobe's own products.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: pspi
Tor Lillqvist wrote: Nathan Carl Summers writes: Gimp plugins do not link with the Gimp and thus do not fall under Gimp's licence. Gimp plugins do link with libgimp*, which is licensed under the LGPL. (note that Nathan's analysis is correct but incomplete, I believe) Are there any licensing issues, BTW, with the pspi plug-in? (The GIMP plug-in that interfaces to Photoshop plugins.) It is currently licensed under the GPL. (I am the copyright holder, so I could change its license if necessary.) The Photoshop plugins that it is able to load (as DLLs) are of course in general totally proprietary software. Is there any problem with this? (I don't distribute any Photoshop plugins.) I can't confidently say, myself. Technically in this case it's the end-user that is doing the 'linking' of the GPL and non-GPL code so you are personally not responsible for anything but having somewhat ill-licensed the pspi plugin for its intended use. :) But, my GPL interpretation gets fuzzy here because no-one is then simply redistributing the result of linking pspi and the Photoshop plugin, and the GPL is generally concerned with distribution rights, not private usage. (But then one part of me says 'so why would a non-GPL program depending on a GPL shared lib ever be a problem?' and things spiral down The GNU Ambiguity Vortex again.) But to me, your plugin sounds much more license-comfortable as LGPL (its entire nature, really, being that it links to foreign-licensed code). --Adam (NAL) -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans)
Michael Schumacher writes: According to Tor Lillqvist, there was something missing from Pango 1.2.3 and fixed shortly after the release. BTW, I now made new pre-built pango-1.2.3 Win32 packages on www.gimp.org/win32/downloads.html, with the missing exports added, so building GIMP 1.3.x for Win32 should now be easier. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans)
Michael Schumacher writes: According to Tor Lillqvist, there was something missing from Pango 1.2.3 and fixed shortly after the release. BTW, I now made new pre-built pango-1.2.3 Win32 packages on www.gimp.org/win32/downloads.html, with the missing exports added, so building GIMP 1.3.x for Win32 should now be easier. Thanks. I've succeeded in building GIMP 1.3 on Win32 using these packages. HTH, Michael -- The GIMP (deutsch): http://www.gimp.de +++ GMX - Mail, Messaging more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Giving a try to gimp-perl
Hi all ;), I know gimp-perl is still unstable, anyway i tried to compile it myself and test it with the bbgallery script. It's not a very complex script, just loads the jpeg images, rescales them to create the thumbnails, and save them. After that uses the HTML perl module to create a html gallery. I'm using gimp 1.3.16 and gimp-perl from cvs, and i got some errors after running it, mainly in the Net.pm module. I post the output of the script, maybe it will be of some help for people currently working in gimp-perl: Warning: Unknown token 'vlink' in config file: /home/huma/.bbgallery Warning: Unknown token 'bgcolor1' in config file: /home/huma/.bbgallery Warning: Unknown token 'alink' in config file: /home/huma/.bbgallery Warning: Unknown token 'bgcolor' in config file: /home/huma/.bbgallery Warning: Unknown token 'thumb_only' in config file: /home/huma/.bbgallery Warning: Unknown token 'text' in config file: /home/huma/.bbgallery Warning: Unknown token 'link' in config file: /home/huma/.bbgallery Warning: Unknown token 'text1' in config file: /home/huma/.bbgallery Warning: Unknown token 'text2' in config file: /home/huma/.bbgallery Warning: Unknown token 'bgcolor2' in config file: /home/huma/.bbgallery gimp_scale.pl: protocol error (1) at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Gimp/Net.pm line 67. (ERROR) protocol error (1) at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Gimp/Net.pm line 67. gimp_scale.pl: protocol error (1) at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Gimp/Net.pm line 67. (ERROR) protocol error (1) at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Gimp/Net.pm line 67. Use of uninitialized value in substitution (s///) at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/HTML/Entities.pm line 399. Use of uninitialized value in concatenation (.) or string at /usr/bin/bbgallery line 222. And thanks for all the great work with gimp 1.3 ;)), even unstable, is a lot better that gimp 1.2 ;) -- David Gómez The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
