Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>: > Mael Hilléreau wrote: > > Well, then the UI is IMO already unintuitive. We have two separate actions: > > > > 1) Edit the external file; > > 2) Edit graphics properties (i.e. how LyX must use the external file). > > Despite they're both related to graphics, these two functionalities are > > clearly distinct. > > Agreed. That's why I think Jean-Marcs proposal is the way to go.
Yes. > > But in order to do 1), the user has to do 2) before. I > > thought that closing the dialog wouldn't be _perfect_, but at least better > > than the current behavior. > > Here is where we disagree. Yes. > > BTW, note that when you click on the "Load" button in the "Child document" > > dialog, this dialog in automatically closed!! ...whereas there are also a > > "Close" and an "Ok" button in this dialog! > > > > Isn't that running counter to a predictable behavior?? ;-) > > Yes, it is. And it's an ui bug IMHO. Thanks for pointing that out. > Attached is a patch that fixes this. OK to commit? I disagree. IMHO the current behavior concerning the "Load" button is the right one for the moment, and so the one of the "Edit" button should be similar, even if this is counter to UI guidelines. I can explain why... We agree that those buttons shouldn't exist at all. But as you must keep them until a better solution is developed, just get them as much ergonomic as possible. I know that in your opinion, "ergonomic" stands for "don't close dialogs without prompt". But, why would the user access to child document (resp. LyX graphics) settings whereas he just want to load (resp. edit) a file?? This sounds illogic/unergonomic to me. In other words, prompt isn't good if your UI isn't designed in the right way. In fact, what you propose here is to make UI worse regarding the "functions separation" aspect, arguing that UI guidelines are not respected regarding the "closing" aspect. BTW, did you already heard about users complaining about the "Load" button? If no, this button behavior isn't so bad for the moment. Moreover, if you change it so that the dialog would no more be closed, then what will users do after clicking it? I bet on close the dialog! > The proper solution here would as well be to take this function out of the > dialog and provide it via context menu. But we don't have this possibility > yet. For me, the right way is to keep the behavior as is (and so also apply my patch) until a context menu is developed. But, as I already mentioned, will this happen one day? Not soon I guess. Mael.
