Hello Ryan,

On Fri, May 29, 2009 at 1:48 PM, Ryan Krauss wrote:

I have a Python Gimp question.  I don't know if it belongs on the user or developer list, but my feeling is that the people with the knowledge are more likely to read this list.  Let me know if this is the wrong list to post to.

I have written a script to create PNG and XCF versions of an image I want to save.  I have a certain layer whose visibility I want to turn off before I save the PNG but I also want the XCF to give me more editting power if I want to alter the image later.  I have this working fairly well, but the problem is that when my script finishes, I am looking at the flattened PNG version of the image.  At that point, I would need to close the PNG and re-open the XCF if I want to edit the file.  This is less than ideal.  I think it could be solved by simply doing one undo step after saving the PNG (since flattening was the last thing I did), but I don't see in the procedural database a way to undo from a script.  Is there a way to save a flattened PNG and then save an unflattened XCF of the same image and leave the XCF open?

Duplicate the image and do your flattening on the copy. It's more efficient than you might think -- the main time involved in duplicating a moderate sized image seems to be actually in setting up its GUI window rather

On Fri, May 29, 2009 at 3:59 PM, Ryan Krauss wrote:

Thanks David.  I stumbled onto that solution just before I checked my email :)

This does the trick of creating the file to go to PNG:

    pdb.gimp_edit_copy_visible(img)     img2 = pdb.gimp_edit_paste_as_new()

It does work nice and doesn't seem to take too long.

So, my script does almost everything that I want.  One last annoyance is that I can't seem to get the window title to change from Untitled-N.0 after the XCF save to the XCF filename.  Neither of these seem to set the window title:

pdb.gimp_xcf_save(1, img, drawable, xcf_path, xcf_path) pdb.gimp_file_save(img, drawable, xcf_path, xcf_path)

Neither of the above set the filename. You should do this.
image.filename = xcf_path

It makes me a little nervous to close windows that don't have the filenames in the title and are not marked clean (no *).  I can do this at the end of the script

pdb.gimp_image_clean_all(img)

but the docs seem to say I shouldn't and that still doesn't set the window title.

How should I save an XCF from a Python script (I assume either of the pdb save methods above) and how do I set the window title?

Saving XCF -- either of the methods you mentioned is fine. You don't set the window title (except indirectly, as above)

  Should the image
automatically be set as clean?

Yes, since you've saved in XCF. That is, setting it clean makes sense, since that's what the GUI code does at the equivalent point in the normal Save process.

The recently introduced Export framework may end up simplifying your situation.. It considers a file 'clean' only when it has just been saved to XCF (or xcf.gz, etc) format, and introduces a separate 'Export' action for producing a 'rendered result' in eg. PNG format.

On Fri, May 29, 2009 at 3:59 PM, Ryan Krauss wrote:

pdb.gimp_xcf_save(1, img, drawable, xcf_path, xcf_path) pdb.gimp_file_save(img, drawable, xcf_path, xcf_path)

That leads into something I've been needing from Python: I'd like a way of bringing up a Save-as or Export-as dialog from a Python script. There's no API for this currently, as far as I can tell. If I call pdb.gimp_file_save like this:

pdb.gimp_file_save(img, newimg.active_layer, pathname, pathname, run_mode=0)

it goes straight to the jpeg save dialog, or the png save dialog, or whatever, skipping the dialog that would let the user change the filename. I'd like to set the filename, but then give the user a chance to change it and to see or change where it's being saved.

Would be be possible to add an API for this, or maybe an optional argument in gimp_file_save and the corresponding _export function? I can try to implement it and submit a patch, but I'd like to know if such an API would be acceptable, and how you'd want it to look. For instance, maybe

pdb.gimp_file_save(img, newimg.active_layer, pathname, pathname, run_mode=0, show_save_dialog=True)

Or, possibly, should the code be changed so that it always shows the save-as dialog if run_mode is interactive? It would change the behavior of existing scripts ... but only in the interactive case.

David Gowers writes:

The recently introduced Export framework may end up simplifying your situation.. It considers a file 'clean' only when it has just been saved to XCF (or xcf.gz, etc) format, and introduces a separate 'Export' action for producing a 'rendered result' in eg. PNG format.

