[amasephy]

Since I discovered there is active development discussion here for this app might I make a suggestion?

A typical functionality of many apps is to allow swiping left to right at the left edge of the screen to navigate back or to pull out a side pane. This is present in certain parts of this app, like going into a tv series season and then back to the season view.

For some reason this isn’t enabled when the remote is active. It might be nice to have it pull out the side menu (movies,tv etc found from tapping the burger button) when using the “navigate back” gesture. Or is this deliberately not enabled here?

[Buschel]

Since I discovered there is active development discussion here for this app might I make a suggestion?

A typical functionality of many apps is to allow swiping left to right at the left edge of the screen to navigate back or to pull out a side pane. This is present in certain parts of this app, like going into a tv series season and then back to the season view.

For some reason this isn’t enabled when the remote is active. It might be nice to have it pull out the side menu (movies,tv etc found from tapping the burger button) when using the “navigate back” gesture. Or is this deliberately not enabled here?

Thanks for your suggestion. Talking about the remote screen itself. You can enter this from the NowPlaying screen and from the main menu. In the first case you can swipe back to NowPlaying. In the latter you can only go back to main menu via the "burger", but not via swipe left. This seems inconsistent, as you can swipe left in all other screens you can enter from the main menu. As the founder is not actively participating the development anymore, I have no history of why this was done like this. I can only imagine the swipe left was/interfering with the use of the remote, e.g. when having gesture panel active. In the case of the remote screen which is reachable via the NowPlaying screen, the remote screen does not use the full screen width but reserves a small portion on the left side.

For consistency I could allow swipe left for both the remote screens (coming from NowPlaying or from main menu). But we need testers which regularly use the gesture functionality of the remote screen to check if there is interference. Could you help with this?

Another remark: I would really like to unify the two remote screens completely. But this is not possible yet as we still support iPhones with smaller screens -- e.g. iPhone 4S. For those the special remote screen  -- coming from NowPlaying -- is still needed. Only in this screen there is enough space for the volume bar.

[MiSeRy]

Can anyone give me an invite please? I dont habe an iPhone device. Thx.

[email protected]

[Buschel]

Can anyone give me an invite please? I dont habe an iPhone device. Thx.

Just follow the link in the first post of this thread (first post) with your iOS device. This will allow you to participate the beta test.

[amasephy]

I could certainly help test it, I use this app daily.

I will say, I only discovered the gesture pad on the remote while trying to find the top/bottom offset toggle. So I don’t really have any familiarity with it so far. I can try and see how it feels as it currently is first and then see how it works if the navigation gesture were enabled.

I do see there is a bit of padding around the edge, my thought would be the gesture requires you to be relatively close to the edge to trigger this gesture but I don’t know for sure. I’m sure the code paints a clear picture as to how this get activated.

As for the second remote view, the on the now playing screen, well I guess I never even paid attention to it before. Seems to me a bit redundant. You would have to use the remote pane to navigate Kodi on a tv, and then start some content. Then you would have to use the burger button and navigate to the now playing pane which gives you a limited remote and a pretty “album” art of whatever is playing. Seems like extra taps to get reduced functionality. You already know what’s playing, as I would assume it’s being watched. Maybe other people like it.


Just some more thoughts regarding the remote pane. Something I thought of. With all the extra vertical space on modern phones would it be possible to implement vertical scale sizing on some of the buttons instead of just scaled positions. Obviously the navigation buttons are the primary buttons and their size reflects that but beyond that I would think the play/pause, stop etc row would be the next most used. I know for me I use the play/pause button the most. I’m thinking back to vcr style remotes with oversized tactile buttons and the play/pause was always easy to hit. Might it be possible to scale the size of that row vertically to fill up some of the empty space? It certainly would make it easier to hit them.

[Buschel]

 

Thanks for offering your support, this will help once I enabled the "swipe left" in the remote screen. This will need some time, but I will announce it here, once the software is available via TestFllight.

The NowPlaying-bound remote screen supports a whole different way of using the remote, like I do. I am not using the TV at all and have a headless Kodi setup, for Music playback only. In such setup you typically use the App to browse the content and start playing it from the database browser. The App then switches to NowPlaying automatically to reflect what is playing and allow the basic controls (play, pause, seek, ...). The remote screen with the volume control is just one click away from there.

Your suggestion to enlarge the play/pause/seek buttons is noted. What can be done w/o too much hassle is to rebalance the height of the first, second and last row of buttons -- allowing the play/pause/seek buttons more size and reducing the others a bit. Definitely the layout can be further optimized, we just need to figure out what's best from a user point of view. E.g. several users asked for the possibility to move the remote to the bottom as it was difficult to reach the navigation button on large iPhone when using the App one-handed. What I had in mind was to either add more "main menu" buttons (e.g. to access Favourites, TV, Radio, ...). This could be done with adding another row of buttons -- only on bigger screens --, or simply support longpress. In fact, the longpress is implemented from some of the buttons, but it does not work for my Kodi 19 test server. I am not sure, if this functionality broke with a past Kodi server update.

Both solutions have pros and cons:

1. New buttons Pro: Clear UI, you get what you see. More effort to implement as the layout needs to be reworked.
   
2. New buttons Con: Needs space and cannot be done for smaller devices, which results in inconsistency over different devices. Navigate buttons would again be located higher on the screen, which impacts the one-handed usability.
   
3. Longpress Pro: No additional space needed. Easier to implement, few layout changes.
   
4. Longpress Con: Need to find a way to visualize the longpress function, which will impact the button design and might be hard to read (e.g. having two icons per button).
   

