+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Supplementary Tools for Kodi (https://forum.kodi.tv/forumdisplay.php?fid=116)
+---- Forum: Kodi Remote for iOS Official Forum (https://forum.kodi.tv/forumdisplay.php?fid=193)
+---- Thread: Beta Testflight access to beta version (/showthread.php?tid=359717)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
RE: Testflight access to beta version - UlfSchmidt - 2024-08-13
(2024-08-13, 22:16)Buschel Wrote: I removed it because you simply cannot edit them.
Yes. I know. Then maybe name it differently in this case. Move or Scroll or Jump or whatever
Was just an idea to solve the complex issue with stopping and restarting the automated scrolling of the playlist during user interaction in an easy and understandable way…
RE: Testflight access to beta version - Buschel - 2024-08-13
Got it now, appreciate your suggestion
But I would like to keep the playlist's bavahviour consistent enough. Let's see if a better idea comes up. It is not so much the implementation which is diffcult, it is more about how shall this behave?
RE: Testflight access to beta version - UlfSchmidt - 2024-08-13
Maybe just stop the automated scrolling once the user interacted with the playlist. Then show an additional button to allow for a manual restart of scrolling to and focusing on the currently playing item. This button could be shown on the bottom left of the playlist pane. But wait, there is already sometimes this strange Party Mode switch. So, once again not a good idea. Sorry! Maybe it’s too late and too warm and I should go to bed?
RE: Testflight access to beta version - Buschel - 2024-08-13
Yep. Currently I just disabled auto-scroll once a user dragged the list. And auto-scroll is enabled again when switching the playlist to another mode and back again. But maybe it is really better to just enable auto-scroll after a timer, like user did not drag the list for 30 seconds.
RE: Testflight access to beta version - UlfSchmidt - 2024-08-13
Yes, I agree, a timer would be the best solution imho. Maybe even a shorter time period would be sufficient, ten seconds or so?
Would be great to see this in one of the next versions. Thanks!
RE: Testflight access to beta version - Buschel - 2024-08-14
This it how looks like with 10s timer: https://www.dropbox.com/scl/fi/mqvevvw5w1gui6ivugc6a/Simulator-Screen-Recording-iPad-8th-generation-2024-08-14-at-08.42.32.mp4?rlkey=a2udk4k9qf8q1ndtj0u6cp59e&st=ipa7ydy6&dl=0
You can that it automatically is moving to middle after 10s. Before that the titles can be skipped and they are updated in playlist, but the playlist does move the current play item to middle. Not how intuitive this really is. Might cause some user to complain as well.
And here an impression of the reworked edit mode: https://www.dropbox.com/scl/fi/bq7ecjijo33dv9q6v9tez/Simulator-Screen-Recording-iPad-8th-generation-2024-08-14-at-08.53.13.mp4?rlkey=u6377mnylnyuadotgbtq7tv33&st=634a6zag&dl=0
You can see that now all items are editable, and the current played items are not highlighted anymore. This simplifies the whole logic and also avoids problems with highlighting only the item played when entering edit mode, and not updating this when the playlist advances. But for proper user feedback I now show errors when the current played item (or an item not available anymore, because of background changes to the playlist while in edit mode) cannot be edited.
RE: Testflight access to beta version - kambala - 2024-08-14
(2024-08-13, 17:58)Buschel Wrote: They layout/rendering topics seems to be (again) an iOS issue. Using the same font size and dimensions it renders well on iOS 15, but not on iOS 16/17. iOS 16/17 renders the text with 1 line less as iOS 15, but still report the same height via boundingRectWithSize, which it would need for the additional line.haven't heard of such issues. Could you point to the place in code?
Screenshots:
https://ibb.co/xFGkjXd
@kambala, I did not find any hint on the web on this. Seems like boundingRectWithSize does not report the size which is really used for rendering the text. Could be related to lineFragmentPadding, but I have no idea how to move on from here.
RE: Testflight access to beta version - Buschel - 2024-08-14
(2024-08-14, 09:18)kambala Wrote: haven't heard of such issues. Could you point to the place in code?
Code which responds with wrong height (I know "bounds" shall be used instead of "frame", but both are same in this case):
Utilties.m:+ (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;
}
In the faulty case I made the screenshots from it is called from here:
ShowInfoViewController.m:- (CGFloat)layoutLabel
if (!mainLabel.hidden) {
CGRect frame = mainLabel.frame;
frame.origin.y = offset;
frame.size.height = [Utilities getSizeOfLabel:mainLabel].height + lineSpacing;
mainLabel.frame = frame;
offset += frame.size.height;
frame = subLabel.frame;
frame.origin.y = offset;
frame.size.height = [Utilities getSizeOfLabelubLabel].height + lineSpacing;
subLabel.frame = frame;
offset += frame.size.height + VERTICAL_PADDING;
}
return offset;
}
RE: Testflight access to beta version - UlfSchmidt - 2024-08-14
(2024-08-14, 08:58)Buschel Wrote: This it how looks like with 10s timer: https://www.dropbox.com/scl/fi/mqvevvw5w1gui6ivugc6a/Simulator-Screen-Recording-iPad-8th-generation-2024-08-14-at-08.42.32.mp4?rlkey=a2udk4k9qf8q1ndtj0u6cp59e&st=ipa7ydy6&dl=0
You can that it automatically is moving to middle after 10s. Before that the titles can be skipped and they are updated in playlist, but the playlist does move the current play item to middle. Not how intuitive this really is. Might cause some user to complain as well.
Maybe you can simply abort or cancel the timer whenever another user interaction outside of the playlist occurs? I think the App behavior would be quite intuitive then.
RE: Testflight access to beta version - amasephy - 2024-08-16
Here’s the video showing the playlist progress label disappearing.
It’s really a very minor thing. Like always, up to you if it’s worth bothering with. Seems like it unloads as you scroll away far enough and reloads as the currently playing item comes back into view.
RE: Testflight access to beta version - UlfSchmidt - 2024-08-16
I also recognized this behavior, but never thought about it as an error, since the progress bar always comes back immediately.
RE: Testflight access to beta version - Buschel - 2024-08-16
Thanks, the video made it clear. This is caused by always starting with a clean slate when a cell is re-used. I changed this now to show the bar in the re-use case, if the cell index matches the current playing playlist item. This works, but this needs some observation for side effects.
RE: Testflight access to beta version - kambala - 2024-08-20
(2024-08-14, 09:33)Buschel Wrote:(2024-08-14, 09:18)kambala Wrote: haven't heard of such issues. Could you point to the place in code?
Code which responds with wrong height (I know "bounds" shall be used instead of "frame", but both are same in this case):
on a simple test case I don't see any issues on iPhone 12 iOS 17, what am I missing? Also tried playing with text contents a bit. The second label with autolayout is for comparison:
Code:
let s = "Aa very long text A very long text A very long text A very long text Aa very long text Aa very long text"
let createLabel = {
let l = UILabel()
l.text = s
l.numberOfLines = 0
l.textAlignment = .justified
self.view.addSubview(l)
return l
}
let w = view.bounds.width - 10*2
let l1 = createLabel()
let r = (s as NSString).boundingRect(with: .init(width: w, height: .greatestFiniteMagnitude),
options: .usesLineFragmentOrigin, attributes: [.font: l1.font!], context: nil)
l1.frame = .init(x: 10, y: 50, width: w, height: r.height.rounded(.up))
let l2 = createLabel()
l2.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
l2.topAnchor.constraint(equalTo: l1.bottomAnchor, constant: 20),
l2.leadingAnchor.constraint(equalTo: l1.leadingAnchor),
l2.trailingAnchor.constraint(equalTo: l1.trailingAnchor),
])RE: Testflight access to beta version - Buschel - 2024-08-20
An example text which shows this issue for me is
"A world of the very near future in which cattle, fish, and even the family pet can be cloned. But cloning humans is illegal - that is until family man Adam Gibson comes home from work one day to find a clone has replaced him. Taken from his family and plunged into a sinister world he doesn't understand, Gibson must not only save himself from the assassins who must destroy him to protect their secret, but uncover who and what is behind the horrible things happening to him."
using a label width of 373 (frame and bounds) and following attributes:
Code:
label.font = [UIFont systemFontOfSize:15];
label.textAlignment = NSTextAlignmentJustified;
label.lineBreakMode = NSLineBreakByWordWrapping;
label.numberOfLines = 0;
RE: Testflight access to beta version - kambala - 2024-08-23
(2024-08-20, 22:19)Buschel Wrote: An example text which shows this issue for me is
"A world of the very near future in which cattle, fish, and even the family pet can be cloned. But cloning humans is illegal - that is until family man Adam Gibson comes home from work one day to find a clone has replaced him. Taken from his family and plunged into a sinister world he doesn't understand, Gibson must not only save himself from the assassins who must destroy him to protect their secret, but uncover who and what is behind the horrible things happening to him."
using a label width of 373 (frame and bounds) and following attributes:
Code:label.font = [UIFont systemFontOfSize:15];
label.textAlignment = NSTextAlignmentJustified;
label.lineBreakMode = NSLineBreakByWordWrapping;
label.numberOfLines = 0;
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.
Code:
let s = "A world of the very near future in which cattle, fish, and even the family pet can be cloned. But cloning humans is illegal - that is until family man Adam Gibson comes home from work one day to find a clone has replaced him. Taken from his family and plunged into a sinister world he doesn't understand, Gibson must not only save himself from the assassins who must destroy him to protect their secret, but uncover who and what is behind the horrible things happening to him."
let createLabel = {
let l = UILabel()
l.text = s
l.numberOfLines = 0
l.textAlignment = .justified
l.font = .systemFont(ofSize: 15)
l.layer.borderWidth = 1
self.view.addSubview(l)
return l
}
let offset: CGFloat = 1
let w = view.bounds.width - 2 * offset
let l1 = createLabel()
let r = (s as NSString).boundingRect(with: .init(width: w, height: .greatestFiniteMagnitude),
options: .usesLineFragmentOrigin, attributes: [.font: l1.font!], context: nil)
l1.frame = .init(x: offset, y: 50, width: w, height: r.height.rounded(.up))
let l2 = createLabel()
l2.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
l2.topAnchor.constraint(equalTo: l1.bottomAnchor, constant: 20),
l2.leadingAnchor.constraint(equalTo: l1.leadingAnchor),
l2.trailingAnchor.constraint(equalTo: l1.trailingAnchor),
])https://imgur.com/a/mhzdkd9