| poetaster | piggz[m], the pertinent and perky question is why are you not fixing them ;) | 06:14 |
|---|---|---|
| poetaster | (duck, run, seek cover). | 06:15 |
| poetaster | attah, cool. I had/have to date just copied into lib and avoided pip. but that limits the range :) | 06:20 |
| dcaliste | Good morning pvuorela, how are you ? | 07:04 |
| pvuorela | dcaliste: good morning. | 07:05 |
| pvuorela | dcaliste: not much new this week either from my side. the last notebook PRs had some review comments and adjustments but didn't get the final approval yet. | 07:07 |
| dcaliste | No problem. As long as it's not completely stalled, that's ok ;) | 07:08 |
| dcaliste | If you agree I would like to discuss an open question on calendar events : | 07:09 |
| pvuorela | alright | 07:09 |
| dcaliste | Yesterday, I received an appointment as ICS data and imported it in my calendar. So far so good. | 07:09 |
| dcaliste | Except that the incidence was declared read-only. So I cannot modify it afterward like adding some description or setting an alarm. | 07:10 |
| dcaliste | I'm wondering what would be the best way to handle this case, I see three possibilities : | 07:10 |
| dcaliste | - change the UI so the read-only flag is just an hint when set per incidence (the read-only flag per notebook should still be a scrict read-only access), something like "change the event to read/write" in the context menu of the event when listing it. | 07:12 |
| dcaliste | - change the import function so the read-only flag is always removed on importation, since the event is copied to a local (possibly shared) notebook. | 07:13 |
| dcaliste | - completely ignore read-only flag at the level of event (but keep it at the level of notebook). | 07:14 |
| dcaliste | That's my thoughts about it. What is your opinion on the matter ? | 07:14 |
| pvuorela | interesting. what's the .ics property controlling this btw? | 07:15 |
| pvuorela | anyhow, the latter options sound better | 07:16 |
| dcaliste | Ah, now that I'm looking at the data itself (sorry I didn't take time to do it yesterday when importing), I don't see any hint about read-only status at the event level. Though KCalendarCore has a function to do it (see IncidenceBase::SetReadOnly). So I've a bug somewhere because this single event in this notebook is considered read-only. | 07:21 |
| dcaliste | Interesting, I'll have to investigate. | 07:21 |
| pvuorela | yea, didn't spot anything in calendarcore setting the readonly status. | 07:22 |
| dcaliste | Ah, I see it now, it's considered as an external invitation because somehow an organizer is set in the event (while it has no mean since the event is just an appointment reminder for some administrative work). | 07:23 |
| dcaliste | So maybe a corner case in that sense. Maybe I could add a label in the UI mentioning the "external invitation" status, explaining why it is considered read-only. | 07:29 |
| dcaliste | I think, you add this addition to the code a while ago handling external invitation and making them read-only in the UI. Could you remember why ? | 07:31 |
| dcaliste | I mean, since the invitation is external, it is not "attached" in a sense to the notebook it is belonging to. | 07:31 |
| dcaliste | And while I can understand that modifying it on device will not change anything to the real invitation, would it make sense to be able to modify it locally ? | 07:32 |
| dcaliste | Let me find the JB associated... | 07:32 |
| pvuorela | uhm, been a while :) | 07:33 |
| dcaliste | Yes, it was JB#45600 | 07:33 |
| dcaliste | 2019-06, not so long ago ;) | 07:33 |
| pvuorela | and even created by me :) | 07:36 |
| pvuorela | for comparison apparently exchange denied editing but google web calendar allowed but then showed warning and required separate confirmation. | 07:38 |
| pvuorela | and android allowed modifying alarms and event color. | 07:38 |
| pvuorela | sending event updates via email need to be skipped for such if changes are allowed | 07:39 |
| dcaliste | I think there is already a guard on email sending, verifying that the organizer email is actually the notebook owner email. | 07:40 |
| dcaliste | About allowing partial modifications (like alarm) for read-only notebooks, it's a very interesting topic that I'm thinking about for a while now, but I didn't find any way to allow it simply. | 07:41 |
| dcaliste | I mean, the sync part is an issue : when syncing down, the modified alarm will be trashed by the upstream version (think about the webcal plugin for instance). | 07:42 |
| dcaliste | So I need a way to retain what are the user-defined alarms for an event, and then somehow merge them with incoming. | 07:42 |
| dcaliste | Alarms are inheriting custom properties so there is hope ! But it's still not clear for me how not to create a large blob just for this at the moment. So it's still just an idea at the moment. | 07:45 |
| dcaliste | To come back to this external invitation, what do you think (since modifying it on device won't trigger any email send) : | 07:45 |
| dcaliste | - could we allow modification, but warn that they are local ? | 07:46 |
| dcaliste | - should we keep denying any modifications, but add a label explaining the user why the event is set read-only in the UI ? | 07:46 |
| pvuorela | the google warning back then seemed to be. "changes will be reflected only on this calendar: ...@gmail.com" - "Are you sure?" - "You are about to make changes that will only be reflected on your own calendar. Note, that when the organizer changes the original event, your changes will be undone! It is recommended that you keep a copy of your changed event description elsewhere." | 07:47 |
| pvuorela | which gives leeway of overwriting the alarm state | 07:48 |
| dcaliste | Google behaviour makes sense in my opinion, while being a bit over complicated to understand for a simple user not knowing how it is working behind. | 07:48 |
| dcaliste | About adding alarms to a read-only event, I've an idea about UI integration : | 07:49 |
| dcaliste | - I don't want to allow to open the edit page because it is too permissive, we just want alarms. | 07:50 |
| dcaliste | - for read-only events, we end up to the event view page, so why not add there a pull menu entry to add / manage alarms, or a button :/ to manage alarms. | 07:51 |
| dcaliste | - this would bring to the page listing alarm possibility and selecting one would define an alarm (or remove it). | 07:51 |
| dcaliste | There could be a label in the event view like the one of Google when this is done for read-only notebook events. | 07:52 |
| dcaliste | Having alarm management available in the view page would also allow in the medium term to complexify the landing page to handle multi alarms. | 07:53 |
| dcaliste | And this without touching the already crowded edit page. | 07:53 |
| dcaliste | That the conclusion I ended up to when thinking about alarm edition for read-only events like birthday a while ago. | 07:53 |
| dcaliste | But didn't make it into practice because of this sync issue I mentioned earlier (not that it applies to birthdays, but I wanted to be generic). | 07:54 |
| pvuorela | pulley menu or button would be different path then for this kind of events. if something maybe the "edit" option could open a slightly different editing page. | 07:55 |
| dcaliste | Yeh, that's why I thought about a button in the screen area where we have alarms, so it would be the same behaviour for normal events and read-only ones. | 07:56 |
| dcaliste | But button are hard to trigger one-handed... | 07:56 |
| pvuorela | then for normal events we'd had two uis for adjusting alarms? | 07:56 |
| pvuorela | overall not either sure should we have special case here and add complexity. if outlook with lots and lots of users manages with just having these events read only. | 07:57 |
| dcaliste | I would keep the edit event page as it is : it's just fine to create event and set a reminder to it in one go. But the proposition is to add a way to manage alarms afterwards. By adding this in the view page would allow to reach to goals in one shot : | 08:02 |
| dcaliste | - being able to add reminders to events from read-only notebooks like birthdays or school timetable received as webcal, | 08:03 |
| dcaliste | - being able to setup more complex reminder schemes like multi reminders, something that is not desirable to add in the edit page because it's already overcrowded there. | 08:03 |
| pvuorela | the birthday goes a bit further than the initial case, though. write protected incidence vs write protected notebook. | 08:05 |
| pvuorela | maybe one simpler alternative candidate: some switch on the event import ui to strip out attendee information in case such exist. | 08:07 |
| dcaliste | Well from the user point of view, I think it's the same : one would like to add a reminder to it and cannot. I know that one could still create a new event, like "bake a cake" the day before ;) | 08:07 |
| dcaliste | About importing the external invitation, I'm afraid that it's too specific to put it in the import, and the user will not understand what to choose, because he won't know the consequences. | 08:08 |
| pvuorela | was thinking of having some label there explaining the modification allowance. | 08:09 |
| dcaliste | What about adding a label about external invitation being read-only in the view page and there put a switch to convert the event into a plain event by stripping the attendees ? | 08:09 |
| pvuorela | also if we'd allow birthday alarm editing, the adjusted cake baking alarm would happen then every year. | 08:09 |
| pvuorela | if it's a synchronized event then stripping the attendees might not be a good idea? | 08:10 |
| dcaliste | Ah indeed. | 08:11 |
| dcaliste | So having this in the import makes better sense, you're right. | 08:11 |
| dcaliste | Maybe a switch there "convert invitations to plain event", with a description like "the ICS data contains external invitations that would not be editable after importation." | 08:12 |
| pvuorela | yea, something like that. | 08:13 |
| dcaliste | And having this visible only if the ICS data actually contains such data. | 08:13 |
| pvuorela | yep | 08:13 |
| dcaliste | Ok, I'll do something in that direction then. And maybe add a label anyway in the event view explaining the read-only status of an external invitation, something like "this event has been created by the organizer, you cannot edit it." | 08:15 |
| pvuorela | sure | 08:15 |
| dcaliste | Great. thanks for the brainstorming. About cake baking reminders, it seems that it is interesting various people on the forum. I can dig it up. Maybe not for cake baking but at least for post-card sending, or the modern equivalence ;) | 08:17 |
| pvuorela | sure, can understand needs for reminding but how to do it is a different thing. | 08:18 |
| dcaliste | Exactly. I like my idea of having editable alarms directly in the view page, but we can continue that discussion another day, maybe with crude implementation or mockups. | 08:20 |
| abr | dcaliste: good info from Alin about the FM! | 09:01 |
| dcaliste | abr, indeed. I'm very grateful for the information. I'm still lacking the driver part... | 09:01 |
| abr | he also says this needs to be enabled on the board: BOARD_HAVE_QCOM_FM := true | 09:02 |
| abr | but Thaodan is getting more info out of him... | 09:02 |
| dcaliste | I've quickly read the sources he pointed to. I must say that it's not by area of expertise at all, so I've surely missed many parts. But it looks like at least very promising for the userland part, on how to speak to the driver. | 09:04 |
| abr | he's cloned those FM packages to their github: https://github.com/sonyxperiadev/vendor-qcom-opensource-fm-commonsys | 09:04 |
| abr | https://github.com/sonyxperiadev/vendor-qcom-opensource-bluetooth_ext | 09:04 |
| abr | https://github.com/sonyxperiadev/vendor-qcom-opensource-system-bt | 09:04 |
| abr | yeah all that is in the porter's domain really | 09:05 |
| dcaliste | Ah indeed, good point, I didn't looked at the commonsys repo yet, just the fm one at the moment. | 09:05 |
| abr | It could be the case that once all that is working properly, the Jolla media player FM plugin will pick it up and it's just a case of enabling that | 09:05 |
| dcaliste | abr. Indeed. I'm not much afraid by the high level part ;) And I could even ask to get access to the source if required. I'm more concerned about the kernel driver part, so the /dev/radio or /dev/fm or whatever would appear on device. | 09:07 |
| abr | yeah, at least it's possible for anyone to build the sony android bits | 09:08 |
| Thaodan | Most stuff I see is just qcom | 09:13 |
| Thaodan | not Sony | 09:13 |
| dcaliste | Alin cloned the commonsys repo into https://github.com/sonyxperiadev/vendor-qcom-opensource-fm-commonsys | 09:18 |
| dcaliste | There are still many things I need to learn to understand this though and arrive to the compilation step. But well, it looks interesting / challenging at least ;) | 09:20 |
| abr | Thaodan: there won't be any sony. I don't think they've done anything with FM yet - cloning those repos is the first step | 09:28 |
| *** Mister_Magister_ is now known as Mister_Magister | 09:36 | |
| mal | if I understand the code in those correctly based on a quick look it seems fm radio is done via hci | 10:27 |
| Thaodan | If I'm right these files are also supplied by blobs so we have to look to replace those or PR changes. | 10:28 |
| mal | not sure if we want to use the blobs, maybe we should talk to hci directly | 10:29 |
| Thaodan | The sources for this are the same as from the blobs. | 10:30 |
| Thaodan | Its bluedroid sources that alin added | 10:30 |
| Thaodan | /odm/lib64/hw/android.hardware.bluetooth@1.0-impl-qti.so | 10:31 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!