Re: [Gimp-developer] API for bringing up a Save dialog
k!! 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 -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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 -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
pyGTK: http://www.pygtk.org/ On Sat, May 30, 2009 at 6:56 AM, Esteban Barahona wrote: > 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. > > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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.
On Fri, May 29, 2009 at 4:57 PM, Sven Neumann wrote:
> 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
>
>
>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
But how would you progromatically suggest a good filename before popping up the dialog? That is what my code does. On Fri, May 29, 2009 at 3:37 PM, Sven Neumann wrote: > 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 > > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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.
FWIW,
Ryan
On Fri, May 29, 2009 at 12:18 PM, 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.
>
> 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
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] API for bringing up a Save dialog
> 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
