Modal dialogs as in NEdit

[eteran]

Modal dialogs as in NEdit

[agarrubio]

#=============== Instructions ==========
1) Install macro "jump to grep"
2) Create document with "Sample text"
3) Start macro "jump to grep"
4) On first dialog type "sub" (grep's query). Press "OK"
5) On grep's output (main window) click the line that says:
"4:sub b {"
6) On the showing dialog press "OK"
7) You should be on line 4 of your document, at 1st line of "sub b".
#=============== macro "jump to grep" ==========
# Lets you find some lines with grep, choose one with the mouse, and
# place the cursor on that line

# get the query for grep
query = string_dialog("grep query")

# filter all document through "grep -n" so that matching lines are numbered.
select_all()
filter_selection("grep -n  " query)
deselect_all()

# Wait for the user to click the desired line
dialog("Click a line. Then press 'OK'")

# Find the number of the wanted lined
beginning_of_line()
forward_word("extend")
lineno = get_selection()

# Recreate the original document
undo()

# Jump to the wanted line
goto_line_number(lineno)
#=============== end of macro "jump to grep" ==========
#=============== Sample text ==========
sub a {
    # do a
}
sub b {
    # do b
}
sub c {
    # do c
}
#=============== end of Sample text ==========

[eteran]

Just for clarity, I believe you mean "non-modal", as in you can interact with other windows while the dialog is up. Correct? (A modal dialog is a window that forces the user to interact with it before they can go back to using the parent application).

Anyway, yes there were a couple of cases where I made a judgment call on making things modal or not, if you can point to specific examples where it either interferes with the workflow or simply doesn't work. Please be as specific as you can. It seems that the "Macro Commands" is an example that you've already bumped into, I'll look at that.

Can you provide examples of broken macros? Something I can minimally reproduce and debug?

If you could let me know more specifics about the dialog quirks you're seeing such as the ones that not getting focus, when enter isn't triggering the default button, etc... and what I can do the reproduce them.

Thanks

[agarrubio]

My mistake. You are right: the term is modeless.
I already mentioned "search" dialog, and the same goes for "replace". With "Shell menu" my use would be the same as with "Macro commands". Besides, as I've said, it is common practice in other editors I use.
In the following comment I am including an example of a macro that works in nedit, but fails in nedit-ng,

[eteran]

I'll take a look at the macro once you post it. Find and Replace dialogs should be deliberately nonmodal, if they aren't, can you provide some details about your system such as the desktop environment and/or flavor of linux?

We'll get this sorted out :-)

[agarrubio]

I was mistaken again: Search and Replace are nonmodal. However, if I open them from the "menu", they get focus, if I open them with "Ctrl-F" and Ctrl-R", they don't.
Tested on:
Linux Mint 17 Qiana, aca ubuntu 14.04
Desktop: cinnamon

[eteran]

Interesting.

OK, there a few areas of concern here, but I'll do my best to work through them. Here's what I think this issue covers:

• Some dialogs do not have the Enter key trigger the default button
• Some dialogs are modal but would be better of non-modal (anything where the user might want to edit/test/repeat such as scripts and macros)
• Some dialogs are not receiving focus when launched (from menu or keyboard shortcuts)
• Dialogs from scripts may require user interaction with the text, and therefore should not be modal (this one might be complicated...)

Did I get everything?

[agarrubio]

Precisely that! Many thaks!

[agarrubio]

Dear Evan!
I have tested every menu shortcut. These do not behave as the menu itself:

• Ctrl+F Find (no focus)
• Ctrl+Shift+F Find (no focus)
• Ctrl+R Replace... (no focus)
• Ctrl+Shift+R Replace... (no focus)
• Alt+M Mark (opens Macro Menu, instead)
• Ctrl+Enter Execute Command Line (wrong label. It should say "Ctrl+KP Enter")
• Alt+R Filter selection (does nothing)
• Ctr+. Cancel Shell Command (does nothing, but it does work to "Cancel Learn" under "Macro")
• F1 Help (does nothing, does not even show the message)
• Ctrl+Alt+L Insert Form Feed (can't test. Intercepted by my desktop)

Hope it helps!

[eteran]

I've edited your comments so I can check them off as I go :-). I'll explain my findings:

Alt+M is a wierd case. The UI editor for Qt keeps forcing the name of the macros menu to be "&Macros" which makes it hijack the shortcut. I manually updated the UI file which does the trick for me locally. But I'll have to be careful when using the UI editor in the future.

Ctrl+Enter I think is just a change in nomenclature. I think Qt refers to a "Return" key and an "Enter" key. I believe that the shortcut fires correctly when using the keypad though. I think this gets filed under "difference between toolkits, but tolerable"

Alt+R similar to Macros issue, Qt is messing with the shortcuts, I have manually corrected it in the source code.

F1 does nothing in my copy of nedit, and seems to work OK in my build of nedit-ng. I'll look though...

Ctrl+Alt+L I can't help what the desktop does, it should otherwise work correctly.

[eteran]

Also, for the shell command, how are you testing? If I tell nedit to run a long-winded command like:

while [ 1 ]; do echo "A"; done

I can successfully cancel it with the menu and the shortcut.

[eteran]

Anyway, I'm headed to bed soon, but I'll continue to work with you to fine-tune things so they are "just right".

I can appreciate how one of the things which makes nedit special is that once you are used to its subtleties, you really start to depend on things working a certain way! It's the reason why I did this project :-).

[agarrubio]

I tested "shell command" with "sleep 1000", However, I am now using your latest commit (7e04121 ) and cannot reproduce the problem. So, either I was wrong, or it has been solved.
Have a good night! And many thanks for your help!

[eteran]

Can please test if the latest push addresses the dialog focus problem? On my system with KDE, I have not been able to reproduce the behavior you're seeing, but I'm explicitly setting the dialog focus now.

Thanks!

[agarrubio]

Hi Evan!
In my case, from those dialogs requiring text input, these get focus:

All dialogs from "File" menu ("Open ...", etc), plus "Go to line ...", 
and "Insert Ctrl Code ..."

And these don't:

"Find...", "Replace ...", "Filter selection ...", "Repeat ..."

Besides, some acelerator (Alt-R for "filter selection") stoped working

[eteran]

Can you clarify some things? Are you saying that Alt+R used to work, but doesn't in the master branch? That was one of the ones that I addressed manually to make it work (mentioned in this comment #43 (comment)).

Are you sure you tested with the latest code?

[agarrubio]

Sorry!
Alt-R with selection, opens dialog; without it, prints 'r' to text

[eteran]

Just wanted to let you know that progress is being made on this!

I have figured out the correct way to make the script initiated dialogs non-modal (was not trivial!), and I've actually tracked down a few other small bugs which were being exercised by your test case, so I'm currently working those out.

I am hopeful to have a fix for the major issue in the near future.

[eteran]

I think it should be working correctly now! Let me know :-)

