[`Black]

Hi,

I've created a small python script which shows the user a short notification on track change in the music playlist or when the user manually plays/stops/resumes/skips a song. The problem is if I skip multiple songs in a row, the notification will not disappear after the desired 2 seconds because of the queueing. Would it be possible to show a notification without adding it to the queue? For example Notification(header,message[,time,image,queue]) with queue = 0 (disabled) and queue = 1 (enabled), default would be 1.

thanks

[`Black]

Just had another idea on this... if I do Notification(header,text,0) I would assume that the kaitoast window immediately closes after it's opened but that seems to be not the case. Less than 1 oder 2s seems to be impossible... if a display time of 0 would be possible, there wouldn't be any problems with the queueing.

[topfs2]

I'm a bit fuzzy about what you want to achieve but is this about right?

You submit a kai dialog toast on song change, if you skip to next song before the old kai dialog has gone down you want to cancel the old (or take it down NOW) and pop up a new which has correct information?

I'm guessing that if a second kai toast would come in between (say remote connected) the first and second song change you'd want the first to cancel then pop up remote connected then after that song change? alternatively update the time of the first and set the info from the second change to the first. i.e. first remains longer but changes to second song change and remote connected comes after.

If I understand this right it seems what you want is some form of mutual exclusivity, that only one kai dialog of a certain ID may exist at any given time in the queue and we solve the problem when two dialogs is in queue be either canceling or updating old. Does that sound ok?

If so perhaps pegging on an optional ID might be ok? that way you can define the ID you want to use in your script and if its omited we generate a unique ID?

[`Black]

Yes that would be ok I think. So if I understand it right, I would have the same id for all my song notifications and if there's already a notification with that id in the queue it get's updated with the new information and display time will be reset?

Another thing which would be nice were some kind of priority for the notifications. So if I have let's say a queue with 3 notifications, the first one is displayed and I send a song notification, I would want to cancel the first, display the song notification and then display the remaining 2 notifications after the song notification. But since this case occurs only rarely, it's not so important.

[topfs2]

Yes that would be ok I think. So if I understand it right, I would have the same id for all my song notifications and if there's already a notification with that id in the queue it get's updated with the new information and display time will be reset?

Yeah that was my thinking, or if not update we could just remove the first off the queue and put the new one on the back, but I think update and reset is probably more wanted?

Another thing which would be nice were some kind of priority for the notifications. So if I have let's say a queue with 3 notifications, the first one is displayed and I send a song notification, I would want to cancel the first, display the song notification and then display the remaining 2 notifications after the song notification. But since this case occurs only rarely, it's not so important.

TBH the entire notification system could use a redesign to allow for stuff like that. Would also be nice to have some view able history of notifications (much like on android) but I guess stuff like that would be a lot more to add. The ID idea would probably work in that API too though.

I'll take a look and see if I can't produce an ID patch, seems possible to do quite simply

[`Black]

Thanks. Notification history is also a thing I was after with a script which should save the current notification with a timestamp in a sqlite database but it seems not possible to get the kai toast label so I dropped it for now.

[pieh]

Priorities and/or notification IDs is something that definitely make sense. Notification history seems more like eyecandy for me - I don't see what value notification history would add to user? What kind of notification user would like to browse history for? Perhaps some use scenario would clear it up for me?

[`Black]

If there would be a history, it should be more like a update history, so you could check recent updates and maybe quickly revert to an older verion if something is broken. It would mostly be eyecandy, so priority for this is (very) low.

[`Black]

Any progress on this?