Sweet!

@mango Have you tried installing the Snap versions?

@lduboeuf I think that I can as well note here the results of my sunday tests with Radicale and UT, it will allow me to retrieve them easily and maybe be of some usefulness to others: it works with 24.04-1.1 stable, but it can be quirky. I used a test server that has already other databases, notably an address book, and these database were proposed as options for sync with the calendar. It's already a problem since an address book is not a calendar. However it got worse since even after selecting the right database, the sync failed repeatedly until I deleted the 'wrong' databases. The server reported a 400 error on some query aimed to the address book (why oh why since I asked specifically to sync with the calendar...) and the whole sync was failed (I guess that Google Calendar has not this problem since it's just a calendar, it does not try to support all kind of Dav databases like Radicale do) This was reported by a red indicator in the UI, however the detailed journal was not particularly enlightening, it reported error codes (10400 ? I guess it was error code 400 with database number 10 - so very Unixy error reporting ) The whole testing was not made easier by the syncevolution user interface, a software that has a conception of 'user friendly' that is decidedly selecting its friends. I had to delete the offending files with 'rm' in the evolution (not syncevolution) directory via the command line to get rid of the excess databases in the UI, while they all got back when I deleted the last one (the calendar). Finally butchering my test server was the right option (and now I don't have any failing test case anymore ).

@vverve From what I know all the gtk/XWayland apps are affected. Something was probably changed in the system concerning maliit. ( Chromium for UT, Min browser, Signal UT, uWolf, Rocket.chat, ect... ) For now I cannot test 24.04-2.x, maybe later. Probably system devs should know more about that problem, and what may have been changed in regard to OSK and maliit.

I have installed the latest version of Dekko (0.5.2) on my OP5T (noble), but the validation cannot be completed (the circle spins endlessly). I would like to integrate a very simple IMAP/SMTP mailbox, which I have successfully linked to other systems with identical settings. The attempts described with an older version or restarts were also unsuccessful. What could be the problem, and what else can I try? Thank you.

Maintenance is now complete!

@vverve GREAT ! Hopefully, that will help others who might be trying to figure out which phone they could buy or upgrade, to be most usable in their respective countries. It definitely was not clear to me when I started searching here 6 weeks ago !

@Bubu Kein Problem, falls es noch klemmt, sag' Bescheid.

@Vlad-Nirky That is an issue with the device from Xenial and Focal.

@Caedem likely not how it works. The 3.5.1 was the last xenial release. Those 9k focal devices, are those who moved from xenial to focal. So there would be a bit less than 4k xenial left with numbers shrinking. And we need to drop them for security reasons at some point. Or can you justify providing a unmaintained insecure system? Also some older devices will simply die due to hardware breaking.

Viability: hmmm, at the moment: No voice calls (no VoLTE) on Pixel 3A (which WAS a primary supported phone for UT), on UT in USA (which is the third largest phone market by country, or 4th largest by region, after Europe). [alternative: VOIP - NOT available in openstore for most recent version UT] That is pretty NON-Viable, if you want a phone you can make calls on. Is that the fault of the UT teams ? I would say NO, it is the fault of the much larger system cancelling 2G, 3G, (USA & Australia , etc, now, and changing worldwide, with plans in place over 10 years ago) and the fact that the drivers for the radio chips and most others are closed source or Android or whatever. Who would be the ones to fix it ? UT dev teams, if at all. Or, what about WiFi calling ? Not functional. Is that the fault of UT devs, or other main stream code (from the larger base) being unavailable ? OR some phone brands / models NOT supporting required radio bands in some countries. NOT Viable. I think PC's are a better analogy than cars, since we are mostly talking software here, not hardware. if using cars analogy, could mention how air bag manufacturers caused a huge recall problem for a variety of car manufacturers. Q: So, where did UT come from ? A: 1) a gigantic base of hardware and software: major players who recently CANCELLED (in some countries, and in process in others) the fundamental ability of UT to make phone calls, through changes to the larger hardware and software system. A: 2) a few dedicated, volunteer developers who are doing their best to modify code for specific devices to overcome above obstacles.

@fredldotme noted, if a bit late

@qusay Thank you that is very helpful!

@gpatel-fr Yeah, I noticed that about the logs too. The phone "thinks" I sent a text, and then it "thinks" I sent another text, but in the middle the phone does "not think" that I tried sending a photo message. Which I did. There's actually three message attempts in that timeframe. The photo message send(MMS) just might as well have never happened at all. It's completely missing, my human activity is not there logged in that moment. So the text messaging app itself probably would have sent the photo over to my carrier but it just never knew I attempted to send the photo from the OS to begin with? I don't know for now but I'm going to have to do the hard reset and wipe it all and start over. For now I need this working. I haven't gotten any text messages in over a week now and and I know how to get it working again. It just is what it is. I need to think about how I will add this to the bug report.

I did not try your method yet, however I debugged the problem in my method. It's something (I guess Lomiri itself) that is sending a signal when the window is paused while switching. It is killing xev. The fix is to use TweakUT to keep the terminal awake, then my method works whatever the launch mode (direct > or with starting a new task &>) So I could repro the problem you have seen. No discrepancy here. I have looked a bit at Firefox and Chrome under vanilla Linux (Kubuntu 24.04) and xev reports something very different than under UT. That is, no strange events, basically the system reports the menu being created and mapped and that's all. I have also 'packaged' a recent version of Firefox freshly downloaded from the editor's site, that is, I did env GDK_DPI_SCALE=2 MOZ_ENABLE_WAYLAND=0 DISABLE_WAYLAND=1 ./firefox and the menus in the top bar display (if no scaling were done, I'd guess that the menu would display if by a stroke of luck I could hit the minuscule screen area) So my guess is that's not a clever packaging trick, that's something that Firefox is doing differently than Chrome. I searched for a Chrome Linux arm64 build but it seems that Google has insufficient resources to generate arm64 Linux builds (it's not a joke, it's exactly what is said by a Google employee in the Chrome issue tracker). I'd say that as under UT Chrome and Firefox are hitting XWayland that is hitting Mir, the problem could be all the way down to Mir. The version of Mir in current 24.04 UT is woefully outdated. When it will be updated, the way forward will be to switch to Wayland anyway and drop XWayland.

It's beginning now.

Latest build fixes the vertical black lines which can be seen sometimes.

@libremax Wow, nice! Thanks to whoever did the work and thanks for letting me know!