Le 17/09/2016 à 08:43, Jürgen Spitzmüller a écrit :
Consistent with which search field?
I had the outliner and PanelStack in mind.
The one in the PanelStack that
greys out items that do not match the filter instead of hiding them (do
you want to do this here as well?)?
Indeed, I would find it clearer and more consistent if PanelStack hide
the entries instead of greying them. (Unless a peculiarity of PanelStack
escapes me, making the current behaviour necessary.)
The one in the Refs dialog that is
below the browser widget and does not provide regex
Thank you for your recent improvements regarding this one. I do not have
much experience with this dialog since it is possible to insert
cross-references only by using copy-paste.
Two things I noticed:
* The "clear" button does not work in the GuiRef filter.
* LyX 2.3 requires qt ≥ 4.8 so the preprocessor directives are not
necessary.
(the next candidatefor dropping, then)?
I have no secret plan to drop the regex option.
And how does your proposal to bind the Enter key to jumping widgets add
consistency?
My suggestion makes sense as well for the other search fields that I
mentioned.
You are a developer as well (and we both are users), and what you
propose is inevitably based on your tastes and habits. So please do not
play out "subjective" and "objective" reasons.
I did not mean to exclude myself from the description, of course.
Also, unless a developer with a training in UX starts contributing, the
best we can do is try to imitate what other applications do. In
particular habits deriving from other applications are more relevant, to
a certain degree.
(And believe it or not,
I am also able to abstract from my own narrow POV; I can follow your
arguments, but still I think the current UI makes sense).
It does make sense. To me it already did with the QToolBox, but
what we have now is even better, on a much larger scale than the
small details I have been discussing. Thanks!
The proposal to assign "Enter" to a different function seems to
imply
the proposal to remove the option to toggle "search on fly". If you
mean this, I will object, since I'd like to have it switched off.
Yes, this is what I mean.
I think it makes sense since this is a filter that needs to filter very
long lists (in my case several thousand entries in over 70 fields). The
performance is acceptable, but I am not sure what happens with larger
databases.
I am not really worried about performance. This is small for a computer.
Especially as the filter already has the optimisation where it filters
among the already-found items, which is very efficient for the
"on the fly" mode. There is an easy test to do: see whether using
backspace in the filter feels ok. There is no optimization in this case.
If the result is that it feels okay, then LyX will cope with much larger
databases.
In general the data manipulated by LyX is very small. In my experience
LyX is sometimes slow not because of the size of the data but because of
bad design in certain places (e.g. constant repaintings of whole insets,
constant global updates of macros, repeated calls to costly functions
(0a8b7f6a)), or algorithmic oversights (e.g. quadratic or worse amount
of calls to copy constructors and such, see c51ebd9b, b2b87330,
89175ee0). As a rule of thumb one should more be on the lookout for
these. Of course this remark is not sufficient to rule-out your concern.
Having said that, I am completely fine with making "search on fly" opt-
out.
This is an alternative I had in mind in the absence of a consensus, so
since you are fine with it I might commit such a patch directly.
Guillaume
