Il 07/03/2012 00:09, LyX Ticket Tracker ha scritto:
Comment (by Jerry):
Hi Jerry, a few comments in line:
On OS X (at least), the Search Backwards text and corresponding checkbox
take up _more_ space than the Find Next button. (This is when the box is
made as small as possible, which is what someone who is concerned about
efficient screen use would do.) So following my original suggestion would
take _less_ space.
quite interesting, perhaps a screenshot from OS-X would help me understand.
Another issue is that the actual size of buttons and labels depends
heavily on the language of the GUI, which adds further chaos to
the topic !
I have another ticket, #8055, where I describe the problem (again, on OS
X), of a seriously anachronistic problem with LyX lacking Command-G and
Shift-Command-G for Find Next and Find Previous.
AFAICS, this is the long-standing request for a "search bar" replacing
the current Quick Find dialog, plus the 2 shortcuts you mention that,
if widely used on Mac, then they should be there also in LyX. It should
not be too difficult to add them to the Advanced F&R, I think, but I
don't have a Mac :-(!
Another problem with Shift-Enter is that there is no way to know this from
the GUI which is poor design.
Sure, agree, perhaps it's mentioned in the manual, but a tooltip over
some of these buttons would surely help.
As long as we're on or near the subject, the Advanced F&R dialog should
have _another_ button, Replace and Find Next.
kind of issue discussed in the past. It seems most editors basically
interpret the "replace next" button this way, i.e., the first time you
hit it, it only finds next, the second time it replaces the current match
and finds the next one. That seems what is needed, in the end, I
can't see the need for another button.
Some space can be saved by changing the button functions when Option is
pressed. This is a _little_ better than the Shift key because there is
precedence in OS X, plus when the Option key is pressed, the text on the
affected button is changed, unlike the present Shift-Return scheme.
I don't know what is the Option button on Mac, so I'm unable to
understand this interaction model. But what you say seems smth.
like: when I do Alt+Click (or Ctrl+Click), any button can be reconfigured
to behave differently, so we can reuse existing buttons in the GUI, and
the user is made aware because the buttons labels change in real-time
as soon as the Ctrl or Alt is hold down. Hmmm..., don't know, surely
it's not the most common GUI interaction model that I can see on
Linux and Windows (perhaps Emacs and XFig may have bits that
resemble such behaviour).
Another problem with the Advanced F&R dialog is that its close button is
not highlighted when it has focus. Indeed, when it has focus, the main
document window's close etc. buttons (the "traffic lights") _are_ colored
which is wrong because it does not have focus. (This latter point is not
unique to the Advanced F&R dialog and probably should get its own ticket.
It might be a Qt problem though.)
Don't know, seems you're referring to the close icons, but these never
change on my Linux/Ubuntu/Gnome. Perhaps I should try a different WM
to see the problem.
And while I'm on a roll (thanks for reading this far), when using Return
and Shift-Return in Advanced F&R, and in the case where there are multiple
instances of the "find" text in the document, the first pressing of Shift-
Return, after at least one successful Return which has left some
highlighted text, does nothing, leaving the previously selected text still
colored as selected. It takes _another_ pressing of Shift-Return to
actually find the previous instance. Ditto for going from Shift-Return to
Return.
I'm aware of this behaviour. Actually, there's a small effect, i.e., the
cursor moves from the beginning of the match to the end (or the
other way round for the backwards search), but I agree
it's hard to notice and probably ununderstandable and useless from
a user perspective.
Pls, add an enhancement request to fix this behavior, so that we don't
forget (unless it's already all included in #8055, but, please, try to
separate bugs/requests for generic Mac-specific GUI interactions
from those for the Find&Replace feature if possible).
Thanks again for the detailed report, it's very useful. We keep track
about pending issues on the Trac ( :-) ), and reminders and discussions
on the list help not forgetting about those issues.
Bye,
T.
