Re: next steps for touch support in GTK+
On Sat, Aug 4, 2012 at 3:43 PM, Matthias Clasen matthias.cla...@gmail.com wrote: === 6. OSK widget context provider (e.g. search vs open vs go...) === Matthias said there was a patch floating around for that. I looked in the bugs with patches attached in bugzilla but could not find it. If someone knows where it is would be great. https://bugzilla.gnome.org/show_bug.cgi?id=651244 is the bug I had in mind. I've now updated that bug with what I intend to commit for 3.6 soon. Comments still appreciated. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On 08/04/2012 07:41 AM, Emmanuele Bassi 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. Just recently there was a discussion on this list about ways to better communicate between GTK+ devs and others including GTK+ users in order to attract potential contributors and keep GTK+ users in the loop as to the future of GTK+. For this reason I'm gratified to see this thread hit the devel list. It's interesting to be updated on the direction GTK+ is heading. That said, if the GTK+ developers cannot accept criticism of design decisions (you don't have to explain every little thing of course), or at least tolerate them (not the same as ignoring btw), then I fear we have the same problem that we had before, which is the perception that GTK+ developers are doing their own thing and not listening to the users. Maybe the only GTK+ users that matter are the Gnome developers, I don't know. But certainly at least two GTK+ users on this list have expressed the legitimate concern that the GtkSwitch widget has usability issues, which seems fair. They are definitely not wrong on the Internet. Doesn't mean they are right and that GTK+ should change direction, but reacting the way you did doesn't reflect well on the GTK+ developers. A more proper way to react may have been I can see your point, but current UI direction and usability research disagrees with you or we've received very positive feedback regarding this widget from GTK+ users and feel like this is the right direction to go. Agree to disagree, etc. Instead we're left wondering if GTK+ is just doing things because they're cool (IE Apple does it). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
Hi, I just went through a midnight read of this thread, might as well throw some ideas relating to the several points which have (or have not) been made. From a touchscreen perspective, you want to avoid spin buttons at large cost if not all cost. From my experience, in the context of a kiosk type machine (think touchscreen jukebox or point of sales unit or such), first of all you want every touchable area to be *at least* as large as an index finger, even then some people with huge fingers can and will be annoyed from using the interface. If you have a 15 or 17 monitor touchscreen to work with, as we did, then you will probably permit yourself some spin buttons in the operator/configuration screens... you wont put very many in that screen... and the up and down arrows will appear after the entry (not on top of each other but beside eachother, as Emmanuele mentioned that takes too much height to be usable at all with touch). However, even then with a 17 monitor we would never allow ourselves to place these spin buttons in any user screens, the operator of the jukebox has to spend time configuring the thing, you dont want to annoy users with spin buttons. On a tablet, if you really really cant avoid it, perhaps you can get away with using a spin button. On a handset, I think you can just forget about it, or limit yourself to having only one (or two ?) spin button visible at a time (perhaps inside a vertical scroll window, however sliders are usually better for this if exact precision is not an issue). Slider widgets need special care with touch as well, specifically you want a huge knob, and you want the indication of where you are to be indicated outside of the knob and not on top of the knob (perhaps the scale widget is an index into the alphabet, or a numerical value, you want to see that value outside the knob, not covered by your finger). Secondly on slider widgets, you generally dont want this awkward jumping by page size when the user touches the trough area. The user's intention with a scale widget is to first get the knob and then make a modification to the scroll position (Up and Down buttons positioned above and below the scale widget are helpful for fine grained modifications). So the correct behaviour is to allow the finger to slide into the trough area without modifying the scale value and allow the finger to Enter the knob area... once the finger has entered the knob's area then the knob should stick to the finger and move with it. a.) It should not jump unexpectedly towards your finger b.) It should not require that your finger cause the button-press-event to occur on the knob, it should instead be tollerant and allow the finger to slide into the knob area and control it. The slider behaviour is also very critical when the slider is controlling the master volume (of your home stereo system or whatever it is), of course you dont want the volume to jump up just because you missed the knob initially when trying to catch it). On bastardising the toolkit to get touchscreen support in GTK+, I personally never thought this was the point to touchscreen support in GTK+. It will definitely be useful if for instance, GTK+ makes some things possible on touchscreens which were not possible before, perhaps panning mode in scrolled windows is a good example, at least some features in basic widgets that you *need* in order to extend your UX to touchscreens. One thing I'm most certainly convinced of is that applications (or their user interfaces) will be written separately for touchscreen devices. You wont be able to ship exactly the same code on a touchscreen enabled device, set the gtk settings touchscreen mode = TRUE and just hope for the best... that will never happen, or perhaps I'll just have to see it to believe it. So yes I think it's completely logical to build a widget kit on top of GTK+ which is particularly suitable for touchscreen environments, in any case its what people will do (write custom widgets for touch in their own applications). I also believe that a GtkSwitch is programaticaly interchangable with a GtkToggleButton, and it's a bit confusing too... when one changes a toggle button to look switchy then one potentially needs to actually change code (i.e. that vfunc which I was overriding in togglebutton no longer compiles when I derive from switch ? ... I changed it for a switch and now GTK_IS_TOGGLE_BUTTON() fails for a switch ? can I connect it to that toggle action which I've been proxying my toggle buttons through like before ?... definitely seems awkward). Then again that's not really worth arguing, there wont be an api break till GTK+4 anyway so... Ok long night... food for though... lets sleep on it guys ;-) Cheers, -Tristan On Sat, Aug 4, 2012 at 8:15 PM, Simon Feltman s.felt...@gmail.com wrote: Toggle buttons and the switch widget both suffer usability problems for me. The visual look of a button represents an action to
Re: next steps for touch support in GTK+
hi; once again, from the department of I didn't bother to ask, so I'll make stuff up... On 2 August 2012 13:52, Morten Welinder mort...@gnome.org wrote: === 4. Which GTK+ widgets break with touch === The SpinButton item from above is one example of those. I really hope the solution is neither remove anything that doesn't work with touch or parallel widget hierarchy. GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. it does not perform the same action. But no, it is currently a totally separate widget not even derived from GtkButton. a GtkButton is a GtkContainer; adding widgets inside a light switch is pointless: how would that even work? not everything has to inherit from existing classes, *especially* if the behaviour is different (both from the user interaction standpoint *and* from the API standpoint). as a side question: do you think that I, and everyone who reviewed that patch, is stupid and doesn't know about the existence of GtkButton? really? all those questions have been posed and answered in the bug report that handled the introduction of the GtkSwitch widget. you may question the appearance of the widget (labels in, labels out, colors) but at least credit the people that wrote it some level of intelligence. 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
Re: next steps for touch support in GTK+
hi; 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 *so* mouse friendly. not. if you're gifted by an overabudance of fine motor skills, you'll also want to reduce all pointer targets to 2x2 pixels; if, on the other hand, you're like the rest of the human inhabitants of this planet, you'll see that small pointer targets are *bad*, and that even before touch enters the equation. to be honest, the current spin button is better, but designed for touch. no, not yet. 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? 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
Re: next steps for touch support in GTK+
hi; On 4 August 2012 00:05, Michael Natterer mi...@gimp.org wrote: On Thu, 2012-08-02 at 08:52 -0400, Morten Welinder wrote: GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. But no, it is currently a totally separate widget not even derived from GtkButton. I could not agree more. and I could agree with you, but then we'd both be wrong. 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
Re: next steps for touch support in GTK+
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 *so* 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
Re: next steps for touch support in GTK+
On Sat, Aug 4, 2012 at 3:44 AM, Emmanuele Bassi eba...@gmail.com wrote: GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. it does not perform the same action. That is a baseless assertion. Of course it does. And stop misquoting me, please. We're talking about two widgets that are both used to turn something off or on. And nothing else. How is that not the same function? In other words, is there a place where one of them is used that would not function right if the other one was substituted? as a side question: do you think that I, and everyone who reviewed that patch, is stupid and doesn't know about the existence of GtkButton? Nope, I don't. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
hi; On 4 August 2012 15:18, Morten Welinder mort...@gnome.org wrote: On Sat, Aug 4, 2012 at 3:44 AM, Emmanuele Bassi eba...@gmail.com wrote: GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. it does not perform the same action. That is a baseless assertion. Of course it does. And stop misquoting me, please. I do not misquote you, but I may be misunderstanding you: what do you mean what you say performs the same function? see below. We're talking about two widgets that are both used to turn something off or on. And nothing else. How is that not the same function? one implies a soft action (GtkToggleButton), whereas the other implies something similar of a hardware switch (GtkSwitch). they both have their use cases which are not interchangeable: https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget the page above should become part of the new Human Interface guidelines/design patterns. not every application should use switches, nor existing applications should be mindlessly migrated to moving from toggle and/or check buttons to switches. In other words, is there a place where one of them is used that would not function right if the other one was substituted? hopefully, the page above answers your questions; it can be improved if it doesn't. the short takeaway is that the switch should be used in specific cases, and that the way its been defined as a widget does not allow inheritance from GtkToggleButton or GtkButton (no label, no children, styling of trough and handle). 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
Re: next steps for touch support in GTK+
On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote: one implies a soft action (GtkToggleButton), whereas the other implies something similar of a hardware switch (GtkSwitch). As every user knows, widgets relay wishes to magic pixies. I wonder if that is soft or hard action, maybe it depends on how hard you need to beat the pixies to do what you want. Do you actually expect different kinds of on/off controls to be mixed wildly because each was selected based on how soft is the action it implies? they both have their use cases which are not interchangeable: https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget the page above should become part of the new Human Interface guidelines/design patterns. not every application should use switches, nor existing applications should be mindlessly migrated to moving from toggle and/or check buttons to switches. All cases listed there as good use cases of GtkSwitch would be – for me – improved by using a plain toggle button. It would take less horizontal space, it would be less wordy, it would not leave me wondering whether it shows ON when it is on or whether I should move it to ON if I want it ON (yes, I still do not remember it), it would not look trendy, and it would not have translation issues. In fact, even the ‘wrong’ checkbuttons would represent an improvement for me. I would also say the widgets are completely interchangeable, but forced to interpret the statement ‘their use cases are not interchangeable' somehow I would have to conclude that GtkSwitch has no meaningful use case at all. Could the page be improved to include this? In my opinion it could lead to a considerable simplification of the guidelines. the short takeaway is that the switch should be used in specific cases, and that the way its been defined as a widget does not allow inheritance from GtkToggleButton or GtkButton (no label, no children, styling of trough and handle). I am sorry but, again, this is just a recapitulation of the status quo. Stating it a hundered times does not make problems vanish magically even if you beat the pixies really hard with a switch. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
=== 6. OSK widget context provider (e.g. search vs open vs go...) === Matthias said there was a patch floating around for that. I looked in the bugs with patches attached in bugzilla but could not find it. If someone knows where it is would be great. https://bugzilla.gnome.org/show_bug.cgi?id=651244 is the bug I had in mind. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
Toggle buttons and the switch widget both suffer usability problems for me. The visual look of a button represents an action to be performed in my mind, perhaps why it was referred to it as a soft-action? So when a button is stateful it can create ambiguity depending on the text of the button. The old, Does it perform the action shown on the label or does the label reflect the current state? This causes dissonance in my mind which can hopefully be resolved by the widget having another visual indication of the state (the depressed look). A typical example of this failure is with Glades usage of toggle buttons on a selected widgets properties (don't mean to offend anyone here, just stating my experience!). This is further confused by the text changing when you press the button to Yes or No. Moving on to the switch widget, I think it mostly suffers the same issues I've described. Does the text on the switch widget represent the current state or the action of setting the state to on or off. Again the visual indication barely saves me here (having it highlighted to blue). Given this, the visual indication aside from the text is what I use to determine the state of either a toggle or switch. This makes me think the text on the widget only confuses things and the widget could simply be a checkbox which would resolve all visual ambiguity. However, I do see value in what is described in the UX guidelines regarding the switch widget and associating it with things that take time (not just a simple checkbox state). The guidelines also don't describe explicit styling of the switch which is my problem with it. I think the visual ambiguity could easily be fixed by showing both available states, looks like it is already being discussed here: https://bugzilla.gnome.org/show_bug.cgi?id=644658 -Simon On Sat, Aug 4, 2012 at 8:47 AM, David Nečas y...@physics.muni.cz wrote: On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote: one implies a soft action (GtkToggleButton), whereas the other implies something similar of a hardware switch (GtkSwitch). As every user knows, widgets relay wishes to magic pixies. I wonder if that is soft or hard action, maybe it depends on how hard you need to beat the pixies to do what you want. Do you actually expect different kinds of on/off controls to be mixed wildly because each was selected based on how soft is the action it implies? they both have their use cases which are not interchangeable: https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget the page above should become part of the new Human Interface guidelines/design patterns. not every application should use switches, nor existing applications should be mindlessly migrated to moving from toggle and/or check buttons to switches. All cases listed there as good use cases of GtkSwitch would be – for me – improved by using a plain toggle button. It would take less horizontal space, it would be less wordy, it would not leave me wondering whether it shows ON when it is on or whether I should move it to ON if I want it ON (yes, I still do not remember it), it would not look trendy, and it would not have translation issues. In fact, even the ‘wrong’ checkbuttons would represent an improvement for me. I would also say the widgets are completely interchangeable, but forced to interpret the statement ‘their use cases are not interchangeable' somehow I would have to conclude that GtkSwitch has no meaningful use case at all. Could the page be improved to include this? In my opinion it could lead to a considerable simplification of the guidelines. the short takeaway is that the switch should be used in specific cases, and that the way its been defined as a widget does not allow inheritance from GtkToggleButton or GtkButton (no label, no children, styling of trough and handle). I am sorry but, again, this is just a recapitulation of the status quo. Stating it a hundered times does not make problems vanish magically even if you beat the pixies really hard with a switch. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On Thu, 2012-08-02 at 08:52 -0400, Morten Welinder wrote: GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. But no, it is currently a totally separate widget not even derived from GtkButton. I could not agree more. --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
Hey :), On jue, 2012-08-02 at 11:42 +0200, Simon Schampijer wrote: Hi, there have been several discussions around GTK+ touch support during GUADEC. To get a good touch experience we talked about the following points. I ordered them by priority that we set in Sugar development for them. If you come across something that we missed, please comment. === 1. Text selection === A lot of work has been going into text selection and manipulation those days from the design and implementation point of view. The current design ideas can be seen at [1]. Carlos created universally usable handles (implemented using GtkWindows) Just a minor annotation, GDK_WINDOW_TEMP GdkWindows to adjust the selection and wrote the code to use them in GtkEntry and the GtkTreeView in this branch [2]. The idea is to make those available as well for external widgets, e.g. in Abiword or WebKitGTK. I'll update that branch in the following days with opposite-sided handles and other minor improvements. We discussed as well how the Edit Palette should look like and agreed loosely on using GtkWindows instead of an Overlay for this to handle cases like resizing windows for example. Something to check is if we want to allow to adjust the selection in moving the right handle over the left one. Both iOS and Android do block that and snap to the minimum selection when releasing the finger which seems a good interaction model and limits complexity and edge cases. Given the loose interaction between the GtkTextHandle helper object and the text widgets, that'd be per-widget implementation, hard to avoid though. Another thing to make sure is that we do not use fixed positions in regards to Wayland. === 2. OSK - Slide canvas vertically to keep insertion point visible === Carlos has been working on this already. He will send a mail with more info about it. To get more background about the issue itself a whitepaper is available at [3]. I'll better advance the rationale here. The target of this work was to extend GtkIMContext to let onscreen keyboards announce the extents the keyboard is going to take, so for example (mostly?) GtkScrolledWindows can move the focus to a visible location if necessary. Likely the root question here is whether this should be entirely a compositor task or a toolkit-level task, if this is handled by the compositor (eg. moving the window altogether) there's probably some important context lost if the window scrolls upwards (toolbars, etc). If this is fully handled by the toolkit there are other corner cases as well, such as scrolled windows falling entirely within the keyboard extents. So probably a mixed approach would be best, although it's a bit unclear when applies what and how to best coordinate those. I've pushed wip/im-osk-position with the initial work about this, it's notably missing a GdkDisplay/Screen argument in the signaling, and this concept altogether is likely not quite friendly with wayland... === 3. SpinButton === We had several discussions around the SpinButton. One thing that came up is why we do not want to reuse the existing one. One option is to put the '' on the left side (this could be done by a property for example). When the SpinButton was redesigned they put the and close together to not interfere with other widgets at the left side. Having something like [button] | 3| might not be as clear. That at last was the reasoning for putting the stepper buttons next to each other. In touch the interaction gets a bit fiddly having the buttons next to each other that is why we propose that configuration option. We would keep the entry widget, on touch you can use the OSK to set a value, or you can set it to be non-editable. Furthermore you can accept a vertical swipe to alter the value, implementing this would be a perfect use case for EventControllers. It also could be a good use for captured events, so touch events only focus the entry on tap, and change-value-as-you-swipe works after a threshold. 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. Another open question there is about the widget implementing GtkOrientable, so buttons (and the swipe gesture) can be aligned on both axes. The big plus of this widget though is the better behavior on touch devices, so it could maybe stand as less useful if GtkSpinButton gains a similar behavior. Cheers, Carlos === 4. Which GTK+ widgets break with touch === The SpinButton item from above is one example of those. Another one was the Combobox which has been fixed by Carlos and landed in master [6]. I will have a look if I come across more. Feel free to add if you are aware of more blockers. === 5. Widget Gestures (e.g.
Re: next steps for touch support in GTK+
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. add TouchSpinButton or something and leave the old one alone. 'bastardized' is a rather unfriendly term for improved. Maybe explain how the old design was mouse friendly, or how the new one is not keyboard friendly ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On 12-08-03 09:21 PM, Matthias Clasen wrote: 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. add TouchSpinButton or something and leave the old one alone. 'bastardized' is a rather unfriendly term for improved. Maybe explain how the old design was mouse friendly, or how the new one is not keyboard friendly ? This issue could be resolved by making a mobile UI toolkit in parallel to (and based on the same libraries as) the existing desktop toolkit (maybe gtk-mobile-3.0?). Why not have a separate set of mobile/touch widgets in a separate library? In terms of usability, desktop and mobile interfaces are completely different beasts and bastardizing[1] (not my word) one toolkit type into the other is bound to make everyone annoyed. Cheers, Matthew Brush (random GTK-app developer and armchair critic) [1] http://developer.gnome.org/gtk3/3.4/GtkColorChooserDialog.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
next steps for touch support in GTK+
Hi, there have been several discussions around GTK+ touch support during GUADEC. To get a good touch experience we talked about the following points. I ordered them by priority that we set in Sugar development for them. If you come across something that we missed, please comment. === 1. Text selection === A lot of work has been going into text selection and manipulation those days from the design and implementation point of view. The current design ideas can be seen at [1]. Carlos created universally usable handles (implemented using GtkWindows) to adjust the selection and wrote the code to use them in GtkEntry and the GtkTreeView in this branch [2]. The idea is to make those available as well for external widgets, e.g. in Abiword or WebKitGTK. We discussed as well how the Edit Palette should look like and agreed loosely on using GtkWindows instead of an Overlay for this to handle cases like resizing windows for example. Something to check is if we want to allow to adjust the selection in moving the right handle over the left one. Both iOS and Android do block that and snap to the minimum selection when releasing the finger which seems a good interaction model and limits complexity and edge cases. Another thing to make sure is that we do not use fixed positions in regards to Wayland. === 2. OSK - Slide canvas vertically to keep insertion point visible === Carlos has been working on this already. He will send a mail with more info about it. To get more background about the issue itself a whitepaper is available at [3]. === 3. SpinButton === We had several discussions around the SpinButton. One thing that came up is why we do not want to reuse the existing one. One option is to put the '' on the left side (this could be done by a property for example). When the SpinButton was redesigned they put the and close together to not interfere with other widgets at the left side. Having something like [button] | 3| might not be as clear. That at last was the reasoning for putting the stepper buttons next to each other. In touch the interaction gets a bit fiddly having the buttons next to each other that is why we propose that configuration option. We would keep the entry widget, on touch you can use the OSK to set a value, or you can set it to be non-editable. Furthermore you can accept a vertical swipe to alter the value, implementing this would be a perfect use case for EventControllers. 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. === 4. Which GTK+ widgets break with touch === The SpinButton item from above is one example of those. Another one was the Combobox which has been fixed by Carlos and landed in master [6]. I will have a look if I come across more. Feel free to add if you are aware of more blockers. === 5. Widget Gestures (e.g. swipe, pinch) === The desired implementation is to use EventControllers for that. The work has currently stagnated on that end. In Sugar we could implement this at our toolkit level but an upstream solution would be desired at least longer term. === 6. OSK widget context provider (e.g. search vs open vs go...) === Matthias said there was a patch floating around for that. I looked in the bugs with patches attached in bugzilla but could not find it. If someone knows where it is would be great. Regards, Simon [1] https://live.gnome.org/GnomeOS/Design/Whiteboards/Selections [2] http://git.gnome.org/browse/gtk+/log/?h=touch-text-selection [3] https://wiki.maliit.org/images/a/a7/Technical-overview-widget-relocation.pdf (from https://wiki.maliit.org/Documentation#Technical_documentation) [4] http://wiki.sugarlabs.org/go/File:Ios_spinbutton.JPG [5] https://bugzilla.gnome.org/show_bug.cgi?id=678108 [6] https://bugzilla.gnome.org/show_bug.cgi?id=678113 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
=== 4. Which GTK+ widgets break with touch === The SpinButton item from above is one example of those. I really hope the solution is neither remove anything that doesn't work with touch or parallel widget hierarchy. GtkSwitch bugs me. It really should just have been a styling of the toggle button since it performs the same function with a different look. But no, it is currently a totally separate widget not even derived from GtkButton. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On Thu, Aug 2, 2012 at 5:42 AM, Simon Schampijer si...@schampijer.dewrote: === 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. add TouchSpinButton or something and leave the old one alone. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
