On Sun, Jul 5, 2009 at 9:51 AM, Dirk Sohler wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi there!

I filed a “bug” with an enhancement request to the GIMP Bugzilla, but Martin Nordholts told me, to send a mail to the GIMP developers mailing list first, so … here it is :)

I had a kind of map opened as image in GIMP. I used the path tool and clicked a path alon a route i want to measure. After i did this i tried to get the path’s length. But i noticed really soon, that it is not possible to output the path’s total length without learning script-fu.

Hmm - it would probably not be too hard to write a plugin for this.

As a quick test, I created a new image, drew a path, and stroked it.

Then I opened the python console and did:

img = gimp.image_list()[0]
path = pdb.gimp_image_get_active_vectors(img) len = pdb.gimp_vectors_stroke_get_length(path, 1, 1) print len

644.628491517

That might choke if you have more than one path - I have not tested.

Is this enough to get you going?

Chris

On Sun, Jul 5, 2009 at 9:51 AM, Dirk Sohler wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi there!

I filed a “bug” with an enhancement request to the GIMP Bugzilla, but Martin Nordholts told me, to send a mail to the GIMP developers mailing list first, so … here it is :)

I had a kind of map opened as image in GIMP. I used the path tool and clicked a path alon a route i want to measure. After i did this i tried to get the path’s length. But i noticed really soon, that it is not possible to output the path’s total length without learning script-fu.

What the heck - I added it as a (very) simple plug-in: http://registry.gimp.org/node/17235

In 2.6. it returns the length of the path on the status bar. I used gimp_message, so IIRC the location of the message is configurable. It silently fails if there is no active path - it seems to work OK with multiple paths, straight lines, and curves. There is no need to stroke the path.

You will need to have Python installed though...

HTH, Chris

Chris Mohler (cr33dog@gmail.com) wrote (in part) (on 2009-07-05 at 16:11):

What the heck - I added it as a (very) simple plug-in: http://registry.gimp.org/node/17235 In 2.6. it returns the length of the path on the status bar. I used gimp_message, so IIRC the location of the message is configurable. It silently fails if there is no active path - it seems to work OK with multiple paths, straight lines, and curves. There is no need to stroke the path. You will need to have Python installed though...

Works on Windows 2.6.6 but message is displayed in Error console (which I have as one of panels in main dock) not on the status bar. Is this somehow configurable?

Note: IMO this is a feature not a bug since it allows user to change the path and re-measure leaving a "history" record in the Error console.

Unlike some "error" messages posted to Error console it does not auto-raise the error console if the panel it is in is displaying something else.

Note: I tested by using Supernova filter on a white background, selecting white, inverting and then Select to Path and named it Path_A. Response to Measure-Path in Error console was: Path Warning Length of Path_A: 3474 px. That would have taken an extremely long time to calculate with the measure tool :-)

Whether paths are Active or not does not appear to change results - it still shows the measurement.

I created a second much simpler path with Free-Select-Tool then converted to path and named it "Path_B". With the two paths it showed: Length of Path_B: 383 px.

It appears (based on swapping order of paths with drag+drop) that it always shows the length of the lowest path (the one a the bottom of the list)

Bug?: The entry "Filters - Measurement - Path" is always enabled whether or not any path exists (expected) but in Filters-Repeat "Path", Filters-Reshow "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed out).
Is this an easy fix?

For reference in case someone other than Chris knows the answer, text of the python plugin follows:

#!/usr/bin/env python # Author: Chris Mohler
# Copyright 2009 Chris Mohler
# License: GPL v3
# GIMP plugin to measure the length of a path

from gimpfu import *

gettext.install("gimp20-python", gimp.locale_directory, unicode=True)

def measure_path(img, drw): try:
path = pdb.gimp_image_get_active_vectors(img) len = pdb.gimp_vectors_stroke_get_length(path, 1, 1) len = int(len)
pdb.gimp_message("Length of " + path.name + ": " + str(len) + " px") except:
pass

register(
"python-fu-measure-path",
"Measure Path",
"Measure Length of the Active Path", "Chris Mohler",
"Chris Mohler",
"2009",
"/Filters/Measure/Path",
"",
[],
[],
measure_path,
domain=("gimp20-python", gimp.locale_directory) )

main()

