Skip to content

Conversation

@salexch
Copy link
Contributor

@salexch salexch commented Feb 21, 2016

I think mouse support should be part of the project..
in tv apps, user can switch from remote to mouse easily, so for better ux it should be supported out of the box, developer will gain from it too..

@salexch
Copy link
Contributor Author

salexch commented Feb 24, 2016

do you want to merge it to master?

@Duder-onomy
Copy link

Hi Alex,
I will definitely check this out. The 'mouseover' event is pretty reasonable to implement.
The reason we left it out originally, is that we did not want to deal with the scroll event in this library.

Im gonna grab some lunch now. I will pull this and check it out right after.
Greg

@salexch
Copy link
Contributor Author

salexch commented Feb 24, 2016

thank you and Bon Appetit.
anyway I didn't add support for scroll, for now it's better than nothing..

Usage: weight-override-up='namespace:test', weight-override-down='namespace:test'

All focusable elements that have the same namespace will get better chance to be selected
@salexch
Copy link
Contributor Author

salexch commented Mar 1, 2016

hello?

more restrictive
@salexch
Copy link
Contributor Author

salexch commented Mar 20, 2016

still here?

@Duder-onomy
Copy link

Hi Alex, looking at this right now.

Refactoring some items to make it more in line with existing code base.

We recently came across a platform where the 'mouseover' event is not available. It only provides the 'mouseenter' event. So I made the mouseover event name configurable.
In your PR, when the event was a mouseover you were looping over all focusable elements in the DOM. I changed this to only loop over the 'knownElements' as we usually have multiple instances of MFF on a single page and certain containers will not be supporting mouse events.

Anyhow. I just finished up the work on the Mouse Support and pushed. I do not understand the namespace feature. Can you describe to us how that is useful and add some tests?

@salexch
Copy link
Contributor Author

salexch commented Mar 22, 2016

Thank you!
namespace is used to prioritize movement in container.
lets say you have 2 vertical containers which overlap one another (one of them is scrollable)
like top of the container "A" is under bottom of container "B", so when you move inside container "A" you want to reach the most top element of it before "magic focus finder" will change to elements in container "B" (it will happen because of overlapping),

hope it was clear..

@salexch
Copy link
Contributor Author

salexch commented Mar 22, 2016

https://jsfiddle.net/spqtacrv/

elements in red container could be under or above elements of "green container".
when focused element in red container I want to force "magic focus finder" first try to move to available elements in that container and if no such then try other focusable elements

@Duder-onomy
Copy link

@salexch regarding this issue. The 'scrollable' containers have always been a problem. We didnt want to address them with this library, though, maybe we will need to now. On old smart TV's. Native scroll was out of the question. In fact, it would crash the older samsung devices if you attempted to scroll an element. We would always implement a fake scroll, an element with overflow hidden, then its contents moving on a rail. It seems like the newer TV's encourage scrollable interfaces.

So, as it stands, I understand why you wanted this feature. But it will take more effort if we are to handle items that scroll. We have overcome this issue slightly differently on all the newer TV's.
There was an update to the scroll code on Filmeeze which seemed pretty good. Also, we have a handful of newer TV apps with diff scroll implementation. I will talk to our team during standup tomorrow morning and see if we can get everyone to rally around a scroll solution that we can implement in this library.

It could be a little weird. We will need to implement some flag you can put on the containing element that needs to scroll. Something like,

<div focus-scroll-container >
    <div focusable ></div>
    <div focusable ></div>
    <div focusable ></div>
    <div focusable ></div>
    <div focusable ></div>
</div>

This will scroll the container to ensure the next item is visible in the direction you wanted to move. We will need to ensure this is configurable to work with all of the implementations (some people want a whole new list of items when scrolling...kind of like a paginated scroll. Some people want just the next item showing. )

Anyhow. I will get back to you tomorrow. Thanks for clarifying your needs.

@salexch
Copy link
Contributor Author

salexch commented Mar 23, 2016

I think introducing namespace is the most generic solution. In filmeeze you
can see my submits I refactored scrolling solution in
binders/gridSelector.js its better than using rowHeight.. and use "while" (in
some cases in caused infinite loop). Maybe we should stick with namespaces
and build another library on top of magic focus finder (like
gridSelector.js) to address scrolling itself. More like plugin for
scrolling..
On Mar 23, 2016 02:25, "Greg Larrenaga" notifications@github.com wrote:

@salexch https://github.com/salexch regarding this issue. The
'scrollable' containers have always been a problem. We didnt want to
address them with this library, though, maybe we will need to now. On old
smart TV's. Native scroll was out of the question. In fact, it would crash
the older samsung devices if you attempted to scroll an element. We would
always implement a fake scroll, an element with overflow hidden, then its
contents moving on a rail. It seems like the newer TV's encourage
scrollable interfaces.

So, as it stands, I understand why you wanted this feature. But it will
take more effort if we are to handle items that scroll. We have overcome
this issue slightly differently on all the newer TV's.
There was an update to the scroll code on Filmeeze which seemed pretty
good. Also, we have a handful of newer TV apps with diff scroll
implementation. I will talk to our team during standup tomorrow morning and
see if we can get everyone to rally around a scroll solution that we can
implement in this library.

It could be a little weird. We will need to implement some flag you can
put on the containing element that needs to scroll. Something like,

This will scroll the container to ensure the next item is visible in the
direction you wanted to move. We will need to ensure this is configurable
to work with all of the implementations (some people want a whole new list
of items when scrolling...kind of like a paginated scroll. Some people want
just the next item showing. )

Anyhow. I will get back to you tomorrow. Thanks for clarifying your needs.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#33 (comment)

@salexch
Copy link
Contributor Author

salexch commented Mar 24, 2016

in filmeeze its called utils/binders/gridBySelector.js
using in views/deliverance/foodIndex/model.js
views/deliverance/foodIndex/template.jade

and there is no need to check the element amount in the container (like with rowHeight in view.js)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants