Skip to content

Add 'pick_on_bounds' property to symbolwidgets for clicking intricate symbols #3319

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

Closed

Conversation

DenSinH
Copy link
Contributor

@DenSinH DenSinH commented Mar 7, 2025

We have some intricate symbols with transparency, but clicking them can be quite annoying, as the mouse might hover over a small transparent region of the image, which makes it not register the hover state / makes it unclickable. We added a property named after the corresponding JavaFX ImageView property "pick on bounds", which makes the entire image bounds clickable, regardless of transparency. For backwards compatibility, it is false by default.

@kasemir
Copy link
Collaborator

kasemir commented Mar 24, 2025

Our site doesn't rely on clickable symbols, in fact I'd discourage that (https://github.com/ControlSystemStudio/phoebus/wiki/Display-Builder-Compatibility#actions-action-buttons).

But if you're stuck with displays full of transparent clickable symbols, this is what you'll have to do, short of updating all symbols to have for example a faint gray background ... as we had to do with the CSS icon because at least on Mac OS X it had the same problem: Click on the "C" icon in the "Doc" and nothing happens because it's mostly transparent...

Still, do we really need a new property for this, or can we simply turn this into a one-line change, making all symbols always fully clickable?

imageView.setPickOnBounds(true);

@DenSinH
Copy link
Contributor Author

DenSinH commented Apr 3, 2025

Fine by me, I figured we would do it this way just to not break the "default" behavior for other users. I'm sure you might not be too eager to just add properties for all such things 😅

@shroffk
Copy link
Member

shroffk commented Jun 3, 2025

Can we think of a use case where you would want to configure this on a per widget basis?

Otherwise we could just make this a preference to enable/disable for all symbol widgets in Phoebus. The preference would allow people to revert back if necessary.

Overall I am fine with the PR.

@shroffk shroffk requested review from kasemir and abrahamwolk June 3, 2025 13:48
Copy link
Collaborator

@kasemir kasemir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather avoid a new property for this. Make it a one-line change, all symbols always fully clickable:

imageView.setPickOnBounds(true);

Or make it a preference setting...

... class JFXPreferences
{
    /** Are symbol widgets fully clickable? */
    @Preference public static boolean pick_on_bounds;

.. with corresponding info and default

# Are symbol widgets fully clickable,
# including their transparent pixels?
pick_on_bounds=true

.. which is then again applied to all symbol widgets:

imageView.setPickOnBounds(JFXPreferences.pick_on_bounds);

@shroffk
Copy link
Member

shroffk commented Jun 3, 2025

My vote is for a single preference too.

@abrahamwolk
Copy link
Collaborator

At ESS, we have clickable Symbol widgets in production and we are relying on the functionality that only non-transparent parts of the symbol widget are clickable. This allows for non-rectangular parts of an OPI to be made clickable.

We do not at all mind an option to change this behavior. However, would it be possible for the new option to be false by default since we are relying on this functionality already?

@kasemir
Copy link
Collaborator

kasemir commented Jun 4, 2025

new option to be false by default

Makes sense, so by default no change

@shroffk
Copy link
Member

shroffk commented Jun 6, 2025

I added the recommended solution in PR #3424

@shroffk shroffk closed this Jun 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants