[wkearney99]

When using ctrl-L to bring up the Analyse and Add Links dialog it would be nice if the first field (for the URL links) could IGNORE the tab key as input, and use it instead to move to the next UI item.

Once out of the URL field the tab key works as expected, moving from one UI element to the next, as does shift-tab moving backward. Until the URL field...

Are there some scenarios where it'd be necessary to recognize a tab key in this field?

Not sure how readily the dialog box code would allow for this.

[pspzockerscene]

While I get your point, that text-field is supposed to be freely editable.

My personal opinion:
I wouldn't add more "smart behavior" to it.
However, if that is e.g. also the typical browser-behavior of such fields, it might make sense.
I'll leave this one open for further feedback of users and team members.

[wkearney99]

Originally Posted by pspzockerscene

While I get your point, that text-field is supposed to be freely editable.

My personal opinion:
I wouldn't add more "smart behavior" to it.
However, if that is e.g. also the typical browser-behavior of such fields, it might make sense.
I'll leave this one open for further feedback of users and team members.

I get the notion of avoiding special-case handling of fields.

I understand where the pasting process might be bringing in text that contained whitespace characters like multiple spaces, tabs, etc. But is it the same code that handles keypresses? I can understand that code complexity sometimes makes things difficult to work around. I don't know if that applies here.

I'll ask, in what scenarios would someone genuinely NEED to be pressing the tab key while in that field?

My use-case is I've got a URL in the clipboard (one that doesn't lend itself to automatic linkgrabbing), I press ctrl-L, ctrl-V to paste into the URL field and then, naturally, want to press tab-tab to get to the Package Name field.

While we're discussing this dialog box... I get why processing Enter as a [Continue] button isn't necessarily a good idea. Though I wouldn't mind if a modifier-Enter existed to do the same (shift|alt|ctrl). I can't recall if there's an universally accepted keystroke for dialog box OK action. That's perhaps a separate suggestion, but seems relevant to mention it here.

[pspzockerscene]

Originally Posted by wkearney99

I'll ask, in what scenarios would someone genuinely NEED to be pressing the tab key while in that field?

We've just discussed this internally and also got to this point.

So afaik this shall be changed to "tab to next field"with the next CORE-update but please wait for further feedback of other team members before taking my words.

[Jiaz]

With next update, in this dialog, the textfield will not support tab but traversal the focus instead/"tab to next field"

[pspzockerscene]

Bitte auf das nächste CORE-Update warten!

Please wait for the next CORE-Update!

Wartest du auf einen angekündigten Bugfix oder ein neues Feature?
Updates werden nicht immer sofort bereitgestellt!
Bitte lies unser Update FAQ! | Please read our Update FAQ!
---
Are you waiting for recently announced changes to get released?
Updates to not necessarily get released immediately!
Bitte lies unser Update FAQ! | Please read our Update FAQ!

-psp-

[wkearney99]

+1. Thanks guys. I continue to be amazed how many little things JD does so well. It's rare to find something that could use tweaking. Glad to do my part to help.

[pspzockerscene]

Update is live.

[wkearney99]

Nice. Though I'm not sure how the initial keys in the dialog are set up. In the past I've clicked manually in the package and used the keyboard down-arrow to bring up the list of recent package names and then used the backspace key to begin editing the string.

Now the first use of the tab key activates the [Continue] button. And tabbing again loops through to the URL field (and now ignores tab as input the field) and then to the package name.

Down-arrow does move to the package title, but not into the field itself, not until you tab again. At which point it selects all the text in the field.

It seems a little strange that the first tab to the package name isn't "into" the field. I can't say that it's wrong, but do find it sort of... off somehow?

So my follow up here is on two points, one being where the first tab "lands" on the dialog. And the second being how tabbing through fields doesn't go "into them" first.

I'd love to hear thoughts on how/why this was the chosen method. Not saying it's wrong though, just a bit... unexpected?

Tangentially, this is where mobile tablet/phone interfaces to some kinds of forms online is an aggravating experience. Trying to tap INTO fields sometimes does/doesn't bring up proper editing features (and then there's the hassle of the virtual keyboard's input not being able to move between fields and/or complete the dialog). I wonder if there's a similar UI methodology at play here?

I'm old enough to remember when there were no mice, everything was keyboard driven. It had it's pros/cons, but for really repetitive tasks it was often much quicker than using a mouse pointer.

Anyway, that's just some thoughts on this. I'm ok with taking the 'win' on my initial tab question. So, thanks!

[Jiaz]

Originally Posted by wkearney99

Now the first use of the tab key activates the [Continue] button. And tabbing again loops through to the URL field (and now ignores tab as input the field) and then to the package name.

Hmm, cannot confirm/reproduce. For me tab key is forward to next element. Shift+tab is backwards.
I can't make it work/fail differently. always correct order.
Maybe you can find a way to reproduce it?
What OS are you on?

Originally Posted by wkearney99

It seems a little strange that the first tab to the package name isn't "into" the field. I can't say that it's wrong, but do find it sort of... off somehow?

Right now, first focus goes to the text field, send focus into the drop down selection. of course I can change, so first focus will directly go to drop down selection.

[wkearney99]

Originally Posted by Jiaz

Hmm, cannot confirm/reproduce. For me tab key is forward to next element. Shift+tab is backwards.
I can't make it work/fail differently. always correct order.
Maybe you can find a way to reproduce it?
What OS are you on?

Windows 10 Pro.

Right now, first focus goes to the text field, send focus into the drop down selection. of course I can change, so first focus will directly go to drop down selection.

It's the combination use of the whole 'text field' as a drop-down, and also as an editable text field. I think it would be helpful if a drop-down selection was made and then the pointer entered the text field.

As in, cltr-l with a URL (the dialog appears)
tab (enters the URL field)
tab (moves to download location drop-down)
tab (moves to package name drop-down)
arrow-down (shows drop-down list of previous package names)
return (selects the first drop-down item)

Here it seems like it "should" enter the field and then select the text in the field. Instead it's still in the drop-down mode. I have to press tab again, and then right-arrow to get to the end of the selected text.

But try the same thing in the download path field above it.

ctrl-L with a URL
tab (enters the URL field)
tab (moves to download location drop-down)
down-arrow (shows a drop-down list)
return (selects the first drop-down item)

now press tab. it jumps to the [Browse] button?

I respect that there is some complicated UI handling going on here, it's just sort of not-consistent in how the fields are handled?

[pspzockerscene]

Originally Posted by wkearney99

Now the first use of the tab key activates the [Continue] button. And tabbing again loops through to the URL field (and now ignores tab as input the field) and then to the package name.

I will focus only on this one for now.
I think I can see how this can happen:
See by default, we got a pre-parser which will pre-analyze the content in your clipboard and display all links line by line in the add links dialog.
While this analyzation is going on, the field for those links is locked/greyed out and is not part of the tab-able fields.
Now my theory is that exactly at the moment when you pressed tab, the "Continue" button got selectable while the pre-parser wasn't finished yet which made it jump to that field.

Please disable the following advanced setting for testing, restart JD and check if the add links dialog behaves in a different way:

LinkgrabberSettings.addlinkspreparserenabled

[Jiaz]

Reason is that the default focus lies with the cancel button and delayed validation then finds links in list (due to pre-parser enabled) and auto switches from cancel to okay/continue button. Idea was that once links are pre-parsed/filled, user only has to hit enter key.

Now question is, what would be best solution. Always auto focus on text field by default? or what other good ideas do you have?

[pspzockerscene]

@Jiaz
So this means deactivating the pre-parser will fix the problem for this user?
In that case, I'd just change nothing since this is a thing which has been reported by exactly one user.
Alternatively, waiting a longer time after opening the add links dialog (with pre-parser enabled) should also "fix" the problem for him.