Re: next steps for touch support in GTK+
- From: Paul Davis <paul linuxaudiosystems com>
- To: Emmanuele Bassi <ebassi gmail com>
- Cc: gtk-devel-list gnome org
- Subject: Re: next steps for touch support in GTK+
- Date: Sat, 4 Aug 2012 09:14:13 -0400
On Sat, Aug 4, 2012 at 3:50 AM, Emmanuele Bassi
<ebassi 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" ...
and yet another case of "I don't know that, so I'll make stuff up".
On 2 August 2012 14:11, Paul Davis <
paul 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"
> add TouchSpinButton or something and
> leave the old one alone.
I have a brilliant idea instead: why don't you write your own widget
if you are relying on specific appearance and behaviour?
as you know, i generally do when it becomes necessary.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]