In the new framework, will gimp_file_save() fail if the filename isn't xcf? Will scripts need to be rewritten to call gimp_file_export instead? If authors have to rewrite their scripts anyway, making a small change to what run_mode=0 does at the same time might not be much of a problem.

...Akkana

Akkana Peck wrote:

I'd like a way of bringing up a Save-as or Export-as dialog from a Python script. There's no API for this currently, as far as I can tell.

The Save and Export dialogs are rather tightly coupled to the core currently so it will not be trivial to extend the plug-in API to show and interact these dialogs but I would not reject patches that implemented it properly.

Would be be possible to add an API for this, or maybe an optional argument in gimp_file_save and the corresponding _export function?

IMO we should not reuse gimp_file_save() for this but instead introduce gimp_show_save_dialog() and gimp_show_export_dialog(). I am a bit worried however that plug-ins will abuse this power. In your case, why do you need to show these dialogs? Isn't it better if the user has to go through a single place to save or export?

In the new framework, will gimp_file_save() fail if the filename isn't xcf?

No, the existing API needs to be backwards compatible so even though it is unfortunate that _save() can be used to export, we need to allow that for the sake of backwards compatibility.

/ Martin

Martin Nordholts writes:

IMO we should not reuse gimp_file_save() for this but instead introduce gimp_show_save_dialog() and gimp_show_export_dialog(). I am a bit worried however that plug-ins will abuse this power. In your case, why do you need to show these dialogs? Isn't it better if the user has to go through a single place to save or export?

I need to show the dialogs because the plug-in needs to save a file (that's the whole point of the plug-in) and it seems like bad UI to pop up the JPEG save dialog without ever showing the user where the file is being saved, or offering them a chance to save it somewhere else. (Have you ever been frustrated when Firefox downloaded a file and you can't figure out where it ended up?) Seems like it's always better UI to go through this step, so the user knows what is being saved and where.

Of course, this being python, I could put up my own save-as dialog and let the user choose the filename that way, then call gimp_file_save() on the result; but I'd rather go through GIMP's standard framework, with the File Type menu and other nice features.

...Akkana

On Fri, 2009-05-29 at 10:18 -0700, Akkana Peck wrote:

Martin Nordholts writes:

IMO we should not reuse gimp_file_save() for this but instead introduce gimp_show_save_dialog() and gimp_show_export_dialog(). I am a bit worried however that plug-ins will abuse this power. In your case, why do you need to show these dialogs? Isn't it better if the user has to go through a single place to save or export?

I need to show the dialogs because the plug-in needs to save a file (that's the whole point of the plug-in) and it seems like bad UI to pop up the JPEG save dialog without ever showing the user where the file is being saved, or offering them a chance to save it somewhere else. (Have you ever been frustrated when Firefox downloaded a file and you can't figure out where it ended up?) Seems like it's always better UI to go through this step, so the user knows what is being saved and where.

Then please add a sane user interface to your plug-in and pop up a file-chooser. The PDB was designed to allow plug-ins and scripts to call procedures in GIMP, not to pop up specific user interface elements. It is totally not suited for this kind of usage.

Sven

Hi,

On Fri, 2009-05-29 at 12:34 -0500, Ryan Krauss wrote:

This is mildly hackish, but my approach is to pop up a Tk save as dialog:

filetypes = [('png files', '*.png'), ('jpg files', '*.jpg'),\ ('all files', '.*')]

def save_as(initialdir=None, initialfile=None): filename = tkFileDialog.asksaveasfilename(initialdir=initialdir, \ initialfile=initialfile, \
filetypes=filetypes) return filename

It would prettier to do a wxPython gtk one, but that requires a parent frame AFAIK.

Any particular reason you are not using a GtkFileChooserDialog? That is the dialog that the GIMP user expects and knows to use. GTK+ is the only toolkit that you can definitely rely on being installed and available. GTK+ is part of the GIMP plug-in API.

Sen

Sven Neumann writes:

On Fri, 2009-05-29 at 10:18 -0700, Akkana Peck wrote:

