Fix Find dialog pinning, blocking & disappearing

Support Resolved
1

One thing I’ve grudgingly become used to, but drives me crazy, is how the Find dialog blocks refocusing of Komodo from the task bar.

Steps to reproduce:

  1. Open any app
  2. Open Komodo and a file
  3. Find something using CTRL+F, and the find dialog pops up
  4. Focus the other app
  5. Click Komodo’s task bar item - Komodo remains hidden, but Find unhides
  6. Close Find
  7. Click Komodo’s task bar item - Komodo shows

It’s really frustrating!

I have find open all the time, and I’m swapping apps all the time, usually to the browser to test things, and I’m constantly finding Komodo won’t focus, so I have to find the Find dialog (on one of my 3 monitors) then kill it, then re-find Komodo, then carry on.

Is this a Mozilla framework issue?

The second issue is the opposite!

If you do a Find All, or Replace All, Find disappears - which is pretty much always not what I want, especially when I have it pinned. I use find all the time, and want the dialog available at all times (just like other apps).

And a Final Find Frustration, when Find does disappear, and I’m forced to revive it with shortcut keys again, what was in the input fields is replaced with whatever is currently under the caret (which may, or may not be what I want). If I’m searching for something similar, I have to click back in, open the history, click the last item, amend it, the start the whole process again. This wouldn’t happen if Find just stayed where it was.

Overall, Finding in Komodo is a bit of a fffff…faff.

I would hope that #1 could be fixed if not a Mozilla issue.
I think #2 and #3 are either usability changes, or new Preferences items.

Can Find get some love please?

Thanks,
Dave

2

Hey Dave,

I THINK 1 and 2 are related. I’m assuming that since you want to pin the find dialog so it stays open. that you have the pin icon selected. This just means “Keep find on top”. The switching applications problem it is rightly giving focus back to the find dialog as you’ve, unwittingly, asked for it to stay in the foreground relative to Komodo. I’d try disabling pin and see if that helps the 1 and 2.

For the third, I’ve filed bud 103650. I agree that’s annoying.

  • Carey
3

Hey Carey,

Thanks for the response.

Well, that being the case, I’d say Komodo’s Find dialog’s implementation of “Keep on Top” needs looking at.

If it takes focus away from the actual app, you’ve replaced one problem (ensuring Find stays focused within Komodo) with another (ensuring Komodo (rather than Find) stays focused within the OS) surely?

It’s really clear what the behaviour / hierarchy should be:

Windows
 +- Komodo
     +- Find

Not :

Windows
 +- Find
     +- Komodo

In any case, why is the Find dialog being treated as a top-level app (I can even see in the Task List) when it should be a child window of Komodo?

If there are technical limitations to this, then perhaps a simple method of flagging could be implemented to ensure Find hands focus back to Komodo if both Komodo AND Find have lost focus, but Find is focussed first:

function onBlur(event)
{
    this.focused = false;
}

function onFocus(event)
{
    if( ! this.focused && ! komodo.focused)
    {
        komodo.focus();
    }
    else
    {
        this.focused = true;
    }
}

This really should be sorted out - the current behaviour really impacts on day-to-day workflow.

Cheers,
Dave

4

And one other major issue with the current functionality, is that if Find is open, it blocks all Komodo system dialogs like…

  • Save changes to file
  • Select the files you wish to save
  • Reload changed files

…so you have to first close Find before they pop-up again.

5

(I’m assuming you’ve mapped Ctrl+F to open the find dialog, rather than the normal incremental search.)

Hrmm, odd, the find dialog isn’t supposed to be modal. The window heirarchy, as it is implemented today, should be:

Desktop
 +- Komodo
 +- Find

That is, you should be able to switch between the two at will, and interact with the Komodo window (even if the find dialog is set to pinned). At least, that’s how it behaves on my Komodo IDE, version 8.5.3, build 83298, platform win32-x86. Built on Mon Nov 18 17:03:19 2013. On Windows 7, at least, this also means that when you click on the taskbar icon and you see both windows and can choose between them.

