Bug 290459 – SWT Slider should simulate correct values on broken Gtk installations < 2.6

Bug 290459 - SWT Slider should simulate correct values on broken Gtk installations < 2.6


Summary:	SWT Slider should simulate correct values on broken Gtk installations < 2.6

Status:	CLOSED WONTFIX

Product:	Platform
Classification:	Eclipse
Component:	SWT
Version:	3.4.1
Hardware:	PC Linux

Importance:	P3 normal (vote)
Target Milestone:	---
Assigned To:	Platform-SWT-Inbox
QA Contact:

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2009-09-24 17:17 EDT by Dilton McGowan II
Modified:	2014-01-21 04:37 EST (History)
CC List:	4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Dilton McGowan II

2009-09-24 17:17:25 EDT

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.14) Gecko/2009090216 Ubuntu/9.04 (jaunty) Firefox/3.0.14 GTB5
Build Identifier: M20080911-1700

The below old Gtk bug still has the power to affect RHEL 4 customers. SWT obligingly reports the click values PAGEUP, DOWN, ARROWUP, etc. as handed to it by GTk. On Gtk < 2.6, the SWT Slider widget reports 0, just 0.

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

SWT in these cases, since it knows what the user clicked, the arrow or the page area of the Slider should do the right thing and report the value.


Reproducible: Always

Steps to Reproduce:
1. Easiest is to use this Snippet: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/
2. It works on Windows XP and Ubuntu 9.04 and fails reporting SWT.NONE (0) on RHEL 4.

Comment 1 Markus Keller

2009-09-25 08:31:27 EDT

That's SWT and version 3.4.1, right?

Comment 2 Dilton McGowan II

2009-09-25 11:27:13 EDT

(In reply to comment #1)
> That's SWT and version 3.4.1, right?

Comment 3 Dilton McGowan II

2009-09-25 11:28:21 EDT

(In reply to comment #2)
> (In reply to comment #1)
> > That's SWT and version 3.4.1, right?

Sorry about the duplication there. Yes it's Eclipse 3.4.1 and the SWT that comes with it.

Comment 4 Markus Keller

2009-09-28 08:45:51 EDT

(In reply to comment #2)
Setting right Product and Component fields again.

Comment 5 Felipe Heidrich

2009-09-28 09:10:23 EDT

(In reply to comment #0)
> 1. Easiest is to use this Snippet:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/

There is over 3 hundred snippet in that folder, can you be more specific ?

Thank you

Comment 6 Dilton McGowan II

2009-09-28 11:20:27 EDT

(In reply to comment #5)
> (In reply to comment #0)
> > 1. Easiest is to use this Snippet:
> > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/
> 
> There is over 3 hundred snippet in that folder, can you be more specific ?
> 
> Thank you

Hmm, thought the whole link was posted. Here is the page, it's the only Slider snippet, I found the page using Google, "swt snippets":
http://www.eclipse.org/swt/snippets/

On the page search for Slider.

Comment 7 Dilton McGowan II

2009-09-28 11:24:15 EDT

(In reply to comment #4)
> (In reply to comment #2)
> Setting right Product and Component fields again.

For the record, when I posted the first reply, Bugzilla prompted for I think it was the Eclipse version number before it would let me post. Whatever fields Bugzilla changed, it did on its own accord.

Comment 8 Felipe Heidrich

2009-09-28 16:30:44 EDT

(In reply to comment #0)
> SWT in these cases, since it knows what the user clicked, the arrow or the page
> area of the Slider should do the right thing and report the value.

Not true. SWT doesn't know what cause the change in the range.
Mouse events are only one possibility.
Key events also cause changes in the range's position. It is unlikely, but possible the user customize the keybinding for the control.
The position of the range can also be changed programmatically.

I not sure it is possible for SWT to guess what caused the ::value_changed signal.

Comment 9 Dilton McGowan II

2009-09-29 13:32:02 EDT

(In reply to comment #8)
> (In reply to comment #0)
> > SWT in these cases, since it knows what the user clicked, the arrow or the page
> > area of the Slider should do the right thing and report the value.
> 
> I not sure it is possible for SWT to guess what caused the ::value_changed
> signal.

The slider moves when clicked. I checked slider.getSelection and the int is incremented by 1 for arrow clicks and 10 for page area clicks. Maybe we
can use this as a workaround in the selection listener and ignore event.detail?

Comment 10 Dilton McGowan II

2009-09-30 13:50:36 EDT

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #0)
> > > SWT in these cases, since it knows what the user clicked, the arrow or the page
> > > area of the Slider should do the right thing and report the value.
> > 
> > I not sure it is possible for SWT to guess what caused the ::value_changed
> > signal.
> 
> The slider moves when clicked. I checked slider.getSelection and the int is
> incremented by 1 for arrow clicks and 10 for page area clicks. Maybe we
> can use this as a workaround in the selection listener and ignore event.detail?

We ended up implementing this and adding a key listener to handle key events. It is working out well. Since SWT has enough information already with slider.getSelection, it seems reasonable still to ask that SWT handle this automatically in cases where the underlying OS reports SWT.NONE for event.detail.

Comment 11 Alexander Kurtakov

2014-01-21 04:37:36 EST

SWT now requires GTK 2.10 or newer. Closing the bug.