Instead of filling default GUI for a specific type of plug-in procedure in
fill_list(), we add 2 methods:
* fill_start() is ensured to run once (and only once) before any fill_list()
code runs.
* fill_end() is ensured to run once (and only once) after all fill_list() ran.
This takes care of 2 kind of GUI bugs which we could have:
1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill()
nor gimp_procedure_dialog_fill_list() were ever run), then the default
interface would not be added to the dialog. Yet this case could happen when
we don't want anything else but the default GUI (this will be the case in the
upcoming file-wmf-load GUI).
2. Second if at the opposite, you fill several times fill functions (I hadn't
thought of this, but noticed some already started to do this in our ported
plug-ins), we obviously don't want the default GUI to be added several times
either.
As expected, it is made to reuse shared code for every GimpVectorLoadProcedure.
In particular, they all need to choose dimensions to load at, so we are sharing
a same GimpResolutionEntry widget logic everywhere now.
I am in fact still very unsure about the code logic for this widget by the way
for these reasons:
* It still puts too much emphasis on the "resolution" (pixel density) part,
which makes people believe it's important, while they should in fact choose
the pixel dimensions most of the time and not care about the pixel density.
* Right now we can't break ratio (which in fact was already impossible in most
vector format plug-ins we had). Do we want to add a chain and allow this?
* If we consider the pixel density as the one we want to set the document with
(which may not be the same thing as the one from when we load the document),
we also want to break link between width/height dimensions and pixel density.
Right now we can't (updating one field updates the others too).
* There is always this issue of precision with pixel density vs. pixel
dimensions because we don't necessarily find the same values when computing
from one side to another because of lack of precision and this confuses
people.
* Finally there is the question of multi-page documents (e.g. PDF) where the
chosen dimensions are the document dimensions whereas each page may have a
different size which has to be recomputed independently and this got me
off-by-one errors. I think I'll need to review a bit the logic, but I'll do
once I've ported all the vector format load plug-ins first to see the most
common usages.
Jehan