New Address Bar / DropDown Control

[TheQwerty]

Just to have a single generic thread for this.

And a few bugs/wishes/comments to start it off:
1) On startup, paths that fit in the bar are still being scrolled to the left and are thus hidden behind the icons. See:

AB-Trimming.jpg

2) The word separators seem to be different when double clicking vs. ctrl+left/right here. Double click seems to grab the whole level, while Ctrl+Left/Right is actually looking for word breaks. I'm probably in the minority in preferring the double click way, so if you stick with actual word breaks, can we get an option or alternate shortcut for level breaking instead?

3) Any chance you're going to write your own auto-complete so that we can get rid of having two possible lists here? It would be nice if the matching MRU and auto-complete could be combined into a single list. Plus we would gain the ability to tab into the AC list then.

4) I don't use the MRU list often so hopefully someone else can comment, but I'm wondering if it wouldn't make more sense to show the matching MRU list by default (F4/Up/Down) instead of the main one? Are most people not starting by typing part of the path before accessing the MRU list?


It's looking fantastic Don! Keep up the good work!

[admin]

1) On startup, paths that fit in the bar are still being scrolled to the left and are thus hidden behind the icons. See:

AB-Trimming.jpg

-->> cannot reproduce

2) The word separators seem to be different when double clicking vs. ctrl+left/right here. Double click seems to grab the whole level, while Ctrl+Left/Right is actually looking for word breaks. I'm probably in the minority in preferring the double click way, so if you stick with actual word breaks, can we get an option or alternate shortcut for level breaking instead?
-->> = side-effect of shell-autocomplete

3) Any chance you're going to write your own auto-complete so that we can get rid of having two possible lists here? It would be nice if the matching MRU and auto-complete could be combined into a single list. Plus we would gain the ability to tab into the AC list then.
-->> I will, later...

4) I don't use the MRU list often so hopefully someone else can comment, but I'm wondering if it wouldn't make more sense to show the matching MRU list by default (F4/Up/Down) instead of the main one? Are most people not starting by typing part of the path before accessing the MRU list?
-->> rather stay with the standard

[TheQwerty]

1) On startup, paths that fit in the bar are still being scrolled to the left and are thus hidden behind the icons. See:

AB-Trimming.jpg

-->> cannot reproduce

I can't in a fresh copy either. I'll play around and see if I can pin it down.

2) The word separators seem to be different when double clicking vs. ctrl+left/right here. Double click seems to grab the whole level, while Ctrl+Left/Right is actually looking for word breaks. I'm probably in the minority in preferring the double click way, so if you stick with actual word breaks, can we get an option or alternate shortcut for level breaking instead?
-->> = side-effect of shell-autocomplete

So... does that mean it can't be changed?

New one: If the AB contains a path that would display the auto-complete list, and you open a new tab via Ctrl+T while the AB is focused the auto-complete list is displayed. Understandable but it's not desirable as it can prevent the user from knowing if the new tab was opened.

[admin]

1) On startup, paths that fit in the bar are still being scrolled to the left and are thus hidden behind the icons. See:

AB-Trimming.jpg

-->> cannot reproduce

I can't in a fresh copy either. I'll play around and see if I can pin it down.

Got it: can happen when window is maximzed on startup. Fixed.

2) The word separators seem to be different when double clicking vs. ctrl+left/right here. Double click seems to grab the whole level, while Ctrl+Left/Right is actually looking for word breaks. I'm probably in the minority in preferring the double click way, so if you stick with actual word breaks, can we get an option or alternate shortcut for level breaking instead?
-->> = side-effect of shell-autocomplete

So... does that mean it can't be changed?

Yes. Unless I write autocomplete myself.

New one: If the AB contains a path that would display the auto-complete list, and you open a new tab via Ctrl+T while the AB is focused the auto-complete list is displayed. Understandable but it's not desirable as it can prevent the user from knowing if the new tab was opened.

Will check...

[TheQwerty]

Got it: can happen when window is maximzed on startup. Fixed.

Well maybe, but my window isn't maximized on startup, so that's not the only case.

Another new one: If focus is in the AB it eats some global shortcut keys like: Ctrl+Tab or Ctrl+Shift+Tab

[admin]

Got it: can happen when window is maximzed on startup. Fixed.

Well maybe, but my window isn't maximized on startup, so that's not the only case.

Another new one: If focus is in the AB it eats some global shortcut keys like: Ctrl+Tab or Ctrl+Shift+Tab

isn't maximized: Yes, but it should be fixed in next version.

eats keys: hmmm, true and I cannot fix it All keys containing TAB are indeed eaten by the dropdown. Well, nothing is perfect. (sigh)

[admin]

New one: If the AB contains a path that would display the auto-complete list, and you open a new tab via Ctrl+T while the AB is focused the auto-complete list is displayed. Understandable but it's not desirable as it can prevent the user from knowing if the new tab was opened.

