key_up, mouse_up

Finally the day has come, will be interesting to see the implementation, see how easy it will be to be able to make UI click animations that support multiple users.

https://twitter.com/dantwohundred/status/573592899943690240

Also better keybindings: Ctrl+<key> will be much easier now!

Less lag!

Can't believe that this has not been added earlier, and I should be on twitter more often, I miss out on so much information! :P/>

Ooooooooooohhhhhhhhhh yeeeeeaaahhhhhhhhhhhh!!!!!!!!!!!!!!!!

Finally I'll actually be able to keyboard shortcuts that actualy work.

Thanks Dan!


The question is, do we suddenly drop support for old versions of ComputerCraft to support this? Ideally not, but things could get quite messy and complicated if having to do it two ways, especially if it's not easy to know if the users version has these events.


I'd also like to propose that mouse_leave be added. Basically if you're dragging and the mouse leaves the computer you would assume that the mouse would still be down, yet it may not be causing some headaches and complexity. The other alternative is to just make it fire mouse_up when it leaves.

Mouse_leave would be nice, but as long as we get mouse_up in all cases, even if it's outside the window, then I'll be happy. I wouldn't want to get a mouse_up event if there's a chance the mouse is still down and coming back.

As for supporting old versions, for edit+, I'm tentatively planning to conditionally disable the features that depend on it, but I don't know yet how much of a mess that might make the code, so I reserve the right to change my mind and only support new computers.

Personally, I'd rather a mouse_up fire as soon as the cursor left the edge of the display, forcing users to re-click if they move the pointer back on. It's a matter of taste, really, but some sort of notification when the cursor is dragged off the edge is obviously strongly desirable.

In fact, having a mouse_leave event with the side and a mouse_enter event also with the side could be useful for editors where dragging outside the bounds of the text input area causes it to scroll.

Even if these aren't added, this is absolutely incredible! Text selection that you can drag to new locations is now possible, as well as drag and drop GUI creators, game creators, better file explorers, the possibilities are enormous. Thanks Dan!

Bomb Bloke, on 07 March 2015 - 07:33 AM said:

Personally, I'd rather a mouse_up fire as soon as the cursor left the edge of the display, forcing users to re-click if they move the pointer back on. It's a matter of taste, really, but some sort of notification when the cursor is dragged off the edge is obviously strongly desirable.

but… Why?! not all drag operations can just be resumed with a new click, many would be forced to start over completely if you accidentally slip the cursor slightly over the edge of the window that way. For me that's a big old hell no.

I have no "practical" reason, it's just a matter of respecting the fourth wall - would a "mouse_leave" event make any sense on a "real" computer?

Bomb Bloke, on 07 March 2015 - 12:53 PM said:

I have no "practical" reason, it's just a matter of respecting the fourth wall - would a "mouse_leave" event make any sense on a "real" computer?

You misunderstand my position, I don't want mouse_leave or mouse_up when the mouse leaves the cc screen. I just want a mouse_up when the mouse is released, even if it's off the screen at the time. The only case where a mouse_up event might need to be inserted is if the player hits esc to close the computer gui while holding the mouse button, in which case it's basically implied you had to release the mouse button to step away from the computer.

Bomb Bloke, on 07 March 2015 - 12:53 PM said:

I have no "practical" reason, it's just a matter of respecting the fourth wall - would a "mouse_leave" event make any sense on a "real" computer?

Yes, but does your "real" computers cursor allow itself to leave the screen? No. That's not a reason to not have these events.

GopherAtl, on 07 March 2015 - 02:44 PM said:

You misunderstand my position, …

I understand that, what I'm saying is that from the computer's perspective it should not be possible for the user to move the mouse off the screen in the first place. Given that we (the coders of these virtual machines) obviously want to know if the mouse leaves the display, and "mouse_leave" makes no sense from an in-game perspective, that leaves firing "mouse_up" at that time instead.

