| dcaliste | Good morning pvuorela, I wish you're fine. | 08:07 |
|---|---|---|
| pvuorela | dcaliste: good morning! | 08:07 |
| dcaliste | Thank you for merging the EXDATE stuff in nemo-qml-plugin-calendar. I've seen you'd pushed it as a 4.5.0 fix also. Thanks. | 08:09 |
| pvuorela | thank you yourself :) | 08:09 |
| dcaliste | I like your suggestion to add a modify future occurrences or delete future occurrences. I didn't have time last week to start the implementation, but I start looking at where to put the Incidence::setThisAndFuture() flag between QML code and nemo-qml-plugin-calendar. | 08:11 |
| dcaliste | KCalendarCore is setting it on dissociation call, but this would imply to modify a bit mKCal and also to propagate this flag in CalendarEvent struct. The other possibility is to set it up in the CalendarWorker::saveEvent() call. | 08:13 |
| pvuorela | hm, what does that thing actually do | 08:13 |
| dcaliste | When you create an exception, calling Incidence::setThisAndFuture(true) on the exception makes all occurrences occuring later than the exception to be based on exception data instead of parent data. | 08:14 |
| dcaliste | Like that you can update a meeting location for instance, or even its time. | 08:15 |
| dcaliste | KCalendarCore is setting this flag in the Calendar::createException() call via an optional argument. But nemo-qml-plugin-calendar is not using this function, but instead a wrapper from mKCal ExtendedCalendar::dissociateSingleOccurrence() which itself is calling it. | 08:16 |
| pvuorela | hm, ok. looks like this in .ics RECURRENCE-ID;RANGE=THISANDFUTURE:19980401T133000Z | 08:16 |
| dcaliste | Exact. This is how it is serialised. | 08:16 |
| pvuorela | sounds good | 08:17 |
| dcaliste | It sarted with your idea to add a simpler way to delete all later occurrence than editing the recurrence end time in the parent. The possibility is to add a third button when calling "delete" on an occurrence, beside the "delete this occurrence" and "delete the full series". This third button would be "delete this and later". Symmetrically in the modify occurrence page, besides the two button we can add a third which would be "modify this occurr | 08:19 |
| dcaliste | ence and later". | 08:19 |
| pvuorela | yea, didn't though realize saying that this detail that can be used for implementation. but that's excellent if that exists. | 08:20 |
| pvuorela | hm, do we store such info in the database now | 08:20 |
| dcaliste | Good point for mKCal, let me grep inside… | 08:21 |
| pvuorela | not spotting immediately thisand... | 08:21 |
| dcaliste | Yeh, so I was happy that KCalendarCore supports it out of the box, but I'll have to add it to mKCal ! | 08:22 |
| pvuorela | good thing i did that schema update thingie if that ends up needing table adjustments :) | 08:23 |
| pvuorela | might also need adjustments to the sync plugins if the app starts using it. | 08:25 |
| dcaliste | Indeed, while we could still use extra3 for it, it would be better to use your migration path with an ADD_COLUMN thing. | 08:25 |
| dcaliste | At least for CalDAV, it should work out of the box. | 08:26 |
| dcaliste | But I agree that for Google for instance one needs to see how this is stored in their JSON format and add it to the converter. | 08:26 |
| pvuorela | ye | 08:26 |
| pvuorela | but we can start with mkcal. support there shouldn't bother others if no-one is using it. | 08:27 |
| dcaliste | Indeed, that's good that we discussed this together, I didn't think about mKCal and Google sync, while support should be added there first. | 08:28 |
| dcaliste | Maybe you didn't have enough time to look into https://github.com/sailfishos/mkcal/pull/40 ? | 08:32 |
| pvuorela | not really. it's been conflicting so didn't pay much attention now. | 08:33 |
| dcaliste | Ah, right, I forgot to update it, my bad… I'll do. | 08:34 |
| dcaliste | Besides, I've got two unrelated questions, if you don't mind : I'm in the process of tracking https://forum.sailfishos.org/t/4-1-0-23-4-0-1-48-4-4-0-64-no-notification-sounds-ringing-sms-alarm/ which can be quite irritating when it happens since the alarms don't ring anymore, and I use the phone as an alarm clock to wake me up in the morning. | 08:35 |
| dcaliste | Well the two questions : | 08:36 |
| dcaliste | - I'm trying to do a reproducer in the form of a QML app that use Nemo.Ngf with NonGraphicalFeedback { effect: "battery_low" } and play it repeatedly. The problem is that it is playing it at loud volume and it is annoying. How can I adjust the volume ? Do you know ? | 08:38 |
| pvuorela | hm, not finding that page. | 08:39 |
| dcaliste | - I've tried it with effect: "email_exists" which is the file that ngfd was playing when the bug happened. But there is a strange behaviour then : the tone is played but it stays in the playing state up to the moment I touch the screen. I can share the code of the app if you want to try yourself and see what I mean. I find this behaviour "strange". But maybe it's expected with ngfd event rules ? | 08:40 |
| dcaliste | The correct link is https://forum.sailfishos.org/t/4-1-0-23-4-0-1-48-4-4-0-64-no-notification-sounds-ringing-sms-alarm/4886, sorry I forgot the numerical id at the end. | 08:40 |
| pvuorela | sounds strange. i think the volume should be proper without any adjustments and the playback shouldn't be related to touching the screen | 08:41 |
| dcaliste | Indeed ! You can find the code in https://github.com/dcaliste/harbour-ding I should do something wrong I guess. | 08:43 |
| dcaliste | The current idea for the bug is a race condition in gstreamer. The idea of the code is to meet the race condition by luck by repeatedly call NGFD to play a file. | 08:44 |
| dcaliste | I tried yesterday, but was unsuccessfull to reproduce the bug within 150 playing attempts with the battery_low tone. | 08:45 |
| dcaliste | I didn't try more because the sound is too loud and disturbing ! Even when I cover the speaker. | 08:45 |
| pvuorela | hm, seems fine for me on jolla c | 08:47 |
| pvuorela | xperia 10 II is clearly louder. not sure if that's wrong, though. | 08:50 |
| pvuorela | tried with the battery_low, didn't modify the qml. | 08:50 |
| dcaliste | Ah, I just retry now with the email_exists effect and the button stays disabled because the file is kept in playing state, up to the moment I touch the screen. | 08:50 |
| dcaliste | Ah ok. battery_low is not having the same behaviour with respect to playing state. | 08:51 |
| dcaliste | For the sound, the min volume is 20 % which is still a bit high for repeatedly playing the tone up. Can I set by hand the ringing volume to 5 % for instance ? | 08:53 |
| pvuorela | ok, on email sound it does play only once and then nothing. interesting. | 08:54 |
| pvuorela | and touching makes it play again. what the heck. | 08:54 |
| dcaliste | Yes, my feeling too ;) | 08:56 |
| dcaliste | Looking at email ngfd events, I didn't find any config line that would indicate "wait" for user input after playing. But yesterday was also the first time I looked at these file, so I may have missed something… | 08:58 |
| dcaliste | Mmh, and what is interesting is that the threads in ngfd are in the same blocking state than the one described in the forum when the bug appears. | 09:01 |
| dcaliste | I mean when the app stayes in the playing state before one touch the screen. | 09:02 |
| dcaliste | Maybe I won't have to hear the email tone for hours before the bug is triggered after all :) | 09:02 |
| pvuorela | dcaliste: pondering if the funny stuff is coming from the led usage of the email event. turning display off does also play more ding. | 09:06 |
| dcaliste | Maybe, there are various things strange here, like the touch the screen to unblock. If you push the button, wait for the tone to play and then attach a gdb to ngfd while the screen is still on, you get a backtrace that indicate that the thread 6 (responsible for playing the file) is in wait condition. Which looks suspicious since the tone has been finished. The gstreamer thread should return, whatever the led handling is going to do… | 09:10 |
| pvuorela | not sure. could be also that the gstreamer thread is just waiting for more things to play. | 09:12 |
| pvuorela | but looking that more closely, could be as well some race thing. | 09:13 |
| pvuorela | not sure. | 09:13 |
| dcaliste | Maybe, but if you look at threads when ngfd is idle, there is no "mpegaudioparseXX" thread. But it could be an optimisation too, that the thread stays alive for a while in case… But (but), the stack of this thread seems to indicating some playing, because there is a long list of gst_audio_decoder_push_forward , gst_base_transform_chain, gst_pad_push_data… | 09:15 |
| dcaliste | So, ok, you can easily reproduce the behaviour, which means that it's not related to my setup (specific ring tome or whatever). So it's worth invstigating from my side. | 09:16 |
| dcaliste | And at least, for a race, it is easily reproducible. If it ends up not being the bug from the forum, at least it's worth understanding why ngfd stays in the playing state. | 09:18 |
| pvuorela | for another thing, it's emitting the playing state twice. | 09:21 |
| pvuorela | that's not necessarily too bad, but at least unnecessary and strange. | 09:22 |
| dcaliste | Yeh, I've noticed, but that may be an implementation detail, like "playing" is emitted when called, and then reemitted when the gstreamer thread actually starts. Because for instance, if you put a wrong effect name, the status is becoming playing and then it switch to error. | 09:28 |
| dcaliste | I agree that avoiding the playing state twice in a row would be nicer though ;) | 09:29 |
| dcaliste | Anyway, that's something we can revisit next Tuesday together with our own investigations. I need to attent a meeting now. Thanks for the fruitfull discussion today pvuorela. See you later. | 09:33 |
| pvuorela | thanks and see you! | 09:33 |
| *** spiiroin_ is now known as spiiroin | 11:10 | |
| poetaster | piggz, rinigus, are you guys ok if I use github webhooks which fire on RELEASE within the chum testing repos? I'm implementing actions to build releases on tags. If a release succeeds, it fires the webhook for obs. | 16:12 |
| piggz[m] | poetaster: the worry we have is that the webhook will be copied to the main chum on submit | 16:12 |
| poetaster | piggz[m], hmmm. | 16:13 |
| poetaster | piggz[m], how about I test that :) | 16:14 |
| poetaster | with a small insignificant gnat of an app. | 16:15 |
| rinigus | poetaster: we had a discussion regarding it last night - check the logs of this channel | 16:19 |
| poetaster | rinigus, will do. | 16:19 |
| poetaster | rinigus, the webhooks work fine in a private repo (and only fire on release), but that doesn't help us determine if the hook on obs will fire for the 'wrong' context. | 16:35 |
| piggz | poetaster: you could do a submit from home to testing, and we could see what is in it | 16:36 |
| rinigus | poetaster: or make separate repo under home and submit there :) | 16:40 |
| poetaster | piggz, rinigus okidoke I'll set something up. | 18:59 |
| poetaster | ah damn. I broke obs :) cibot to the rescure. | 21:40 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!