Add SwipeTriggerBehavior

[sonnemaf]

I have added my SwipeTriggerBehavior to the project. It can be used to detect a swipe behavior in a given direction (default = All).

I have also added a sample in the SampleApp. Swipe the rectangle to move it inside the 3x3 Grid. A Left swipe will change the fill color to Yellow, A Right swipe will change the fill color to Red.

I used it in some of my apps. It might be useful for others.

[brianlagunas]

I tend to agree with @PedroLamas here. I see this more of a "novelty" behavior, and something that should exist outside the main repo.

[sonnemaf]

I understand your motiviation and I am OK with submitting it to the Windows Toolkit.

It is a slippery slope. Which behaviors do we accept and which not. We should at least write down some criteria.

[skendrot]

I believe this library is for more "generic" behaviors. Vote to close

[sonnemaf]

I have doubts about this. What is a "generic" behavior? @skendrot

Are there any behaviors added in the 3 years this library is available? I have looked at the closed PR's and I couldn't find one. Why? Are we setting the bar too high?

Silverlight and WPF have a TimerTrigger and KeyTrigger. Would those be generic enough? Should we develop them?

I agree that the Windows Tookit Blur behavior (https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/master/Microsoft.Toolkit.Uwp.UI.Animations/Behaviors/Blur.cs) should not be in this library. It is a Behavior nog a Trigger. Triggers are way more generic.

A Swipe is common interaction mode in Windows. I think it should be in this library and not in the Windows Toolkit.

This leads maybe to another question. Must we stop with this project and merge it into the Windows Toolkit. Something like Windows.Toolkit.Uwp.UI.Behaviors. The documentation, samples, processes of the tookit project are great. Why have 2 projects? @nmetulev

[LocalJoost]

Good point. Because behaviors was originally a Microsoft project and the CT was not. But now they are both OS. OTOH why would you want to force CT depencies on someone just wanting to use behaviors. Also the behavior package is way more basic and foundational than the CY

Yet, thinking about this, I think Fons' argument has merit. They both are a basically a toolkit for building UWP apps. But we will have to make a transition strategy.

http://www.9folders.com/Joost van Schaik

Windows Development MVP

"The world as I envision it in my head is such a more interesting place"

---

From: Fons Sonnemans notifications@github.com Sent: Saturday, December 8, 2018 09:08 To: Microsoft/XamlBehaviors Cc: Subscribed Subject: Re: [Microsoft/XamlBehaviors] Add SwipeTriggerBehavior (#146)

I have doubts about this. What is a "generic" behavior? @skendrothttps://github.com/skendrot

Are there any behaviors added in the 3 years this library is available? I have looked at the closed PR's and I couldn't find one. Why? Are we setting the bar too high?

Silverlight and WPF have a TimerTrigger and KeyTrigger. Would those be generic enough? Should we develop them?

I agree that the Windows Tookit Blur behavior (https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/master/Microsoft.Toolkit.Uwp.UI.Animations/Behaviors/Blur.cs) should not be in this library. It is a Behavior nog a Trigger. Triggers are way more generic.

A Swipe is common interaction mode in Windows. I think it should be in this library and not in the Windows Toolkit.

This leads maybe to another question. Must we stop with this project and merge it into the Windows Toolkit. Something like Windows.Toolkit.Uwp.UI.Behaviors. The documentation, samples, processes of the tookit project are great. Why have 2 projects? @nmetulevhttps://github.com/nmetulev

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/XamlBehaviors/pull/146#issuecomment-445441109, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD8BnwEa5QmtUbM2oJXK6hvIGLPstDoyks5u23OEgaJpZM4ZIhm9.