One would expect a mouse_release event to work much the same as mouse_click in reverse, indicating the co-ords where the mouse was released, and the button that was released. Again: This makes no sense if the mouse isn't even on the screen at the time when a user lets go.

But again, I consider the handling a matter of taste, and won't complain if "ease of use" is chosen over "what makes sense". I'm sure Dan's already decided on his implementation anyway.

oeed, on 07 March 2015 - 11:36 PM said:

Yes, but does your "real" computers cursor allow itself to leave the screen? No. That's not a reason to not have these events.

Er, the fact that a real computer doesn't let you do that is my point. Neither should these virtual computers. Thus if the user attempts to do so, as far as the machines are concerned, that should be the same as letting go of the mouse.

Bomb Bloke, on 07 March 2015 - 11:40 PM said:

GopherAtl, on 07 March 2015 - 02:44 PM said:

You misunderstand my position, …

I understand that, what I'm saying is that from the computer's perspective it should not be possible for the user to move the mouse off the screen in the first place. Given that we (the coders of these virtual machines) obviously want to know if the mouse leaves the display, and "mouse_leave" makes no sense from an in-game perspective, that leaves firing "mouse_up" at that time instead.

One would expect a mouse_release event to work much the same as mouse_click in reverse, indicating the co-ords where the mouse was released, and the button that was released. Again: This makes no sense if the mouse isn't even on the screen at the time when a user lets go.

But again, I consider the handling a matter of taste, and won't complain if "ease of use" is chosen over "what makes sense". I'm sure Dan's already decided on his implementation anyway.

oeed, on 07 March 2015 - 11:36 PM said:

Yes, but does your "real" computers cursor allow itself to leave the screen? No. That's not a reason to not have these events.

Er, the fact that a real computer doesn't let you do that is my point. Neither should these virtual computers. Thus if the user attempts to do so, as far as the machines are concerned, that should be the same as letting go of the mouse.

I'd say the computer should pretend the user just tried to move the cursor past the edge, but failed. If they drag back onto the screen, then they resume getting drag events, which, worst case, is like they very quickly moved the cursor quickly around the edge of the screen. A leave event seems to be a greater concesion to the unreality, and also seems worse from both the perspectives of a CC program developer and user.

GopherAtl, on 08 March 2015 - 12:32 AM said:

I'd say the computer should pretend the user just tried to move the cursor past the edge, but failed.

Hrm. Could work. If the user lets go of the mouse while the pointer is off the computer's display, have the resulting event return the co-ords where the mouse left from - as if it were still there. Indeed, I reckon that'd be best!

I remember the reservations on having key_down and key_up events, but I don't begrudge their arrival. Time to put a few more cc game ideas back on the drawing board :)/>

what IS key_up, mouse_up? what do they do?

slow-coder, on 08 March 2015 - 02:37 AM said:

what IS key_up, mouse_up? what do they do?

Guess.

I mean… it's pretty damn obvious isn't it? When a key is released it fires key_up, when the mouse is release it fires mouse_up.

oeed, on 08 March 2015 - 02:47 AM said:

slow-coder, on 08 March 2015 - 02:37 AM said:

what IS key_up, mouse_up? what do they do?

Guess.

I mean… it's pretty damn obvious isn't it? When a key is released it fires key_up, when the mouse is release it fires mouse_up.

ok, sry, i just thought that something like this would be called key_release or something

Talking about UI… TheOriginalBit: I was checking you github profile and i noticed a graphic library that seems pretty cool. But is been 4 months… are you still developing it? Will it be available?

RoD, on 08 March 2015 - 08:35 PM said:

Talking about UI… TheOriginalBit: I was checking you github profile and i noticed a graphic library that seems pretty cool. But is been 4 months… are you still developing it? Will it be available?

Kinda and eventually. I was going through a rewrite to make some things a little easier, and I did hit some limitations such as how it would function better with mouse_up events. I will most likely resume development on it once these events are added; I've also been considering making a program which you can drag drop GUI elements and customise them etc (which will use my Library to make other programs with my library)