-
Notifications
You must be signed in to change notification settings - Fork 27
Add focus indicator for blocks #179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Set the focus mode on Blocks so they can process input events. When dragged on the canvas, set the dropped block to be focused. Note the subtle interaction between FocusMode.FOCUS_ALL, which allows focusing by mouse click, and MouseFilter.MOUSE_FILTER_IGNORE, which filters out mouse click events. The combination means that the mouse click will be handled in Godot for focusing the block, but the mouse click can't be processed in _gui_input().
a72e1ae
to
73eda98
Compare
Nice! This is exactly what I was trying to do the other day. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! The stylebox thing is weird but I don't think there's a ton of room for improvement. I'll probably pull this into my branch as is while I address some other comments there.
|
||
_panel_focus = _panel.get_theme_stylebox("panel").duplicate() | ||
_panel_focus.bg_color = color | ||
_panel_focus.border_color = Constants.FOCUS_BORDER_COLOR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is indeed awkward since there are now 3 styleboxes including the one saved in the scene. Is it possible to have one stylebox in the code that duplicates the one in the scene and then just mutate the color properties on it instead of overriding back and forth? You could even go further and build the initial override in code instead of taking it from the scene, but I feel like people would prefer to edit the non-color properties in the editor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is indeed awkward since there are now 3 styleboxes including the one saved in the scene. Is it possible to have one stylebox in the code that duplicates the one in the scene and then just mutate the color properties on it instead of overriding back and forth? You could even go further and build the initial override in code instead of taking it from the scene, but I feel like people would prefer to edit the non-color properties in the editor.
For reference, other Control nodes in Godot have several styleboxes, one per each style. For example Button has styleboxes for Normal, Pressed, Disabled, Focus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooh, should we attach a bunch of different styleboxes and then use theme_type_variation
to switch between them? Right now I have it swapping the stylebox for the "Panel" style, but looking at the documentation for that property I see…
The name of a theme type variation used by this Control to look up its own theme items. When empty, the class name of the node is used (e.g. Button for the Button control), as well as the class names of all parent classes (in order of inheritance).
… which helps me to understand why styleboxes have these two completely different naming schemes. But I'm still completely bewildered by how "focus" behaves, which is apparently drawn as an overlay, but does that mean it's a separate node that certain controls (but not the Panel control) show on focus? Or something weirder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's certainly very interesting. I suppose that would be good because we'd be inheriting whatever Panel theme variation is in the project. I'm going to punt and keep what you have for now, but feel free to keep investigating how to better manage this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I was misunderstanding what these things are, and I think I have the same confusion as this person: https://www.reddit.com/r/godot/comments/1bdc48p/i_am_confused_about_the_name_part_used_in_themes/. Unfortunately, the explanation is making my brain melt.
|
||
|
||
## Get the nearest Block node that is a parent of the provided node. | ||
static func get_parent_block(node: Node) -> Block: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up putting this in the new BlockTreeUtil
class I made so as not to re-introduce a circular dependency. The Util
class otherwise depends only on native classes.
I've pulled this in to #170 now. Let's have any further discussion there. |
Note that this requires ac4c748 from #170.
Helps: #162