Will check...

Again I can't fix it. Arrgh. Also happens with Ctrl+A or any other key. Looks like auto-complete cannot really be recommended anymore. You have to live with some side-effects. Until I write my own...

[TheQwerty]

.... Until I write my own...

Any ideas where that's falling on the roadmap?
I'm not sure I'll be able to live without Auto-Complete for long.
I guess I'll have to look into avoiding these problems with AHK... hmm.

[admin]

.... Until I write my own...

Any ideas where that's falling on the roadmap?

Not before 7.70. I'd love to kick out the shell thing. The problem is that there are also Edit controls (not just dropdowns) with that functionality. Adding a list to them is possible but not in 30 minutes. Actually I would implement them as dropdown without arrow button probably... but there are some things to care about. What e.g. when you hit a pattern with 10'000 matches? I'd probably have to set limit somewhere... It's really a drag that that shell thing is such a drag.

[TheQwerty]

Okay here's some that should have absolutely nothing to do with the shell list, since they're both dealing with the MRU list.

Could it be made case INsensitive?

The paths aren't sensitive so it's kind of silly that just because once I type d:\... instead of D:\... that they should both be listed. Sure I can delete those entries but they'll just keep collecting.

A similar case comes with the trailing "\".

Between those two cases, I have 4 MRU entries that point to the exact same directory.

It would also be nice if there were some way to delete entries directly from the list instead of having to open the LM. Firefox can handle this and it's pretty useful.

Page Up/Down support would also be nice.

Oh.. I've always hated how these drop down lists prioritize a hovering mouse over tabs/arrow keys, anything you can do about that?

[admin]

Okay here's some that should have absolutely nothing to do with the shell list, since they're both dealing with the MRU list.

Could it be made case INsensitive?

The paths aren't sensitive so it's kind of silly that just because once I type d:\... instead of D:\... that they should both be listed. Sure I can delete those entries but they'll just keep collecting.

A similar case comes with the trailing "\".

Between those two cases, I have 4 MRU entries that point to the exact same directory.

It would also be nice if there were some way to delete entries directly from the list instead of having to open the LM. Firefox can handle this and it's pretty useful.

Page Up/Down support would also be nice.

Oh.. I've always hated how these drop down lists prioritize a hovering mouse over tabs/arrow keys, anything you can do about that?

All agreed.

Don't understand the last one. It seems to me that XY's dropdown lists exactly do NOT do this.

[TheQwerty]

Oh.. I've always hated how these drop down lists prioritize a hovering mouse over tabs/arrow keys, anything you can do about that?

Don't understand the last one. It seems to me that XY's dropdown lists exactly do NOT do this.

I don't know what to say, but it's happening here.

If I hover over an entry in the MRU list and then use (Shift+)Tab to navigate the list, if I pause it jumps back to the entry the mouse is hovering over.

[admin]

Oh.. I've always hated how these drop down lists prioritize a hovering mouse over tabs/arrow keys, anything you can do about that?

Don't understand the last one. It seems to me that XY's dropdown lists exactly do NOT do this.

I don't know what to say, but it's happening here.

If I hover over an entry in the MRU list and then use (Shift+)Tab to navigate the list, if I pause it jumps back to the entry the mouse is hovering over.

Whoops, I misread your statement of hate. I will make that configurable.

[TheQwerty]

One thing you might want to reconsider is the use of Home/End to navigate the list. I had originally had them in that previous list of requests, but edited them out when I realized it would conflict with navigating the edit box.

So I'd instead suggest Home/End don't work in the list (only the edit). If you want to maintain the new functionality consider Ctrl+Page Up/Down instead.


And I'm still getting the odd bug where the path fits in the control but is being pushed under the icon on startup. It seems to be related to having Auto-Synchronize Tree turned off.
From a fresh install run the following script (which incidentally crashes XY here but still works):

Code: Select all

::GoTo("<xypath>");#488;#182;#190;

Aside from that it's still looking great, Don!

[TheQwerty]

Okay, found a new bug.

This one is a bit interesting when comparing the MRU with the SHAutoComplete (SHAC).

When there is not enough room below the edit box to show the list, both correctly show the list above.

• As the value changes and the lists filter accordingly; if the list becomes:
• Smaller but remains too large to fit below the edit box:
  • SHAC keeps the list touching the edit control by shrinking the list from the top.
  • MRU shrinks the list from the bottom thus creating a gap between the two. See image below.
• Small enough to fit below the edit box:
  • SHAC moves the list below.
  • MRU leaves the list and gap above.

Now I think the gap issue should be fixed so that the list and edit box are always touching and clearly connected. However, I'm undecided on whether the list should be allowed to switch positions after creation. I find the SHAC way a bit disorienting, but is it more confusing if the behavior is not standard?

Screenshot - 10_6_2008 , 11_30_10 AM.png