The second issue, I guess, is that you want to be able to keep the find dialog around after it’s done its job (which is, to start a find). The relevant code doesn’t look very extensible… Might need to add a pref check there, and in the mean time use a macro that does a magical hack type of string replacement on the function to wipe out the window.close calls… :frowning:

6

Looks like you guys are getting some eyes on this bug right now. How about we do a quick Skype? Then I could show you exactly the behaviour I’m getting.

I’m on my usual email address, which is the same one as on the bug: https://bugs.activestate.com/show_bug.cgi?id=103652

7

I think you raise some really interesting point, and the question I am currently asking myself is “do we really need the find dialog to be in a dialog?”.

I’d be interested in playing a bit with the UI and seeing if we can’t have the find functionality be embedded, just like quick find. Hell the 2 could probably be merged if we do the UX right. Point being that, as Dave said, having the dialog pop up from the window kind of pulls you out of your code.

I’d need to do some mockups to see if this is at all feasible, given the substantial amount of functionality we have in the find dialog. Currently this is not a big priority for me though as I have many other things to work on. If anyone feels inclined to do a simple mockup and share it with us that’d be much appreciated.

Maybe I’ll add a section to the website where we can list simple jobs like this for those that are interested in contributing but aren’t sure what they could work on.

Dave, I have no problem jumping on Skype with you, but not sure if it’s necessary. I understand the bug you are describing, but I think this issue may need more than a simple fix (ie. we may want to make some significant UX changes).

8

I’ve also been mulling over whether find could be some other kind of UI element actually, such as a tab or what have you. I had a poke through the chrome / Find code and there’s certainly a lot of it, so refactor could possibly be a bit of a long old slog.

Totally agree on having to thrash this out before diving in, you could easily swap out one set of issues for another. I think Find is perfectly fine as a dialog for now, it’s just the focusing aspect (have uploaded a video, URL in the bug).

EDIT: Also, having find as a dialog is really useful, as you can move it to another monitor.

Regarding taking a look at things, as you know I’m all up for that!

Have some other projects to do first though, and it’s not exactly a bug, just fairly draggy UX :frowning:

Thanks for looking at this by the way, it is appreciated.

PS. Would the JS code example I posted above not provide a fix?

9

What you wrote will work fine in theory, but it’s just pseudo-code. It’s not unlikely that there’ll be a few gotcha’s along the way of implementing this. So it’s still TBD… :slight_smile:

10

Hrm. Maybe stick it in a pane/widget? That way people who really want it to be a dialog (hi Dave!) for some unknown reason can still detach the thing, whereas everybody else just gets it in the bottom of the window or something.

If you want to be really magical, have the find results just show it in the same place (and let people have multiple find widgets open).

Just thinking out loud, here, not a promise to implement anything… :stuck_out_tongue:

@davestewart: No, your code above doesn’t help, because we aren’t trying to make the find dialog do what it’s doing in your video; that’s a bug, and I can’t think of anything that would cause it. Best guess is macro or some external Windows application having a bad interaction… And I know you’ve used at least one thing that has global hooks (Direct Folders), so maybe you have more :smiley:

11

Yeah that’s what I was thinking. Though having to support multiple implementations could be messy.

12

Why would we need to support multiple implementations? In that world, we’d just be using the widget; we get the “dialog” by detatching the widget (using the existing widget detaching).

The only multiple implementation we’d have is the find bar, which we already have anyway…?

I think I’m missing something.

13

I’d want to do a bit more than just move the find dialog into a widget, that’d feel cheap and would not offer a very good UX. So the challenge would lie in coming up with a UX for the “dialog” which would work in both a dialog and widget context.

14

Hmmm… I wonder? Best thing I can do then is to start in safe mode, or kill everything in the task manager, and see how I go. Stand by…