[Gimp-developer] Invoking custom Gimp module from Web (Apache)
i consider myself pretty well versed with efficiency based upon server performance and apache conforms for me pretty well in plugging in modules to suite my needs and users demands. But I just don't see how you can use Common Gateway Interfacing for this task. I found your thread through a search engine looking for this exact same type of discussion but theres no way I'm gonna pipe gimp to apache in this manner. But Hey Man if you fetch yourself a release of mod_wsgi or mod_python this cgi method might just be doable, but with a lot of users running this, it could be hazardous. With My method I am developing I am going to use (hypothetically, I have not done this) a seperate module for gimp which will thread request's to and fro mod_wsgi(which I have just config'd and am working on the kinks). I would be more than happy to share my progress. Check out my website in a couple of days (http://site.google.com/site/abstractind) -- Subscidiary Faction of AbstractIndustrys ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Hacking on the mail plugin
OK, so I thought bug 596066
(https://bugzilla.gnome.org/show_bug.cgi?id=596066) might be easy
enough for me, an admitted novice in C.
However, I can not for the life of me figure out why my call to
g_spawn_async throws a segfault every time. I would be most grateful
if someone could point out the problem (I'm sure it's a newbie error
on my part).
This patch has known problems. Due to the new import/export structure
(I think), it will only work on native .XCF files right now., and the
file must be saved. There is some legacy code from the original
sendmail plugin hanging around that isn't doing much. And the
segfault of course :) And finally, xdg-email is broken, and needs to
be patched in order for Evolution or Thunderbird to even accept
attachments. You can grab the patch for xdg-email from launchpad
(filed upstream also):
https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/408350
The git patch is attached.
Thanks!
Chris
PS - is there any reason to maintain backwards compatibility with the
original mail plugin? The attached patch was a heavy-handed attack
just to see if I could get it working with xdg-utils - I have not
really settled on the best approach yet.
From 099cf07983d1dbc82510952b2a2bce798b7ef62f Mon Sep 17 00:00:00 2001
From: Chris Mohler
Date: Sat, 3 Oct 2009 21:10:35 -0500
Subject: [PATCH] Update mail plugin to use xdg-email
This is a work-in-progress patch to use xdg-email instead of sendmail. There are known problems.
---
plug-ins/common/mail.c | 501 +++-
1 files changed, 30 insertions(+), 471 deletions(-)
diff --git a/plug-ins/common/mail.c b/plug-ins/common/mail.c
index 8f5625a..19b8e71 100644
--- a/plug-ins/common/mail.c
+++ b/plug-ins/common/mail.c
@@ -102,8 +102,8 @@ static const guint8 mail_icon[] =
};
-#ifndef SENDMAIL
-#define SENDMAIL "/usr/lib/sendmail"
+#ifndef XDGEMAIL
+#define XDGEMAIL "/usr/bin/xdg-email"
#endif
#define BUFFER_SIZE 256
@@ -114,10 +114,6 @@ static const guint8 mail_icon[] =
typedef struct
{
gchar filename[BUFFER_SIZE];
- gchar receipt[BUFFER_SIZE];
- gchar from[BUFFER_SIZE];
- gchar subject[BUFFER_SIZE];
- gchar comment[BUFFER_SIZE];
} m_info;
@@ -128,26 +124,11 @@ static void run (const gchar *name,
gint *nreturn_vals,
GimpParam **return_vals);
-static GimpPDBStatusType save_image (const gchar *filename,
+static GimpPDBStatusType save_image (gchar *filename,
gint32image_ID,
gint32drawable_ID,
gint32run_mode);
-static gboolean save_dialog (void);
-static void mail_entry_callback (GtkWidget*widget,
-gchar*data);
-static void mesg_body_callback (GtkTextBuffer*buffer,
-gpointer data);
-
-static gboolean valid_file (const gchar *filename);
-static void create_headers (FILE *mailpipe);
-static gchar* find_extension (const gchar *filename);
-static gboolean to64 (const gchar *filename,
-FILE *outfile,
-GError **error);
-static FILE * sendmail_pipe(gchar **cmd,
-GPid *pid);
-
const GimpPlugInInfo PLUG_IN_INFO =
{
@@ -159,11 +140,9 @@ const GimpPlugInInfo PLUG_IN_INFO =
static m_info mail_info =
{
- "", "", "", "", ""
+ ""
};
-static gchar *mesg_body = NULL;
-
MAIN ()
@@ -176,16 +155,11 @@ query (void)
{ GIMP_PDB_IMAGE,"image", "Input image" },
{ GIMP_PDB_DRAWABLE, "drawable", "Drawable to save" },
{ GIMP_PDB_STRING, "filename", "The name of the file to save the image in" },
-{ GIMP_PDB_STRING, "to-address","The email address to send to" },
-{ GIMP_PDB_STRING, "from-address", "The email address for the From: field" },
-{ GIMP_PDB_STRING, "subject", "The subject" },
-{ GIMP_PDB_STRING, "comment", "The Comment" },
-{ GIMP_PDB_INT32,"encapsulation", "ignored" }
};
gimp_install_procedure (PLUG_IN_PROC,
N_("Send the image by email"),
- "You need to have sendmail installed",
+ "You need to have xdg-utils installed",
"Adrian Likins, Reagan Blundell",
"Adrian Likins, Reagan Blundell, Daniel Risa
Re: [Gimp-developer] Compiling from git on Ubuntu 9.04
On Sat, 3 Oct 2009 16:39:40 -0500 Chris Mohler wrote: > Well, I installed gtk 2.16.6 into /opt/gtk, then exported my > LD_CONFIG_PATH to there before compiling gimp (and also added to > PKG_CONFIG_PATH), so hopefully I've sidestepped that. If I'm headed > for trouble with this approach, someone please let me know :) > > It seems to be working OK, but it's not picking up the current GTK > settings/devices (like tablet). I think this method will work well > enough for testing purposes though, and my stock 2.6.6 install seems > to be working just fine. This might work and might not. Start gimp from the console, but before you do set the LD_LIBRARY_PATH to /opt/gtk or where ever you installed it Owen ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling from git on Ubuntu 9.04
On Sat, Oct 3, 2009 at 4:27 PM, Alexia Death wrote: > On Sat, Oct 3, 2009 at 10:02 PM, Chris Mohler wrote: >> On Sat, Oct 3, 2009 at 1:54 PM, Chris Mohler wrote: >>> Not sure how best to proceed - GIMP is requiring libgtk 2.16.6 to >>> proceed, and Ubuntu 9.04 is shipping 2.16.1. >> Compiling 2.16.6 now, sticking in /opt... > > you probably should remove any *.la files from your /usr/lib, or you > will run into a bad dependency/libtool hell. Happened to me after > installing gtk from git, and I was told this is common. Well, I installed gtk 2.16.6 into /opt/gtk, then exported my LD_CONFIG_PATH to there before compiling gimp (and also added to PKG_CONFIG_PATH), so hopefully I've sidestepped that. If I'm headed for trouble with this approach, someone please let me know :) It seems to be working OK, but it's not picking up the current GTK settings/devices (like tablet). I think this method will work well enough for testing purposes though, and my stock 2.6.6 install seems to be working just fine. Thanks, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling from git on Ubuntu 9.04
On Sat, Oct 3, 2009 at 1:54 PM, Chris Mohler wrote: > Not sure how best to proceed - GIMP is requiring libgtk 2.16.6 to > proceed, and Ubuntu 9.04 is shipping 2.16.1. > > Any ideas? Never mind :) Compiling 2.16.6 now, sticking in /opt... Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Compiling from git on Ubuntu 9.04
Hi, Not sure how best to proceed - GIMP is requiring libgtk 2.16.6 to proceed, and Ubuntu 9.04 is shipping 2.16.1. Any ideas? Also - the INSTALL file probably needs an update: 4. You need to have installed GTK+ version 2.16.1 or newer Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
photocomix wrote: >> so I am sorry. no additions solely for digital-artists. > > I am afraid that you undervalue creativity of who use gimp for photo > or image > editing > > I explain better, even if the goal may be different (as photo- > retouch differs > from use gimp to paint) the tool used are often the same > > So as who use gimp for paint may also take advantage of filters and > tools > developed with the goal of photo editing...who use gimp to retouch > or edit, > (in other words the group that you focus as the main users )may > well benefit of improvement of brush tool...because they use same > tools > > In this case as example i will not exclude the utility of a mix > brush for > restore digital or scannered images you see, now we are talking. by taking the debate to how a certain addition can really improve the productivity or creativity of our core groups, how painting can be made better in general, there is much better chance of getting somebody to listen and to get it integrated, one day. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Icons for layer modes
>so I am sorry. no additions solely for digital-artists. I am afraid that you undervalue creativity of who use gimp for photo or image editing I explain better, even if the goal may be different (as photo-retouch differs from use gimp to paint) the tool used are often the same So as who use gimp for paint may also take advantage of filters and tools developed with the goal of photo editing...who use gimp to retouch or edit, (in other words the group that you focus as the main users )may well benefit of improvement of brush tool...because they use same tools In this case as example i will not exclude the utility of a mix brush for restore digital or scannered images -- photocomix (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
peter (yahvuu) wrote: > peter sikking wrote: >> to have a reason to add these icons to GIMP, they really have to >> add something for usability, not just be different enough icons that >> happen to be similar in their group. what the icons have to deliver >> is additional _user_insight_ into the modes, in addition to the name >> of the mode. also this insight must _feel_ to be true, it must match >> users' experience. > > OK, i can't imagine that it's possible to visualize the subtle > difference > in _feeling_ between, say hardlight and grain merge. actually you are doing all right in the difference department, but I started seeing disinformation in the feel-true department. I think you can have a shot at trying to fix that. > Surprisingly enough, the > 'brightness diff' plots turned out to be so characteristic that i > soon started > to identify blend modes by their plots instead of by their names. > But then, > i've probably been looking at too many such diagrams lately :-) don't forget you have an engineering background and can do the math. I expect the majority of our core users to simply use this by feeling and build up a wealth of experience that that can retrieve by using the names of the modes. > i guess that litmus test can be used in the opposite direction as > well: > if it is impossible to create suitable icons for layer modes, then > they probably should not be presented as a drop-down list. no that is not true. what you run into is the very limited possibilities to express something (usable) in an icon of this size vs. the incredible richness that language has. I do admit that these mode labels have their legacy issues, nothing to be done about that. > I wonder if the criteria are different for preset selection, e.g. for > the curves tool. Here, any visual hint of distinction seems like an > improvement > over pure textual choices like 'curves 2009-08-01' or 'curves > 2009-08-02'. > Even if there's no correspondence with the 'feeling' of a certain > curve. > Or is this case within the same category as general icons? I have discussed ages ago with Mitch what is needed on the levels/ curves/etc. (remembered) presets. for the automatically created presets what is needed to help selecting is not only date + time, but also the the result: the thumbnail of the layer _after_ applying this levels/curves/etc. to it. this gives two orthogonal ways to identify an automatically created preset. for the presets that users saved + named, the richness of language is enough and no icon is needed. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
hi, peter sikking wrote: > to have a reason to add these icons to GIMP, they really have to > add something for usability, not just be different enough icons that > happen to be similar in their group. what the icons have to deliver > is additional _user_insight_ into the modes, in addition to the name > of the mode. also this insight must _feel_ to be true, it must match > users' experience. OK, i can't imagine that it's possible to visualize the subtle difference in _feeling_ between, say hardlight and grain merge. Surprisingly enough, the 'brightness diff' plots turned out to be so characteristic that i soon started to identify blend modes by their plots instead of by their names. But then, i've probably been looking at too many such diagrams lately :-) i guess that litmus test can be used in the opposite direction as well: if it is impossible to create suitable icons for layer modes, then they probably should not be presented as a drop-down list. I wonder if the criteria are different for preset selection, e.g. for the curves tool. Here, any visual hint of distinction seems like an improvement over pure textual choices like 'curves 2009-08-01' or 'curves 2009-08-02'. Even if there's no correspondence with the 'feeling' of a certain curve. Or is this case within the same category as general icons? greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
hi, peter sikking wrote: > Martin Nordholts wrote: >> [..] I have >> for a long time felt that layer modes is just a primitive and naive >> way to achieve some kind of non-destructiveness. yes, the evil plan which spun off my posting is to get rid of the layer mode concept. In my regard, blending is a complex adjustment rather than the choice of one discrete mode. What is currently called layer modes can be seen as factory presets of a future blend tool. A dedicated tool which allows on-canvas adjustment of blending characteristics will presumably work best. Using an analogy, the current situation for blending is like not having the curves tool, but only preset curves to choose from. And indeed there's a relation between curves and blending, for each RGB blend mode can be described as a set of 256 curves, at least within 8bit-accuracy. But that's a loong way to go, especially if the adjustments shall be artistically relevant ones. So the question is what to do right now? The current set of layer modes seems rather arbitrary to me. peter sikking wrote: > maybe there are simply zero arguments to add modes... each new mode adds one finer step for adjustment of blending characteristics. If i want to darken a layer by itself, the curves tool allows nearly infinite different characteristics of darkening. If i want to darken a layer by another one, there are a total of 3(!) characteristics available: 'darken only', 'multiply' and 'burn'. Of course, there won't ever be enough layer modes, which is one reason why they have to die long-term... > [..] but now I see that > [..] applying an adjustment layer [..] > [..] is completely valid, [..] i'd like to take the same line: if a layer is just a transparent sheet, and a composition is just a projection of a stack of sheets, then it's most natural to insert (photographic) filters in between. Say, a colorizing red glas or a freaky effect lens, in general: an adjustment layer. thanks for the encouraging comments, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
