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

Fix wrong implementation of TEXT_PLAIN_UTF8 transfer feature #879

Merged

Conversation

iloveeclipse
Copy link
Member

  1. The utf-8 content should be same as in UTF8_STRING, it just should use different label/type id.
  2. The change in ClipboardProxy.setData() was non functional and makes no sense, it only leaks memory/wastes time

See #863 See #851

1) The utf-8 content should be same as in UTF8_STRING, it just should
use different label/type id.
2) The change in ClipboardProxy.setData() was non functional and makes
no sense, it only leaks memory/wastes time

See eclipse-platform#863
See eclipse-platform#851
@iloveeclipse
Copy link
Member Author

@the-snowwhite : please test this implementation with your original use case in #851.

Copy link
Contributor

Test Results

     299 files  ±0       299 suites  ±0   6m 18s ⏱️ +20s
  4 095 tests ±0    4 087 ✔️ ±0    8 💤 ±0  0 ±0 
12 197 runs  ±0  12 124 ✔️ ±0  73 💤 ±0  0 ±0 

Results for commit 5c6a7a7. ± Comparison against base commit 5193ab5.

@the-snowwhite
Copy link
Contributor

@iloveeclipse
Your statement here is a misunderstanding.(verified bu the eclipse debugger)

  1. The utf-8 content should be same as in UTF8_STRING, it just should use different label/type id.

    1. The change in ClipboardProxy.setData() was non functional and makes no sense, it only leaks memory/wastes time

See #863 See #851

I have fully tested the functionality of #863 wia functional testing in the eclipse debugger running in a wayland session.
with only the changes in TextTransfer.java the debugger responded to no breakpoints in javaToNative (in TextTransfer.java)
and no data was presented to the wayland clipboard.

Then after introducing the 3 lines in ClipboardProxy.java the debugger now stopped in javaToNative and data was presented to the wayland clipboard.

Please suggest functional code changes in functional code instead of abstract programming lingo the is hard for me to understand.
I'm an intuition based functional procedural programmer with a gift for code and bugfixes but i do not understand OOP or OOP lingo.
OK ?

@the-snowwhite
Copy link
Contributor

@the-snowwhite : please test this implementation with your original use case in #851.

OK I hope it works I like the much more simple style than what chatgpt4 beaten with a (stick and large scissors) could provide...

@iloveeclipse
Copy link
Member Author

I have fully tested the functionality of #863 wia functional testing in the eclipse debugger running in a wayland session.
with only the changes in TextTransfer.java the debugger responded to no breakpoints in javaToNative (in TextTransfer.java)
and no data was presented to the wayland clipboard.

What I'm asking you now: please test this patch with Wayland! Not what you might have tested before in some debug session!

If it is not working under Wayland, it means, the code you've added in ClipboardProxy.setData() should only be called under Wayland session (if it the right place to do it at all, which I highly doubt here), because now under X11 I see that we call this code three times and it is not needed at all under X11!

The use case (as far as I could understand it, because it is not clearly described) was:

running in both gtk v3.24.33 and gtk v3.24.38 it is possible to paste into eclipse from all applications that only present
RFC-1341 types (so far only text/plain;charset=utf-8) in the clipboard under a wayland session.
I have also just tested pasting the danish special characters åæø and that went fine also.

If I understood it right, the text copied to clipboard from Eclipse should be able paste to "kate" editor under Wayland.

Note: it is not the ClipboardProxy.setData() that should call javaToNative(), but ClipboardProxy.getFunc(), at least under X11, so if under Wayland it is differently, you should look why ClipboardProxy.getFunc() doesn't call javaToNative or why ClipboardProxy.getFunc() is not callled.

I have no Wayland, so I can't check, but current code state is definitely wrong.

@mickaelistria, @akurtakov, @trancexpress : could you please check this PR & use case, if you have Wayland?

If this PR doesn't work under Wayland, I would propose a PR reverting #863 for RC1 as it definitely does wrong things on X11.

@the-snowwhite
Copy link
Contributor

the-snowwhite commented Nov 10, 2023

@iloveeclipse

What I'm asking you now: please test this patch with Wayland! Not what you might have tested before in some debug session!

Yes i'm just having some issues as my main eclipse installation for SWT building has crapped out showing over 861 errors
and not being able to run the clipboard example .
Luckily I have a Kubuntu 22.04 VM that has a working Eclipse build setup, however now I'm having some issues installing wayland so it's slow progress. I hope your PR works as its a much more simple solution (stated more verbosely in other comment).

@the-snowwhite
Copy link
Contributor

@iloveeclipse
Btw the audience for the paste fix is ubuntu 22.04 LTS users that have gtkv3.23.33(the one without the gtk paste fix).

@mickaelistria
Copy link
Contributor

@the-snowwhite So do I get it right you successfully tested that patch and are OK with it being merged?

@iloveeclipse
Copy link
Member Author

iloveeclipse commented Nov 10, 2023

@the-snowwhite : once again: can you clearly answer to the question: have you successfully tested that patch and are OK with it being merged?

@mickaelistria : can you please test this patch - as obviously you were able test the original one?

Copy link
Contributor

@the-snowwhite the-snowwhite left a comment

Choose a reason for hiding this comment

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

@iloveeclipse
The title is mis leading
This is a functional change for an already functional verified and merged PR
Will you please wait til after the freeze ?

@iloveeclipse
Copy link
Member Author

Will you please wait til after the freeze ?

No, because original patch is NOT OK.

Can you please answer to the question have you successfully tested that patch and are OK with it being merged?

@iloveeclipse iloveeclipse changed the title Cleanup implementation of TEXT_PLAIN_UTF8 transfer feature Fix wrong implementation of TEXT_PLAIN_UTF8 transfer feature Nov 10, 2023
@the-snowwhite
Copy link
Contributor

@iloveeclipse
@mickaelistria
The original intention of testing required that the buxfix was able to run on 2012-09_R So next logical test step will be
to cherrypick the #879 to r_29_Maintanance and test via the
#858
procedure.
However if that works next logical step will be I have to figure out which branch corresponds to the most recent binaries
created by the I-build (I think @mickaelistria gave me the info yesterday ?).
And then download the binaries from: here ?
https://www.eclipse.org/downloads/packages/2023-03m3
and test the 3 binaries I can produce in the plugin folder ...
oh wait the filename is
eclipse-inst-jre-linux64.tar.gz
Hmmm will ruin my current 2012-09 installs ?
Ill start on the test procedure but give me a few hours or so
OK ?

Copy link
Contributor

@mickaelistria mickaelistria left a comment

Choose a reason for hiding this comment

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

Using the ClipboardExample
Without patches from #863 , I can copy from StyledText to Qt widget (I'm using Carla application as example of a KDE/Qt application) but I cannot copy from Carla/Qt/Kde... to StyledText.
With current master including patches from #863, I can copy/paste in both directions (that what I tested before merging)
With this patch, I can also copy in both directions.

So I'm totally in favor of merging this patch, which achieves the same result with simpler code and removing some extra unnecessary processing.

Thanks @iloveeclipse for the polishing here.

@iloveeclipse
Copy link
Member Author

Thanks @mickaelistria, merging.

@iloveeclipse iloveeclipse merged commit a90888b into eclipse-platform:master Nov 10, 2023
10 of 11 checks passed
@iloveeclipse iloveeclipse deleted the issue_851_followup branch November 10, 2023 18:26
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.

3 participants