Page MenuHomePhabricator

atulfokk (Atul Kumar Singh)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Sunday

  • Clear sailing ahead.

User Details

User Since
Mar 8 2015, 10:10 PM (253 w, 4 d)
Availability
Available

Recent Activity

Dec 29 2016

atulfokk updated the diff for D4536: ecore_wayland_input : updating global x y coordinates when enter using pointer.

correcting file permissions

Dec 29 2016, 4:09 AM · efl
atulfokk updated D4536: ecore_wayland_input : updating global x y coordinates when enter using pointer.
Dec 29 2016, 3:43 AM · efl
atulfokk retitled D4536: ecore_wayland_input : updating global x y coordinates when enter using pointer from to ecore_wayland_input : updating global x y coordinates when enter using pointer.
Dec 29 2016, 3:36 AM · efl

Jun 14 2016

atulfokk added a comment to D4026: focus: next/prev(Tab Order) implementation.
In D4026#66994, @cedric wrote:

As per my understanding, we should keep the default tab ordering as object creation based and we should implement position based tab ordering which can be enabled/disabled using APIs. There can be existing applications which are depending on old default tab order behavior.

I do not believe there is a good reason to manually handle focus in application or rely on creation order. Once we implement graph logic, it should be the only solution. It is not acceptable for application to tweak this kind of knob to get something working.

Jun 14 2016, 10:17 PM
atulfokk added a comment to D4026: focus: next/prev(Tab Order) implementation.

Hey Cedric & Marcel,
As per my understanding, we should keep the default tab ordering as object creation based and we should implement position based tab ordering which can be enabled/disabled using APIs. There can be existing applications which are depending on old default tab order behavior.
Besides we need to discuss more in detail to decide tab order behavior in case of position based tab order. To me it seems to be same order as right direction key for a row and then jump to 1st object in next row from last object in current row. If that's correct then we can implement it as next task (if nothing else is higher priority). If you agree then we'll fix other review comments to push this patch.

Jun 14 2016, 4:27 AM

Jun 10 2016

atulfokk added inline comments to D4026: focus: next/prev(Tab Order) implementation.
Jun 10 2016, 1:17 AM

Jun 9 2016

atulfokk added a comment to D4026: focus: next/prev(Tab Order) implementation.

@cedric : agree that TSP is a really interesting problem to solve but I think we won't really need it here as it is. Anyway...
I have earlier mentioned that existing default tab order (focus chain) is same as object creation and not their visual location. I have now retested it by simply creating 3 buttons on a window. Later to clarify Marcel's doubt I looked at Box code and found that it's using custom tab order and not default. I have even created a wpf app and java app on ellipse and found that it's still same old default tab order which is in same sequence as object creation.
Your idea of automatic and smart tab order based on visual position is really great and new and it will do away with many custom focus orders written at widget/app levels. We can definitely work on once we decide the priorities..

Jun 9 2016, 6:39 AM