Prepare TransferData for GTK4 support

[jonahgraham]

The fields in TransferData are platform specific - but GTK3 and GTK4 share the same class. The fields needed for GTK4 are quite different than for GTK3. Therefore this change refactors TransferData's internals to make it ready for GTK4 better.

This is achieved by splitting out all existing fields in a new GTK3 specific subtype, and including a starting point for GTK4 fields.

Some type checking is done to make sure that the correct object is used on GTK3 vs GTK4 respectively and this is done via the newly introduced gtk3() and gtk4() methods.

For now the GTK4 has no fields, but it will eventually have the internal fields needed for GTK4 serializing and deserializing of objects from the native side.

Part of #2126
Split out of #2538

[github-actions]

Test Results

  118 files  ±0    118 suites  ±0   12m 7s ⏱️ -34s
4 577 tests ±0  4 558 ✅  - 2  17 💤 ±0  0 ❌ ±0  2 🔥 +2 
  298 runs  ±0    294 ✅ ±0   4 💤 ±0  0 ❌ ±0 

For more details on these errors, see this check.

Results for commit 0a5f620. ± Comparison against base commit 34becc0.

♻️ This comment has been updated with latest results.

[jonahgraham]

Not ready for review. Despite TransferData.type being commented:

The type is a unique identifier of a system format or user defined format. (Warning: This field is platform dependent)

The type field is actually accessed from non-Platform dependent code and I missed that before submitting this.

Its just for debugging AFAICT, but since type is available on all platforms today perhaps I should just leave that outside of the GTK3/GTK4 structures. More thought required.

[jonahgraham]

Its just for debugging AFAICT, but since type is available on all platforms today perhaps I should just leave that outside of the GTK3/GTK4 structures.

This is what I did for now - but I think it would be nicer if TransferData had a toString that the DropTargetEvent.toString called instead of looking into the private data.

[jonahgraham]

@akurtakov Please let me know if such a refactor is acceptable or if I need to find a different way for GTK4 and GTK3 to co-exist in TransferData

[jonahgraham]

For "Compiler — 2 new issues, 19 tota"l check I see this (I assume the top two are the new ones). But this seems incorrect as we are using * imports in SWT. What is going on here?

The continuous-integration/jenkins/pr-head and Jenkins failed too, but AFAICT that is the same issue as above.

Any help gratefully received.

[akurtakov]

@jonahgraham The new compiler warnings are because there are unused imports. You have TransferData in the same package so there is no need to import it, importing it's inner classes is not needed either as you don't refer to their types at all in the respective classes. Long story short - just delete the 2 unused imports (jdt even gives warnings for them) and warnings are gone.

[akurtakov]

That's quite an unusual way to do it for SWT.
What I am missing here is what will TransferData on Gtk 4 contain? Will it be that different ?
The usual approach is to keep the fields that are there, add the newly needed ones and set them when needed. If needed the classes using it can have if (GTK4) setPropertyA else setPropertyB. That would keep it more in line with the rest of the codebase.
Maybe the differences are really that big that make such approach not feasible but I am not convinced of that for now.

[akurtakov]

I would prefer if we don't introduce new classes/methods/fields that are accessible by endusers and are only hidden by PDE apitools as not every SWT user/developer is developing with PDE apitools and this has created some churn in the past.

[jonahgraham]

OK - I will keep that in mind.

[jonahgraham]

@jonahgraham The new compiler warnings are because there are unused imports. You have TransferData in the same package so there is no need to import it, importing it's inner classes is not needed either as you don't refer to their types at all in the respective classes. Long story short - just delete the 2 unused imports (jdt even gives warnings for them) and warnings are gone.

Oops - I went to look again, I wasn't looking in the correct place. If I had it would have been obvious what I was doing wrong.

The reason I looked at wrong thing is that the link in the output doesn't actually go to the correct place:

I suspect there is supposed to be some annotation in my PR that isn't being created properly, so the link didn't go to the correct place and then I was acting blind 🤦

[jonahgraham]

That's quite an unusual way to do it for SWT. What I am missing here is what will TransferData on Gtk 4 contain?

In GTK4 it will be quite different.

For GTK3 the TransferData contains pointers to a block of memory pValue and its size length/format.

For GTK it will be a handle to GdkContentSerializer or GdkContentDeserializer depending on whether we are doing java to native or the reverse.

The usual approach is to keep the fields that are there, add the newly needed ones and set them when needed.

OK. For now I am going to abandon doing it this way and we can look at applying this refactor when the Clipboard is done if we find the contents of TransferData too complicated.