Req Notifications timing
#1
Problem:
The standard XBMC notification dialog (dialogkaitoast.xml) sometimes does not stay visible long enough for a long notification message to display fully. This is particularly problematic for non-english languages and in skins where the notification label / textbox involves scrolling.

Examining GUIDialogKaiToast.cpp: https://github.com/xbmc/xbmc/blob/c410b2...KaiToast.h, it looks like the display time is fixed as a constant to 5 seconds?

(Possible) solution:
Calculate notification display time based on the length of the string to display and the speed of the scroll (as set by the skinner).
Reply
#2
that's a default parameter value, not a hardcode. it can be passed everywhere a toast is thrown.
Reply
#3
@ironic_monkey: Just out of interest, doesn't the use of uppercase denote a constant by general coding convention?

Does this mean that the notification time is set at various lengths across the XBMC codebase? What would you suggest to be the best way of handling this better?
Bitcoin donations: 1Hvo9rWzhAVbuPrshgaGZaD7qcLFTCPuiv
[Skin] Pellucid
[Skin] Maximinimalism
Reply
#4
yes, those values are a constant in linked file, but if you look at the functions, the display time is also a parameter that can be passed (which defaults to that constant). So time can vary.
Reply
#5
yes, uppercase means a constant. how that constant is used however does matter.. here it's used for the default time to show a dialog. it does not in any way imply that the time to show the dialog is constant. just that we have a constant holding the default value.

i don't think it's set much in the code base, i.e. most toasts use the default value. but the ability to do so is there.

your suggestion sounds semi-sane. but it will be rather involved to pull off. it's not just about string length, it's about (relative) length in pixels which means resolution, scroll speed, language, font all matter.

EDIT: just in case you didn't know. c++ allows for default values for parameters of a function.

Code:
void foo(int bar=3);

foo(); // calls foo with the parameter 3
foo(4); // calls foo with the parameter 4
Reply
#6
Thanks - all knowledge is good knowledge :-)

Good point on the string length. Perhaps the easiest option would be to simply increase the default constant?

@solbero - what are we talking here? A few extra seconds?
Bitcoin donations: 1Hvo9rWzhAVbuPrshgaGZaD7qcLFTCPuiv
[Skin] Pellucid
[Skin] Maximinimalism
Reply
#7
(2014-06-23, 11:47)thedeadman Wrote: Perhaps the easiest option would be to simply increase the default constant?

cat and mouse ...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#8
@Memphiz: Fair comment.

Any suggestions for a workable solution? A notification isn't much use if it can't be read!
Bitcoin donations: 1Hvo9rWzhAVbuPrshgaGZaD7qcLFTCPuiv
[Skin] Pellucid
[Skin] Maximinimalism
Reply
#9
notifications should at least show for the full text-scroll duration. Can't we use callbacks for this? Like adding a callback/message/observer to the GUI elements that fire once a scroll effect is starting over again?
Reply
#10
The fact that android doesn't try to automagically calculate the duration of toast dialogs speaks for itself imo (well or they just didn't even think about it *g*).

So on android the duration is in the hands of the caller. (they even only provide 2 fixed durations 2 and 3.5 secs - callers hack around this by calling the show method via a timer for allowing toasts lasting longer then 3.5 secs up to invinite).

I am not sure if toast text is scrolling on android though which makes our use case a bit different. Ideally the result would be that the duration of our toast dialog starts after the scrolling is completed for the first time. So yeah we need something to either precalculate the scrolltime and add this to the duration - or some callback thingy (which might be a bit over engineered though?).
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#11
callback thingy might be overengineered but probably a cleaner more decoupled approach? Didn't have have a look at the code though, so just an assumption.
Reply
#12
What about click-to-close notifications so the user sure can read all the notifications? Should be optional of course.

When XBMC runs 24/7 on a mediabox, you will always miss all these notifications about updated content and addons. Could be also done in separate "notification center" (as thedeadman already suggested in another thread) or "history".
Reply
#13
click to close might be a bit wonky with remote controls ...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply

Logout Mark Read Team Forum Stats Members Help
Notifications timing0