Re: Volunteer

[Lieven van der Heide <lievenvanderheide gmail com>]

Hi Matthias,

For a start, I'll pick up your first suggestion.

>> For your nested scrolling use case, I think it a good start would be a somewhat convincing testcase. In my experience nested scrolling is almost always a source of frustration and best avoided...

A test case I was thinking of was to implement an image gallery similar to those on mobile devices: Swiping left and right scrolls between images, pinching would let you zoom, and when you've zoomed such that the image is larger than the area, just dragging lets you scroll the image, until you've reached a boundary, after which you'd start dragging the neighboring image in. I'm actually not even sure if a scrolled windows would be the best way to implement this. Some new features would have to be added anyway: Support for paging (ie. bounce back to a page boundary after the drag is released), support for zooming, and probably an option to hide scrollbars. 

A problem we would have with paging would be that the start of a page would change when the scrolled window gets resized, and to accomodate to that we would need to automatically scroll the widget while it's being resized. Because page boundaries farther away from the origin might then move much faster than the amount the size of the scrolled window changed, this might give very weird results. In the case of the image gallery, this wouldn't be a problem, because you would always change the size of the children to match the size of the visible area of the outer scrolled window.

An option would of course be to use a GtkStack instead, and add support for swiping between pages (as you suggested). Personally, I'd like it if it'd still behaved a bit like a paging scrolled window, ie: it starts scrolling as soon as you start dragging, and bounces to the nearest page when you release the touch (probably taking velocity into account, so a very short but fast swipe will move to the next page).

But still, I think that to implement this, we might still need functionality which lets widgets propagate only a part of a drag gesture to its parent widget.

Regards,

Lieven

On Wed, Jun 4, 2014 at 11:13 PM, Matthias Clasen <matthias clasen gmail com> wrote:

Hey Lieven,

great that you are interested in helping out ! I'm sure you'll find
something interesting to work on. Here's a few ideas:

- pick any widget that is currently still using a button press event
handler, and convert it to using event controllers instead

- add support for switching pages by swipe gestures in GtkStack
(probably depending on the transition)

- investigate using swipe-from-the-edge for bringing up controls in
fullscreen mode

- choose any application that could benefit from touch support, and
try to implement it using the current GTK+ gesture API (one example
might be swipes to show/hide the sidebar in gnome-weather)/


For your nested scrolling use case, I think it a good start would be a
somewhat convincing testcase. In my experience nested scrolling is
almost always a source of frustration and best avoided...