On 7 Jul 2000, Lars Gullik Bjønnes wrote:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | 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.
> |=20
> | 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?
I really have no idea, it will require verifying that the code is up to
it, and probably besides the file browser it probably is possible. Though
I have no idea regarding the XForms side of it.
The current way is just to switch the data to the new inset, might be a
bit strange if you mistakenly clicked on the other inset. But then, why
did you go back to LyX without closing the dialog first?
The option of making it modal is a possible way, though I have no idea how
to do it with XForms.
All in all, the current way is how most(all?) of LyX is working, possibly
it is better to leave it this way, unless we decide that LyX should behave
differently, but then we need to do the change all over, no need to
confuse the user with different behaviours for different dialogs.
> | 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 (!=3D 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 =3D=3D 0 is an error so put an assert there.
Ok. The assert will stay, should I also leave the 'if (!inset)' guard, or
rely on the assert finding the bug in development code? After all the
asserts are not active in production code.
> | 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.
So what's the ruling? new format? old format? both?
both means read the new and old, write only the new.
> | 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.
Ok. The second case applies here so I'll leave it as it is.
> | 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?
Currently it's not done in a choice button at all so this problem does not
manifest itself. In labels (the label of the radio button) there is no
such problem.
> | I think I'll stop here before I'll be hanged :-)
>
> Oh, come on. We'll never hang you... (but I=A0have an electric chair
> hidden somewhere...)
Ah, electric chair is cool, I'll plug my massage seat to the electricity,
will save on pulling a cord from the wall.
--
Baruch Even
http://techst02.technion.ac.il/~sbaruch/ (My Site)
http://rpghost.com/jindor/ (My brothers AD&D site)
" Learn to laugh ... it's the path to true love! "
- The Angel in the movie Michael
