Alexey-T
Qt5: Find dialog is opened as a "top level" window
I have two issues with the Find dialogue:
If I have immediate search (Im) selected then the search starts immediately when I start typing. While this is strictly in accordance with the requested action it s somewhat distracting. For example if I enter "Search" then firstly the next "S" is found, then the next "Se" and so on. I would suggest starting "immediate" after a minimum of three characters is entered to avoid this. This may also be a partial fix for #5473 :)
The find widow is opened as a "top level" window, by which I mean that the window will appear over other unconnected windows.
Can it be opened as a 'sibling' of the Cudatext 'parent' window?
Do you suggest to ignore the typed text when len<=2? bad! identifiers of len=1 also exist. so I cannot change it. To avoid search for 'S' and 'Se' (in 'Search') you can decrease the option "find_hi_max_lines". when option is e.g. "100" all documents with line_count > 100 will be searched by timer (typing 'www' fast will search only for 'www').
Can it be opened as a 'sibling' of the Cudatext 'parent' window?
Form style should be "stay on top of ALL windows" if Cud's main window has 'View / Toggle always on top" checked. do you have it checked?
Do you suggest to ignore the typed text when len<=2?
Yes, exactly, I do not want to search for a single letter, ever, ( and if I should want to I can press Enter :) This applies to any document, even short ones.
Form style should be "stay on top of ALL windows" if Cud's main window has 'View / Toggle always on top"
Not necessary in linux, I can simply toggle "Always on top". Don't know about windows. In either case it should be sufficient to keep the Find window always on top of the Cuda window and not on top any others (see screenshot above) PS: I do not have View>Always on top selected
Yes, exactly, I do not want to search for a single letter, ever, ( and if I should want to I can press Enter
Ok example is SublimeText, it searches for single char. VSCode too. they do not have an option for this, I guess.
Not necessary in linux, I can simply toggle "Always on top". Don't know about windows. In either case it should be sufficient to keep the Find window always on top of the Cuda window and not on top any others (see screenshot above) PS: I do not have View>Always on top selected
I guess it is the Lazarus Qt5-version bug, that on-top works like system-on-top. I will study it.
Ok example is SublimeText, it searches for single char. VSCode too. they do not have an option for this, I guess.
May be, I don't use either. There are plenty of examples where find works after the third character is entered. :)
on-top works like system-on-top.
Yes, I see that the find window is set as "Always on Top" in the window manager, and I can reset it to "Normal". But that will put the window below Cuda, which is no use at all. Don't know about Lazarus :(
From what I can remember, every app with find-as-you-type I know process from the first char and I think that's right. Including web browsers, the most universally popular software class with find-as-you-type.
I'm not against providing an option for those who don't like it, the more customizing options the better, but surely current behavior should remain as default.
2 issues were reported:
- wish to only search (by 'Im' option) from input len = 3 chars. declined, sorry. I don't think we need an option, too many opts already.
- report about incorrect work of 'stay on top' style of the Find window. it is the Lazarus issue so I put the lebel 'Lazarus/FPC issue'. will report it to Lazarus team.
@AndyM48 - please try to use on this cases cmd Find in Lines (part of CudaExt), here I have minimum 3 characters… works fine for me the years… some options available… (on my case - dedicated Ctrl+Q for start to search… floating dialog, vs standard Find/Search is docked for me)
Cannot find 'Find in Lines'?
I prefer floating find dialogue to docked, hence my issue.
'Find in lines' - can be found in the Command Palette when plugin CudaExt is installed.
This 'find in lines' dlg can be DOCKED into the top or bottom of the main Cud window. Press '=' button in 'find in lines', you will see that option.
I don't know pascal I'm afarid, but is this not an issue with FindWindow.Parent:= Self or similar, instead of FindWindow.Parent:= MainWindow or similar?
I see that this occurs with all the sibling windows opened by CudaText.
No, it is not the problem with FindWindow.Parent. It is problem of the 'top most' window style, how it works.
report about incorrect work of 'stay on top' style of the Find window. it is the Lazarus issue so I put the lebel 'Lazarus/FPC issue'. will report it to Lazarus team.
Is there any progress from the Lazarus team on this issue? If it is not possible to make the 'find' window a sibling of the main Cuda window then I might suggest an alternative approach.
Is there any progress from the Lazarus team on this issue?
not yet. I just posted additional demo to the same Lazarus bugreport: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40933
The Pascal/Lazarus report does not seem to have offered any solutions to this problem:
Would you consider this solution? Simply close the Find window when both Cudatext and the Find window lose focus. It is simple enough to reopen the Find window, with exactly the same contents, if it is needed, by either clicking on the Find button or Ctrl-F. Note that it is necessary to close the Find window since minimising it and the using Ctrl-F or the Find button to raise it has unexpected consequences.
on opening the Find dlg, rules for "find_suggest_" options apply / options are changed too for current document (it can be picture or binary viewer or too big text file). so sometimes it's not easy to reopen Find dlg with the same text and options (options change too).
But that is an option, which can be selected/changed. Not that I am only referring to the Find window.
If you test it on Windows you Will see the topmode works ok? So its much better to fix it in the gtk2 and-or qt5 widgetset.
Honestly, I doubt that it is a problem with gtk or qt, since, apparently/as far as I know, it does not affect any other programmes. I would imagine it is a problem with how Pascal/Lazarus interacts with gtk/qt. Either way, since I will not be going back to windows, and there is a possible fix for the problem, I would prefer that Cudatext worked on Linux.
Please read this knowing that I really like Cudatext and appreciate all your hard work.
May be add what I suggested as an option??
You misread this. I mean "problem in gtk-qt widgetset (ie wrapper) in lazarus". Lazarus issue.
Is there any reason that this fix would not work in the qt6 version (Artix Linux Cudatext-qt6 v 1.215.6.0)?
you can see in formmain.pas methods AppPropsActivate / AppPropsDeactivate, that I supported qt5+qt6:
{$if defined(LCLQt5) or defined(LCLQt6)}
//workaround for issue https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40933
FPrevFindDlgVisible:= Assigned(fmFind) and (fmFind.Parent=nil) and fmFind.Visible;
if FPrevFindDlgVisible then
fmFind.Hide;
{$ifend}
i don't have qt6 installed on my work pc, i don't want to pollute the pc, so cannot test.
Unfortunately our "fix" seems to have the side issue of fixing the position of the find window so that I can no longer pull it into position.