Remove deprecated Color(Device, ...) constructor usage

[vogella]

Summary

• Replaces all new Color(Device/Display, ...) constructor calls with the modern new Color(...) equivalents across 64 files
• The Color(Device, int, int, int), Color(Device, RGB), and Color(Device, RGBA) constructors are being deprecated in Deprecate old Color constructors that require a Device/Display parameter eclipse-platform/eclipse.platform.swt#3233
• This reduces boilerplate, avoids NPE risks on non-UI threads, and simplifies resource management

Test plan

• Verify the project compiles successfully
• Verify no regressions in color rendering across widgets

🤖 Generated with Claude Code

[vogella]

The build failure (continuous-integration/jenkins/pr-head) is a Jenkins environment issue it requires Java 21 but the CI agent is running Java 17. I send another PR for fixing this.

[merks]

@vogella

Probably every bundle that's changed needs to have a lower bound such that it can only be installed with a version of SWT that has the newer constructor.

[vogella]

@vogella

Probably every bundle that's changed needs to have a lower bound such that it can only be installed with a version of SWT that has the newer constructor.

That would be 3.115 AFAICS:

• @SInCE 3.115
  */
  public Color(int red, int green, int blue) {
  super();
  init(red, green, blue, 255);
  }

[merks]

Sorry, I should have thought of this before, but now with a visible change to the manifest, something needs to be incremented. Probably the minor version. And then corresponding feature increments for the including features...

Dear goodness, quite some things to consider... 😢 Sorry.

[vogella]

Sorry, I should have thought of this before, but now with a visible change to the manifest, something needs to be incremented. Probably the minor version. And then corresponding feature increments for the including features...

Dear goodness, quite some things to consider... 😢 Sorry.

What is the version strategy of Nebula? It looks like most bundles were set to 1.0.0 when created and simply never incremented, even as functionality changed. So effectively AFAICS, Nebula doesn't have an active versioning strategy.

They seem to rely on the build qualifier.

[vogella]

I think we should not start incrementing suddenly versions if Nebula never did it in the past.

I can do this but it feels to me that this would violate the way of working in Nebula (no version increase, what a beauty to work with).

[merks]

It's not that they never did it because we do see a mixture of versions:

https://download.eclipse.org/nebula/updates/nightly/latest/index.html

Just so you know where I'm looking:

But certainly there was never much attention paid to the version numbers. That serves the consumers extremely poorly, especially now if we literally are breaking backward compatibility knowingly.

@lcaron @wimjongman

As team leads, you set the direction. I know that versions are hard to maintain and keep correct and consistent, even more so with such a large boatload of bundles and fine-grained features... I expect feature versions don't matter so much because consumers probably specify the bundle dependencies with ranges.

[wimjongman]

Nebula API is not breaking, it is an upstream plugin that changes. Lifting the lower SWT requirement should be enough.

We must increment the major version if this breaks the API of one of our plugins.
We must increment the minor version of each affected plugin.

WDYT?

[merks]

I agree. I think for this non-API breaking change, every affected bundle should have a minor version increment; I'm not so concerned about feature version, though incrementing the minor version of each including feature would be nice if the AI agent can do that relatively easily.

[vogella]

What increment for minor? Just "1"?

So we go for example:

• version="1.0.0.qualifier"

• version="1.1.0.qualifier"

And 1.6.1 would become 1.7.0

[wimjongman]

We must also bump the pom I think.

[vogella]

We must also bump the pom I think.

Thanks, already noticed, I initially assumed Nebula is pomless....

[merks]

@vogella

That's looking really great!

[merks]

I didn't review line by line, but generally looks just fine!

[wimjongman]

I didn't review line by line, but generally looks just fine!

[wimjongman]

Thanks, Lars!!

[vogella]

Thanks, Lars!!

Pleasure my friend. Would be nice to met you again for a cold one. :-)