Poll #17

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Show All Polls | Show Comments | Submit Comment ]

Poll #17

Should the NumLock key be honored when pressing keys on the numeric keypad? (currently we ignore the NumLock state)
Yes, use NumLock 379 / 81%
No, keep it as it is 36 / 7%
I don't care 50 / 10%
465 total votes.
This poll is closed.

User Comments

Submit Comment ]

From James Cook, 11:13 May 20, 2004 (score=3)

Support the Numlock key, please.  My company has a 3D application we are thinking of moving to FLTK.  To make 3D navigation easy, we use the arrow keys, but PgUp and PgDn can be used for vertical control.  Thus the Numpad is great for navigation.

But other times, our users need to input a lot of numbers. Therefore having "real" Numlock support is important.
Reply ]

From Thomas, 05:42 May 15, 2004 (score=3)

I am a fanatic numpad user, and that's not because I'm stubborn. It's because when you navigate through your text document, the numpad is far superior to the arrow keys (IMHO, of course). With the numpad, you've got all of the usefull navigational keys (like PgUp, PgDw, Home, End, etc.) at your literal fingertips. It's really convenient. If you use the arrow keys, you constantly have to reach out to that block of keys above, which is just really badly placed... I've tried to use them many times, but felt so incapacitated each time, I just had to revert back to the numpad... Even though I'm somewhat amazed by how few people are actually aware of the power of the numpad, I know there are more people like me. Respecting numlock will make us happy.

Also, concerning the idea for making the behaviour optional: I honestly don't see the point. People that don't use the numpad for navigation always have numlock switched on, so it will not affect them in any way. People that switch off numlock do it for a reason.
Reply ]

From Galen Kannarr, 05:49 May 14, 2004 (score=2)

I personally don't use the numeric keypad (it's upside down from the phone!), but I think it is in FLTK's interest to help developers write applications which have a familiar look and feel to the user.  So I recommend support of the NumLock key.  But I like the suggestion for an option to go either way.  Should this be a compile-time or runtime option and what should be the default?  I'm not sure.
Reply ]

From Anonymous, 09:09 May 21, 2004 (score=2)

I'm afraid you have it a bit backwards. It is the phone that is up-side-down from what mechanical calculators had been doing for years.

Just consider... shouldn't the 'zero' button be near the 'one' button?  And shouldn't higher numbers be located higher on the device?

Also remember that this IS the phone company we are talking about.  The prototype for abusive monopolies (like the one spoiling the world of computing). They've already dictated too much to the world.
Reply ]

From Roman, 08:45 May 14, 2004 (score=1)

...runtime (shared libs?), default to recent behavior...
Reply ]

From Roman, 17:26 May 13, 2004 (score=2)

Well, i do not rely care (i would gladly cut off that part of the keyboard to have that little animal more close to my hands), but if there is going to be a change, could this behavior be "switchable" (and have the possibility of both ways)? It would be a shame to loose the possibility to distinguish between physically different keys...
Reply ]

From Anonymous, 00:29 Jan 14, 2005 (score=2)

I concur. fltk::num_lock_sensitive = false; fltk::num_lock_sensitive = true;

default is false for backward compatibility.
Reply ]

From Anonymous, 07:56 May 19, 2004 (score=1)

If you want to make the behaviour switchable, why not use the numlock key as the switch? Like this:

numlock on: old behaviour numlock off: new behaviour

Reply ]

From Matthias, 14:42 May 13, 2004 (score=2)

NumLock is really a pretty obsolete key. It is a left-over from times where keyboards had no arrow keys yet. I find it a waste to support, but unfortunatly, users seem to get upset when interfaces don't duplicate what they got accustomed to. I have heard people complain that their VCR did not blink 12:00 after a power failure. So lets make the 12:00 blink again.
Reply ]

From Anonymous, 13:14 May 17, 2004 (score=2)

Know how easy it is to "support it", I find the poll and discussion a waste, not the coding effort.
Reply ]

From Mike Sweet, 05:22 May 21, 2004 (score=3)

The reason for the poll is that this feature (ignoring numlock) has been in FLTK for a very long time. We want to make sure that we don't break a lot of applications by changing the behavior, thus the poll.
Reply ]

From Gavin, 19:13 May 29, 2004 (score=1)

This goes to the "Principle of Least Surprise".  The NumLock key is there for a reason, and users would be terribly confused if one FLTK application refused to recognise their keyboard properly when all other applications do.

It is a matter for the users to decide which keyboard, layout and settings they use.  We must respect this, and be consistent.
Reply ]

From Sean McInerney, 10:41 Jun 17, 2004 (score=1)

I heartily second this appraisal. Additionally, there have been no concerns raised over recognition of NumLock state breaking existing code. If the meaning of an input can depend on the system being in one of multiple states, it is difficuly to justify not recognizing all possible states.
Reply ]


Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.