[amasephy]

Thanks for taking my thoughts into account. I know it’s difficult to support many screen sizes and user desires.

I forgot about starting content directly from the app vs navigating to it on a tv. That totally makes sense now. The headless setup you talk about is a while other configuration. I imagine that is not typical. I had looked into that in the past but it seemed difficult to get setup. A little off topic but doesn’t it require a different sql database backend to operate?

Maybe something easier to start with in lieu of resizing buttons would be to use the center Kodi button to play/pause. The navigation buttons already function as seek forward & backward. The center Kodi button doesn’t seem to do anything other than undim my display when content has been paused for a few minutes. This would eliminate the difficulty of reaching for the smaller play/pause.

For short press vs long press maybe a one time app tutorial upon first launch would help. I have seen other apps do a quick guided tour like this. Also, haptics being added might be nice when pressing buttons. There could be a differing haptic feedback while short or long pressing.

[Buschel]

A little off topic but doesn’t it require a different sql database backend to operate?

No, in fact this is a plain unchanged -- but self compiled -- build, running on Linux Mint. I am just minimizing the window after start to reduce the load, that´s it.

Maybe something easier to start with in lieu of resizing buttons would be to use the center Kodi button to play/pause. The navigation buttons already function as seek forward & backward. The center Kodi button doesn’t seem to do anything other than undim my display when content has been paused for a few minutes. This would eliminate the difficulty of reaching for the smaller play/pause.

Hmm, the skip/seek and navigate buttons behave different. E.g. the seek via navigate only works when you showing a playing video, their function is context related and managed by Kodi server. The seek/skip buttons also work, if the playback happens in background. I would definitely keep the skip/seek buttons.

For short press vs long press maybe a one time app tutorial upon first launch would help. I have seen other apps do a quick guided tour like this. Also, haptics being added might be nice when pressing buttons. There could be a differing haptic feedback while short or long pressing.

Good point. I was searching for a way to have a kind of help especially after changes in the UI. Like the latest changes with handling movie sets.

[Buschel]

For consistency I could allow swipe left for both the remote screens (coming from NowPlaying or from main menu). But we need testers which regularly use the gesture functionality of the remote screen to check if there is interference. Could you help with this?

Quick update: I opened an issue in GitHub and already raised a PR with the implementation (PR#400). In fact, the pan gesture is interfering with the gesture zone. So, we either can decide to leave it as it is (behaviour of Remote screen is always same, regardless whether gesture zone is active or not), or we can support the pan gesture for the Remote as long as gesture zone if inactive. I am personally preferring the latter.

[kambala]

I am just minimizing the window after start to reduce the load, that´s it.

fyi on the forum there's a patch for true headless Kodi (with docker support iirc), search for headless

[amasephy]

Hmm, the skip/seek and navigate buttons behave different. E.g. the seek via navigate only works when you showing a playing video, their function is context related and managed by Kodi server. The seek/skip buttons also work, if the playback happens in background. I would definitely keep the skip/seek buttons.

My apologies, I think I might have been a little confusing here and possibly caused a misunderstanding here. What I meant was, the navigation buttons act as a skip forward and backward already while content is playing. Yes, they behave differently from the other buttons you mentioned. However the button with the Kodi symbol in the middle of the remote is what I was primarily talking about. It does not seem to do anything while content is playing. During normal navigation it acts as an “enter” key.

What I was originally asking was whether it would be possible to make this “Kodi symbol center button” act as a “play/pause” button during content playback. This way you have nice large buttons in the middle of the remote that act as skip back, play/pause and skip forward.

Definitely wasn’t suggesting removing any buttons. Just adding functionality to a seemingly unused button during a specific context (content playback).

[amasephy]

For consistency I could allow swipe left for both the remote screens (coming from NowPlaying or from main menu). But we need testers which regularly use the gesture functionality of the remote screen to check if there is interference. Could you help with this?

Quick update: I opened an issue in GitHub and already raised a PR with the implementation (PR#400). In fact, the pan gesture is interfering with the gesture zone. So, we either can decide to leave it as it is (behaviour of Remote screen is always same, regardless whether gesture zone is active or not), or we can support the pan gesture for the Remote as long as gesture zone if inactive. I am personally preferring the latter.

I thought about this and it seemed like the latter was a good idea. I didn’t suggest it originally because I was worried about concerns regarding user experience consistency. For me personally this wouldn’t be a concern but maybe it could cause some concern for others?

[Buschel]

1.8.1 Build 2625
Release Notes

First bugfix version for 1.8 based on user and AppStore feedback.

[Buschel]

What I was originally asking was whether it would be possible to make this “Kodi symbol center button” act as a “play/pause” button during content playback. This way you have nice large buttons in the middle of the remote that act as skip back, play/pause and skip forward.

Thanks, this makes your suggestion a lot clearer to me. I can take look at this, and we could test it via TestFlight for a while and see, if there is some counter indication reported.

I thought about this and it seemed like the latter was a good idea. I didn’t suggest it originally because I was worried about concerns regarding user experience consistency. For me personally this wouldn’t be a concern but maybe it could cause some concern for others?

This change is already implemented and can be tested via TestFlight in some of the upcoming builds. For me this new behaviour feels consistent, but I am neither a power user of the remote in general, nor the remote's gesture zone in particular.

[Buschel]

1.8.1 Build 2632
Release Notes

Next bugfixes to fix two reported crashes and to re-enable the support for XBMC 11 which broke with Remote App 1.6.2.