Follow FlatLaf colours for component drag target indicator.

[neilcsmith-net]

Update FlatLaf properties to set the colour of the drag target indicator to match the active tab underline colour (usually accent colour). Also make the stroke weight configurable and reduce slightly in FlatLaf.

This follows a conversation with @Chris2011 on Slack, and also relates to an old discussion in #7420 and follow up on #8845 I always use the orange accent colour, so until Chris mentioned this I hadn't even realised it wasn't picking up the accent colour already! 😄

[Chris2011]

Code looks good to me any it looks way better, than before. Thx

[mbien]

not a fan of it. It is hard to see when you drag a tab to sort it within a tab list using the default themes.

E.g the editor tab list uses a modified version of the same accent color for background and focused tab uses it too.

having only one accent color might not be enough to map all contrast/attention-seeking operations to it.

[neilcsmith-net]

Given I've been using the IDE for years with this pretty much matching the accent colour, I don't really see what the issue you're describing is. It shouldn't be a hardcoded colour. And we don't really have support for secondary, contrasting accent colours at the moment.

So, I can change, but how? I'll try a darker accent variant on light theme, and a lighter one on dark, and see what you think.

[mbien]

Given I've been using the IDE for years with this pretty much matching the accent colour,

Similar here, I use the same default accent color just with a slightly altered dark theme (and while testing I often look at the light theme anyway). The accent color itself is not the problem, its just that it becomes one once it is used everywhere since than its no accent anymore.

So, I can change, but how?

I don't know yet. We have to play with this a bit. Color, tone, thickness, stroke are all tools we can use to find the right combination.

[neilcsmith-net]

Given I've been using the IDE for years with this pretty much matching the accent colour,

Similar here, I use the same default accent color just with a slightly altered dark theme ...

In which case I don't get it. You're using a theme, like me, where this indicator is the accent colour, but if it matches on other accent colours it's an issue?!

So, I can change, but how?

I don't know yet. We have to play with this a bit. Color, tone, thickness, stroke are all tools we can use to find the right combination.

I've made the colour tones derive from the accent, but different for light and dark. And I've put the stroke weight back, but left it configurable.

Have tested with all the light and dark default accents (not that they're all perfect ootb anyway).

The only way I can think we might be able to generically derive a secondary accent would be to spin the existing accent, but tried this here and it fails to be useful too often.

[mbien]

In which case I don't get it. You're using a theme, like me, where this indicator is the accent colour,

the window drop indicator used to be hardcoded as signal color (some red/orange tone: 255, 90, 0) as long I remember using NB. It used to be a basic stroke, I changed it to dashed lines to indicate that it is a dock point (dashes often indicate cut/paste/drop targets) for NB 28. Dashes make signal colors less signally since they reduce the number of painted pixels which was a side effect of the change.

What I was saying is that I am using a theme similar to FlatLaf Dark. Similar accent color of flatlaf dark. (no my accent color is not orange). While testing PRs, I am sticking to default themes since that is what a user would see most likely.

I've made the colour tones derive from the accent, but different for light and dark. And I've put the stroke weight back, but left it configurable.

Making it configurable via the properties is great. But changing a color which used to be a signal color (signal colors contrast with everything, like red for errors) to an accent color which is used everywhere will likely need some testing.

I haven't really played with this much but my guess is that changing it back to the equivalent of BasicStroke(3) will likely look better with the default blue accent color and will stand out a little more when multiple shades of the same accent colors overlap. It also seems to use some alpha blending depending on the drop target (alpha increases if the drop would change a view into an editor or vise versa) - never noticed it so far - wondering if this is an effective way to communicate mode mixing.

[neilcsmith-net]

Updated screenshot - back to 3pt, and now a darker (or lighter on dark laf) variant of the accent colour rather than the same.

What I was saying is that I am using a theme similar to FlatLaf Dark. Similar accent color of flatlaf dark. (no my accent color is not orange). While testing PRs, I am sticking to default themes since that is what a user would see most likely.

OK, I was misunderstanding what you were getting at. I also always check dev builds and PRs with the default colours for that reason. Any colour change I also check with all provided accents.

However, I run my main IDE with orange - mainly so it's easier to tell which is the right IDE to type in! 😄 Maybe because I don't drag windows much, I think I'd assumed this was accent derived already. I've certainly never thought it didn't stand out enough when close to accent colour. Or really thought about how ugly the default is until Chris mentioned it!

But changing a color which used to be a signal color (signal colors contrast with everything, like red for errors) to an accent color which is used everywhere will likely need some testing.

I disagree with you that this is a signal colour, or semantic colour, which is what you suggest with red for errors. If this was semantic, it's giving the wrong message - would probably be better green, with amber for the view / editor mismatch. The current warning isn't alpha blending btw, it's a cross-hatch paint.

This colour possibly linked in well with look and feels with fixed dual accent colours - Nimbus is blue with orange IIRC. But we don't at the moment have secondary accent colours in FlatLaf as far as I know. If you feel we need one (I don't) we could generate from the primary. But it should not be something fixed or it no longer guarantees contrast when people change the accent.

Funny how the tiniest visual changes generate the most discussion! 😄