Baruch Even <[EMAIL PROTECTED]> writes:
| The goals for the insetgraphics are to use the newer graphicx package in
| latex, call for the image conversions when exporting (like ExternalInset)
| be more robust than insetfig (the old figure inset) and possibly more
| feature rich.
Good.
| Currently I'm aiming it to be a drop in replacement to insetfig, that is
| no full support to graphicx but only the minimal work required to get it
| up to par with figinset and continue from there (smaller targets make for
| faster overall work). Actually in the first stage is to do everything
| figinset does but without the inline viewing (I really want to be able to
| create PDF's and need to inset PNG images, so figinset is out ;-)
Ok.
| Afterwards, I'll need to do the GraphicsCache and FormatConvertor, the
| first is an image cache that also will do the different transforms
| (rotation, color change, etc.) and the FormatConvertor will be plucking
| that part from ExternalInset to an independent class (I haven't looked at
| ExternalInset yet, is this rational?) This two classes together will
| transfer everything for me to something I can both view on screen and
| export for (pdf)latex to use.
This sounds good.
| 2. I have the current scenario which I don't know how to handle:
| a. User clicks on a graphics inset, the edit dialog opens.
| b. User clicks in LyX on another graphics inset, it's edit dialog should
| open.
|
| BUT there is only one edit dialog so I should either ignore the old edit
| dialog, and use the new dialog details (current action).
| or I should ignore the later request, possibly with a beep and a dialog
| raise.
How hard would it be to have the possibility of several dialogs of the
same type at the same time open?
| 3. I hold a pointer to the inset (I clear it when I hide()), currently my
| stand is that I must verify where appropriate that I have the inset
| pointer, this is done in two stages, if assertions are on, I assert it's
| not null (!= 0), and in any case I have a bail out return if its zero.
| Should I drop this checks/part of them/add a print to the bail out
|return?
ptr == 0 is an error so put an assert there.
| 5. What about the file format? Should I be compatible with figinset, so as
| to allow smooth upgrading? Should I be orthogonal to it and just rely on
| some externally crafted translator between formats? (on this note, I
| suggest we maintain a format upgrader program so as to avoid the problems
| that cropped lately in the lists)
Upgrade has never been a problem, downgrade is always a problem.
(upgrade has had quirks inside development/cvs versions but that does
not count)
It is easy to convert old style to the new style regardless of how you
do this.
| 9. I wanted to change the radio buttons on the dialog to a choice button,
| any reason why not to?
The only reason not to is perhaps visibility, or if some of the
options requrie a input to and others don't.
| I have a problem doing it since I need to enter the percent character and
| I can't seem to do it correctly since the percent char is a special char
| for xforms. I couldn't find anything in xforms manual, I need to enter
| something like "% of Page", I tried \% and %%, the former did nothing the
| second showed only the % so if I did "%% of Page" I got "%", which is not
| a good idea.
How is it done in the code currently?
| I think I'll stop here before I'll be hanged :-)
Oh, come on. We'll never hang you... (but I have an electric chair
hidden somewhere...)
Lgb
