Le 9 juil. 07 à 17:33, Richard Heck a écrit :
I checked that if you modify isBufferDependent() for LaTeX logs
(hence into ControlLog.h) so that it returns true when belonging
to a LaTeX log dialog, then it is no more hidden when switching
buffer (but this isn't sufficient because there are update issues
to deal with...).
Yes, this is all related to the update issue. The call to
ControlLog::initialiseParams() is supposed to pass (a) the name of
the logfile type and (b) the name of the logfile. We're supposed to
return false if there's some error in the parsing of this
information. The call you mention passes no data at all, so the
parsing fails, and we return false. To do a proper update, you'd
have to have that information lying around somewhere.
I'm curious to know how one should specify that a buffer dependent
dialog has to hide/keep displayed when switching to another buffer.
At present, there is no way to do this. Perhaps a new hideOnSwitch
() virtual method is needed.
I agree.
A more general solution, perhaps, would be to add a new onSwitch()
virtual method, which would allow the dialog to do whatever it
wished when the buffer was switched. Perhaps it would hide itself;
perhaps it would clear itself; perhaps it would try to update
itself. This could be called before the update().
Yes, this solution would be better.
As for the graphics dialog, a question: If you click away from
the graphics inset to which the dialog is attached, what happens?
The dialog remains as is if you stay into the same buffer. It is
emptied if you switch to another buffer. But in the latter case I
think we have a bug: despite the dialog is emptied, if you modify
some parameters and click the "Apply" button, then parameters are
always linked (and so applied) to the graphics inset. IMO, this is
really unadapted!
Yes, that would be a bug. This should probably return true for
hideOnSwitch(), or do something sensible in onSwitch().
Should I file a bug for this particular behavior?
What should happen?
In my vision, this shouldn't be possible for dialogs such as
graphics (modal dialogs). You'd have to close the dialog before.
This would avoid undesired effects (e.g. modify some graphic
parameters whereas the preview is no more visible due to
scrolling, or buffer switching...).
The addition of a hideOnSwitch() method would deal with this
problem, while allowing you to do this: change the graphics
parameters for one inset; then (in the same document), click
another graphics dialog and make changes there, without having to
close and re-open the dialog.
Ok. For my usage, it's not annoying to close and reopen because most
of time, I make settings just after inserting graphics.
But there are issues about update that led
to the paragraph settings dialog becoming modal. Abdel is working
on this.
The intention is for it to become non-modal again, once he's got
it sorted
out.
Well I can't see why. If you want to apply the same settings to
several paragraphs, you could select them all, and then apply
settings, no?
The idea was that maybe you are making different changes in
different paragraphs, and it slows you down to have to close and
open the dialog every time.
Ok, now I understand why some people like it. But personally, I'd
prefer modal dialogs. What about a preference option? It would
concern only this kind of dialogs (I don't know, maybe we could refer
to them as "Inset dialogs").
Mael.
