tktable-tile-dev

[Tile-dev] Feature Request: combobox text field mousewheel binding

[Mark G. <du...@ya...>]

Another feature which IMHO should be part of tile.
When the text field has the focus, moving the mouse wheel should change the selection. Windows XP combos work this way.
 
Thanks,
 
Mark

		
---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Find what you need with new enhanced search. Learn more.

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Pat T. <pat...@us...>]

Mark Garvey <du...@ya...> writes:

>Another feature which IMHO should be part of tile.
>When the text field has the focus, moving the mouse wheel should change the selection. Windows XP combos work this way.

Not always a good thing. I have a number of people raising a bug on
our bugzilla installation that an accidental slip of the mouse wheel
in the wrong place can cause mail to be sent to everyone.

I wonder if this 'feature' is the cause of some of the more famous
internet e-mail disasters :/


-- 
Pat Thoyts          http://www.zsplat.freeserve.co.uk/resume.html
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

RE: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Jeff H. <je...@Ac...>]

> >Another feature which IMHO should be part of tile.
> >When the text field has the focus, moving the mouse wheel should change 
> >the selection. Windows XP combos work this way.
> 
> Not always a good thing. I have a number of people raising a 
> bug on our bugzilla installation that an accidental slip of 
> the mouse wheel in the wrong place can cause mail to be sent 
> to everyone.

misfeature or not, it is dangerous to go against standards.

Jeff

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Brian G. <bgr...@mo...>]

Jeff Hobbs wrote:

>>>Another feature which IMHO should be part of tile.
>>>When the text field has the focus, moving the mouse wheel should change 
>>>the selection. Windows XP combos work this way.
>>>      
>>>
>>Not always a good thing. I have a number of people raising a 
>>bug on our bugzilla installation that an accidental slip of 
>>the mouse wheel in the wrong place can cause mail to be sent 
>>to everyone.
>>    
>>
>
>misfeature or not, it is dangerous to go against standards.
>  
>

Standard or no, I think this is just plain broken.  I can't tell you how 
many times a day I mouse wheel over a different panel only to have some 
combo box scroll instead because that is where the focus is.  If the 
pointer was over the combo box, it would be one thing, but the pointer 
is often on the other side of the screen as are my eyes.

This is really more of a problem with the mouse scroll/pointer then the 
combo box on Windows, but the combination just makes the feature a 
problem rather than a convenience.

-Brian

-- 
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-------------------------------------------------------------

RE: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Jeff H. <je...@Ac...>]

> >>>Another feature which IMHO should be part of tile.
> >>>When the text field has the focus, moving the mouse wheel should 
> >>>change
> >>>the selection. Windows XP combos work this way.
> >>>
> >>Not always a good thing. I have a number of people raising a
> >>bug on our bugzilla installation that an accidental slip of 
> >>the mouse wheel in the wrong place can cause mail to be sent 
> >>to everyone.
> >
> >misfeature or not, it is dangerous to go against standards.
> 
> Standard or no, I think this is just plain broken.  I can't tell you how 
> many times a day I mouse wheel over a different panel only to have some 
> combo box scroll instead because that is where the focus is.  If the 
> pointer was over the combo box, it would be one thing, but the pointer 
> is often on the other side of the screen as are my eyes.

I will have to disagree on the misfeature, as I have used it
myself intentionally, as well as having been caught by it.
However, you have to look at the design of the widget to see
that the mousewheel behavior is 100% appropriate.  It is the
same as a 1-line listbox, and you would want to take away
mousewheel from a listbox, would you?

Jeff

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Brian G. <bgr...@mo...>]

Jeff Hobbs wrote:

>>>>>Another feature which IMHO should be part of tile.
>>>>>When the text field has the focus, moving the mouse wheel should 
>>>>>change
>>>>>the selection. Windows XP combos work this way.
>>>>>
>>>>>          
>>>>>
>>>>Not always a good thing. I have a number of people raising a
>>>>bug on our bugzilla installation that an accidental slip of 
>>>>the mouse wheel in the wrong place can cause mail to be sent 
>>>>to everyone.
>>>>        
>>>>
>>>misfeature or not, it is dangerous to go against standards.
>>>      
>>>
>>Standard or no, I think this is just plain broken.  I can't tell you how 
>>many times a day I mouse wheel over a different panel only to have some 
>>combo box scroll instead because that is where the focus is.  If the 
>>pointer was over the combo box, it would be one thing, but the pointer 
>>is often on the other side of the screen as are my eyes.
>>    
>>
>
>I will have to disagree on the misfeature, as I have used it
>myself intentionally, as well as having been caught by it.
>However, you have to look at the design of the widget to see
>that the mousewheel behavior is 100% appropriate.  It is the
>same as a 1-line listbox, and you would want to take away
>mousewheel from a listbox, would you?
>  
>

No, but M$ really needs to fix the Mouse Wheel/Pointer problem. 

I guess my point is M$ can get things wrong also.  Just because they do 
something some way doesn't make it a standard.

-Brian

-- 
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-------------------------------------------------------------

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Joe E. <jen...@fl...>]

Brian Griffin wrote:
> I guess my point is M$ can get things wrong also.  Just because they do
> something some way doesn't make it a standard.

+1.  Windows gets a lot of things right, but not everything.
If Tk can do better, it should.

That said, I'm not sure where this particular feature falls 
on the right thing/wrong thing spectrum (my home machine has a 
trackball, no mousewheel, so I'm a little bit in the dark here ... :-)

The convention on X11 (which Tk follows) is that mousewheel 
events are delivered to the window under the mouse pointer, 
not the one with keyboard focus.

With this model, comboboxes are less likely to be accidentally
mousewheeled; OTOH, it also makes combobox mousewheel bindings
somewhat less useful.

I thought there was talk of making Tk on Windows work the
same way (i.e., mousewheel events follow pointer instead
of focus) -- what became of that?

Implementation question: should the selected item "wrap around"
when scrolled with the mousewheel, or should scrolling up
(resp down) stop at the first (resp last) item?


--Joe English

  jen...@fl...

RE: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Jeff H. <je...@Ac...>]

> The convention on X11 (which Tk follows) is that mousewheel=20
> events are delivered to the window under the mouse pointer,=20
> not the one with keyboard focus.
>=20
> With this model, comboboxes are less likely to be=20
> accidentally mousewheeled; OTOH, it also makes combobox=20
> mousewheel bindings somewhat less useful.
>=20
> I thought there was talk of making Tk on Windows work the
> same way (i.e., mousewheel events follow pointer instead
> of focus) -- what became of that?

http://www.tcl.tk/cgi-bin/tct/tip/171.html

"Instead of requiring a widget to have [focus] to receive MouseWheel =
events,
the new proposal operates with MouseWheel as a global binding. When =
fired, it
first does a safety check to prevent double-firing if an existing =
MouseWheel
binding is on the widget. It then finds the widget which the mouse if =
over and
uses that as the target for the scrolling event. If that widget doesn't =
exist
(usually meaning that it returned {} indicating we are outside the Tk =
app),
then use the widget which has the actual [focus]."

So this proposal doesn't avoid all the Combobox focus issues,
but it will avoid the most common ones.

> Implementation question: should the selected item "wrap=20
> around" when scrolled with the mousewheel, or should=20
> scrolling up (resp down) stop at the first (resp last) item?

Hmmm, I haven't seen wrapping done with mousewheel scrolling.
The mousewheel is an adjunct to the scrollbar, and scrollbars
don't wrap.


Jeff