Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 361122

Summary:

[Theming] Not all styles are applied properly

Product:

[RT] RAP

Reporter:

Sebastian Bauer <mail>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

cole, ivan, ruediger.herrmann

Version:

unspecified

Target Milestone:

1.5 M3

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
The CSS file for the test	none
The test application	none
The configurator	none

Description Sebastian Bauer

2011-10-17 07:42:12 EDT

Build Identifier: 

In my application, I want to maintain three different button styles. For this purpose, I add the .css (attached to this bug) the custom ApplicationConfigurator.

If I run the also-attached test application with the nightly of 14th of October, I see two green buttons, although one of them should be red. If I hover over the button that should be red, the button appears red. If I change the order of the css definitions, the green buttons become red while hovering over the button that should be green but is red becomes green. So I suppose that my css definition at least is somewhat correct. But I'm not sure about this. 

Reproducible: Always

Comment 1 Sebastian Bauer

2011-10-17 07:46:35 EDT

Created attachment 205309 [details]
The CSS file for the test

Comment 2 Sebastian Bauer

2011-10-17 07:47:16 EDT

Created attachment 205310 [details]
The test application

Comment 3 Sebastian Bauer

2011-10-17 07:48:23 EDT

Created attachment 205311 [details]
The configurator

Comment 4 Ivan Furnadjiev

2011-10-17 10:00:24 EDT

The problem is in QxImage#hashCode, which returns same hashCode for different gradients.

Comment 5 Cole Markham

2011-10-17 10:55:32 EDT

I would say more precisely that the problem is that ImagePropertyAdapter.getKey uses the QxImage.hashCode instead of using a key guaranteed to be unique. The same could be said for all of the adapters in ThemePropertyAdapterRegistry.

Comment 6 Ivan Furnadjiev

2011-10-17 11:00:49 EDT

Make the multipliers smaller in QxImage#hashCode to avoid out of integers range. Changes are in CVS HEAD.

Comment 7 Ralf Sternberg

2011-10-17 18:30:17 EDT

I don't understand how this fix will _reliably_ solve the issue. Could you explain why the collisions occurred and why the smaller values prevent this?

Apart from this, I agree with Cole that ImagePropertyAdapter.getKey methods could be implemented better than using Object#hashCode(). But we should also keep the strings short as they are send over the wire.

Comment 8 Ivan Furnadjiev

2011-10-18 01:30:22 EDT

(In reply to comment #7)
> I don't understand how this fix will _reliably_ solve the issue. Could you
> explain why the collisions occurred and why the smaller values prevent this?
> 
> Apart from this, I agree with Cole that ImagePropertyAdapter.getKey methods
> could be implemented better than using Object#hashCode(). But we should also
> keep the strings short as they are send over the wire.
I agree with you that this fix is not 100% reliable - probably with 10 stop colors in the gradient the hash code will exceed the max integer value again. But I don't see such a real use case. I've added a JUnit test with 5 stop colors + start and end color and there is no collision.
I agree with Cole too, that we have to find a proper implementation of ImagePropertyAdapter.getKey that guarantee the unique key.

Comment 9 Ivan Furnadjiev

2011-10-18 03:26:13 EDT

Here is an example of calculation collision:
-2104393728 * 31 + 1113587712 + -2104393728 = -1802502144
43089920 * 31 + 1113587712 + 43089920 = -1802502144

Comment 10 Ivan Furnadjiev

2011-10-28 12:52:48 EDT

Just for the record - QxImage#hashCode now uses CRC32.

Comment 11 Ralf Sternberg

2011-10-29 05:06:02 EDT

One more note for the record: bug 362390 suggests a proper fix.