macro dialogs to be always on top

[marilmanen]

This just a change proposal to make dialog and list_dialog pop-up windows to be always on top. Sometimes it's just annoying to search for the dialogs and I can't figure out when always on top property could be an issue for those dialogs.

[grege2]

Interesting idea. On the one hand, I confess that sometimes when I mark a Find or Replace Dialog box as "Keep Dialog" it gradually drifts behind other stuff and then you have to go hunting for it, if you've even remembered it was a Keeper. But on the other hand ... dialogs that force themselves to be "on top" can be a huge annoyance .. like the Mac generic OS Help window, which is always on top, and consequently generally hiding what you were getting Help on on the first place. I would be careful in forcing dialogs to be on top. Maybe it could be a Preference setting ?

[tksoh]

@grege2 On Find or Replace Dialog, I'm not sure what you meant by 'drifting', but the dialogs are supposed to tag alongside their parent window when we bring the window to front. I double checked this behavior on Windows 10 and Linux Mint. Is this not true on your system?

In any case, even if the Find/Replace dialog somehow 'drifted' behind other stuff, you can always press ctrl-F/R in the editor window to bring them up again. I wonder if you are not seeing the same.

[eteran]

Interesting idea, I can certainly make this an optional feature that is off by default and enabled by a setting in the config file.

[grege2]

Hi @tksoh Sorry I should have highlighted more that I'm on Mac. No my Find or Replace (or any non-Modal Dialog, like the Macro Command editor) is completely divorced from the main window, and doesn't come forward when you raise the main window. If you invoke it again with Cmd-F it does come up, but with an empty search field, so if you want to Search Again with the previous search term you have to Up-Arrow to recall it. Not a big deal.

I should test again with the latest build, there's been a bit of work on all this lately.

[grege2]

Hi, I just downloaded and built branch "alternate-nc-desktop-detection" which seems to only an hour old. The Mac Find dialogs still behave the same, ie. they do not come forward when the main window is raised.

I also tested the same with the current master branch.

FYI, I'm getting this stdio/stderr msg at startup:
"Populating font family aliases took 351 ms. Replace uses of missing font family "Monospace" with one that exists to avoid this cost."

(By the way, the version in the Help/About-Nedit-ng dialog is still 2020.1, and no branch id like 610b002, I hope I'm doing this the right way).

Ciao.

[eteran]

@grege2

That branch isn't intended to fix that problem. It's looking to solve an issue that @anjohnson is experiencing with nc on macOS.

As for the font messages, that just means that something is trying to use the font Monospace, but that doesn't exist on your system so it's using a substitute somewhere.

As for the about dialog, if you are building from a git clone, and do a cmake after, then you should see a branch id in the help dialog for sure. Just make sure to re-run cmake after you pull.

[tksoh]

@grege2 I am rather surprised to hear that dialogs (not app window) do follow their parent windows on Mac OSX. I wonder if other apps on the platform are the same on this aspect, or if this is something unique to Qt on OSX. Maybe @eteran knows better ;-)

[tksoh]

As for the font messages, that just means that something is trying to use the font Monospace, but that doesn't exist on your system so it's using a substitute somewhere.

Perhaps that message can be simplified to avoid alarming users unnecessarily?

[eteran]

Perhaps that message can be simplified to avoid alarming users unnecessarily?

I'd love to, but it's produced by Qt itself. So my only real option is to find a way to avoid it.

I think I can do it, just gotta figure out the best way.

[grege2]

@eteran Thanks for the tips on Github and branches, I am not very savvy there. I will test it again more carefully.
Re the fonts message, it didn't alarm me, since I was seeing all the discussion here about such things, but I guess it could confuse someone new to nedit-ng.

@tksoh I will think about what else does/doesn't "follow" ie. raise nicely. But the only thing that comes to mind is nedit-ng. Maybe I could download some demo Qt app that has a mix of dialogs.

[marilmanen]

One possible solution would be to add always on top as a optional argument to the dialog and macro_dialog commands. This would allow maximum flexibility. Many of the macro commands already support optional arguments so this could be easy to implement.

[tksoh]

If you invoke it again with Cmd-F it does come up, but with an empty search field

IMO, this is probably not the best behavior. Perhaps we should detect if the dialog is already up, and just place the focus on the dialog without clearing the search string. Something to consider on your TODO list, @eteran ?

[eteran]

@tksoh Hmm, I actually disagree a bit.

I think that when the user types Ctrl-F, they should be able to just start typing when they want to search for and hit enter. A compromise would be to have it focus on the dialog and select the text (that way if they type any characters, it will automatically replace the text with what they typed).

But... another consideration is that the current behavior is in line with NEdit5, and as we've discussed, preserving classic behavior at least for the current release is desirable.

I can say that @marilmanen's suggestion of an extra parameter also seems like a decent idea since it is a non-breaking additive change. Existing users wouldn't see any change in behavior at all.

[tksoh]

@eteran No problem. I am not too upset if we don't change this, since this is how nedit has operated for so many years (thanks for reminding me ;-)

Admittedly this suggestion was merely a workaround at best to address the issue where somehow the dialogs don't tag along their parent windows. So perhaps that's the real issue that needs to be addressed.