Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented a scalable control pad #477

Merged
merged 1 commit into from
Oct 27, 2017

Conversation

poisdeux
Copy link
Member

@poisdeux poisdeux commented Oct 23, 2017

This should hopefully fix issue #383 and fix the issue with the original version from PR #428. The original version did not include a check to see if the event server was disabled by the user. This was probably the reason some users reported issues with the control pad not working during the beta release of 2.3.X.

I falsely assumed that checking if the event server connection failed, the variable eventServerConnection would be set to null. This is only the case if hostname resolving fails. Thus, if the event server is not available and the user disabled its usage we would still be using it and do not fall back to using the HTTP input events. This has been fixed now.

In general the following changes have been made in this PR:

  • Refactored RemoteFragment and created a compound view for the
    actual remote. I called it ControlPad to make it more clear what
    its main function is.
  • Implemented a custom grid layout (SquareGridLayout) that will
    always be square. When its width and height are both set to
    match_parent, it will take the smallest of the two as the
    actual size.
  • For devices with a smallest width smaller then 360dp the ControlPad
    is sized to the maximum available space. For larger devices we still
    use the old fixed sizes.

@SyncedSynapse
Copy link
Member

Looks good at first sight. Let me just test a little bit more.

@SyncedSynapse
Copy link
Member

@poisdeux Just one observation: With this PR we get 2 fragment_remote that look very similar (both in portrait and in landscape). The only differences that i could see (in the portrait version) are the FrameLayout that surrounds the top panel on the non-360dp version (which i didn't really understood why it was needed, can't it be removed?) and the FrameLayout that surrounds the control pad on the 360dp version.

Can't this be done using the same fragment_remote, applying different styles? I mean, keep the necessary FrameLayouts and give them a style that gets set to wrap_content or a fixed dimension depending on the version.

@poisdeux poisdeux force-pushed the feature/scalablecontrolpad branch 3 times, most recently from 34cf404 to e2f6e24 Compare October 27, 2017 09:52
   * Refactored RemoteFragment and created a compound view for the
     actual remote. I called it ControlPad to make it more clear what
     its main function is.
   * Implemented a custom grid layout (SquareGridLayout) that will
     always be square. When its width and height are both set to
     match_parent, it will take the smallest of the two as the
     actual size.
   * For devices with a smallest width smaller then 360dp the ControlPad
     is sized to the maximum available space. For larger devices we still
     use the old fixed sizes.

Refactored code to use styles
@poisdeux
Copy link
Member Author

Good suggestion. I changed the code to use two new styles for devices with a smallest width equal or bigger then 360dp. One for portrait orientation and one for landscape orientation. That should reduce the duplication considerably.

@SyncedSynapse SyncedSynapse merged commit b764fc6 into xbmc:master Oct 27, 2017
@poisdeux poisdeux deleted the feature/scalablecontrolpad branch November 1, 2017 09:43
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