Bug 22320 - Coolbar - delete item behavior problem
Summary: Coolbar - delete item behavior problem
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 2.0.1   Edit
Assignee: Felipe Heidrich CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-08-09 13:32 EDT by Lynne Kues CLA
Modified: 2002-08-21 15:09 EDT (History)
0 users

See Also:


Attachments
test case jar file (5.78 KB, application/octet-stream)
2002-08-09 13:40 EDT, Lynne Kues CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lynne Kues CLA 2002-08-09 13:32:38 EDT
Build 2.0.1 20020807.

1. Run the attached test case.
2. Press the Delete/Add button multiple times.  This removes the second item, 
then adds it back.  Notice that the item is not added back in its original spot 
and keeps sliding over as you press the Delete/Add button.

On Windows, this behavior does not occur.  On Linux, when the item is deleted 
the space that it occuppied is added to the first item, so adding the item back 
at its original spot doesn't work as expected.  The emulated behavior should be 
like the Windows behavior.
Comment 1 Lynne Kues CLA 2002-08-09 13:40:15 EDT
Created attachment 1824 [details]
test case jar file
Comment 2 Felipe Heidrich CLA 2002-08-09 14:10:24 EDT
To fix this is just a matter of removing the last lines of removeItemFromRow.
But, this will cause the emulated coolbar to changed the position of the next
item of row when a is removed from the row by disposing of the item (what is ok
and will fix the problem) or by dragging it to another row (what is bad but
happens on windows).

I think it's not a friendly behavior change the position of a item "B" when you
are draging a item "A".

In short, straithforward fix for this will add to the emulated coolbar a "bad
behavior" that  does exist on windows, but it can be avoid by passing a flag.
My question is: should this behavior be emulated anyway ?

I'll discuss it with SN.


that's a fix:


/**
 * Remove the item from the row. Adjust the x and width values
 * appropriately.
 */
void removeItemFromRow(CoolItem item, int rowIndex) {
	int index = findItem(item).x;
	int newLength = items[rowIndex].length - 1;
	Rectangle itemBounds = item.getBounds();
	if (newLength > 0) {
		CoolItem[] newRow = new CoolItem[newLength];
		System.arraycopy(items[rowIndex], 0, newRow, 0, index);
		System.arraycopy(items[rowIndex], index + 1, newRow, index, newRow.length - index);
		items[rowIndex] = newRow;
	}
	else {
		CoolItem[][] newRows = new CoolItem[items.length - 1][];
		System.arraycopy(items, 0, newRows, 0, rowIndex);
		System.arraycopy(items, rowIndex + 1, newRows, rowIndex, newRows.length - rowIndex);
		items = newRows;
		return;
	}
//
if (index == 0) {
//
	CoolItem first = items[rowIndex][0];
//
	Rectangle bounds = first.getBounds();
//
	int width = bounds.x + bounds.width;
//
	first.setBounds(0, bounds.y, width, bounds.height);
//
	first.requestedWidth = width;
//
	redraw(bounds.x, bounds.y, CoolItem.MINIMUM_WIDTH, bounds.height, false);
//
} else {
//
	CoolItem previous = items[rowIndex][index - 1];
//
	Rectangle bounds = previous.getBounds();
//
	int width = bounds.width + itemBounds.width;
//
	previous.setBounds(bounds.x, bounds.y, width, bounds.height);
//
	previous.requestedWidth = width;
//
}
}



Comment 3 Steve Northover CLA 2002-08-12 13:39:33 EDT
Fixed > 20020812 and in R2.0.1