Bugzilla – Full Text Bug Listing
| Summary: | Scrollbar.getSelection() behavior differs greatly on Linux GTK | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Tiede <markus.tiede> | ||||||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | eclipse.felipe | ||||||||
| Version: | 3.7 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux-GTK | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 200932 [details]
Windows 2008 32bit behavior
Created attachment 200933 [details]
Mac OS X 10.6.8 64bit Cocoa behavior
This is not a bug. The meaning of selection value depends in the native control implementation. On GTK, the GTK developer chose to a pixel based scrollbar. On Win32 and Cocoa the scrollbar is item based. closing as wont fix. |
Created attachment 200931 [details] Fedora 8 GTK 32bit behavior The SWT API behavior differs greatly when running on Linux GTK: Calling getSelection() on a Scrollbar, e.g. a List's getVerticalBar(), returns differently scaled selections for the current Scrollbar state, as soon as the Scrollable is scrolled to display a list item. See the attached screenshots for further information: I used Mac OS X 10.6 Cocoa and Windows 2008 32bit as reference platforms to show the "normal" behavior. In addition to that I started the same application on Fedora 8 GTK 32bit. I "produced" the output as follows: - launch the snippet application, re-size it to show only e.g. 4 items, place it to the top (to avoid too big screen coordinates - easier to read and understand ;) ) - select the first item 0 and successively select item n + 1 and so on - as soon as the scrolling starts (In my case item 3) the behavior differs on Linux GTK