| *** frinring_ is now known as frinring | 02:33 | |
| tortoisedoc | mal : https://build.merproject.org/package/live_build_log/home:tortoisedoc:branches:home:sfietkonstantin:sailfish:rust/rust-1.27.0/sailfishos_i486/i586 | 06:33 |
|---|---|---|
| tortoisedoc | are there ways to control memory assignment to the build hosts? | 06:33 |
| dcaliste | Hello chriadam and jpetrell! | 07:08 |
| chriadam | dcaliste: hi | 07:08 |
| jpetrell | dcaliste: hi | 07:08 |
| dcaliste | chriadam, I wish you feel better day by day. | 07:09 |
| chriadam | dcaliste: slowly improving, thanks. probably going to be a couple more weeks until the inflammation settles down entirely, but c'est la vie | 07:09 |
| dcaliste | Yeh, have patience, good luck. | 07:10 |
| dcaliste | Concerning signature handling, I've seen you approved the QMF patch, thank you. | 07:10 |
| dcaliste | When accepted, I'll update https://git.merproject.org/mer-core/messagingframework/merge_requests/18 | 07:11 |
| chriadam | I was planning to stage that one after I have a chance to chat to Matt on Thursday | 07:12 |
| chriadam | so Thursday or Friday with luck it will integrate upstream | 07:12 |
| dcaliste | This PR is updating the spec file to package the new crypto plugin files and also is adding account settings for signatures. | 07:12 |
| dcaliste | This account part cannot go upstream yet because it is based on the SSO patch we have in MER. | 07:13 |
| dcaliste | Ok for the planning, good, good. | 07:13 |
| dcaliste | Then, there is a MR in nemo-qml-plugin-email that must be coordinated with the MR in ui-jolla-email because I've slightly changed the way mail are built and sent. | 07:14 |
| chriadam | will that one affect also the sailfish-eas / activesync side? e.g. will other plugins have to adapt to nemo-qml-plugin-email changes? | 07:15 |
| dcaliste | What was before: | 07:16 |
| dcaliste | - mail is built in nemo-qml-plugin-email; | 07:16 |
| dcaliste | - mail is then queue for sending; | 07:16 |
| dcaliste | - page is popped. | 07:18 |
| dcaliste | Now the following scheme is in place: | 07:19 |
| dcaliste | - mail is built in nemo-qml-plugin-email; | 07:19 |
| dcaliste | - if there is no signature, mail is queue for sending and sendEnqueued is emitted; | 07:20 |
| dcaliste | - if there is a signature, the passphrase is required and the sendEnqueued signal is emitted only when mail is signed and ready; | 07:20 |
| dcaliste | - ui-jolla-email catch the sendEnqued signal and pop the page. | 07:20 |
| dcaliste | In case of error in signature, the page stay there and the user is prompt to either send it again (and enter again properly his passphrase), or uncheck the checkbox asking for signature. | 07:21 |
| dcaliste | So I think this won't affect activesync IMHO, it's only an additional step between building the message and sending. | 07:23 |
| dcaliste | chriadam & jpetrell: I need some feedback though from design, because I'm not entirely satisfied with the behaviour. When you can test sending a message, you'll see that the UX is not as smooth as it can be. Of course when resource available to look into this… | 07:24 |
| chriadam | makes sense, something in jolla-email / ui side only. | 07:25 |
| chriadam | I guess there will be some capacity available for checking UX after the current release? jpetrell ^ | 07:26 |
| dcaliste | chriadam: yes I think so. The diff is quite clear in components/EmailComposer.qml I think to see the additional step. | 07:26 |
| chriadam | maybe we can merge it as-is and then iterate the UX afterward, if needed? | 07:26 |
| dcaliste | That would be great. | 07:26 |
| dcaliste | For normal email, it has no consequences. | 07:26 |
| dcaliste | (Besides side effects on plugins, but I don't see why, everything is between nemo-qml-plugin-email and ui-jolla-email). | 07:27 |
| jpetrell | dcaliste: not smooth how? | 07:28 |
| jpetrell | chriadam, dcaliste: yeah I will review UX once we get the Sailfish 3 mature | 07:29 |
| dcaliste | You have some tenth of seconds spent between pulling "send" and the system window password appearing asking for the passphrase. | 07:29 |
| jpetrell | yeah that is not good. any idea why? | 07:29 |
| dcaliste | When password is wrong, I've tried to emphase what is wrong highlighting the signature checkbox, but I don't like it much. | 07:30 |
| dcaliste | jpetrell: difficult to avoid: the pinentry is a separated process. | 07:30 |
| jpetrell | publish notification describing the error to user? with warning icon | 07:30 |
| dcaliste | Will take time to be trigerred. | 07:30 |
| chriadam | the IPC will take time. jolla-email -> secrets, secrets -> gpg, gpg -> secrets_auth_plugin, secrets -> pinentry. will need a busy spinner to show that the send operation is in progress. | 07:31 |
| dcaliste | Maybe it will require to add a busy something on composer during waiting time. | 07:31 |
| dcaliste | chriadam ;) | 07:31 |
| jpetrell | yeah since email app knows signature checkbox is checked it should show some kind of loading state, e.g. inline banner with busy indicator and label | 07:31 |
| dcaliste | Current implementation in composer is quite crude, but since there were various options, I wanted you to try and give me your opinion before trying various options. | 07:32 |
| jpetrell | overall not good to have so much latency in in-device use cases | 07:32 |
| jpetrell | ok | 07:33 |
| dcaliste | For the error, I didn't go the notification and wanted to have something in-app because the page is still present. | 07:33 |
| dcaliste | Once everything is in place to easily test for you, I think we can iterate quite quickly to find a nice and smooth solution. | 07:34 |
| jpetrell | we often handle such transient error states where operation fails with notifications. in-app in general would be better but notification is more consistent with other platform use cases | 07:34 |
| jpetrell | dcaliste: that is true. UI-wise these are easy solutions | 07:35 |
| dcaliste | Ok for notification then. I'll give it a try maybe in a separate branch so we can test both side by side. | 07:35 |
| dcaliste | chriadam: I know you're very busy and have more pressing topics. So when you have a moment, may you give a look to https://git.merproject.org/mer-core/nemo-qml-plugin-email/merge_requests/39 ? | 07:39 |
| chriadam | I will certainly take a look, hopefully Thursday | 07:39 |
| dcaliste | Particularly to the discussion ? It's about allowing to sync several mail folders, not only the Inbox one. | 07:40 |
| chriadam | sure | 07:40 |
| dcaliste | All the code is already available in QMF, but Inbox is hardcoded in buteo-sync-email and in it's relation with the EmailAgent in nemo-qml-plugin-email. | 07:41 |
| dcaliste | Thank you anyway ;) | 07:41 |
| chriadam | thank you very much for your work | 07:41 |
| chriadam | just for clarity, what are next steps? | 07:41 |
| chriadam | 1) qmf upstream merge | 07:41 |
| chriadam | 2) mer-qmf updated? | 07:41 |
| chriadam | 3) n-q-p-e reviewed + merged | 07:41 |
| chriadam | 4) jolla-email reviewed + merged | 07:41 |
| chriadam | 5) jolla-settings-accounts merged? | 07:42 |
| chriadam | 6) need to merge secrets gpg plugin | 07:42 |
| chriadam | 7) anything else? | 07:42 |
| dcaliste | No 7), exactly these 1 to 6. | 07:42 |
| dcaliste | 1-4 will provide signature checking. | 07:42 |
| chriadam | ok. does (2) need input from our side at this stage? | 07:42 |
| dcaliste | No, I take care of 2) myself. Waiting for upstream merge to update submodule. | 07:43 |
| chriadam | ok | 07:43 |
| dcaliste | 4-7 will provide signature of new emails. | 07:43 |
| dcaliste | chriadam, last question, where can I discuss with pvuorela, mvogt and yourself a design issue in QMF? | 07:43 |
| dcaliste | It's about handling attachment-only emails. | 07:44 |
| chriadam | so then I will do (1), (3), (5), (6) next week (fingers crossed). jpetrell hopefully will get a chance to do (4) next week. | 07:44 |
| dcaliste | I mean, no multipart, just the message being disposition:attchment. | 07:44 |
| dcaliste | chriadam: great, I'll update 2) (required for 3) as sson as 1) is done. | 07:44 |
| chriadam | I can ask matt if he can join this channel on Thursday or Friday, I suppose | 07:45 |
| chriadam | not 100% sure if he will have meetings or so forth on at this time though | 07:46 |
| dcaliste | chriadam: yeh, thanks, because I don't see any way to handle this without major changes in QMailMessage which will require a lot of discussions to make it properly. | 07:46 |
| chriadam | ah | 07:46 |
| dcaliste | See https://together.jolla.com/question/190602/bug-email-client-unable-to-handle-content-transfer-encoding-base64/ | 07:47 |
| dcaliste | I've checked RFC, IMHO this email is valid. | 07:47 |
| dcaliste | It is treated propely by QMailMessage, but there is no attachment, because attachment is supposed to be a MailPart, while Message doen't inherit MailPart. | 07:48 |
| chriadam | ok, I will mention this to Matt and see if he's available on Thursday or Friday for a chat. please ping me on Thursday (or Friday, whichever suits you best) | 07:49 |
| dcaliste | So, if you think that the issue requires indeed discussion, that would be nice if we can have a meeting at one moment. It's not in a hurry though. | 07:49 |
| chriadam | hopefully pvuorela_ will be free then also | 07:50 |
| dcaliste | Thursday or Friday morning is fine with me. I'll ping around 7am UTC. If not everyone is here, we can move it to another day/week, no problem. | 07:51 |
| chriadam | thanks | 07:51 |
| chriadam | good that we have clear path forward, for the moment too. Just depends on whether we have time to do the review and merge next week. Thanks very much once again for your great contribution and communication. | 07:52 |
| dcaliste | Great, thank you chriadam also for mentoring and review work. | 07:53 |
| chriadam | and I'll poke Matt about Thursday :-) | 07:54 |
| chriadam | is there anything else? if not, have a great evening | 07:54 |
| dcaliste | Nothing more indeed. Maybe just a word also for jpetrell about Calligra. I've corrected the performence regression issue. Latest can be tested and should be more or less to the same level as the older 2.9 we currently have. | 07:56 |
| dcaliste | I've upstreamed all patches making sense and am trying to propose some additional modifications upstream also to avoid one or two more. | 07:58 |
| dcaliste | Remaining patches are about patching build system because we don't have KF5 packages and I've tried not to compile so many of them or with full capabilities when it was not related to document viewing. | 07:59 |
| chriadam | that's great news. jpetrell, pvuorela_ what's the plan with that calligra upgrade? 3.0.1 content, or is that too risky? or did it require something more invasive (e.g. new Qt or so)? | 08:00 |
| dcaliste | I've packaged LATEST (a bit more than 3.1.0). It's not requirering Qt upgrade, I've patched what was needed for 5.6 to work. | 08:01 |
| dcaliste | Normally, you can directly test the calligra packages from my OBS without touching anything else on device. | 08:01 |
| dcaliste | https://build.merproject.org/package/show/home:dcaliste/calligra-bundle | 08:01 |
| dcaliste | Later modifications will require to update sailfish-office also for newer functionalities like annotation, text search or even why not edition but that's for later when calligra latest is in MER. | 08:03 |
| chriadam | cool | 08:04 |
| chriadam | ok, I will poke pvuorela_ again about that one next week | 08:04 |
| chriadam | I guess everyone is super busy until then at the very least | 08:04 |
| dcaliste | Sure, I understand, just to keep you informed about advances. | 08:07 |
| chriadam | :-) | 08:07 |
| dcaliste | So see you next Thursday or Friday. Have a nice evening. | 08:11 |
| chriadam | thanks, you too | 08:11 |
| munchausen | chem|st yes sorry I meant the native sailfish pebble app, I can't remember what it's called | 08:42 |
| munchausen | It's rockpool | 08:43 |
| munchausen | From https://github.com/abranson/rockpool seems it's still reasonably well supported, it has switched to the rebble app store so looks good | 08:44 |
| chem|st | munchausen: just clarifying BT+android | 09:28 |
| munchausen | chem|st yeah cool. It's actually a shame for things like smart watches, but solutions do exist | 10:06 |
| rs33 | smart watches should use Sharp's memory-TFT | 10:09 |
| rs33 | sorry for OT | 10:09 |
| munchausen | rs33 yeah I agree, I use a pebble | 10:09 |
| munchausen | Although, the pebble panels are actually made by JDI | 10:10 |
| munchausen | IIRC | 10:10 |
| rs33 | memory TFT or E-Ink? | 10:10 |
| rs33 | unfortunately the mfgrs seem to think consumers want bright oled candy-colors on a watch | 10:11 |
| munchausen | memory tft | 10:11 |
| munchausen | Same sort of thing as sharp | 10:11 |
| rs33 | cool | 10:11 |
| munchausen | https://www.j-display.com/english/product/wearable.html | 10:11 |
| rs33 | you could get a 4" n900 style screen on a wristband | 10:12 |
| rs33 | and my idea: put a ring of thin cylindrical batteries on the watchband | 10:12 |
| rs33 | get the batt out of the watch body | 10:12 |
| rs33 | make it as slim as a normal watch | 10:12 |
| munchausen | The pebble time/time steel were supposed to have those sort of features | 10:14 |
| munchausen | Smart bands I think they were called | 10:14 |
| rs33 | nice | 10:14 |
| munchausen | The batteries I mean | 10:14 |
| munchausen | Unfortunately pebble got bought out not long after they were released | 10:15 |
| rs33 | too many innovative companies getting 'bought out' | 10:15 |
| rs33 | but this is too offtopic | 10:15 |
| munchausen | But they have the connectors to support power/serial comms with watch bands | 10:16 |
| munchausen | Yeah :) | 10:16 |
| munchausen | They do compliment sailfish well though, I hope :) | 10:16 |
| munchausen | s/compliment/complement | 10:17 |
| rs33 | sort of | 10:18 |
| rs33 | i don't know how well the reliance on animated elements (swipes) would work on memory-tft | 10:19 |
| rs33 | but can you sell any OS where things don't move and animate pointlessly nowadays... | 10:19 |
| munchausen | Oh I meant as an accessory to a sailfish phone... I'm not sure about touch screens on watches at all to be honest | 10:19 |
| rs33 | yeah that's why i say 4" screen watchband | 10:20 |
| rs33 | these 1.8" screens are not so great | 10:20 |
| munchausen | Ahh | 10:20 |
| rs33 | but that 4" body would need to be slim | 10:20 |
| rs33 | or it would look terrible | 10:20 |
| rs33 | i'd like a nice high dpi of course, so you could read a half page of info | 10:21 |
| rs33 | and built-in radio/sim | 10:22 |
| tortoisedoc | yellow | 12:18 |
| tortoisedoc | any way out of this cul-de-sac -> https://build.merproject.org/package/show/home:tortoisedoc:branches:home:sfietkonstantin:sailfish:rust/cargo?expand=1 | 12:18 |
| tortoisedoc | ping Nokius ^, mal ^ | 12:22 |
| mal | tortoisedoc: how exactly are you trying to build that, did you manually upload the source package there? | 12:26 |
| tortoisedoc | mal : i tried to upload a file via a url | 12:27 |
| tortoisedoc | and BANG | 12:27 |
| mal | maybe try to just manually upload the source package, an example here https://build.merproject.org/package/show/home:mal:anbox/boost | 12:27 |
| tortoisedoc | ok thanks, ill try that later | 12:28 |
| *** oku_ is now known as oku | 15:40 | |
| *** MMori_ is now known as MMori | 17:43 | |
| flav0r | hi im looking to install sailfish x but i have a question due to ambiguity in the instructions | 20:48 |
| flav0r | this is for a sony xperia | 20:49 |
| flav0r | anyway the instructions say to check if i have an unlockabkle bootloader. apparently i do | 20:49 |
| flav0r | but then it talks about if the bootloader is UNLOCKED before updating android | 20:50 |
| flav0r | how do i check if its actually unlocked | 20:50 |
| flav0r | or is this a bit misleading and its just taliing about if its unlockable | 20:50 |
| flav0r | oh apparently its locked because it says its unlockable | 20:52 |
| *** Renault_ is now known as Renault | 22:43 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!