[Buschel]

adjusted test code to match that: still can't reproduce last line being cut, however now I see the difference in manual computation vs autolayout (iOS 17.6.1, screen size = 375). Will think how to overcome that.
…
https://imgur.com/a/mhzdkd9

Great! It was never about something being cut, it was always about the issue seen in your screenshot.

[kambala]

adjusted test code to match that: still can't reproduce last line being cut, however now I see the difference in manual computation vs autolayout (iOS 17.6.1, screen size = 375). Will think how to overcome that.
…
https://imgur.com/a/mhzdkd9

Great! It was never about something being cut, it was always about the issue seen in your screenshot.

indeed: I noticed the fact that the last word is actually there on your SS only a few minutes ago thanks to my colleague who helped me brainstorming the issue

this sounds like an iOS bug actually. But I've found a workaround that computes height perfectly: use -[UIView sizeThatFits:] method on the label (after configuring all label properties of course).

[Buschel]

Node. This works for simulator on iOS 15, 16 and 17.

Code change:
+ (CGSize)getSizeOfLabelUILabel*)label {

    /*

    CGRect expectedLabelRect = [label.text boundingRectWithSize:CGSizeMake(label.frame.size.width, CGFLOAT_MAX)

                                                        options:NSStringDrawingUsesLineFragmentOrigin

                                                     attributes:@{NSFontAttributeName: label.font}

                                                        context:nil];

    CGSize labelSize = CGSizeMake(ceil(expectedLabelRect.size.width), ceil(expectedLabelRect.size.height));

    return labelSize;

     */

    return [label sizeThatFits:label.frame.size];

}

But it this just something we do temporary, or shall I just change the method in general to us sizeThatFits.

boundingRectWithSize is also called inside some other class. But think it is quite straight forward to use the helper method getSizeOfLabel there as well.

[kambala]

actually correct would be

Code:

[label sizeThatFits:CGSizeMake(label.frame.size.width, CGFLOAT_MAX)]

[Buschel]

True, made this change before I raised the PR.

[amasephy]

Played with the iPad app this evening and found one bug which I believe to be new and finally am able to reproduce a strange quirk I have noticed for months.


Bug: if you enter the search bar of a library view the menu at the bottom of the view becomes inoperable. Buttons like grid/list toggle and full screen. None of them will work without reinitializing the view.


Now the quirk. Typically if you have a single pane visible on iPad then the pane will be movable left and right but will not stay centered. It snaps to the right hand side of the screen. You can trick the pane to stay in the center though.

Steps:
Go to a library view such as movies.

Bring up remote.

Tap settings gear.

Slide settings pane off to the right.

On library view tap full screen.

Exit full screen.

Slide library view to the left.

It now stays centered.

[Buschel]

The first one is not really bug, but at most an suboptimal user experience.  
I did this for purpose in 2022, to avoid that the search function ended up in locked up and undefined state. Not sure, if I can allow this again after the search bar has been reworked a lot in recent months.

The last one I can reproduce, even w/o the gear. You can just go to Music and open a second pane by selecting any album. In this state the left pane behaves exactly like you describe. After entering and leaving fullscreen the right pane is gone, but obviously the left pane still behaves as if the right one would be still there. Will look into this.

[UlfSchmidt]

Oh, I remember running into the same or at least very similar problems on my iPad a while ago and also reported these here, but since I wasn’t able to reproduce them properly, @Buschel somehow put them into his backlog. Good findings @amasephy !

[Buschel]

Just fixed the bounce behavior. This was a classic example of not fully resetting internal variables.

The search topics at a first glance also looks promising, most likely because of the search bar rework of the past months. I can allow the toolbar presses, ending an active search before executing the button press. Feels quite natural. I am yet a bit reluctant to make this change as I am not sure about any side effects -- search functionality always has been difficult to maintain.

[UlfSchmidt]

…
I am yet a bit reluctant to make this change as I am not sure about any side effects -- search functionality always has been difficult to maintain.

Just implement it. We are here to test and report back

[Buschel]

Just implement it. We are here to test and report back

Did so. 👍

[Buschel]

Ouch, just received (and fixed) a nasty regression in the last build: It is not possible to enter add-ons anymore, e.g. youtube.

[UlfSchmidt]

These (recently) introduced new confirmation dialogues “Are you sure?” - what was the rationale for these? Honestly, I find them quite (read: very) disturbing und unnecessary. Any chance to get rid of these or at least to make them configurable?

[Buschel]

Those were there for iPhone since I started to maintain the app. They got just added to iPad as well -- recently, I admit. I guess this was mainly done to avoid that someone is running scans or shutting down the system or Kodi by accident. Basically, confirmation is asked for everything which impacts the system or Kodi activity status or the database. This is obviously a matter of playing safe with system and database. It was just not done for iPad all the years.

But I admit you can have different opinions on this. E.g. there is even an open GitHub issue which asks to do the same every time "play" overwrites an existing playlist.

[amasephy]

In keeping with my philosophy of giving the user choice, how about making this an app option? Default could be to display the confirmation dialog, with option to toggle it off.

I have to admit I really had no idea what dialog was even being discussed.