[agarrubio]

They are indeed non-modal. That helps a lot!
The Alt-R printing "r" when there is no selection, and input field not getting focus in some dialogs are still unsolved issues. Right?
Many, many thanks!

[agarrubio]

Dear Evan!
"Some dialogs are not receiving focus when launched from keyboard shortcuts."
should, indeed be:
"Some dialogs are not receiving focus when launched" (from menu or keyboard shortcuts)

[eteran]

Glad to hear that modal issue is working correctly 👍

You are correct about the Alt+R and focus issues. Unfortunately, the focus issue is one that I haven't been able to reproduce locally at all... would it be possible for you to test on a non-cinnamon desktop? I wonder if there is a weird interaction there?

[agarrubio]

Dear Evan!
I have now tested in Xfce and it is the same. The strange thing is that simple dialogs ("Goto line number ...", "Filter Selection ...") work correctly.
Now I know that the problematic dialogs ("Find ...", "Replace ...") do get focus. I discovered it with this procedure:

1. in terminal run command: sleep 10;xdotool getwindowfocus getwindowname
2. in nedit-ng open dialog (Ctrl-F)
3. Wait untill sleep ends
4. xdotool says focus is in "Find", which is the dialog

The problem is that the input field (where yo type the query) doesn't. You need to click inside.
Hope this helps!

[eteran]

That definitely helps! I can add some code to explicitly set the focus on the input box and I expect that to resolve the issue 👍

[eteran]

Hrmm, I already had some code to set the focus on the show event ... But I've just changed the order of things which MAY help. Let me know if that fixes it for you.

[agarrubio]

Dear Evan!
Sorry to tell you that I see no change. I am completly ignorant of Qt, but this might help:

QTimer::singleShot(0, line, SLOT(setFocus()));

Which I got from this post, under the answer with the most positive opinions:
https://stackoverflow.com/questions/526761/set-qlineedit-focus-in-qt

On the other hand, I'm so naive that I'm not even sure it is related.

[eteran]

Interesting. I think that would work, but maybe a bit more of a "trick" than an ideal solution.

I'm going to check in a version which has this in it, let me know if it helps, if so, then at least we know we're on the right track even if it's not an "ideal" solution

[eteran]

OK, giving that code you found a try, it seems reasonable, but we'll see if it has the desired effect.

[agarrubio]

Dear Evan:
If I open "find" from the menu, it works. If I open with Ctrl-F, it doesn't.
Because I had doubts of the previous behavior (I have poor memory), I commented out that line, and now it also fails from the menu. So I can tell that that line is progres! But the shortcut still fails.
I have the feeling that in some previous version it was like now: it worked from the menu, but failed from the shortcut.
As another attempt, I created a macro that only calls find_dialog(), which is what NEdit calls a "menu command". The behavior is the same: if I call it from the "macro" menu, it works, if I call it from its shortcut (I used Ctrl+Alt+Shift+F), it doesn't work.
So the dialog acts differently depending on the trigger.

[eteran]

That is very weird. Because the same code is triggered to show the dialog regardless of if you use a macro, the menu, or the shortcut. They are programmatically identical once it determines which function to call!

[eteran]

@agarrubio I think that I was able to fix this! Please let me know so I can close this issue :-)

[agarrubio]

Dear Evan:
I was away so I couldn't test until today. Your fix didn't work for me. However, if you add the following code at the very end of void MainWindow::action_Find_Dialog, just after dialogFind_->show();, it works:

    dialogFind_->raise();
    dialogFind_->activateWindow();
    return;

The same for the Replace dialog.
I don't code Qt, so this was a "shot in the dark". I would send you a "patch" If I knew how to do it.
Thanks for your help!

[eteran]

Hmm, it's interesting that this is required for your setup, on mine those aren't necessary at all. But I'll apply it since it seems to help.

[eteran]

Applied and pushed. Let me know if this finally fixes the issue for you.

[agarrubio]

Many thanks Evan! It works now!