LÖVE

OS 9000 wrote:I'm sorry Dave, but I can't let you do that. You are jeopardizing the mission. Use the mouse.

Something like that?

New update.

By default only textfields, textviews, tableViews are tab-accessible, but you only have to go aButton.tabAccessible=true to make it tab accessible too.

07 May 2009
Implemented tab-focusing chain. set a control's tabAccessible's value and it'll be included in the chain.
Buttons can now be activated by space or return if they are tab-accessible. (by default they are not, however).
Textfields are by default tab accessible.

Added textView, which only displays multiple of lines of text in a scrollView.

The premise being that when there are many controls on the screen it takes forever to go through them all, when 90% of the time people are using the mouse anyway. So now tab is used to go to the 'important' places instead where users will spend more of their time/ access more.

EDIT: The update had a bug; when no tab accessible control pressing tab will freeze! Here's a patch! Thanks to bartbes for pointing it out.

Some more bugs... Its all to do with implementing tab-access... as you can see because it was so heart wrenching there are bugs propping up. Fixed pressing key when focused on button bug.

EDIT: another bug

It seems that LoveUI is really getting somewere.

One thing: if I press Shift+Tab, it goes to the next control, just like Tab, instead of the previous control, what would be the obvious thing (for me, at least). On the other hand, after looking at the code, it seems it would require quite a lot of typing, just to implement this small feature.

Hmm I just had to copy some of the tab-code and reverse its direction and tweak how events work a bit so that one of its features which I have never used before would actually work. i.e anEvent.keysDown[love.key_lshift] will return whether the key is pressed or not. Could've used love's own function though... but shift key might've been released by the time the code is run? I am not quite sure.

Problem.. when I press tab it goes through the boxes way too fast, am I doing something wrong (something like I need to add a dt somewhere) or did you make a mistake somewhere?

EDIT: More details, this "fast mode" gets activated when you hold tab and then release it, seems like it's not switching back to normal behavior.

Change code to this near line 159 of LoveUIContext.lua to: from
or download this patch.




I deleted the line because I forgot what it does.

I'll stop adding new stuff until no more bugs and then release a 'stable'.

The keyRepeat part isn't done well because realisitically setting keyRepeatSpeed doesn't do much so I might have to refactor that.

Ok, I'll download once I'm back in linux.

EDIT: Downloaded, added to Netris, fix confirmed.

In the demo posted above, I can edit the first input text box. is this intended? (it will not have an effect on what is selected though. I can enter "Bali" but launching missile will only destroy what was selected in the list on the right.

I cannot edit the second text box (below it) but if I do press keys, the cursor will move. is this intended?

also I get this in the demo: LoveUI: aButton.title is deprecated. Please use aButton.value instead

I'm not appleide (no, really?), but I can answer some of it.

qubodup wrote:In the demo posted above, I can edit the first input text box. is this intended?

Yes. In fact, if you select another server on the right, and select the previous one again, you'll see your change has been saved. You are right though it would have been clearer if the listview was updated as well.

qubodup wrote:I cannot edit the second text box (below it) but if I do press keys, the cursor will move. is this intended?

I found that one too. Just didn't think it was that important . But I thought it is a bug. Am I right, appleide?