[Gimp-developer] template python plugin
Hi Everyone,
I've been fiddling around with writing gimp-python plugins and ended
up creating a template for myself. It took me a day to put together so
I was thinking I might post it. It demonstrates a few things like
logging exceptions to a file for gui debugging (print statements and
exceptions don't seem to display in gui mode for some reason) and
running a plugin from the console which I've found useful for quick
debug iterations. And it also shows how to use a file chooser dialog
to prompt the user for a file. Hope you like it.
-Greg
#!/usr/bin/env python
# 9/14/2008 - Greg MacDonald
# This is an example gimp python plugin template. It demonstrates how to
# create two different types of plugins; an image plugin, and a toolbox
# plugin. The toolbox plugin only takes a run_mode parameter, while
# the image plugin takes a run_mode parameter as well as an image and
# drawable paramter.
#
# The example also shows how to use logging. This is useful for "printf"
# debugging when running in interactive mode as print statements don't seem to
# output to the console. They do however in batch mode.
#
# Batch mode is also demonstrated with a mechanism to run a command in batch
# mode if this file is run from the command line: "python
gimp_plugin_template.py".
#
# If an exception occurs during plugin execution, a stack trace is sent to the
log.
try:
import gimp
except:
if __name__ == '__main__':
import os
cmd = 'gimp-2.4 --console-messages --verbose --no-data
--batch-interpreter python-fu-eval --no-interface --batch
"pdb.toolbox_go(RUN_NONINTERACTIVE)" --batch "pdb.gimp_quit(0)"'
os.sys.exit(os.system(cmd))
else:
raise
import gimpplugin
from gimpenums import *
pdb = gimp.pdb
import logging
FORMAT = '%(lineno)d:%(levelname)s %(asctime)s : %(message)s'
# Other logging format options:
#%(name)sName of the logger (logging channel).
#%(levelno)sNumeric logging level for the message (DEBUG, INFO,
WARNING, ERROR, CRITICAL).
#%(levelname)sText logging level for the message ('DEBUG', 'INFO',
'WARNING', 'ERROR', 'CRITICAL').
#%(pathname)sFull pathname of the source file where the logging call
was issued (if available).
#%(filename)sFilename portion of pathname.
#%(module)sModule (name portion of filename).
#%(funcName)sName of function containing the logging call.
#%(lineno)dSource line number where the logging call was issued (if
available).
#%(created)fTime when the LogRecord was created (as returned by
time.time()).
#%(relativeCreated)dTime in milliseconds when the LogRecord was
created, relative to the time the logging module was loaded.
#%(asctime)sHuman-readable time when the LogRecord was created. By
default this is of the form ``2003-07-08 16:49:45,896'' (the numbers after the
comma are millisecond portion of the time).
#%(msecs)dMillisecond portion of the time when the LogRecord was
created.
#%(thread)dThread ID (if available).
#%(threadName)sThread name (if available).
#%(process)dProcess ID (if available).
#%(message)sThe logged message, computed as msg % args.
logging.basicConfig(filename=r'c:\gimp_plugin.log', level=logging.INFO,
format=FORMAT)
import gtk
class MyPlugin(gimpplugin.plugin):
def __init__(self):
self.log = logging.getLogger('MyPlugin')
def start(self):
self.log.info('start')
gimp.main(self.init, self.quit, self.query, self._run)
def init(self):
self.log.info('init')
def quit(self):
self.log.info('quit')
def query(self):
self.log.info('query')
authorname = "My Name"
copyrightname = "My Name"
date = "2008"
menupath = "/My _Plugin/_Go"
toolbox_go_description = "An example of a toolbox plugin."
toolbox_go_help = "An example of a toolbox plugin."
toolbox_go_params = [(PDB_INT32, "run_mode", "Run mode")]
gimp.install_procedure("toolbox_go",
toolbox_go_description,
toolbox_go_help,
authorname,
copyrightname,
date,
menupath,
"*",
PLUGIN,
toolbox_go_params,
[])
menupath = "/My _Plugin/_Go"
image_go_description = "An example of an image plugin."
image_go_help = "An example of an image plugin."
image_go_params = [(PDB_INT32, "run_mode", "Run mode"),
(PDB_IMAGE, "image", "Input image"),
(PDB_DRAWABLE, "drawable", "Input drawable")]
gimp.install_procedure("image_go",
image_go
Re: [Gimp-developer] Transparency in transform tools
On Sunday 28 September 2008 21:01:16 Guillermo Espertino wrote: > Probably this should be discussed a little bit more. There's a > particular situation where having an opaque original makes very hard to > use a transform tool... My personal annoyance with this occurs when I float a bit of a mostly transparent layer to adjust it that does not vary much in color and try to make it smaller. It can become VERY difficult to see where you are with your transform at any given moment very quick. Sample. Make a blue blot, not uniform in shape. Select and float it. Now make it smaller so it is placed in a manner you like that may be dependent on the layer below or rest of the image. You wont even see the borders of your preview because they are the same color. > If it's possible to directly hide the original, I'd prefer that option > until the GEGL porting of the display code is ready, even knowing that > the transformation proxy isn't very accurate. > I'd like to know how other users feel about this. I personally am in favor of this. It would make using transform tools both easier and more intuitive. -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Transparency in transform tools
> (hiding the original layer during the operation is possible, but > because of the simplicity of the preview rendering, the preview may > look much different that you'd expect.) Probably this should be discussed a little bit more. There's a particular situation where having an opaque original makes very hard to use a transform tool: when you paste a layer that is bigger than the image area and you have to scale it down to a desired size. You simply can't see the background because the opaque original is in front, so you can't apply the transformation with precision. The same applies when you have to rotate an element to match an angle of something that is behind the layer that you want to transform. I can think of a couple more of examples where this situation makes very hard to work. There's a workaround, that is lowering the original layer opacity then transforming, but it's not very handy (you have to do that and then remember to raise the opacity after you apply each transformation). This makes working with transformations quite slow and tedious. If it's possible to directly hide the original, I'd prefer that option until the GEGL porting of the display code is ready, even knowing that the transformation proxy isn't very accurate. I'd like to know how other users feel about this. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Transparency in transform tools
Hi Guillermo, On Fri, Sep 26, 2008 at 10:56 AM, Guillermo Espertino <[EMAIL PROTECTED]> wrote: > I'm testing Gimp 2.5.4 and it's amazing. > I know it's late for a feature request, but I think it's worth to > discuss about the current behavior of the new feature present in the > transform tools: the ability to set the transparency of the layer or > selection being transformed. > I think it would make more sense to apply that transparency to the > original layer instead of the transformed instance. > In most cases, the original occludes the background, and what the user > usually wants is to see the transformed object on the final context. > This situation becomes particularly annoying when scaling down images. > The larger original doesn't let the user see the real background, where > the transformed image will end up. So this new transparency function > would be much more helpful (in my oppinion) for the original, not for > the "target". > Somebody suggested in the IRC channel that the original should simply > dissapear, because the user wants to see the result of the > transformation, not the original. This has already been discussed, it is far from trivial to implement, mainly because the preview must be drawn directly on the canvas. When the display code is ported to GEGL, this may become practical. (hiding the original layer during the operation is possible, but because of the simplicity of the preview rendering, the preview may look much different that you'd expect.) > I think that there are lots of situations where having a reference of > the original, un-transformed image would be very useful, but not that > useful if having it doesn't let me see the background. > So, what do you think about applying the transparency to the original > insteado of applying it to the transformed image? > > Gez. > David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python back-up files
On Sun, 28 Sep 2008 02:21:13 +0200, Chris Mohler <[EMAIL PROTECTED]> wrote: > On Sat, Sep 27, 2008 at 6:16 PM, Samuel <[EMAIL PROTECTED]> wrote: >> Another question from me: >> >> When I write a plugin, my text editor (kwrite or kate) creates a backup >> file named plugin.py~. When I start now the plugin in GIMP, it is >> executing the backup instead the original. > > Hi, > > I think you should file a bug against kwrite and kate - while it's a > good idea to create backup files, I see no reason why they should have > the execute bit turned on (even if the file you are editing is > executable). > > Chris I can see arguements for and against but that is irrelevant on this list. What would appear to be gimp related here is that it is executing a file ending in .py~ , maybe file name is irrelevant. What is the mechanism for gimp ? Does it execute everything in the plugin directory? (I would see this as valid approach on cross platform software since the idea of dots and "file extensions" has no meaing on linux/unix and should remain so). If that is the case, the correct solution is not to dump your backup files in the gimp pluging dir. The best solution probably being to disable dumb microsoft style automatic backups and backup your work as needed. Both the editors mentioned allow you to disactivate auto backups. Auto backups are overwritten every time you save so in reality they are virtually useless. There's much more chance over recovering from an error with cntl-z The sooner linux world stops trying to ape windows the better. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
