convert the search dialog to a search bar

[muzzle@…]

I wish lyx could learn from firefox how useful it is to have the search tool
displayed as a bar at the bottom of the sceen (or a side pane, maybe, a la
acrobat reader), rather than as a dialog that you need to move every time while
looking for the highlighted text.

Would you consider implementing a pop-it search bar? Hope you like the idea.
Bye,

Emme

BTW
I also think a side pane to handle the spellchecker would be great.

[muzzle@…]

A side pane would be the ideal place for the "find and replace" interface.

[andreas1973@…]

A search bar would be great.
Andreas

[mike@…]

Perhaps such a feature could be combined with the spell check interface? There
isn't much utility in having a spell check interface that exists as it's own
dialog window.

[stroboscopicallyconfluent@…]

Agree!

[muzzle@…]

Bump!
Two stable version of Lyx came and went without any work on this feature :(

[ps@…]

there seems to be some progress on completely new search panel, not for 1.6.0
though.

[Uwe Stöhr]

will be fixed by the fix for #3998

[Uwe Stöhr]

Fixed by Tommaso's new find and replace dialog, see
​http://wiki.lyx.org/LyX/NewInLyX20

[Vincent van Ravesteijn]

I believe that the plan is to keep the 'simple' find (and replace) feature next to the advanced search widget. This 'simple' dialog is then the perfect candidate to be replaced by a search bar. This has still to be done.

[ps]

Vincent:
I've already done some work on it. I really want to have this in 2.0.0,
so we have a polished brand new search and replace functionality.

If not before 2.0.0, it must be done as soon as possible.
Anyway, sign me up for this one.

[ps]

nobody is working on this.

[Uwe Stöhr]

Well, we have already the advanced find search bar in LyX 2.0.x. If you don't agree that this is enough, please reopen.

[racoon]

Possible duplicate: #11434.

[Richard Kimberly Heck]

This is a nice idea. Could we put it into a toolbar somehow? Alternatively, we have plenty of dock-able widgets now. Would it be enough to make this one dockable?

[lasgouttes]

It would be nice, but of course, we would lose replace.

[ps]

Dockable dialogs are in recent Qt versions unfortuntaly pain, at least here.
Do you observe the same problem? If one drags the docked pane out of the main window, it becomes undocked but unresponsive for any mouse input.

[racoon]

Replying to lasgouttes:

It would be nice, but of course, we would lose replace.

If it would be a dockable search bar, like the command execution bar, then there could be, for example, a second row with the replace option or one which opens on a button a second row with the replace field when needed.

[Juergen Spitzmueller]

Patch for dockable find/replace is ready. See
​https://marc.info/?l=lyx-devel&m=161322311729579&w=2

[racoon]

Are you going to add a patch to the ticket to play with?

[Juergen Spitzmueller]

patch

[Juergen Spitzmueller]

Replying to racoon:

Are you going to add a patch to the ticket to play with?

Here you are.

[superkryo]

Replying to spitz:

Replying to racoon:

Are you going to add a patch to the ticket to play with?

Here you are.

Very nice! If this is to be implemeneted, switching among the tabs in the docked pane will be more frequent for users. Hence #12125 might become a bit more relevant.

[racoon]

Replying to spitz:

Replying to racoon:

Are you going to add a patch to the ticket to play with?

Here you are.

Thanks for working on this.

I am inclined to think that one important aim is to make the docks minimal size as small as possible (while being usable). Currently, its margins are more like a proper dialog (at least on macOS, see larger.png). I suggest something like the attached patch (see smaller.png). Unfortunately, the results are quite different for the macOS Qt style as compared to the fusion style (on mac at least). There might be a setting somewhere to get this right. I'll try to find it.

Next, I would try to get rid of the third (almost empty) row. Maybe the checkboxes could be replaced by toggle buttons with shorter (but common) labels like "Match Case" and "Whole Words" or maybe even better replacing the labels on all buttons by icons. Unfortunately, I could not play around with the buttons because the icons did not show up for me (see screen captures).

[Juergen Spitzmueller]

Don't waste you time on coding, as I am working on this myself.

[racoon]

Replying to spitz:

Don't waste you time on coding, as I am working on this myself.

Okay. That the patch is "ready" sounded as if you were done working on it for now. Anyway, I'd be happy to check and give feedback on how it looks like on macOS.

[Juergen Spitzmueller]

Fixed in master at [2baa3a46a6ad/lyxgit].

[racoon]

So, you are done with it for now?

Btw. I don't think disabling the Replace text field is a good idea (as opposed to deactivating the replace buttons) because sometime one wants to fill in the replace field first and then the search field later. And I haven't seen this implemented elsewhere.

Use case: if one is at a passage with a replace text and wants to copy & paste it into the field and next copy & paste a search text from somewhere else into the search field.

[Juergen Spitzmueller]

Replying to racoon:

So, you are done with it for now?

Depends on feedback.

Btw. I don't think disabling the Replace text field is a good idea

Changed.

[racoon]

1. Right now, on Ctrl/Cmd + F, the Search Widget is toggled. However, standard behaviour in other applications (and LyX's Advanced Find and Replace) is that the widget stays but gets focused.

2. In other applications, on Ctrl/Cmd + F, all the text in the find text field gets selected. This makes it possible to quickly search for several search words (Ctrl/Cmd + F, enter search word, Enter, Ctrl/Cmd + F, enter search word, Enter, etc.).

[Juergen Spitzmueller]

Replying to racoon:

1. Right now, on Ctrl/Cmd + F, the Search Widget is toggled. However, standard behaviour in other applications (and LyX's Advanced Find and Replace) is that the widget stays but gets focused.

I want to switch in on/off quickly and also changed that for Advanced BTW.

2. In other applications, on Ctrl/Cmd + F, all the text in the find text field gets selected. This makes it possible to quickly search for several search words (Ctrl/Cmd + F, enter search word, Enter, Ctrl/Cmd + F, enter search word, Enter, etc.).

I see if I can implement this.

[racoon]

Replying to spitz:

Replying to racoon:

1. Right now, on Ctrl/Cmd + F, the Search Widget is toggled. However, standard behaviour in other applications (and LyX's Advanced Find and Replace) is that the widget stays but gets focused.

I want to switch in on/off quickly and also changed that for Advanced BTW.

Switching on: Ctrl/Cmd + F.
Switching off: Ctrl/Cmd + F, Esc.

IMO, it would be good to stay with the standard behaviour rather than let people re-learn to do it differently in LyX.

[racoon]

The advantage with having a non-toggling behaviour is also that one does not even have to look at the search widget to search. With the toggling behaviour one has to first check whether it is visible or not.

[Juergen Spitzmueller]

Replying to racoon:

2. In other applications, on Ctrl/Cmd + F, all the text in the find text field gets selected. This makes it possible to quickly search for several search words (Ctrl/Cmd + F, enter search word, Enter, Ctrl/Cmd + F, enter search word, Enter, etc.).

This is actually already the case. If you hit enter or click Find, the text in the search widget gets selected.

[racoon]

Replying to spitz:

Replying to racoon:

2. In other applications, on Ctrl/Cmd + F, all the text in the find text field gets selected. This makes it possible to quickly search for several search words (Ctrl/Cmd + F, enter search word, Enter, Ctrl/Cmd + F, enter search word, Enter, etc.).

This is actually already the case. If you hit enter or click Find, the text in the search widget gets selected.

No, the sequence I gave would toggle the dialog, or? But what I had actually in mind was

• Ctrl/Cmd + F, enter search word, Enter, make changes, Ctrl/Cmd + F, enter search word, Enter, make change, etc.

I guess that this doesn't work either, in part, because of the toggling but the old dialog would not select the search word when Ctrl/Cmd + F was pressed and the dialog was already open.

[Juergen Spitzmueller]

Ah, you mean "make changes" in the workarea (not the dialog). No, this is not possible. What I meant is: make changes to the search string. This is possible as this is selected after any find action in the dialog.

[racoon]

Replying to spitz:

Ah, you mean "make changes" in the workarea (not the dialog).

Yes, that's what I meant. Sorry, now I see that it was ambiguously formulated.

[racoon]

It would be good to have the options "Case sensitive" and "Whole words" visible at all times. Because otherwise in minimized mode one would always have to wonder whether not finding a word is due to the word not present in the text or one of these settings and might sometimes forget about the options set and think that the word is not present when it in fact is present.

[Juergen Spitzmueller]

This conflicts with other people's wish to have a lean oneliner widget.

But I can add an indicator in the search bar that options are set (and a tooltip displaying the settings). Like Qt Creator does it.

[racoon]

I don't think it necessarily conflicts with a leaner one-liner widget which I am also in favour of. Many one-liner widgets have these settings visible, see e.g. Firefox and Visual Studio Code. If it's possible to add an indication why not make it clickable to (de)activate the option?

[Juergen Spitzmueller]

Because I want the options to be immediately accessible by keyboard and do not want to duplicate widgets.

[racoon]

I am not sure I can follow. What has the accessibility of the options to do with this? Why would a duplication be necessary?

[Juergen Spitzmueller]

There is not enough space in the first row to add these widgets on top level. If we add them to a context menu (as QtCreator does), accessibility with the keyboard is limited (those can only be reached by mouse).
As it is now, the Options can be set by a single shortcut (if search is expanded).

Note that Qt Creator provides duplicated widgets (in expanded mode) for this reason. I really do not see a need for that. Expanding and changing is as quick (or even wuicker) than expanding a menu button an select an item.

[racoon]

One way to get more space is by using simple arrow icon buttons rather than buttons with captions for "< Find" and "Find >". Possibly up/down rather than left/right arrows because they are more commonly used, I think. Then "Case sensitive" (or shorter "Match case" as used in Firefox) and "Whole words" toggle buttons would have enough space I think, or in case not, they could also get icons like "Aa" and "|Ab|" (or under and overline on the latter icon) and maybe a fitting shortcut to activate them can be found.

[Juergen Spitzmueller]

I can only provide to implement the indicators. If you think this does not help, I'll leave things as they are.

[racoon]

Indicators do help I think. I only think that being able to fully use the search capabilities in minimized mode would be even better. I could try to implement it and you could tell me what you think. So, you don't need to waste your time on something you are sceptical about.

[racoon]

Okay, I have a good idea now how to implement it. I'll make an attempt and post it here later today.

[Juergen Spitzmueller]

But if my skepticism remains you will have wasted your time.

[racoon]

Well, I would also do it for my sake because I really would like to have this kind of functionality. And I am happy to take my chances and others might have feedback and ideas as well on this.

[Juergen Spitzmueller]

As you wish. Meanwhile I will have a go at the indicators approach.

[racoon]

You could also wait with this, since it will be made redundant *if* my patch is fitting.

[racoon]

By the way, I might not have currently the latest version compiled but if I activate "Search as you type" I can only find one instance of a search string. Has this been fixed? Otherwise, fixing it might be a better time investment in the meanwhile.

[Juergen Spitzmueller]

Search as you type works for me as intended.

[Juergen Spitzmueller]

Oh, I see. I'll have a look.

[Juergen Spitzmueller]

Search as you type fixed at [180fca2fcdca/lyxgit].

[racoon]

Next one: Search as you type should find the next instance after the current cursor position in the work area. If that is fixed as well, I am inclined to think that Search as you type should be always activated (or at least be the default).

[Juergen Spitzmueller]

You mean if I type "te" and it finds "te" in test, and I enter "s" ("tes") it should jump to the next match rather than sticking with the current one if it still fits?

[Kornel Benko]

Still does not work. For instance having

'lyxsocket lyxserver'

in text, try to find 'lyxse', you get the 'not found message'

[racoon]

Replying to spitz:

You mean if I type "te" and it finds "te" in test, and I enter "s" ("tes") it should jump to the next match rather than sticking with the current one if it still fits?

Ah, I see. It's more complicated than I thought. The easiest implementation might be to always start from the beginning of the current selection to search (instead of from the beginning of the document). In this way one would also avoid jumping to the next instance as in your case.

[Juergen Spitzmueller]

What do you mean by "instead of the beginning of the document"?

[racoon]

Replying to spitz:

What do you mean by "instead of the beginning of the document"?

At least in the version that I have, the "type as you search" search seems to always starts to search for the search string from the beginning of the document.

[Juergen Spitzmueller]

Replying to kornel:

Still does not work. For instance having

'lyxsocket lyxserver'

in text, try to find 'lyxse', you get the 'not found message'

You need to be more precise. This works for me.

[Juergen Spitzmueller]

Replying to racoon:

At least in the version that I have, the "type as you search" search seems to always starts to search for the search string from the beginning of the document.

It is supposed to start from the current cursor position (and does so here)

[racoon]

Okay, then I need to do a re-compile later.

[Kornel Benko]

Replying to spitz:

Replying to kornel:

Still does not work. For instance having

'lyxsocket lyxserver'

in text, try to find 'lyxse', you get the 'not found message'

You need to be more precise. This works for me.

Arrrg ... my fail. The word 'lyxserver' started with the logo 'LyX'.

In findadv, this is found though.

[Juergen Spitzmueller]

We can add support for special chars quite easily if wanted. We already do so for special chars.

[Juergen Spitzmueller]

Replying to spitz:

We can add support for special chars quite easily if wanted. We already do so for special chars.

I mean for InsetQuote. Currently, we deliberately skip special char insets.

[Juergen Spitzmueller]

Actually it does already work, but not case-insensitive. Searching for "LyX" does find the logo.

[Juergen Spitzmueller]

As of [ab1cc8e1c2ab/lyxgit] case-insensitive search works as well.

[Kornel Benko]

Confirmed. Prefect.

[lasgouttes]

When I use find as you type, using backspace reduces the selection, except when the search string is finally empty: there is still one letter selected in the buffer view.

[Juergen Spitzmueller]

Replying to lasgouttes:

When I use find as you type, using backspace reduces the selection, except when the search string is finally empty: there is still one letter selected in the buffer view.

Fixed at [80cb0650e44/lyxgit]

[racoon]

Replying to spitz:

Replying to racoon:

At least in the version that I have, the "type as you search" search seems to always starts to search for the search string from the beginning of the document.

It is supposed to start from the current cursor position (and does so here)

It does not so here (with the latest version). Steps to reproduce:

1. Write "aa"
2. Put the cursor before the second "a"
3. Search for "a" (with "Search as you type" active)

Actual result:

• The first "a" is found

Expected result:

• The second "a" is found

[Juergen Spitzmueller]

I cannot reproduce this. Here, the second "a" is highlighted as soon as I enter"a" to the search field. Or I misunderstand your recipe.

[racoon]

Okay, screen capture of first attempt attached. It still needs some adjustment. It is extremely tricky to get both Fusion and Macintosh styles right at the same time.

Again, the idea is this:

• keep the widget as tight as possible
• allow and show most important configuration of the search in "Minimized"/"Less" mode

[Juergen Spitzmueller]

This only pulls two of the options in the first row. One (Selection only) is even missing at all. I also do not like the small find buttons. And I do not think push buttons are the appropriate widget for options.

I'll push the indicators approach later today (I have it ready). This will make _all_ options accessible in minimized mode.

[racoon]

Replying to spitz:

This only pulls two of the options in the first row.

Yes, as I said, it's only about the most essential options.

One (Selection only) is even missing at all.

Something is strange with my git. I don't see that option in master.

I also do not like the small find buttons.

They are quite common with these kinds of small search widgets though. It seems unnecessary and even distracting to always present these texts since it's quite obvious what their meaning is.

And I do not think push buttons are the appropriate widget for options.

They are quite common in these kind of widgets too. They look quite clean, I think.

I'll push the indicators approach later today (I have it ready). This will make _all_ options accessible in minimized mode.

Looking forward to it.

[Juergen Spitzmueller]

Pushed at [a7e6dcc31d/lyxgit].

[racoon]

In order to get more space for the search line edit, I'd suggest to use placeholder text "Find" and "Replace" (lineEdit()->setPlaceHolder()) rather than "Find:" and "Replace with:" (I haven't seen these labels in search widgets. Also "More" and "Less" is shorter (at least in English but also the German translation) than "Expand" and "Minimize" and the meaning seems equally as clear.

[Juergen Spitzmueller]

The problem with these placeholders is

1. they are only visible when the widget is empty
2. the grey text is not very well readable (this is a serious accessibility issue for people with reduced eyesight)
3. you lose the accelerators to the input widgets

With "More" and "Less" you have less accelerators available (l, e and s are already taken). Note that we cannot use any main menu or key accelerator either, as these are active for docked widgets. I also think Expand and Minimize are more transparent ("more of what?", "less of what?").

[racoon]

In general, in other apps, dockwidget seem to be designed quite a bit different from dialog because they are suppose to make the most of the limited space. For example, they often have no or almost no margins, like toolbars. LyX doesn't follow this. I was thinking about working on this a bit as well.

[Juergen Spitzmueller]

This must be theme dependent. I do not get too much space here. See screenshots at
​https://wiki.lyx.org/LyX/NewInLyX24#toc12

[lasgouttes]

There are interesting examples for progressive disclosure in dialogs in ​Windows documentation.

They do not discuss accessibility, though.

For textual buttons, the suggestion is 'More >>' and '<< Less'.

Another possibility for the options is a popup menu.

There is a suggestion of a vertical chevron in the search filed itself to show the 'replace' part. Worth a read, anyway.

[lasgouttes]

Here are the similar ​macOS description, which is less interesting though.

[Juergen Spitzmueller]

Replying to lasgouttes:

There are interesting examples for progressive disclosure in dialogs in ​Windows documentation.

This pretty much reveals how Windows is designed as a click-only UI (one of the reason I despise it).

Another possibility for the options is a popup menu.

We have that now, but only in minimal mode. The popup menu is less accessible by keyboard. It is still faster (with keyboard) to expand, select option, and minimize again.

[Juergen Spitzmueller]

Replying to lasgouttes:

Here are the similar ​macOS description, which is less interesting though.

It would be interesting to see how the dialog would look if we followed this suggestion. A forest of down arrows.

I agree with them, though, that the disclosure label should be as descriptive as possible. This conflicts with MS' "More" and "Less" suggestion, which is probably the least descriptive label one could come up with.

[racoon]

Replying to spitz:

The problem with these placeholders is

1. they are only visible when the widget is empty
2. the grey text is not very well readable (this is a serious accessibility issue for people with reduced eyesight)

It should be pretty obvious from the button context what the line edits are for. So, I do not think either of these is a serious issue.

3. you lose the accelerators to the input widgets

I did not see an accelerator in your implementation. Also, since the implementation is so common, I guess it's not much of an issue?

(Also I think "Replace" rather than "Replace with" is better as in "Search" rather than "Search for".)

With "More" and "Less" you have less accelerators available (l, e and s are already taken). Note that we cannot use any main menu or key accelerator either, as these are active for docked widgets. I also think Expand and Minimize are more transparent ("more of what?", "less of what?").

Again, I think "More" and "Less" are obvious from the context (and if not, all it takes is an innocent press). And you also don't ask "Expand to what?", "Minimize to what?"

[racoon]

Replying to spitz:

Replying to lasgouttes:

Here are the similar ​macOS description, which is less interesting though.

I agree with them, though, that the disclosure label should be as descriptive as possible. This conflicts with MS' "More" and "Less" suggestion, which is probably the least descriptive label one could come up with.

Descriptiveness ist only one aspect. I find many search bar implementation not very descriptive but that is no issue because they are used so often. Once you have figured it out, you are happy that it takes so little space. Also, tooltips go a long way for those who can't figure it out.

[Juergen Spitzmueller]

Replying to racoon:

It should be pretty obvious from the button context what the line edits are for.

No it isn't (if you are not familiar with the dialog). With this rationale, we can just get rid of most labels to save space-.

3. you lose the accelerators to the input widgets

I did not see an accelerator in your implementation.

Search: Alt+s
Replace: Alt+l

Also, since the implementation is so common, I guess it's not much of an issue?

How does this help you navigating to the widget with the keyboard?

(Also I think "Replace" rather than "Replace with" is better as in "Search" rather than "Search for".)

It's semantically wrong. "Search 'foo', replace 'bar'" is not the same as "Search 'foo', replace with 'bar'". In the former case, I'd expect "bar" to be replaced, not "foo".

Again, I think "More" and "Less" are obvious from the context (and if not, all it takes is an innocent press).

Well, this does again not help with the accelerator problem.

And you also don't ask "Expand to what?", "Minimize to what?"

Expand this, minimize this. This ellipsis is completely transparent in context.

[Juergen Spitzmueller]

Replying to racoon:

Descriptiveness ist only one aspect. I find many search bar implementation not very descriptive but that is no issue because they are used so often. Once you have figured it out, you are happy that it takes so little space. Also, tooltips go a long way for those who can't figure it out.

I do not see how we gain any more space with your suggestions. But we lose accessibility (both in cognitive and in motorical terms).

[racoon]

Replying to spitz:

Replying to racoon:

It should be pretty obvious from the button context what the line edits are for.

No it isn't (if you are not familiar with the dialog). With this rationale, we can just get rid of most labels to save space-.

I think people are familiar with search bars/docks (it's not a dialog, I think).

3. you lose the accelerators to the input widgets

I did not see an accelerator in your implementation.

Search: Alt+s
Replace: Alt+l

Doesn't work here. Maybe a macOS issue.

Also, since the implementation is so common, I guess it's not much of an issue?

How does this help you navigating to the widget with the keyboard?

I just pointed out that it doesn't seem to be an issue since it is implemented like this everywhere else.

(Also I think "Replace" rather than "Replace with" is better as in "Search" rather than "Search for".)

It's semantically wrong. "Search 'foo', replace 'bar'" is not the same as "Search 'foo', replace with 'bar'". In the former case, I'd expect "bar" to be replaced, not "foo".

Again, I think "More" and "Less" are obvious from the context (and if not, all it takes is an innocent press).

Well, this does again not help with the accelerator problem.

But you could choose other accelerators elsewhere, or?

And you also don't ask "Expand to what?", "Minimize to what?"

Expand this, minimize this. This ellipsis is completely transparent in context.

I guess by "this" you mean "this search bar". But then "More of this" seems fine as well.

[racoon]

Replying to spitz:

Replying to racoon:

(Also I think "Replace" rather than "Replace with" is better as in "Search" rather than "Search for".)

It's semantically wrong. "Search 'foo', replace 'bar'" is not the same as "Search 'foo', replace with 'bar'". In the former case, I'd expect "bar" to be replaced, not "foo".

True. But it's still not used anywhere else. If people are familiar with the meaning of "Replace" in a search dialog, then using it is shorter than "Replace with".

[racoon]

Replying to spitz:

Replying to racoon:

Descriptiveness ist only one aspect. I find many search bar implementation not very descriptive but that is no issue because they are used so often. Once you have figured it out, you are happy that it takes so little space. Also, tooltips go a long way for those who can't figure it out.

I do not see how we gain any more space with your suggestions. But we lose accessibility (both in cognitive and in motorical terms).

For example, space is gained by removing "Search" and "Replace with" or even only the "with" and by using "Less" instead of "Minimize"

[Juergen Spitzmueller]

Replying to racoon:

I think people are familiar with search bars/docs (it's not a dialog, I think).

This is a plain guess.

Search: Alt+s
Replace: Alt+l

Doesn't work here. Maybe a macOS issue.

Maybe. Cannot test.

I just pointed out that it doesn't seem to be an issue since it is implemented like this everywhere else.

"everywhere else" strikes me a bit overstated. From the two apps I know that use such bars, one (Qt Creator) has labels, the other one (Firefox) doesn't. And the former is much closer to LyX, as Firefox obviously is not a tool for editing (and it therefore only has one input widget, not two to toogle between).

And of course it is an issue for people working with the keyboard.

But you could choose other accelerators elsewhere, or?

The range of available accelerators is extremely limited in that case. I had to try long to come up with a free accelerator for every widget on the dock.

I guess by "this" you mean "this search bar". But then "More of this" seems fine as well.

More of this search bar? Come on.

[Juergen Spitzmueller]

Replying to racoon:

For example, space is gained by removing "Search" and "Replace with" or even only the "with" and by using "Less" instead of "Minimize"

So like 5mm more space for the already long enough search input widget?

[racoon]

Replying to spitz:

Replying to racoon:

I think people are familiar with search bars/docs (it's not a dialog, I think).

This is a plain guess.

Search: Alt+s
Replace: Alt+l

Doesn't work here. Maybe a macOS issue.

Maybe. Cannot test.

I just pointed out that it doesn't seem to be an issue since it is implemented like this everywhere else.

"everywhere else" strikes me a bit overstated. From the two apps I know that use such bars, one (Qt Creator) has labels, the other one (Firefox) doesn't. And the former is much closer to LyX, as Firefox obviously is not a tool for editing (and it therefore only has one input widget, not two to toogle between).

Yes, definitely an overstatement. I should have said almost everywhere else I tested. For example, Libre Writer, Visual Studio Code, Pages, MS Word.

And of course it is an issue for people working with the keyboard.

Here is how the issue is resolved, and I think nicer than with accelerators: Cmd+F focuses on the Search field, Tab from there focusses on the Replace field.

But you could choose other accelerators elsewhere, or?

The range of available accelerators is extremely limited in that case. I had to try long to come up with a free accelerator for every widget on the dock.

I guess by "this" you mean "this search bar". But then "More of this" seems fine as well.

More of this search bar? Come on.

I think it's good enough.

[racoon]

Replying to spitz:

Replying to racoon:

For example, space is gained by removing "Search" and "Replace with" or even only the "with" and by using "Less" instead of "Minimize"

So like 5mm more space for the already long enough search input widget?

At least 5mm, I'd say...

[racoon]

Replying to racoon:

Replying to spitz:

Replying to racoon:

For example, space is gained by removing "Search" and "Replace with" or even only the "with" and by using "Less" instead of "Minimize"

So like 5mm more space for the already long enough search input widget?

At least 5mm, I'd say...

No, seriously, I think it's worthwhile because one might work with a narrow window, having placed others beside.

[lasgouttes]

Please make sure that we do not get into too heated arguments, we do not need them ;) The fact is that Jürgen has the privilege of the implementer, so he is the one who gets to choose the design. All we can do to help is to point to relevant possible solutions, but at the end one cannot force someone else to implement something.

[racoon]

Replying to lasgouttes:

Please make sure that we do not get into too heated arguments, we do not need them ;) The fact is that Jürgen has the privilege of the implementer, so he is the one who gets to choose the design. All we can do to help is to point to relevant possible solutions, but at the end one cannot force someone else to implement something.

Oh, I did not perceive this as heated. Only as exchanging reasons (though sometimes a bit quickly maybe).

I don't have the illusion of any privileges or decisions to make. I would not even call myself part of the "LyX team". I am just trying to contribute a bit here an there.

[lasgouttes]

I prefer to say something before it gets really heated!

BTW, of course you are part of the LyX team.

[lasgouttes]

I have 3 issues with the current code (see screenshot above):

1. when using Ctrl-f the first time, the widget has an empty line below; this disappears if I use maximize, then minimize
2. when using Ctrl-f the first time, I see a "Search string not found!" message in the status bar (I use find as you type)
3. There is no separation between the dock and the status bar; the issue also exists with other panes with this theme (Ubuntu), but it is more annoying here.

All in all, the new search bar is really great. I like the new indicators, although it is difficult to guess which is which and the menu is not really discoverable. You mentioned that the menu is accessible by keyboard, how can it be done?

[racoon]

Sorry, I came in between. JMarc meant his screen capture, obviously.

In my screen capture, which is of course an extreme case, working in the work area is still quite feasible but searching gets tricky due to the limited space. Every extra bit would be nice to have.

BTW, being part of a team I connect with a certain feeling of belonging. I don't have that. But it's okay for me. It's partly my voluntary decision.

[racoon]

Replying to racoon:

Replying to spitz:

And of course it is an issue for people working with the keyboard.

Here is how the issue is resolved, and I think nicer than with accelerators: Cmd+F focuses on the Search field, Tab from there focusses on the Replace field.

By the way, this will free the accelerator 'l' for "Less".

[Juergen Spitzmueller]

Replying to lasgouttes:

1. when using Ctrl-f the first time, the widget has an empty line below; this disappears if I use maximize, then minimize

I cannot reproduce this. Maybe Qt version related? I use Qt 5.15.2 here.

2. when using Ctrl-f the first time, I see a "Search string not found!" message in the status bar (I use find as you type)

I try to address this. Should not be too hard.

3. There is no separation between the dock and the status bar; the issue also exists with other panes with this theme (Ubuntu), but it is more annoying here.

This also is probably theme dependent. I have a clear separation here, see
​​https://wiki.lyx.org/LyX/NewInLyX24#toc12

I am not sure what to so here.

I like the new indicators, although it is difficult to guess which is which and the menu is not really discoverable.

I tweaked the icon to make it a bit more apparent.

You mentioned that the menu is accessible by keyboard, how can it be done?

No, the options are accessible (by Expanding, Selecting, Minimizing). We can add an accelerator to the menu, but then (1) how to communicate it, and (2) this will save only one key stroke

[Juergen Spitzmueller]

2. when using Ctrl-f the first time, I see a "Search string not found!" message in the status bar (I use find as you type)

I try to address this. Should not be too hard.

Should be fixed at [b6945764a4/lyxgit]

[Juergen Spitzmueller]

Replying to racoon:

Oh, I did not perceive this as heated. Only as exchanging reasons

Me, too, for that matter. However, it seems important not to miss the point where discussions run in circles. And IMHO we have passed this point (once more).

[racoon]

Replying to spitz:

Replying to racoon:

Oh, I did not perceive this as heated. Only as exchanging reasons

Me, too, for that matter. However, it seems important not to miss the point where discussions run in circles. And IMHO we have passed this point (once more).

I do not even see a circle. I only see difference branches being taken up again to add to the reasons for and against. But I take it that at least further discussion isn't desired. Which is of course fine. I don't want to waste my time.

[superkryo]

Replying to spitz:

Pushed at [a7e6dcc31d/lyxgit].

Would be nice to invert "search-options.svgz" for dark mode. Thanks

[lasgouttes]

Replying to racoon:

In my screen capture, which is of course an extreme case, working in the work area is still quite feasible but searching gets tricky due to the limited space. Every extra bit would be nice to have.

I am curious: if you expand the dialog and then minimize again, does it return to the same size? In my case, it becomes nice and tight.

[Juergen Spitzmueller]

Replying to superkryo:

Would be nice to invert "search-options.svgz" for dark mode. Thanks

Done at [9ee73dbb305/lyxgit]

[superkryo]

Replying to spitz:

Replying to superkryo:

Would be nice to invert "search-options.svgz" for dark mode. Thanks

Done at [9ee73dbb305/lyxgit]

Perfect, cheers!

[racoon]

Replying to spitz:

Replying to lasgouttes:

3. There is no separation between the dock and the status bar; the issue also exists with other panes with this theme (Ubuntu), but it is more annoying here.

This also is probably theme dependent. I have a clear separation here, see
​​https://wiki.lyx.org/LyX/NewInLyX24#toc12

The URL brings me to no screen capture but only a section on "Typographic quality". So, I am not sure what it looks like. But maybe you could try one of the document mode patches on ticket #9391, to see whether your separations disappears or not. Then it might be possible to fix it for everyone uniformly on Linux.

[Juergen Spitzmueller]

Replying to racoon:

Replying to spitz:

Replying to lasgouttes:

3. There is no separation between the dock and the status bar; the issue also exists with other panes with this theme (Ubuntu), but it is more annoying here.

This also is probably theme dependent. I have a clear separation here, see
​​https://wiki.lyx.org/LyX/NewInLyX24#toc12

The URL brings me to no screen capture

Here are direct links:
​https://wiki.lyx.org/uploads/LyX/NewInLyX24/lyx-fr1.png
​https://wiki.lyx.org/uploads/LyX/NewInLyX24/lyx-fr2.png

But maybe you could try one of the document mode patches on ticket #9391, to see whether your separations disappears or not.

it looks the same with the (latest) patch applied.

it might be possible to fix it for everyone uniformly on Linux.

Sure, I am all open to that.

[racoon]

Replying to spitz:

Replying to racoon:

But maybe you could try one of the document mode patches on ticket #9391, to see whether your separations disappears or not.

it looks the same with the (latest) patch applied.

it might be possible to fix it for everyone uniformly on Linux.

Sure, I am all open to that.

I take it that by "looks the same" you mean that you have a separation line between document and status bar. Unfortunately, I think that makes it a bit harder to find a uniform solution (because for others the separation line disappeared). But maybe there is a way to check for the existence of a separation line or it's look.

[Juergen Spitzmueller]

Replying to racoon:

I take it that by "looks the same" you mean that you have a separation line between document and status bar. Unfortunately, I think that makes it a bit harder to find a uniform solution (because for others the separation line disappeared).

I am not sure if I would call it "separation line". It's a sort of frame (as you can see in the screenshots). In any case, it does not change with the patch.

[racoon]

So, you cannot even click on the scrollbar with the patch when the window is maximized and the mouse pointer on the very right edge of the screen because you only click on the frame.

[Juergen Spitzmueller]

You lost me. I thought we were talking about the separation of the bottom dock widgets to the status bar.

[racoon]

Replying to spitz:

You lost me. I thought we were talking about the separation of the bottom dock widgets to the status bar.

For other people the separation line was part of a frame that goes around the whole work area including the scroll bars. I thought that was the frame you referred to.

[Juergen Spitzmueller]

No. The context we haven been discussing here is the search widget and its separation from the status bar.

[racoon]

Replying to spitz:

No. The context we haven been discussing here is the search widget and its separation from the status bar.

I know. But it was related via the patch on the other ticket you tried. That is why I thought that the "frame" that came up there might be the same "frame" as you mentioned. Different context but same thing. Apparently that wasn't the case. But it might well have been.

Anyway, maybe you could add your screenshot with the document mode patch from the other ticket (but with the search widget hidden so one sees the transition from status bar to work area) to the other ticket.

[Juergen Spitzmueller]

Replying to racoon:

Anyway, maybe you could add your screenshot with the document mode patch from the other ticket (but with the search widget hidden so one sees the transition from status bar to work area) to the other ticket.

In this case, I also see the frame disappear, as the other reporters.

[racoon]

I see. So frame dividing workarea and status bar and frame dividing work area and dockwidget are not the same. Thanks for testing.

[ps]

2.4 beta is out.