search

microsoftarchive / android-sliding-layer-lib

Highly customizable SlidingLayer as you have seen in Wunderlist
http://wunderlist.com
Apache License 2.0
932 stars 277 forks source link

tab on other parts of the screen #4

Closed dpreussler closed 11 years ago

dpreussler commented 11 years ago

I currently can use all the ui elements on other parts of the screen. They still work. How can I disable that? I would like to close the menu in that case as Wunderlist does. setCloseOnTapEnabled does not do the work as I hoped.

JlUgia commented 11 years ago

Hey!

I had already written my answer when I got your point. By "in other parts of the screen" you are meaning clicking outside of the container right? We didn't implement anything like that:

closeOnTap is meant to work when clicking in any "dumb" area of the container (at some place where the event won't be processed). I'm speaking from the top of my mind but I'm pretty sure you should be able to get that by disabling the elements you don't want to be touchable. After all, what would be the point of not allowing the user to interact with the elements within the container? That's actually the way it works in Wunderlist: you have to click in the paper (where there's nothing) to make it hide again.

Additionally click events outside of that container are independent from this object and shouldn't need to be processed by it. If you want to close the container by clicking somewhere else the "right" approach would be to catch touchEvent by yourself (ie.: click) and dismiss the container by using its method for that.

dpreussler commented 11 years ago

thanks for the quick reply. Yes I mean outside of the container. And closing the menu is exaclty what I want. So you change sth like a listener on your views when the menu is opened so when the user clicks outside the menu that you force it to close. Did I get that right? In wunderlist when the left menu is open, I can still see the checkmarks but if i click on them 1st the menu closes. Thats what user expects but you had to implement that outside of your slider right?

JlUgia commented 11 years ago

No worries, you caught me on that perfect time of relaxed work after dinner :) Exactly, as you say it makes sense from the user perspective, but it really doesn't to me from the code (a container just knows about the area occupied by it and its children unless you make external connections to other views, which just makes sense in specific cases). Correctly, for Wunderlist whenever the slidingMenu is open we place an invisible container on top of the tasks view that listens for a touch, which whenever gets one it'll close the slidingMenu and get rid of the "fake" container. I'd suggest something similar for your case.

dpreussler commented 11 years ago

just found a better way: set a large shadowWith with a transparent shadowDrawable. What to you think about that? Seems to work just fine :)

JlUgia commented 11 years ago

There you go, you tricked it. And sometimes programming is all about that: You've lost the shadow functionality but you got your purpose. Why not going for it, if it doesn't suppose other negative aspects rather that it wasn't meant for that? I don't see a reason why it shouldn't work properly. :)

dpreussler commented 11 years ago

:) Any reason why fill_parent does not work as layout width?

JlUgia commented 11 years ago

Well, it should work. You mean in the slidingLayer?