Circle menu fixes #2904
Circle menu fixes #2904
Conversation
|
am testing this. thanks for doing this! |
|
I didn't review the code, but the changes feel good. I think that its quicker to exit the menu and select things. I wish there was a way to display the circle menu as a a "pie slice" so we can highlight the whole slice, but the work here is a clear improvement. |
There was a problem hiding this comment.
It's pretty nice. I noticed a couple of minor aesthetic issues (non-merge-blocking):
- In the Armory menu, currently owned items do not highlight when the cursor is in their sectors. But a currently owned item is selectable (clicking it sells the item.)
- It looks kind of bad when the crosshairs of some weapons are drawn in the space between the cancel button and the options.
|
Thank you for your time. I got preoccupied this week, before I managed to tidy up my refactoring.
Yes, Sir, I'll do that. I was planning on signalling somehow readiness for review after I removed ugly regressions my refactoring introduced and now I know how. Refactoring(and cleanup) of lua is the easy part. The harder part is advanced key handling, which requires querying client key binds. BTW, build menus seem to ignore their first (inducing) mouse click which they shouldn't do if a single click confirm-on-release selection is to be a thing. So another thing potentially to be done. |
|
@RedSkyByte If you need help with something I know how to do, don't hesitate do ask me |
For a single-press mode the commands would probably need to be changed to "plus" commands which allow responding to key up. See for example |
A shallow Object Oriented abstraction of circle menus. Concrete implementation derive from CircleMenu prototype. They must handle data acquisition, displaying info and option selection. In turn, objects inherit from prototype all mechanisms for building menu and all major event handlers. All these mechanisms centralised in CircleMenu object's methods, but can be easily overwritten to handle exceptional behaviour.
RedSkyByte
force-pushed
the
circle-menu-fixes
branch
from
40d5328
to
31a2f33
Compare
|
I should have force pushed rebase without last commit. My changes are far less readable now. I'm sorry.
There is no other clear way to implement select-on-release with exception of building of course. As reminder: I don't want to issue commands here, I want to consume inputs and interpret what they mean. Combined with support for movement with menu open, it's not a trivial problem. |
| event:StopPropagation() | ||
| self.menuElement.child_nodes[index+1].first_child:Click() | ||
| end | ||
| end | ||
|
|
||
| function CircleMenu:Quit(event) |
There was a problem hiding this comment.
What's with this super complicated quit thing? It worked fine before without that.
There was a problem hiding this comment.
It worked fine before without that.
Not exactly, there was a lot of corner cases of undesired behavior around clicking and click-releasing on buttons and backdrop, closing menu or leaving it open when it shouldn't.
Managing events from click events is a bit tricky, especially since onclick, onmouseup and onmousedown are separate. I also found that one click event on body element tends to leak out and fire after menu document is closed, no matter what I do.
And like I mentioned that in comments, trying to hide document already hidden (and deallocated, I presume) does, on occasion, crush the program.
There was a problem hiding this comment.
I wonder if this is due to us using this Events.push_event hack instead of calling the methods directly. I think Events.push_event() causes the action to occur on the next frame instead of immediately.
So, in most places where you do Events.pushevent("hide foo"), you could probably do self.document:Blur()
This should cause the hide action to take effect immediately.
I started implementing what we arrived at in discussion of #2895 :
keyup/mouseupVery humble changes, but already major change in usability. I'm looking for some advise and input.
I can't progress on 3. and 4. before I can query current binds (so i know what keys to be on the lookout).
With no. 3 there is also problem with building - currently mouse press that spawns menu doesn't emit mouseup when released.
I can't do anything on 5. without basing it on #2900
I can jump into refactoring, but I'd like to know if armory menu will stay as is and if what I changed so far makes sense.
Lua code that needs to be abstracted namespaced better which might be needed if complexity of UI will rise. Other then that I'm also thinking data binding(MVC) for displaying up-to-date information live and less hacky menu building.