[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [Gimp-developer] Need feedback for the new PDF plugin
From:       LightningIsMyName <lightningismyname () gmail ! com>
Date:       2009-09-06 9:17:16
Message-ID: e926d4dc0909060217l698309cfmf968274a72d7604a () mail ! gmail ! com
[Download RAW message or body]

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@gmail.com> 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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[prev in list] [next in list] [prev in thread] [next in thread]