Hello, I tried the new GIMP 2.7 and now I saw what the export feature behaves like. After some thought I reached the conclusion that we should probably merge both procedures (single and multi page) into one procedure for exporting everything. However I also have 2 new additions: 1. The export parameters (aka the pages and optimization) should be saved for each image individually. If the export is automatically suggested for the same file as last time, we should save the parameters for each file - which means saving the parameters for each image. 2. We should warn the user when he wants to re-export the PDF if one of the images that was a part of the PDF was closed, so he won't overwrite his PDF and loose pages. For feature 1, we need to make sure the parameters are saved per image but are only relevant for the current session (since the pages are the open images, not images from files). I need some help here on how to do this... Should I save the parameters to some file instead of adding the to the image? Then I can probabbly use the quit() procedure of the plugin to delete this file. This is the only solution I could think off, and then, should I use the .gimpX.X/tmp/ dir for saving the file? Waiting for feedback =) ~ Barak On Fri, Aug 21, 2009 at 10:59 PM, Martin Nordholts<enselic@xxxxxxxxx> wrote: > We can't predict what a user wants to do. We can only give sane defaults, > such as the previous export options, and allow the user to change them if > they are not right. > > A more sophisticated solution would be to have per-image export options. Not > sure if that is a good idea or not. > >> The problem is that the multipage procedure should be non-related to >> the single-page save procedure since these are different tasks. > > I don't see these two as conceptually different tasks. In both cases the > user wants to export a PDF. > >> I have only one solution which can solve our problem but I want to >> hear your opinion about it: >> 1. Merge the gui both procedures, and make the view of the multipage >> procedure hidden inside a GtkExpander. >> 2. Behaviour will be configure like this: >> a. When the expander is not expanded, only the options for the single >> page export will be visible, and it will behave as a single page >> export. >> b.When the expander is expanded, it will behave as the multipage >> export and will export the all the images in the GtkIconView. > > What d you mean w ith all images in the GtkIconView? Can't we simply let the > user pick the images for the multi-page PDF? > >> 3. In case of GIMP_RUN_WITH_LAST_VALS it will be assumed that the >> expander is hidden and it's a single page export. > > Wouldn't it make more sense to simply run with last vals? That is, if the > user previously exported image 1 2 and 3, invoking 'File->Export to > file.pdf' would re-export this multi-page PDF. > >> 4. We should make sure that if the multipage procedure was used the >> image will still be marked as unsaved somehow (Does the new export api >> causes images to still be marked as unsaved when using the Export >> function? If so, this solves our problem :D) > > In git master, exported dirtiness is separate from saved dirtiness. You > should try it out :) > > BR, > Martin _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
