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

Bug 314421

Summary: [Theming][Tree] Improve background-color/selection theming
Product: [RT] RAP Reporter: Tim Buschtoens <tbuschto>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: bbarzu, shashwat.work, steffen, tbuschto
Version: 1.3   
Target Milestone: 1.4 M1   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 309519    
Bug Blocks: 320597    
Attachments:
Description Flags
Screenshots of the issue none

Description Tim Buschtoens CLA 2010-05-26 05:41:01 EDT
I have decided to open a seperate bug for this, as i don't want to bother with this issue any further while implementing the new Tree.

With SWT/win it's like this:
- Usually when selected, the label of the first column (the tree-column) changes its foreground and background. Not the entire cell, only the label.
- When FULL_SELECTION is used, the entire row changes its foreground/background.

With the old tree it's like this:
- FULL_SELECTION flag is not supported. (See Bug 206780)
- The TreeItem has themeable background-color, but it is not honored unless the item is selected.
- When the background-color is applied, its on the first columns label, though not exactly like in SWT.

The new tree should.
- Always honor the background-color.
- Support FULL_SELECTION

The problem is: What to do when the item is not selected and has a (theming) background color? Apply the background-color to the entire row or only the label? It would seem strange to change the theming-behavior depending on wether the item selected or not. (Which is what the new tree currently does.)

To solve this, i would suggest that:
a) We introduce a new subwidget "TreeItem-Label", which also gets the selected state if its either the first column or FULL_SELECTION is set.
b) FULL_SELECTION will be made available as a style for TreeItem (and label?).

Comments?
Comment 1 Steffen CLA 2010-06-01 06:26:02 EDT
291604
Comment 2 Bogdan B. CLA 2010-07-12 09:27:55 EDT
I had recently the requirement to transform a Table into a Tree. I had the surprise to discover that:
 - selection is supported only by the first (tree) column, even if SWT.FULL_SELECTION is used;
 - alternate-color (see TableItem:even, TableItem:even:hover) background is also only supported by the first column;

I checked the "Themeable RWT Widgets" section of the rap-tooling-1.3.0-R-20100615-1734.zip help and have seen that the following CSS classes, properties, states or styles that I would need are supported by Table but not by Tree:
Exist 			Does not exist		Properties, Styles, States

Table-Cell		Tree-Cell		<at all>	
Table-GridLine		Tree-GridLine		<at all>
TableColumn		TreeColumn		color, font
TableItem		TreeItem		:even, :hover
Table-Checkbox		Tree-Checkbox		width
Could you estimate if and when they would be available?

In the mean time, I shall test the Patch from 291604, or the solution from 218420.
Comment 3 Ralf Sternberg CLA 2010-07-18 05:22:19 EDT
(In reply to comment #2)
Before trying out patches, you should rather wait for the new Tree (bug 309519) which will replace the current implementation. The change will appear in CVS in the next weeks and will solve all these issues.
Comment 4 Tim Buschtoens CLA 2010-07-21 07:06:47 EDT
Created attachment 174831 [details]
Screenshots of the issue

The new Tree is now commited and supports FULL_SELECTION. However, the issue is still relevant when not using FULL_SELECTION, as demonstrated by this screenshot.
Comment 5 Tim Buschtoens CLA 2010-07-26 10:34:14 EDT
Fixed in CVS HEAD by using the selection state for the background-theming only when FULL_SELECTION is set, but always for the label-background. Therefore two different colors can be used for the same item at the same time.

Regarding Comment#2:
Those are all valid suggestions for enhancements, but mostly not directly related to this bug. You may open a seperate bug if you wish.
Comment 6 Bogdan B. CLA 2010-07-28 02:57:14 EDT
(In reply to comment #5)
> Regarding Comment#2:
> Those are all valid suggestions for enhancements, but mostly not directly
> related to this bug. You may open a seperate bug if you wish.

Done:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=320987