| *** zbenjamin is now known as Guest51561 | 02:26 | |
| *** zbenjamin_ is now known as zbenjamin | 02:26 | |
| Tekk_ | Anyone know how solid sailfish is on a pinephone atm? Supposedly jolla got shipped some phones for porting but I dunno if that went anywhere. | 02:45 |
|---|---|---|
| Nico[m] | It still has some issues. I think there is a thread on both forums (sailfish and pinephone) and a wiki entry for it, that goes more in depth | 03:01 |
| Nico[m] | I think the biggest issue is the audio noise | 03:01 |
| Tekk_ | Hm, alright. | 03:37 |
| Tekk_ | Trying to decide between that and probably oof the XA2 models. Is the build quality as terrible on those as it is on the X? | 03:39 |
| Tekk_ | I got my refurb X not even 3 years ago. First year the camera died, second year the USB port died, and now the whole phone died on me this year. | 03:40 |
| *** nyov is now known as Guest45790 | 04:17 | |
| gmc | Tekk_: I've got my XA2 for about 2-3 years now, no issues so far.. the camera is a bit poor though, but that is a design thing and it doesn't bother me | 07:10 |
| gmc | someone forwarded me this yesterday: https://www.indiegogo.com/projects/pro1-x-smartphone-functionality-choice-control#/ - they claim to be working on sailfish support | 07:12 |
| gmc | but more than i'm willing to spend on a phone though :) | 07:12 |
| Nico[m] | I think Sailfish did run fairly well on the predecessor? | 07:15 |
| dcaliste | Hello chriadam, how are you ? | 08:01 |
| chriadam | Hi dcaliste, I'm well thank you. How are you? | 08:01 |
| dcaliste | Fine also, thanks. | 08:02 |
| chriadam | I saw your comment on my recent mkcal PR related to notifications - thanks, I will fix that to do date-time comparison as you suggest | 08:03 |
| dcaliste | I'm looking at your comment on the mKCal MR dealing with simplifying ExtendedCalendar code also. Thanks for the review. I'm going to correct the points you mentioned. | 08:04 |
| chriadam | not a thorough review, just a quick read-through earlier today | 08:04 |
| chriadam | looking great, though. nice to see so much code removal | 08:05 |
| dcaliste | Yeh, it makes everything much clearer, in particular the specificities of ExtendedCalendar with upstream. | 08:06 |
| dcaliste | Last week testing again the migration of mKCal to upstream KCalendarCore, I noticed I missed to propagate an important fix from you upstream. | 08:07 |
| chriadam | I'm currently running a grep job to try to find all .spec files with: `BuildRequires: pkgconfig(libkcalcoren-qt5)` in it | 08:07 |
| dcaliste | The one for recurring event by day of week with occurrences starting before the dtStart in timesInInterval. | 08:07 |
| chriadam | I don't recall that change specifically - hopefully it was fairly self-contained and simple to upstream? | 08:08 |
| dcaliste | I've submitted the fix and the test upstream some days ago. Got a thumb up : https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/16 | 08:08 |
| dcaliste | Well, finally, I proposed a fix slightly different, but kept the test ! | 08:08 |
| chriadam | great | 08:09 |
| chriadam | thanks very much | 08:09 |
| dcaliste | With this last patch applied to upstream, mKCal is all passing its own tests after basing it on QDateTime and upstream, yeh ! | 08:09 |
| chriadam | excellent | 08:09 |
| dcaliste | Yeh, that's very good, particularly the rawExpandedEvents() ones that are very tricky. | 08:10 |
| chriadam | absolutely | 08:10 |
| dcaliste | I feel a bit more confident now that all these extensive tests exist and passed. | 08:10 |
| dcaliste | When I started the migration some time ago these tests were not there and I had quite mixed feeling about the rightness of the migrqtion. | 08:11 |
| chriadam | I completely understand. having extensive unit tests is a huge help when making any change, even small ones. but definitely for big structural changes. | 08:14 |
| dcaliste | It seems I've got another issue with discovery code in CalDAV : https://forum.sailfishos.org/t/unable-to-sync-fastmail-calendars-after-3-4-0-24-upgrade/3451 | 08:14 |
| dcaliste | I'm going to investigate today or tomorrow. This may ends up as a new MR in CalDAV during the week. | 08:15 |
| chriadam | thanks! I didn't see that one | 08:15 |
| dcaliste | Back on the KCalendarCore migration, I've noticed that upstream does not support per incidence colors as defined in RFC7986, so I'm proposing a patch upstream : https://forum.sailfishos.org/t/unable-to-sync-fastmail-calendars-after-3-4-0-24-upgrade/3451https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/17#note_133043 (when in once but was later revert because I forgot conditional compilation on ical version :/ ) | 08:17 |
| dcaliste | With this one in, upstream will have two new fields per incidence : URL (already upstream) and color. | 08:17 |
| dcaliste | We'll have to alter mKCal components table to add these two fields. | 08:18 |
| chriadam | sure | 08:18 |
| dcaliste | I'm going to prepare a backport of these two properties and create a MR in mKCal to apply the extension. I think SQlite can add new columns without major issues on index... | 08:19 |
| dcaliste | Having this in would allow to keep event colours chosen on another client. | 08:21 |
| chriadam | flypig: you probably know more about this than I, regarding sqlite indexes and adding columns. I know that if an index is changed after an icu collation is loaded, that is bad for sqlite, but I think merely adding columns should be fine? | 08:21 |
| dcaliste | At the moment, if I defined a colour to an event on a NextCloud web UI for instance, down sync the event, modify the summary on device and up sync again makes the colour to be reseted. | 08:21 |
| chriadam | yup, that's suboptimal indeed. good to fix. | 08:22 |
| flypig | Good morning/evening. Sorry I have to catch up with the conversation. | 08:22 |
| dcaliste | Hello flypig, it was about adding columns to an existing database in SQlite. | 08:23 |
| dcaliste | They would be simple string columns, nothing fancy and not changing constraints or indexes. | 08:23 |
| flypig | Ah, I'm afraid this "flypig: you probably know more about this than I" isn't true. Sorry. | 08:24 |
| chriadam | no worries :-) | 08:24 |
| dcaliste | No problem, I'll check on the web. | 08:25 |
| dcaliste | There is already a Versiu\on table | 08:25 |
| dcaliste | There is already a version table in mKCal so checking it would allow to apply alterations. | 08:25 |
| chriadam | yep :-) | 08:25 |
| dcaliste | Technically, there are already to extra string fields in the component table that are not used and the comment saying "Extra fields added for future use in case they are needed." Do you prefer to use these fields instead ? | 08:28 |
| dcaliste | Or is creating a migration code based on version favoured ? | 08:28 |
| chriadam | I have no strong feeling either way. pvuorela might? I guess if we don't use those extra fields at all, we may as well "codify" that they mean URL + color, and update the field names etc etc. | 08:29 |
| chriadam | but I would do such changes along with a schema version bump anyway tbh | 08:29 |
| dcaliste | Ok. I'll see what I can come up with based on these reflexion. Thanks. It's for medium term anyway. | 08:31 |
| pvuorela | been thinking it would be nice if mkcal got some refactoring so that we could even modify the schema. | 08:31 |
| pvuorela | so far we've tried to squeeze in small changes when other places often just migrate the database. | 08:31 |
| dcaliste | pvuorela, looking at the current code, there is a version check that is done on opening and that stops if it doesn't match. | 08:32 |
| pvuorela | yea, but it doesn't do any migration. | 08:33 |
| dcaliste | Would you suggest to add migration code there so when a lower version is found, some modifications are done to migrate to new schemas ? | 08:33 |
| pvuorela | compared to lot of other databases that run a set of actions when version changes. | 08:33 |
| pvuorela | for example https://git.sailfishos.org/mer-core/qtcontacts-sqlite/blob/master/src/engine/contactsdatabase.cpp | 08:35 |
| pvuorela | the upgradeVersion... parts | 08:35 |
| dcaliste | Ok, I see the use of PRAGMA user_version also to allow to follow upgrading. | 08:37 |
| dcaliste | I'll keep this in mind when going to modify mKCal code for database migration. Thanks. | 08:37 |
| dcaliste | Mmmh, upgradeVersion10() looks great ;) Far from my SQL capabilities and knowledge. Interesting. | 08:39 |
| pvuorela | that's really something :D | 08:39 |
| chriadam | matt's a ninja | 08:40 |
| pvuorela | btw, suppose lot of that migration could be already removed by now? | 08:40 |
| chriadam | possibly, although not sure how stop releases work etc | 08:40 |
| chriadam | well, I mean, you're right, we can remove that code in current head. | 08:41 |
| chriadam | but for "documentation" purposes I guess it doesn't hurt to leave it, so we can "see" what happens when someone does a factory reset and then a series of upgrades. | 08:41 |
| pvuorela | doesn't hurt, except complicating the file, but otherwise it's just dead code by now. | 08:42 |
| chriadam | true | 08:43 |
| dcaliste | About migration, how should we proceed with QMF Qt6 Ci happyness (or lack of) ? | 08:43 |
| dcaliste | Some more patches begin to pile up, fixing real issues like the on of Slava, or the old one of Rainemak. | 08:44 |
| chriadam | from pragmatic perspective, I'd prefer to merge things into our repo if we are happy with it, to avoid blocking those. | 08:45 |
| chriadam | I had let that one slip off my radar a bit unfortunately. on upstream side, what are the current issues remaining? | 08:46 |
| dcaliste | No idea, it compiles fine on my machine the last time I tried with the Qt6 of that moment. | 08:47 |
| dcaliste | But, you never know what CI will trigger because of slightly different flags or compiler version. | 08:47 |
| chriadam | ok, great. I will try also on my machine, and run `make check` also. | 08:47 |
| chriadam | tomorrow | 08:47 |
| chriadam | oh wait, I'm not in the office tomorrow | 08:48 |
| chriadam | thursday | 08:48 |
| dcaliste | Ok thanks. | 08:48 |
| chriadam | if all the tests pass on my machine, we can start looking at pressing the button. I'll poke matt ;-) | 08:48 |
| chriadam | I didn't get a chance to try building e.g. buteo-sync-plugins-social with upgrade kcalcore stuff, but hopefully will get a chance to do so on thursday also. | 08:49 |
| dcaliste | Thank you. The fact that extra-cmake-modules was upgraded last week simplified much the compatibility with older version patch. That's noticeable ;) | 08:51 |
| dcaliste | Just remains the Qt version issue in the patch :/ | 08:52 |
| dcaliste | Maybe one last topic today, is the setEnabled() stuff in sailfish-components-accounts. | 08:52 |
| chriadam | flypig: iirc you had some comments on that one ^ | 08:53 |
| dcaliste | I've modified it following the nice idea of flypig to use setConfigurationValue(). | 08:53 |
| flypig | Yeah, it looks fine to me. I'm confused about the situation with regards selected calendars in the settings app, but I think that's a separate issue and should be treated separately. | 08:54 |
| flypig | I should have approved+merged it already, sorry dcaliste. | 08:54 |
| dcaliste | No problem flypig, you have other business at hand, I'm sure. | 08:54 |
| flypig | dcaliste, your last comment, about saveAccount(), is that a reason not to merge already? | 08:56 |
| flypig | (I'm thinking not, but just checking). | 08:57 |
| flypig | To clarify (too many negatives): I'm thinking it's not a reason to not merge. | 08:57 |
| dcaliste | I don't think so, I was just wondering if your modifications not to trigger sync if no changes were done is in 3.4.0. If so, there's something I don't understand because the sync() code path seems to be activated since the calendar visibilities are changed. While with the patch they are not. | 08:58 |
| dcaliste | If your changes didn't make it for 3.4.0, then it's fine and the patch seems to cure the behaviour, for CalDAV calendars at least. | 08:59 |
| flypig | Let me just check that then. The changes went in with dee01acc887c6cd1fe45eceeebb4e64db4cc0623 | 09:00 |
| flypig | It looks like they went in after 3.4.0. | 09:02 |
| dcaliste | Ok, so that's why just looking at the page and quiting it is triggering the sync. | 09:04 |
| dcaliste | So my question in Bitbucket got an answer ;) | 09:04 |
| dcaliste | If you agree feel free to accept the patch then. | 09:04 |
| flypig | Yeah, I double-checked, and it definitely looks like it was added after the 3.4.0 branch. Okay, good. | 09:05 |
| flypig | Okay, I'll accept and merge. | 09:05 |
| flypig | Today :) | 09:05 |
| chriadam | thanks very much, both of you. | 09:05 |
| chriadam | anything else to discuss? any PRs that I've forgotten about which need my attention? | 09:05 |
| flypig | Can I take the opportunity to ask about the buteo-plugsin-sync-social change for Google calendars. | 09:06 |
| chriadam | oops I forgot all about tha tone | 09:06 |
| dcaliste | No that's all for me. Thanks. flypig, no problem to discuss the social MR. | 09:06 |
| flypig | Well, you both gave excellent, really useful, comments. Thank you for that. | 09:06 |
| flypig | I tried to address them all. | 09:07 |
| chriadam | seems there's an open query about a change related to determining if a local modification should be discarded due to remote deletion | 09:08 |
| chriadam | dcaliste: you originally said "good catch" when flypig added a check to the condition, but it's not immediately obvious that the extra check is needed | 09:08 |
| flypig | Yes, in the latest push I removed that check again. | 09:09 |
| flypig | But I'm uncertain. | 09:09 |
| dcaliste | I said "good catch" because it seems to me that without the modification proposed by flipig the else if branch will never be reached. But I didn't look at the content of the branches and if they were necessary :/ | 09:10 |
| dcaliste | Or did I mixed again a && and a || ? (always need to read three times a boolean condition for unknown reason my brain always interpret them the opposite way) | 09:11 |
| flypig | dcaliste, yes, it looks like that, but in fact one refers to the event, and the other to the parent. | 09:12 |
| flypig | Unless one implies the other? | 09:14 |
| flypig | if (allMap.contains(eventId)) { | 09:14 |
| flypig | } else if (!parentId.isEmpty() && allMap.contains(parentId)) { | 09:14 |
| dcaliste | Is parentId and eventId different in Google serialisation format ? | 09:15 |
| chriadam | I may be wrong, but I think the way it is in the current version is correct (i.e. without the added condition) - in any case, it's not strictly related to this change/PR so if it's wrong, we could look at it separately I think (i.e. different PR) | 09:15 |
| dcaliste | In CalDAV, occurrence->uid() == parent->uid() by design. | 09:16 |
| flypig | I don't know about this: "Is parentId and eventId different in Google serialisation format", would need to check. | 09:16 |
| chriadam | I don't recall the specifics (whether an occurrence id from google will differ from parent series id, or not) | 09:16 |
| chriadam | in either case, changing the semantics of this particular piece of code seems out of scope for the PR, or am I mistaken? | 09:16 |
| dcaliste | The fact that it can be treated in a separated MR is justified indeed. | 09:17 |
| flypig | Yes, I'd agree with you both on that. | 09:17 |
| dcaliste | So the rest can goes in and this can be discussed on its own. | 09:17 |
| flypig | I'd be happy with that. I can look into the difference between parent/eventId and report back next week, if you like? | 09:18 |
| dcaliste | But it seems indeed that eventId and parentId means something different than event->uid() otherwise the code would have no sense. We can both look at this during the week indeed. | 09:20 |
| flypig | That would be great, thank you. | 09:20 |
| chriadam | thank you | 09:21 |
| chriadam | and as always, thanks for your hard work and effort :-) it is much appreciated | 09:22 |
| chriadam | have a great week! | 09:22 |
| * chriadam -> home | 09:22 | |
| dcaliste | Thank you have a good week both of you two. | 09:22 |
| flypig | Same from me! | 09:23 |
| *** frinring_ is now known as frinring | 10:25 | |
| karry | Hi @lbt . May I ask you for user account on git.sailfishos.org ? I would like to send few patches to connman. My Jolla username is Karry... | 11:53 |
| lbt | sure | 11:54 |
| lbt | I sent you a msg - need an email too | 11:55 |
| lbt | sent | 11:58 |
| karry | Thank you! | 13:57 |
| Tekk_ | Nico[m]: Not to necrochat, but gmc was responding to my issues with the build quality of the Xperia X. Sailfish ran fine on the X for me. | 15:06 |
| Nico[m] | I feel like I completey lost the context for this :D | 15:07 |
| Tekk_ | I was asking about sailfish XA build quality, then gmc said it was fine and linked a new indiegogo phone saying they want to improve sailfish support, then you said it was well supported on its predecessor, so I think the conversation had actually moved a bit c: | 15:09 |
| Nico[m] | Ah, I see | 15:10 |
| Nico[m] | Happy that it works for you :3 | 15:10 |
| Tekk_ | Haven't tried it yet. Still trying to decide whether it's better to go with a pinephone and have a jankier experience at the start with more possibilities or just get an XA Ultra/Plus | 15:11 |
| Nico[m] | Pinephone is very janky atm | 15:12 |
| Nico[m] | X I have been using for as long as it has been available already. Pinephone is no fun to use atm. | 15:12 |
| Tekk_ | Mhm. But it supports more than sailfish in case something bad happens to Jolla, and if I had to guess at the end of the day there's not going to be any reason to go for an official Jolla port aside from wanting to support them. | 15:13 |
| Tekk_ | Anbox is looking more promising than whatever they do for android compatibility officially (I remember using the predecessor on my nexus 5, which was the best android support I've seen on a sailfish phone as far as compatibility,) apps in the jolla store are always way behind storeman, etc. | 15:14 |
| Nico[m] | In my experience there is no good OS on the pinephone yet. it is improving slowly, but everything is laggy and a lot of stuff doesn't work and you need to do a lot of command line stuff | 15:14 |
| * Tekk_ nods | 15:14 | |
| Tekk_ | It's basically a something that works now vs something that works later problem imo | 15:15 |
| Nico[m] | There is no guarantee, that the PP will ever work really well | 15:15 |
| Nico[m] | It feels currently, like this will always be a devkit | 15:15 |
| Nico[m] | I'd suggest buying one, when it actually works (and the lastest hardware iteration by that point). Unless you want to develop for it now, then by all means go for it | 15:16 |
| Tekk_ | I mean I do like the idea of developing on it, but I do also know that the software isn't here yet, hence my problem. Iirc a big part of the performance issue was fixed recently and should be trickling out to distros, but there's a fair amoung of jank around calls and texts | 15:17 |
| Tekk_ | I also don't know how well anbox works *on* the pinephone. Haven't tried that | 15:17 |
| Nico[m] | In my experience jollas android stuff works a lot better, since it is better integrated with other apps, but you can already run apps in anbox on the PP | 15:19 |
| Tekk_ | tbf part of my caution there is the announcement that they weren't updating the android compatibility layer on the X beyond 4.4 | 15:24 |
| Tekk_ | Which is a version of android which was several years old when sailfish x launched | 15:25 |
| Nico[m] | On current devices it is android 8 iirc | 15:26 |
| Tekk_ | Yeah. | 15:26 |
| Nico[m] | Just not on the older devices, that are not based on lxc | 15:26 |
| Tekk_ | So basically they weren't able to do it because the kernel used for older devices doesn't have LXC compiled in? | 15:27 |
| ol | Nico[m] (IRC): That are not based on Android 8+, to be precise. | 15:27 |
| Nico[m] | No, old devices weren't updated, because it would have been a lot of effort and it wouldn't have made them much money, I think | 15:28 |
| Tekk_ | Maybe I'll give it a shot then. Annoying as it'll be to have to go through the dance to pay Jolla again | 15:29 |
| ol | Hardware adaptation for Xperia X was based on older Android. And AFAIK, Alien Dalvik is somehow tied to Android version underlying hardware adaptation uses. | 15:29 |
| Nico[m] | ol: Well, not really. The Xperia X was never shipped with android 4.4. | 15:30 |
| Nico[m] | But the adaption is tied to the hardware and at least before lxc it was not easy to update | 15:30 |
| ol | But it was not shipped with Android 8 at the time hardware adaptation wad made. | 15:30 |
| Nico[m] | I think the move to lxc made that a bit easier, but not sure | 15:30 |
| Tekk_ | Quick check: as far as sailfish is concerned an XA2 Ultra is an XA2 Ultra is an XA2 Ultra right? | 15:30 |
| Tekk_ | Not like the Xperia X where the single and dual sims had differing support | 15:31 |
| Nico[m] | ol: Sure, but if it had to be shipped with the original android version, the X would have 6 or 7. But it has an older version, because that's what dalvik supported at the time | 15:31 |
| Budgii | hi! i'm trying to flash sailfish for my pinephone via the script installer | 15:33 |
| Budgii | it seems to be hanging on the flash step. is that normal? | 15:33 |
| Budgii | (been maybe 10 minutes) | 15:33 |
| ol | Nico[m] (IRC): I think, Alien Dalvik does not get latest version of Android from hardware adaptation automatically. It supports some Android API version by itself, but this version can not be newer than hardware adaptation's one. For example, Sony Xperia 10 was shipped with Android 9, but Alien Dalvik still supports only Android 8. | 15:35 |
| Nico[m] | Budgii: Check if you are still doing io to the sdcard, i.e. run iotop for example | 15:35 |
| Nico[m] | ol: There may be an issue like that. but that is not the reason, why the Xperia X will never get something newer than 4.4 | 15:35 |
| Tekk_ | Alright, ordered an XA2 Ultra | 15:36 |
| Nico[m] | Tekk_: Have fun with it and don't blame me, if you don't like it! >.< | 15:36 |
| Tekk_ | :D | 15:36 |
| Tekk_ | I'm sure I'll like it fine in the moment. I'm just not looking forward to it potentially dying in a couple years | 15:37 |
| ol | Nico[m] (IRC): The reason is that hardware adaptation on Xperia X is based on older Android, so newer Alien Dalvik that supports Android 8 can not run on it. And nobody is going to make a new hardware adaptation for Xperia X based on Android 8. | 15:37 |
| Budgii | ooo, it just finished guys, its all done. booting pinephone now! | 15:38 |
| Nico[m] | Tekk_: With Sailfish, the worst that usually happens is that your android support doesn't get updated. My first Sailfish device is still getting updated! (Just not the android support) | 15:38 |
| Nico[m] | Budgii: Good to hear, you probably just had a slow sdcard or writer :3 | 15:39 |
| Budgii | Nico[m]: most likely. I plugged it into my pi to write, lol | 15:39 |
| Budgii | does sailfish allow convergence package with pinephone? | 15:39 |
| Nico[m] | I need to flash my sdcards from my xperia x compact, since all my other sd card writers are somewhat broken. Fun! xD | 15:40 |
| Tekk_ | Nico[m]: No, I mean dying in a very real sense. I have a post on the forum about it. Bought a refurb X in 2018 -> had to replace the camera in 2018 -> had to replace the USB port in 2019 -> 2 days ago I turned the phone off and it won't turn back on, not visible via fastboot, etc. | 15:40 |
| Tekk_ | I was *annoyed* about android updates but those weren't the end of the world | 15:40 |
| Nico[m] | ol: Yep, that's pretty much it, also explained here: https://blog.jolla.com/sailfish-x-sony-xperia-10/ | 15:41 |
| Nico[m] | Tekk_: Well, that sucks, but my X compact still works perfectly fine, so not all of them are broken :D | 15:42 |
| ggabriel | I heard that it's also a challenge to migrate app data from Android N to Android M (N<M), I wonder who cares about their app data too | 15:42 |
| Nico[m] | ggabriel: I do. Whatsapp would lose all my messages otherwise :D | 15:43 |
| Tekk_ | Phone should be here on Monday. | 15:43 |
| Nico[m] | (Although I'm moving WA to a vm soon and then I won't need android at all anymore) | 15:43 |
| ggabriel | Nico[m]: just send a gdpr request to facebook and ask for all your chats | 15:44 |
| Nico[m] | (Since my matrix client is progressing well and I have it bridged to the WA running on my phone) | 15:44 |
| Nico[m] | ggabriel: WA is e2ee, so that would just give me a bunch of garbage :D | 15:44 |
| Nico[m] | And I have to many contacts, that only message me on WA | 15:45 |
| Tekk_ | Sure it is :D | 15:45 |
| ggabriel | Nico[m]: I don't think that's true; I'm sure I can prove it, too. But never mind :) in your case, you don't want your android upgraded then! | 15:45 |
| Nico[m] | Tekk_: Well, the messages are encrypted, but it would be very easy for WA to backdoor, by just removing the QR code scan step from the weblogin | 15:46 |
| Budgii | ahh, appears sailfish does not support convergence on pinephone. :< | 15:46 |
| Nico[m] | ggabriel: Well, soonish I won't need the android support at all :D | 15:46 |
| Tekk_ | Does it support convergence on *anything*? | 15:46 |
| Tekk_ | That's more UBPorts' thing | 15:46 |
| Budgii | Tekk_: it worked on the manjaro os it came with, ubports did not | 15:47 |
| Budgii | was my last try with convergence :) | 15:47 |
| Tekk_ | Weird | 15:47 |
| Budgii | ya. specificially, with pinephone i dont think convergence is supported | 15:48 |
| Tekk_ | Back when Canonical was trying to develop ubuntu touch, convergence was the whole selling point | 15:48 |
| Budgii | yes. its a future goal for pinephone, if i understand correctly | 15:48 |
| Budgii | onto the next os in search of compatibility with convergence. i bought the adapter, gotta find one. right? :) | 15:48 |
| Budgii | how do I close an app on the homescreen view? | 15:57 |
| Budgii | dont remember that being covered in the tutorial. i like the responsiveness to touch on this os! | 15:57 |
| Nico[m] | long press | 15:57 |
| Nico[m] | Then it should show little X s | 15:57 |
| Budgii | oo | 15:58 |
| Budgii | Thanks! | 15:58 |
| *** vilpan is now known as Guest40387 | 17:09 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!