Re: Need for better dialogs
Le 12 juil. 07 à 16:10, Richard Heck a écrit : Go ahead and file the enhancement bug with a note pointing to this thread. We can sort out the details later. Done: bug #4022. Mael.
Re: Need for better dialogs
Le 12 juil. 07 à 16:10, Richard Heck a écrit : Go ahead and file the enhancement bug with a note pointing to this thread. We can sort out the details later. Done: bug #4022. Mael.
Re: Need for better dialogs
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.
Re: Need for better dialogs
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.
Re: Need for better dialogs
Mael Hilléreau wrote: To Richard: please, don't forget the list in your reply ;-) I was out of town and using an unfamiliar system Le 6 juil. 07 à 23:17, [EMAIL PROTECTED] a écrit : There are going to be many of dialogs that behave like this one. AFAIU, precisely all dialogs whose controller has a method virtual bool isBufferDependent() const returning true. You can find them in all src/frontends/controllers/ ControlXXX.h source files. BTW, there seems to be an rc1/rc2 bug for some of them (e.g. graphics dialog don't hide anymore when switching buffer, whereas it did in 1.4.4). Please could you confirm? This was changed a while ago: Buffer dependent dialogs are not automatically closed when switching buffers any longer. There was a bug report about this, in particular, concerning the TOC/outline. Does automatically means for every class of dialog? Yes. Previously, any dialog whose isBufferDependent() method returned true would be closed on buffer switch. But I'm now convinced that most of these dialogs should remain hidden when another buffer is displayed. Indeed, it is senseless (despite respecting the don't close without prompt UI guideline) to keep on screen e.g. a graphics dialog when switching to another buffer (unrelated info). Right, but what this means, it seems to me, is that the isBufferDependent() function was being double-used. To be buffer dependent, in the intended sense, is to make no sense absent a buffer. That is different from being dependent upon the specific buffer displayed. Then I can confirm. There's a problem related to the use of isBufferDependent(). Into LyXView.cpp (line 168), you have this function call: // Buffer-dependent dialogs should be updated or // hidden. This should go here because some dialogs (eg ToC) // require bv_-text. getDialogs().updateBufferDependent(true); Then, if you go to Dialogs.cpp, Dialogs::updateBufferDependent() (line 214), you can see that isBufferDependent() leads to hiding buffer dependent dialogs (assuming that dialog-controller().initialiseParams() will always return false, which is the case for log dialogs). 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. 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(). 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(). 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. 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
Re: Need for better dialogs
Mael Hilléreau wrote:
To Richard: please, don't forget the list in your reply ;-)
I was out of town and using an unfamiliar system
Le 6 juil. 07 à 23:17, [EMAIL PROTECTED] a écrit :
There are going to be many of dialogs
that behave like this one. AFAIU, precisely all dialogs whose
controller has a method "virtual bool isBufferDependent() const"
returning true. You can find them in all "src/frontends/controllers/
ControlXXX.h" source files.
BTW, there seems to be an rc1/rc2 bug for some of them (e.g. graphics
dialog don't hide anymore when switching buffer, whereas it did in
1.4.4). Please could you confirm?
This was changed a while ago: Buffer dependent dialogs are not
automatically closed when switching buffers any longer. There was a bug
report about this, in particular, concerning the TOC/outline.
Does automatically means for every class of dialog?
Yes. Previously, any dialog whose isBufferDependent() method returned
true would be closed on buffer switch.
But I'm now convinced that most of these dialogs should remain hidden
when another buffer is displayed. Indeed, it is senseless (despite
respecting the "don't close without prompt" UI guideline) to keep on
screen e.g. a graphics dialog when switching to another buffer
(unrelated info).
Right, but what this means, it seems to me, is that the
isBufferDependent() function was being double-used. To be buffer
dependent, in the intended sense, is to make no sense absent a buffer.
That is different from being dependent upon the specific buffer
displayed.
Then I can confirm. There's a problem related to the use of
isBufferDependent(). Into LyXView.cpp (line 168), you have this
function call:
// Buffer-dependent dialogs should be updated or
// hidden. This should go here because some dialogs (eg ToC)
// require bv_->text.
getDialogs().updateBufferDependent(true);
Then, if you go to Dialogs.cpp, Dialogs::updateBufferDependent() (line
214), you can see that isBufferDependent() leads to hiding buffer
dependent dialogs (assuming that
dialog->controller().initialiseParams("") will always return false,
which is the case for log dialogs).
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.
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().
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().
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.
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
Re: Need for better dialogs (was: 1.5.0beta2: bibliography nuissances window/dialog style not OK)
To Richard: please, don't forget the list in your reply ;-) Le 6 juil. 07 à 23:17, [EMAIL PROTECTED] a écrit : Le 5 juil. 07 à 16:34, Jürgen Spitzmüller a écrit : Mael Hilléreau wrote: 1. Create a new doc. 2. Run latex. 3. View the LaTeX log. 4. Switch to another buffer. Zoops! The log dialog is closed. Bug? Probably yes. I agree, but I have bad news... There are going to be many of dialogs that behave like this one. AFAIU, precisely all dialogs whose controller has a method virtual bool isBufferDependent() const returning true. You can find them in all src/frontends/controllers/ ControlXXX.h source files. BTW, there seems to be an rc1/rc2 bug for some of them (e.g. graphics dialog don't hide anymore when switching buffer, whereas it did in 1.4.4). Please could you confirm? This was changed a while ago: Buffer dependent dialogs are not automatically closed when switching buffers any longer. There was a bug report about this, in particular, concerning the TOC/outline. Does automatically means for every class of dialog? But I'm now convinced that most of these dialogs should remain hidden when another buffer is displayed. Indeed, it is senseless (despite respecting the don't close without prompt UI guideline) to keep on screen e.g. a graphics dialog when switching to another buffer (unrelated info). Right, but what this means, it seems to me, is that the isBufferDependent() function was being double-used. To be buffer dependent, in the intended sense, is to make no sense absent a buffer. That is different from being dependent upon the specific buffer displayed. Then I can confirm. There's a problem related to the use of isBufferDependent(). Into LyXView.cpp (line 168), you have this function call: // Buffer-dependent dialogs should be updated or // hidden. This should go here because some dialogs (eg ToC) // require bv_-text. getDialogs().updateBufferDependent(true); Then, if you go to Dialogs.cpp, Dialogs::updateBufferDependent() (line 214), you can see that isBufferDependent() leads to hiding buffer dependent dialogs (assuming that dialog-controller ().initialiseParams() will always return false, which is the case for log dialogs). 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...). I'm curious to know how one should specify that a buffer dependent dialog has to hide/keep displayed when switching to another buffer. 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! 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...). If you click in a new graphics inset, then the dialog gets updated, I'm sure. True. But what if you just click elsewhere? However, IMO, for most of these dialogs (such as graphics, label, citation, reference, etc.), there would be an easier and better solution regarding buffer switch (among others): make them modal! After all, what is the benefit of keeping such dialogs independent from the main window? This is a much discussed issue. Some people like having non-modal dialogs, Ok. I'm not of them, with a fiew exceptions, e.g. for the LaTeX log in the scope of master/children docs. e.g., the text settings dialog. 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? If you want to deal with several paragraphs in a row, it's much more convenient to be able to keep it open. Several paragraphs in a row?? I don't understand. Could you explain please? Clearly, this would have non negligible advantages: [snip] But it's overkill, I think, to make everything modal. I didn't say that. I think there should some exceptions for dialogs managing info related to more than one buffer, or even more than one inset, if applicable. But note that some dialogs are already modal (I think of open, save and so on...).
Re: Need for better dialogs (was: 1.5.0beta2: bibliography nuissances & window/dialog style not OK)
To Richard: please, don't forget the list in your reply ;-)
Le 6 juil. 07 à 23:17, [EMAIL PROTECTED] a écrit :
Le 5 juil. 07 à 16:34, Jürgen Spitzmüller a écrit :
Mael Hilléreau wrote:
1. Create a new doc.
2. Run latex.
3. View the LaTeX log.
4. Switch to another buffer. Zoops! The log dialog is closed.
Bug?
Probably yes.
I agree, but I have bad news... There are going to be many of dialogs
that behave like this one. AFAIU, precisely all dialogs whose
controller has a method "virtual bool isBufferDependent() const"
returning true. You can find them in all "src/frontends/controllers/
ControlXXX.h" source files.
BTW, there seems to be an rc1/rc2 bug for some of them (e.g. graphics
dialog don't hide anymore when switching buffer, whereas it did in
1.4.4). Please could you confirm?
This was changed a while ago: Buffer dependent dialogs are not
automatically closed when switching buffers any longer. There was a
bug
report about this, in particular, concerning the TOC/outline.
Does automatically means for every class of dialog?
But I'm now convinced that most of these dialogs should remain hidden
when another buffer is displayed. Indeed, it is senseless (despite
respecting the "don't close without prompt" UI guideline) to keep on
screen e.g. a graphics dialog when switching to another buffer
(unrelated info).
Right, but what this means, it seems to me, is that the
isBufferDependent() function was being double-used. To be buffer
dependent, in the intended sense, is to make no sense absent a buffer.
That is different from being dependent upon the specific buffer
displayed.
Then I can confirm. There's a problem related to the use of
isBufferDependent(). Into LyXView.cpp (line 168), you have this
function call:
// Buffer-dependent dialogs should be updated or
// hidden. This should go here because some dialogs (eg ToC)
// require bv_->text.
getDialogs().updateBufferDependent(true);
Then, if you go to Dialogs.cpp, Dialogs::updateBufferDependent()
(line 214), you can see that isBufferDependent() leads to hiding
buffer dependent dialogs (assuming that dialog->controller
().initialiseParams("") will always return false, which is the case
for log dialogs).
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...).
I'm curious to know how one should specify that a buffer dependent
dialog has to hide/keep displayed when switching to another buffer.
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!
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...).
If you click in a new graphics inset, then the dialog gets
updated, I'm sure.
True.
But what if you just click elsewhere?
However, IMO, for most of these dialogs (such as graphics, label,
citation, reference, etc.), there would be an easier and better
solution regarding buffer switch (among others): make them modal!
After all, what is the benefit of keeping such dialogs independent
from the main window?
This is a much discussed issue. Some people like having non-modal
dialogs,
Ok. I'm not of them, with a fiew exceptions, e.g. for the LaTeX log
in the scope of master/children docs.
e.g., the text settings dialog. 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?
If you want to deal with several paragraphs in a row, it's much more
convenient to be able to keep it open.
Several paragraphs in a row?? I don't understand. Could you explain
please?
Clearly, this would have non negligible advantages:
[snip]
But it's overkill, I think, to make everything modal.
I didn't say that. I think there should some exceptions for dialogs
managing info related to more than one buffer, or even more than one
inset, if applicable.
But note that some dialogs are already modal (I think of open, save
and so
Need for better dialogs (was: 1.5.0beta2: bibliography nuissances window/dialog style not OK)
Le 5 juil. 07 à 16:34, Jürgen Spitzmüller a écrit : Mael Hilléreau wrote: 1. Create a new doc. 2. Run latex. 3. View the LaTeX log. 4. Switch to another buffer. Zoops! The log dialog is closed. Bug? Probably yes. I agree, but I have bad news... There are going to be many of dialogs that behave like this one. AFAIU, precisely all dialogs whose controller has a method virtual bool isBufferDependent() const returning true. You can find them in all src/frontends/controllers/ ControlXXX.h source files. BTW, there seems to be an rc1/rc2 bug for some of them (e.g. graphics dialog don't hide anymore when switching buffer, whereas it did in 1.4.4). Please could you confirm? But I'm now convinced that most of these dialogs should remain hidden when another buffer is displayed. Indeed, it is senseless (despite respecting the don't close without prompt UI guideline) to keep on screen e.g. a graphics dialog when switching to another buffer (unrelated info). Besides, this reinforces my idea that UI guidelines are good in theory, but that there's a need to consider functionality and practice as well ;-) IMO, exceptions are to be when dealing with child documents. For example, the LaTeX log of a master document shouldn't be hidden when switching to one of its children (because it contains info related to the contents of children). But it should be hidden otherwise. However, IMO, for most of these dialogs (such as graphics, label, citation, reference, etc.), there would be an easier and better solution regarding buffer switch (among others): make them modal! After all, what is the benefit of keeping such dialogs independent from the main window? Clearly, this would have non negligible advantages: * This would definitely unseat problems such as the one described by Rob at the beginning of this thread, increasing UI intelligibility. * This would also unclutter the screen, as complained in bug #3836. * Finally, this would also simplify some code (e.g. disabling some menu entries, as mentioned in bug #1720, wouldn't be needed anymore). May I file an enhancement request for better/modal dialogs? Mael.
Need for better dialogs (was: 1.5.0beta2: bibliography nuissances & window/dialog style not OK)
Le 5 juil. 07 à 16:34, Jürgen Spitzmüller a écrit : Mael Hilléreau wrote: 1. Create a new doc. 2. Run latex. 3. View the LaTeX log. 4. Switch to another buffer. Zoops! The log dialog is closed. Bug? Probably yes. I agree, but I have bad news... There are going to be many of dialogs that behave like this one. AFAIU, precisely all dialogs whose controller has a method "virtual bool isBufferDependent() const" returning true. You can find them in all "src/frontends/controllers/ ControlXXX.h" source files. BTW, there seems to be an rc1/rc2 bug for some of them (e.g. graphics dialog don't hide anymore when switching buffer, whereas it did in 1.4.4). Please could you confirm? But I'm now convinced that most of these dialogs should remain hidden when another buffer is displayed. Indeed, it is senseless (despite respecting the "don't close without prompt" UI guideline) to keep on screen e.g. a graphics dialog when switching to another buffer (unrelated info). Besides, this reinforces my idea that UI guidelines are good in theory, but that there's a need to consider functionality and practice as well ;-) IMO, exceptions are to be when dealing with child documents. For example, the LaTeX log of a master document shouldn't be hidden when switching to one of its children (because it contains info related to the contents of children). But it should be hidden otherwise. However, IMO, for most of these dialogs (such as graphics, label, citation, reference, etc.), there would be an easier and better solution regarding buffer switch (among others): make them modal! After all, what is the benefit of keeping such dialogs independent from the main window? Clearly, this would have non negligible advantages: * This would definitely unseat problems such as the one described by Rob at the beginning of this thread, increasing UI intelligibility. * This would also unclutter the screen, as complained in bug #3836. * Finally, this would also simplify some code (e.g. disabling some menu entries, as mentioned in bug #1720, wouldn't be needed anymore). May I file an enhancement request for better/modal dialogs? Mael.