I need to show the dialogs because the plug-in needs to save a file (that's the whole point of the plug-in) and it seems like bad UI to pop up the JPEG save dialog without ever showing the user where the file is being saved, or offering them a chance to save it somewhere else.

Then please add a sane user interface to your plug-in and pop up a file-chooser. The PDB was designed to allow plug-ins and scripts to call procedures in GIMP, not to pop up specific user interface elements. It is totally not suited for this kind of usage.

I'm confused -- you say I should pop up a file chooser, then you say that's not what the PDB is for. Is there a non-PDB way to do this from a plug-in?

Popping up a file chooser is exactly what I'm trying to do. But I'd ideally like it to be the gimp file chooser with the image file types, not a generic GTK file chooser (just for consistency, because the GIMP dialog is what the user expects to see elsewhere in gimp). That's why I was asking for an API to do that.

...Akkana

speaking of python... are there any wrappers of python (or perl) in gtk?

.../5/29 Ryan Krauss

No, I have no good reason :) I am not really familiar with any Python GUI toolkit other than wxPython. When I realized that wouldn't work, I googled for Tk because I thought that was the one that ships with Python.

Hi,

On Fri, 2009-05-29 at 16:02 -0700, Akkana Peck wrote:

Sven Neumann writes:

On Fri, 2009-05-29 at 10:18 -0700, Akkana Peck wrote:

I need to show the dialogs because the plug-in needs to save a file (that's the whole point of the plug-in) and it seems like bad UI to pop up the JPEG save dialog without ever showing the user where the file is being saved, or offering them a chance to save it somewhere else.

Then please add a sane user interface to your plug-in and pop up a file-chooser. The PDB was designed to allow plug-ins and scripts to call procedures in GIMP, not to pop up specific user interface elements. It is totally not suited for this kind of usage.

I'm confused -- you say I should pop up a file chooser, then you say that's not what the PDB is for. Is there a non-PDB way to do this from a plug-in?

Yes, use the GtkFileChooserDialog. GTK+ is part of the GIMP plug-in API, so that is available to you.

Popping up a file chooser is exactly what I'm trying to do. But I'd ideally like it to be the gimp file chooser with the image file types, not a generic GTK file chooser (just for consistency, because the GIMP dialog is what the user expects to see elsewhere in gimp). That's why I was asking for an API to do that.

The PDB is the wrong place for such an API though. It is not meant to provide user interfaces to plug-ins. The fact that it allows to call plug-in procedures in interactive run-mode is just due to the fact that the core uses the PDB to start a plug-in the user has selected in the menus. Core procedures don't expose this functionality and they shouldn't.

Sven

On Friday 29 May 2009, Martin Nordholts wrote:

Akkana Peck wrote:

I'd like a way of bringing up a Save-as or Export-as dialog from a Python script. There's no API for this currently, as far as I can tell.

The Save and Export dialogs are rather tightly coupled to the core currently so it will not be trivial to extend the plug-in API to show and interact these dialogs but I would not reject patches that implemented it properly.

Would be be possible to add an API for this, or maybe an optional argument in gimp_file_save and the corresponding _export function?

IMO we should not reuse gimp_file_save() for this but instead introduce gimp_show_save_dialog() and gimp_show_export_dialog(). I am a bit worried however that plug-ins will abuse this power. In your case, why do you need to show these dialogs? Isn't it better if the user has to go through a single place to save or export?

Certainly not -- the idea of plug-ins is to automate workflows! And a common enoguh use case is to save a modified copy of an image - or a series of images with diferences between them (although this would need a folder + file name pattern rther than =justa file path).

Akkana: I've never missed callign the save or export dialogs because I normally use the PF_FILE and PF_DIRECTORY entry parameters for my plug-ins taht deal with file export. Aren't they (with gimp_file_save) enough for your use case?

In the new framework, will gimp_file_save() fail if the filename isn't xcf?

No, the existing API needs to be backwards compatible so even though it is unfortunate that _save() can be used to export, we need to allow that for the sake of backwards compatibility.

/ Martin

js
->

EEEEk!!

The E-mail client is showing me unread messages from months ago as if they where "New" :-(
Sorry for digging into this ancient thread. :-(

js ->