hi; On 4 August 2012 14:14, Paul Davis <p...@linuxaudiosystems.com> wrote:
> On Sat, Aug 4, 2012 at 3:50 AM, Emmanuele Bassi <eba...@gmail.com> wrote: > > [ ... ] > > and yet another case of "i'm so nervous and irritated by criticism of our > design decisions that i'll resort to calling people stupid" ... design has nothing to do with it, sorry to disappoint the conspiracy theorists. just another case of "somebody is wrong on the Internet" that I should know better not to reply to. >> and yet another case of "I don't know that, so I'll make stuff up". >> >> On 2 August 2012 14:11, Paul Davis <p...@linuxaudiosystems.com> wrote: >> >> >> === 3. SpinButton === >> >> Another option is introducing a complete new widget targeted at touch >> >> usage (similar to the one in iOS Garageband) [4] which Carlos >> >> implemented >> >> already [5]. The issue is here the height, which at least in a Sugar >> >> toolbar >> >> could be not as ideal and introducing a new widget. >> > >> > >> > votes++. The spin button in gtk3 has already been bastardized from its >> > original mouse/kbd/space-friendly form. >> >> yes, because 6x6 pixel targets are *sooooo* mouse friendly. > > > My remark consisted of a triple: "mouse/kbd/space-friendly". What that > meant, if you want it fully decomposed was: > > "its original form that was very favorable in terms of the space it used > and the amount of mouse/pointer motion required to move the value in two > different directions, and was clearly oriented towards being controlled by > either a mouse, whose pointer focus is small enough that the design worked, > or a keyboard (where the on-screen display size is irrelevant). the one > thing that it was not absolutely friendly towards is touch control, for > obvious reasons" just FYI, if you have a point to make, it helps actually making it - not writing down half-formed sentences and expecting people to deduce what you meant. "the previous design worked": here is where you and I completely disagree. moving the controls on the horizontal axis from the vertical does not impinge in the ability to change the values; it does allow increasing the target area to the height of the entry, instead of splitting it in half. it makes the target immediately recognisable and improves the chances of hitting the desired target. it also adds the ability to do things like a proper focus ring without cramming it in with the icon. if, with the older widget layout, you could hit either the up or down arrows at first sight, just by moving the pointer without fine control, then congrats: you either have a precise control on the pointer, or you have an accurate pointer device. neither of those two conditions are a given - and, actually, the latter is becoming the norm given the incredibly crappy trackpads that are now commonplace everywhere that does not have an Apple logo. if keyboard navigation is broken, that would warrant a bug, as it would be a pretty serious regression. touch had a factor in changing the layout of the SpinButton, but less than the considerations on accessibility and input devices that I outlined above; gtk+, unlike some applications, has the challenge of working on different form factors as well as different input methods, so we need to be touch-friendly - even if we're not touch-driven (and we most definitely are not). adding a TouchSpinButton would still be recommended, and probably will happen at some point; but it would also very likely have a *very* different layout than the current SpinButton anyway. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list