On Mon, Jul 6, 2009 at 2:57 AM, Dirk Sohler wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Chris Mohler schrieb: | What the heck - I added it as a (very) simple plug-in: | http://registry.gimp.org/node/17235

I can’t find the menu option „Filters->Measure->Path“. :(

Hmm - did you place the plug-in into ~/.gimp-2.x/plug-ins and is it executable? (chmod +x)

If so, try starting GIMP from a terminal and see if it throws an error?

Chris

On Sun, Jul 5, 2009 at 9:42 PM, Alec Burgess wrote:

Works on Windows 2.6.6 but message is displayed in Error console (which I have as one of panels in main dock) not on the status bar. Is this somehow configurable?

Note: IMO this is a feature not a bug since it allows user to change the path and re-measure leaving a "history" record in the Error console.

OK - I don't usually open the error console, but I see the same behavior in linux with the console open. I pretty much did just the bare minimum on the plug-in, but I'm pretty sure it's possible to make it pop up a message instead, and/or change the message type.

Whether paths are Active or not does not appear to change results - it still shows the measurement.

I created a second much simpler path with Free-Select-Tool then converted to path and named it "Path_B". With the two paths it showed: Length of Path_B: 383 px.

It appears (based on swapping order of paths with drag+drop) that it always shows the length of the lowest path (the one a the bottom of the list)

For me, it gives the length of whatever path is selected in the paths dialog. I will install the plugin in Windows at some point and see if I can reproduce...

Bug?: The entry "Filters - Measurement - Path" is always enabled whether or not any path exists (expected) but in Filters-Repeat "Path",  Filters-Reshow "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed out).
Is this an easy fix?

I see the same thing here - I'm not sure what's happening. I will investigate when I find some time...

Chris

Bug?: The entry "Filters - Measurement - Path" is always enabled whether or not any path exists (expected) but in Filters-Repeat "Path",  Filters-Reshow "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed out).
Is this an easy fix?

I see the same thing here - I'm not sure what's happening.  I will investigate when I find some time...

I think that if you change the image type to "*" rather than "" it will be remembered.

-Rob A>

On Mon, Jul 6, 2009 at 12:41 PM, Rob Antonishen wrote:

Bug?: The entry "Filters - Measurement - Path" is always enabled whether or not any path exists (expected) but in Filters-Repeat "Path",  Filters-Reshow "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed out).
Is this an easy fix?

I see the same thing here - I'm not sure what's happening.  I will investigate when I find some time...

I think that if you change the image type to "*" rather than "" it will be remembered.

I think you are right - thanks!

Chris

Hi,

On Sun, 2009-07-05 at 22:42 -0400, Alec Burgess wrote:

Works on Windows 2.6.6 but message is displayed in Error console (which I have as one of panels in main dock) not on the status bar. Is this somehow configurable?

Note: IMO this is a feature not a bug since it allows user to change the path and re-measure leaving a "history" record in the Error console.

If the error-console is opened, all messages are redirected there. The ideas is that the error-console is only useful when debugging or developing scripts.

Bug?: The entry "Filters - Measurement - Path" is always enabled whether or not any path exists (expected) but in Filters-Repeat "Path", Filters-Reshow "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed out). Is this an easy fix?

This might fix itself if you change your script not to use the deprecated register() API. You should instead use the variant that passes the menu location as value of the named parameter 'menu'. The way your script is using register() triggers an obscure backward compatibility quirks mode, which is probably not what you want.

Sven

On Mon, Jul 6, 2009 at 2:55 PM, Sven Neumann wrote:

On Sun, 2009-07-05 at 22:42 -0400, Alec Burgess wrote:

Bug?: The entry "Filters - Measurement - Path" is always enabled whether or not any path exists (expected) but in Filters-Repeat "Path",  Filters-Reshow "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed out). Is this an easy fix?

This might fix itself if you change your script not to use the deprecated register() API. You should instead use the variant that passes the menu location as value of the named parameter 'menu'. The way your script is using register() triggers an obscure backward compatibility quirks mode, which is probably not what you want.

I had a little trouble finding docs on the named parameters (I ended up using help(gimpfu.register) in the console). I've pasted the new register() below - one thing seemed strange: the 'params' parameter seems to require that I add the current image and drawable - is that correct? Any other big mistakes here? ;)

Thanks, Chris

register(
proc_name=("python-fu-measure-path"), blurb=("Measure Path"),
help=("Measure Length of the active path. Output is directed to the Status Bar or Error Console."),
author=("Chris Mohler"),
copyright=("Chris Mohler"),
date=("2009"),
label=("Active Path"),
imagetypes=("*"),
params=[
(PF_IMAGE, "img", "Image", None), (PF_DRAWABLE, "drw", "Drawable", None) ],
results=[],
function=(measure_path),
menu=("/Filters/Measure"),
domain=("gimp20-python", gimp.locale_directory) )

On Sun, Jul 5, 2009 at 9:42 PM, Alec Burgess wrote:

Whether paths are Active or not does not appear to change results - it still shows the measurement.

I've updated the plug-in at the registry (http://registry.gimp.org/node/17235). If in doubt which is which, I added 'Version 0.2' to the header info of this one.

In linux and XP (both 2.6.6), it reports the length of whichever path is selected in the Paths dialog.

I also fixed the 'Repeat' and 'Reshow' weirdness, and also disabled the plug-in when no image is open.

Let me know how it works out...

Chris

Hi,

On Mon, 2009-07-06 at 16:58 -0500, Chris Mohler wrote:

I had a little trouble finding docs on the named parameters (I ended up using help(gimpfu.register) in the console). I've pasted the new register() below - one thing seemed strange: the 'params' parameter seems to require that I add the current image and drawable - is that correct? Any other big mistakes here? ;)

Why does it require that? What's required is that you register all the parameters that your function actually needs. If you need an image parameter, then you should have PF_IMAGE in your input parameters. If you also need a drawable, then this should be followed by PF_DRAWABLE. But these are by no means obligatory. If you don't need an image nor a drawable, then you can safely omit them.

Sven

On Mon, Jul 6, 2009 at 5:19 PM, Sven Neumann wrote:

Hi,

On Mon, 2009-07-06 at 16:58 -0500, Chris Mohler wrote:

I had a little trouble finding docs on the named parameters (I ended up using help(gimpfu.register) in the console).  I've pasted the new register() below - one thing seemed strange: the 'params' parameter seems to require that I add the current image and drawable - is that correct?  Any other big mistakes here?  ;)

Why does it require that? What's required is that you register all the parameters that your function actually needs. If you need an image parameter, then you should have PF_IMAGE in your input parameters. If you also need a drawable, then this should be followed by PF_DRAWABLE. But these are by no means obligatory. If you don't need an image nor a drawable, then you can safely omit them.

Sorry - I did not phrase that very well.

When using the old, unnamed register() parameters, if you leave 'params' empty, the main plug-in function still receives two parameters - the current image and drawable. Using the new, named register() parameters does not seem to do this anymore.

No big deal really, but I thought it odd that the behavior would be different.

Chris

Hi,

On Mon, 2009-07-06 at 17:32 -0500, Chris Mohler wrote:

When using the old, unnamed register() parameters, if you leave 'params' empty, the main plug-in function still receives two parameters - the current image and drawable. Using the new, named register() parameters does not seem to do this anymore.

No big deal really, but I thought it odd that the behavior would be different.

That is exactly the odd quirks mode for backward compatibility that I mentioned. If you use the old register() API, then parameters are added for you depending on the menu location your script is registering to. As that is hard to understand and frequently leads to automatically added parameters that the script does not actually need, this behavior was changed. It is still there, for backward compatibility, if you use the old API though.

Sven

On Mon, Jul 6, 2009 at 5:45 PM, Sven Neumann wrote:

Hi,

On Mon, 2009-07-06 at 17:32 -0500, Chris Mohler wrote:

When using the old, unnamed register() parameters, if you leave 'params' empty, the main plug-in function still receives two parameters - the current image and drawable.  Using the new, named register() parameters does not seem to do this anymore.

No big deal really, but I thought it odd that the behavior would be different.

That is exactly the odd quirks mode for backward compatibility that I mentioned. If you use the old register() API, then parameters are added for you depending on the menu location your script is registering to. As that is hard to understand and frequently leads to automatically added parameters that the script does not actually need, this behavior was changed. It is still there, for backward compatibility, if you use the old API though.

OK - thanks for clarifying that. I had no idea that the automatic parameters varied based on menu location.

Chris