Skip to content
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

Correct contracts of Control#[get|set]Location() #790 #1454

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

HeikoKlare
Copy link
Contributor

The Control#getLocation() and Control#setLocation(...) operations currently claim to always work (i.e., yield reasonable values or actually change the location). This specification is incorrect when executing these methods in shells on a platform that uses the Wayland protocol.
Currently, there does not seem to be a fix to make the implementation fulfill the specification. In case we claim that SWT can be used on Wayland, the specification thus has to be adapted to reflect that behavior. This change adds an according warning to the specification in order to avoid that clients rely on the specification to be fulfilled.

Currently, most UI elements requiring a separate shell/dialog are not placed as expected when using a platform with Wayland. In the Eclipse SDK, this includes the find/replace UIs (both the existing dialog and the new overlay), notification popups, quick type hierarchy, and other.
Having a warning in the specification of the broken methods is supposed to avoid further usage of those methods in problematic scenarios (to prevent avoidable regressions like #1447).

Why in Control instead of Shell?

We might also add the warning only to Shell#[get|set]Location(), as it only applies to those methods executed on a shell. This But that would break the substitution principle as you might have a control at hand, not knowing that it's actually a shell that behaves differently.

Contributes to #790

Copy link
Contributor

github-actions bot commented Sep 7, 2024

Test Results

   486 files  ±0     486 suites  ±0   7m 23s ⏱️ -13s
 4 156 tests ±0   4 148 ✅ ±0   8 💤 ±0  0 ❌ ±0 
16 378 runs  ±0  16 286 ✅ ±0  92 💤 ±0  0 ❌ ±0 

Results for commit 6f544fc. ± Comparison against base commit ca113ca.

♻️ This comment has been updated with latest results.

@HeikoKlare HeikoKlare marked this pull request as ready for review September 7, 2024 10:16
@HeikoKlare
Copy link
Contributor Author

@akurtakov what do you think?
The only alternative I see it to state that SWT does not support platforms using Wayland, but that's obviously not something we would like to do...

The Control#getLocation() and Control#setLocation(...) operations
currently claim to always work (i.e., yield reasonable values or
actually change the location). This specification is incorrect when
executing these methods in shells on a platform that uses the Wayland
protocol. Since there is currently no fix to make the implementation
fulfill the specification, this adds an according warning to the
specification in order to avoid that clients rely on the specification
to be fulfilled.

Contributes to
eclipse-platform#790
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.

1 participant