I guess this is not really a bug, but it bugs me. :D
Why aren't the tab key presses indexed to a proper order? Here's what I mean:
Go to a panel like the Objects|Object Scale. Click in the Minimum scale text entry box and type in a value. Now press the tab key. This takes you to the slider for minimum scale. Why? I just typed in a minimum scale.
Now press tab again. It the "Import from text file..." gets focus. No only is that redundant (again, I already entered a minimum scale value) but it is visually out of order (usually it would be left to right, then down, like x/y/z entry boxes.)
What I would like is to click in the minimum box, make my entry, press tab and find myself in the maximum field.
Maybe I'm missing a work-flow feature, but if not, this should be a simple change or code cleanup task.
I believe its just part of the operating system and how it interprets things. Tab switches to the next possible input field designated, and planetside has it set to the sliders cause some people might use them. It wouldn't make sense to have tab ignore possible places to input.
What if I was using the slider in min because i just wanted to tweak it, but in max i wanted to type something in?
As for not in proper order for the last one to set animation key/import from file, animation keys must be set AFTER modifying the data inside. So it makes sense to be able to enter your data, then tab to animation key and set it. As then terragen knows what to animation between, otherwise it doesn't animate it properly.
I'm not sure what compiler/IDE the Planetside people are using, but with Microsoft Visual Studio you can control the TabIndex property for each control (button, textbox, etc.) The operating system does have a tab hierarchy, but it is programmed too.
I believe the TabIndex sequence is set by the object creation order, but as I mentioned, it can be modified to a more efficient order.
The point is, the text entry box is a mouse click/keyboard event and the sliders are usually mouse driven. You make a decision on the type of data entry for one field and when satisfied you go to the next (I like using the tab key to do that.)
So if the TabIndex for Minimum scale is 58, setting the index to 59 for Maximum scale would accomplish this.
Of course there's occasions where you use a slider and then decide to fine tune with the text entry so a shift tab to back up would work. But I suspect that happens less often than a quick click/enter/tab/enter sequence for the example I mentioned for max/min entry.
So it's not a bug, but an annoyance, at least for me.
I know, which is why I believe planetside has set it up the way they want. The fact that they tab in order properly through the buttons in a somewhat logical order shows they spent the time to set that order.
You could always just train yourself to *tab*tab*tab* really quick... /shrug
Yes, it's probably personal preference and of course I can get used to it. But I thought the idea was to make the work-flow better?
For example, you add water (lake). You click and move the water level slider. Is it logical to hit tab and expect the next control with focus is the water level text file entry button? On most occasions, if you were going to enter it via a text file, you would start there (at the text file button.)
I'm used to Lightwave. They have a numeric panel and the tab order is width, height, depth, even though they have a slider to the right of each text entry field. In fact, they slider doesn't have a tab index.
Hi jaf,
The reason that all controls can be tabbed to is that it's one of the "rules" of Windows UI design (which we try to follow) - all interactive controls must be able to be tabbed to. If you were someone who was primarily a keyboard navigator, as opposed to a mouse navigator, then not being able to tab to a particular control wouldn't be appreciated.
In the example you gave, tabbing from the Minimum scale text field to the slider is the proper order.
The thing you mention about the "text file button" ( we call it the animation button ) is a valid point though. I will see if I can improve that.
Regards,
Jo
Quote from: jo on May 23, 2009, 09:56:33 PM
The thing you mention about the "text file button" ( we call it the animation button ) is a valid point though. I will see if I can improve that.
Yes but the animation button must be used to set key frames after you input the numbers, so doesn't it make sense to tab to it after you change the one value?
I agree that all controls should be accessible via tabs, I just don't like the order and don't think it's the most efficient way to implement the data entry work-flow.
I just looked at Excel. If I go to format cell|borders style and click on one, a tab does not take me to the next style, it takes me to a new category -- color, which makes sense since I already chose a style. If I go to Photoshop and select the Hue/Saturation panel and click in the Hue text entry field and make an entry, a tab doesn't take me to the Hue slider; it takes me to the Saturation text entry field (because at least to me, I already made a Hue selection -- I don't immediately need another way to do that.)
Anyway, like I mentioned, it's not a bug and I can get used to it. I spent a couple years as a human factors engineer with Raytheon on training devices (flight simulators) and we spent a lot of time designing the most efficient instructor consoles. Maybe my old habits are swaying my judgement.
Hi neuspadrin,
Quote from: neuspadrin on May 23, 2009, 09:59:58 PM
Yes but the animation button must be used to set key frames after you input the numbers, so doesn't it make sense to tab to it after you change the one value?
The general expectation is that the flow goes left to right though, not jumping back. I think it's better to work as expected than throw in "odd" behaviour that the user has to figure out. You can shift-tab to move backwards to the animation button in your scenario. The only reason the animation button is tabbed to in the way it is now is because it's created after the other controls in the "row" but then placed to the left of them, not by design.
Regards,
Jo
If anything then the animation button should be moved to the right of the slider.
Quote from: neuspadrin on May 24, 2009, 11:27:33 AM
If anything then the animation button should be moved to the right of the slider.
Nah, just Shift-tab! If you're used to that it comes natural. As long as the left to right, top to bottom order is implemented, you can get everywhere with Tab / Shift-Tab.
oh shift tab reverses?
amazing! never knew that! thanks mohawk! haha, learn something new everyday. seems i wouldve hit that earlier.
Quote from: Mohawk20 on May 24, 2009, 01:32:45 PM
Quote from: neuspadrin on May 24, 2009, 11:27:33 AM
If anything then the animation button should be moved to the right of the slider.
Nah, just Shift-tab! If you're used to that it comes natural. As long as the left to right, top to bottom order is implemented, you can get everywhere with Tab / Shift-Tab.
I believe it has nothing to do with left to right. It's the tab index for each control. You could program it to do minimum scale, maximum scale, min slider, max slider, animation button, animation button. But then I basing this on my C# stuff, so maybe it is different with TG2.
Quote from: jaf on May 24, 2009, 03:07:25 PM
Quote from: Mohawk20 on May 24, 2009, 01:32:45 PM
Quote from: neuspadrin on May 24, 2009, 11:27:33 AM
If anything then the animation button should be moved to the right of the slider.
Nah, just Shift-tab! If you're used to that it comes natural. As long as the left to right, top to bottom order is implemented, you can get everywhere with Tab / Shift-Tab.
I believe it has nothing to do with left to right. It's the tab index for each control. You could program it to do minimum scale, maximum scale, min slider, max slider, animation button, animation button. But then I basing this on my C# stuff, so maybe it is different with TG2.
You're right, and I didn't mean it exactly like that... I meant if the index is natural, like we expect it to be from left to right, it's not important where the buttons are as you can shift-tab backwards anyways. No need to go shuffle the buttons around.
Sorry -- I thought of that after I sent to post. 8)
At least TG2 is consistent. I've looked at many of my applications and there's quite a few that seem to have no real order, like they let multiple programmers develop their own preferences instead of an overall design.
Hi everyone,
On Terragen 3 (osx) , is there any index at all?
Because when I am in the render menu for example, here is how hitting TAB works for me:
If I click on the "Image width" field for example, then enter numbers, when I hit TAB, I get the focus on the arrows on the right (.. well.. that is fine)... but when I hit TAB again (to enter "image Height").. the focus is set on the Render Node "Name" field at the top...(not so nice), then hitting TAB again takes me to the settings button on the right of the name field (...) and finally if I continue to hit tab, I get caught in a loop back and forth between the "name" field and the setting button...., so i have to use mouse to get out of there.
This happens in every menu of Terragen for me.
I am doing something wrong? Or is it a known problem ?
Thanks
Hi mathieubr,
I guess you have Full Keyboard Access turned on? I turned it on (I don't usually have it on) and see the same behaviour. This isn't something I knew about and I'll have a look at it today.
Regards,
Jo
Hello,
Turning full keyboard access off solved my problem.
Thank you!
Would be nice to be able to use Terragen with full keyboard access on though.
Hope there is a solution for a future update!
Bests