Offline
Just one question: Any reason you don't host this project on a git platform, like "Github" or "Gitlab" or "Bitbucket" ? Maybe having to go to google drive links may look a bit weird for some people.
Maybe it could help also to publish more screenshots, or even better a video of your application running on Ubuntu Touch.
Also I'm sure you will get feedback when you publish the app on the openstore, but it might not be ready yet?
Thank you!
It's not that there is only "system", it is that the combobox, ( or "<select>" in html ) does not work. i.e the element that allows you to chose, does not display well, but it is sadly the case in most XWayland apps, in UT and I can't do much about it right now.
What do you mean "change the appearence"? It simply means that you can display and navigate properly in the menu in vertical mode, as shown in the screenshot.
The combobox still do not work, it is a problem with XWayland and Lomiri.
I've published version 0.8.3-2 with the following improvements.
Note: no Signal-Desktop version bump for this revision, because building broke with my current scripts for 8.4.0 and 8.5.0, I'll have to look into it later.
Don't hesitate to tell me if everything works well for you.
@pparent Where was this announced?
Well "annonced" maybe was not the correct term, but it was at least mentioned as a possibility here:
Just out of curiosity, in the end is the fairphone 6 supported by mainline linux kernel as annonced?
The idea is that it's a generic feature, not something specific to Ubuntu Touch.
Well yes and no. It is a generic feature to detect option 114 and make the request to the API. BUT It is an OS sepcific feature to decide how you are going to display the captive portal. Here I display it using urlDispatcher via DBus that is an UT-specific feature that could hardly be upstreamed. Android has it's own mini-browser designed exclusively to display captive portal.
So this is kind of hard to have a generic way to handle captive portals in all OS that embed NetworkManager, independenty of the OS specifics. And all the existing OS (Android, iOS, Windows, MacOS) handle captive portal each, their own way.
I don't think in that regard UT should limit itself to what is availiable upstream, i.e keep basic things not working and not implemented, while it requires a 20 line script to have things running fine. If some day NetworkManager improve it's implementation, it will allways be time to use it then.
Yes but, that being said on desktop this feature is not as important as on mobile. Even in windows the portal does not open automatically, and it's handled browser-side. So on desktop it seems more "OK" not to have this feature system-side.
On Ubuntu Touch given that Morph does not handle at all captive portal internally, it seems to me very important to be able to open it automatically. I've seen several users complaining of not being able to use networks with captive portals, and even cited as one of the reasons they can't use it as a daily driver. (Example here: https://www.youtube.com/watch?v=HjfwyMuLnPo&t=475s )
I will look at the pull request you mentioned, thanks! Ps: Ha but it was not a merge request it was just an issue wasn't it?
Nice! Your app could be very useful especially to receive notifications in background with lower battery costs.
Hope the whatsmeow library can remain reliable in the long run!
Maybe you would like to post some screenshots of your app? 
Very nice!
How do you interact with Whatsapp protocol? Did you reverse ingeneer it yourself? Do you use an existing library?
Ps: we could add in the same script the "legacy" hotspot detection (on top of the RFC8010 detection) based on make a dummy http request on a dummy URL, and it could allow have a large compatibility to detect most hotspot portals on the market.
So I've found a way to have hotspot detection working with rfc8910.
Here is the behaviour when I connect to a Hotspot Wifi compatible with rfc8910: https://www.youtube.com/shorts/0et6I-lwwwQ
To have it working you need to add to the filesystem the following script:
/etc/NetworkManager/dispatcher.d/99-rfc8910
#!/bin/bash
# NetworkManager dispatcher script for handling DHCP Option 114 (RFC8910)
# Opens the captive portal with URLDispatcher if the network indicates a captive portal
logger "Option 114 init $1 $2"
IFACE="$1"
STATUS="$2"
# Only proceed if the interface is up or dhcp4-change
if [ "$STATUS" != "dhcp4-change" ]; then
exit 0
fi
# --- Retrieve the Option 114 value using dhclient test request ---
dhclient -1 -v -lf /var/lib/NetworkManager/dhclient-rfc8910-wlan0.lease wlan0
LEASE_FILE="/var/lib/NetworkManager/dhclient-rfc8910-wlan0.lease"
CAPTIVE_API=$(grep 'option default-url' "$LEASE_FILE" | tail -n1 | awk -F'"' '{print $2}')
# Remove escaped ampersands (\&) from the URL
CAPTIVE_API=$(echo "$CAPTIVE_API" | sed 's/\\//g')
if [ -z "$CAPTIVE_API" ]; then
logger "No DHCP Option 114 found for interface $IFACE"
exit 0
fi
logger "DHCP Option 114 detected for $IFACE: $CAPTIVE_API"
# --- Query the captive portal API using wget ---
API_RESPONSE=$(wget -qO- "$CAPTIVE_API")
if [ -z "$API_RESPONSE" ]; then
logger "Failed to reach captive portal API: $CAPTIVE_API"
exit 0
fi
# --- Parse JSON for 'captive' and 'user-portal-url' ---
# Extract the 'captive' status (true/false)
CAPTIVE=$(echo "$API_RESPONSE" | grep -oP '"captive"\s*:\s*\K(true|false)')
# Extract the 'user-portal-url' and remove all backslashes
PORTAL_URL=$(echo "$API_RESPONSE" | grep -oP '"user-portal-url"\s*:\s*"\K[^"]+' | sed 's/\\//g')
logger "Captive portal API response: captive=$CAPTIVE, portal_url=$PORTAL_URL"
# --- If the network is captive, open the portal URL via D-Bus ---
if [ "$CAPTIVE" = "true" ] && [ -n "$PORTAL_URL" ]; then
USER_NAME=phablet
sudo -u "$USER_NAME" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/32011/bus" \
gdbus call \
--session \
--dest com.lomiri.URLDispatcher \
--object-path /com/lomiri/URLDispatcher \
--method com.lomiri.URLDispatcher.DispatchURL \
"$PORTAL_URL" ""
logger "Captive portal opened: $PORTAL_URL"
fi
Don't forget to chmod +x /etc/NetworkManager/dispatcher.d/99-rfc8910 and reboot
Tested on 24.04-1.x daily on OnePlus Nord N10
Unfortunatly the script is slightly hacky because it requires to make an external dhclient request. I've not found any other way around as the internal Network Manager dhcp client does not support option 114 in any way. We'll see if it can integrated to the system despite this, and if it can be slightly improved.
On what canal should I discuss with system devs about that?
I'm wondering about something, as this problem is an IP loss problem, I think it should be noted that by defualt NetworkManager uses it's internal dhcp handler. But it is also possible to configure it to use dhclient. And I wonder if the later would not be more reliable.
So I think I will test to change the configuration of my NetworkManager to use dhclient, and see if it has any impact on this bug.
Although, to be fair the creator of the WhatsNew app has taken measure to suspend the app when it looses focus as well
I've not done that specifically in whatsnew. What happens is that normally when an electron app is not anymore in foreground it goes into a "throttling" mode meant to keep operating the website but with lower resources. This is a feature from chromium.
That being said I have no idea why XWayland/electron apps don't get suspended by default. For Signal UT or Whatsnew it is handy to get background notifications though.
The behaviour encountered by @smobilesoft (high CPU usage) is not normal , I've not been able to observe it myself, and it seems since he reinstalled the app it has gone. So this is a bit strange.
Ok well this is very strange.
Well it's possible that whatslectron take a lot of CPU on some occasions. For example when syncing messages. But this should not be a recurrent behaviour that drains the battery when the app is in background.
If there were 2 windows remaining this could explain the problem, but I don't see how uninstalling and reinstalling the app could have any effect on that, as you now seem to have the proper behaviour i.e the second window closing after few seconds.
But, so do you still have the battery drain problem?
Hum this is kind of strange as I don't observe anything similar. For me "Whatslectron" which is the process behind whatsnew, takes 1-3% CPU when in background (more or less the same that whatsweb consumed when unsuspended)
Question:
-What version of Ubuntu Touch are you using precisely? Stable or daily?
-When you use Whatsnew, when you go in the window carousel, do you see one ore two window corresponding to whatsnew, and what icon does it have under it?
-What is precisely the name of the process you see in top taking 100% CPU? Is it "Whatsnew"? "whatslectron"? Something else?
-Could you give me the result of "md5sum /lib/aarch64-linux-gnu/liblomiri-private.so" in your terminal?
Well it could help if when the battery is draining fast, you can go to the terminal and type "top", to see what program is using a lot of CPU.
I have 2 questions:
-Is there any ongoing plan to developing support for RCS? I think this could be the next blocking point for Ubuntu Touch, so I may contribute to a project to support RCS given that I can find time for that.
-What role and importance do you think offering options for all the most popular messaging protocols, have for UT's potential for adoption as a daily driver? Both the standard ones like SMS, MMS, RCS, email, but also the private ones like Whatsapp, Telegram, Signal, and even Facebook messenger?
Thank you so much for everything! 
You can try to update to 24.04 from the settings app in the update panel from your 20.04 install. Does it propose you the update there?
You should have a much better experience with 24.04 in the long run, and more compatible apps from the openstore!
VoLTE works for me, though sometimes the VoLTE connexion is lost after loosing network and does not necesarilly reestablish automatically.