So whilst Firefox OS had the most "#accessible"#Development#tools (literally using #Firefox for it and having every #App as #WebView|s / #HTML5+#JS5+#CSS3 files in a container), they didn't even sold us said devices, making it a worse flop than #UbuntuTouch which at least still gets some devices made that support it...
And #nerds like myself are far from the "#consoomer#Normies" for whom stuff that isn't on shelves at Staturn/MediaMarkt, BestBuy, Walmart, ... doesn't exist. I'm used to importing #tech that I want!
Nowadays we have shitty #WebApps that eat up 100+MB just for a #WebView and which are instantly useless once they don't have a high-speed, low latency internet connection!
People like #GraceHopper and #MargaretHamilton propably wouldn't even be mad, but just disappointed, knowing how a modern #IDE eats more computing power than the entire human race had at their career peaks...
@ahrienby that's because #iOS and #Android are quite different and unless you want to generate 100+ MB #Cordova / #nwjs containers, you're better off writing native code...
Pretty shure both just spawn a modified #WebView context...
@dgar Many web developers still need to deal with Internet Explorer because its rotting undead corpse still lives on in the Windows WebView component used by countless applications to render html. The Chromium-based WebView2 is still far from fully deployed. #webview
Following up on Android's incredibly broken WebView safe area inset handling, it turns out Android 16 is making edge-to-edge mandatory and the Android WebView team says edge-to-edge support is not currently on their roadmap
So basically, expect every app that uses a WebView to possibly be broken when built against Android 15+
(There's an opt-out flag on Android 15, but that's getting removed in Android 16)
It appears Android WebViews finally implement `safe-area-inset-*` environment variables properly¹²³
---
1. Only on Android 15+ when built with an SDK version 35+
2. Because Android 15 & SDK 35 now enforce edge-to-edge display mode on everything, so have fun with the bottom navigation bar for people who don't use gesture navigation
3. `viewport-fit=cover` vs `viewport-fit=contain` makes no difference on Android
Does anybody know how non-Web URI's are handled in a WebView on Android?
I am using #Tiddloid on a local #TiddlyWiki in #Android which seems to be implemented in a #Webview. If I click https:// links, it opens the web browser. If I click callto: and payto: links, a permissions dialog for opening an external app is shown, but allowing it doesn't do anything.
Somebody that uses #Flipboard can answer me if they always used android/ios #webview to display their content?
I am asking because I decided to use it again after who knows how many years, and it doesn't have its dedicated reader such as #Feedly or #Feeder and I definitely remember it did.
As part of my continuing exploration of embedded browsers, a hands-on look at three nice examples: Chromium Embedded Framework, Qt WebEngine and Sailfish WebView.
What features do they support? What do their APIs look like? What are they like to use in practice?
Mi servirebbe una specie di wrapper per alcune app e servizi #web che già ci sono (maggior parte che hosto io), ma ai quali voglio accesso più organizzato (e magari più ottimizzato per l’uso a tastiera) delle tremila schede fissate su Firefox desktop, che ormai sono talmente tante da coprire tutta la barra… ️
Purtroppo, ho scoperto di essere così tanto al mio limite di star rivalutando pure Android!!! Lì, nonostante le rogne, è tanto facile fare una app nativa che mostra una banale #webview e funziona e basta… Ma su Linux #desktop….AIUTO!!!!! È da letteralmente 3 o 4 giorni che sto girando mia testa attorno a ‘sta storia, ma nulla! ️
Il problema è che voglio un eseguibile 100% statico e autocontenuto, di cui ho la certezza possa fungere su qualunque sistema abbia il kernel #Linux e un server X11/Wayland, senza pensare ad altro; come un EXE su Windows, o qualunque cavolo di APK su Android… voglio che la app funzioni ovunque e per sempre senza ricompilare, e senza dipendere dalla distro. ️
Ho provato quasi tutte le opzioni webview consigliate su https://github.com/sudhakar3697/awesome-electron-alternatives, ed è così tragico… una buona manciata sono esplicitamente abbandonate, altre non sono mantenute e quindi comunque non installano/compilano, ma comunque tutte si basano solo su: CEF (Chromium Embedded), QtWebView (che è CEF), Electron (che è CEF), e WebKit2GTK. ️
Questa roba dell’eseguibile autocontenuto (con libc statica) l’avevo fatta per una app PyGame (FrameNX), ma pare sia letteralmente impossibile far funzionare qualsiasi di questi motori web in questo modo qua. Il problema è che hanno così tante dipendenze, così fragili, che è un attimo che fai questa pacchettizzazione forzata statica strana, e subito non girano più. ️
Ho provato sia cefpython3, (che comunque è abbandonato alla versione 66 di Chromium, preistoria), che pywebview (che si appoggia a Qt o GTK), ma PyInstaller li spacca; manco il tempo del passaggio con staticx. Ho provato poi a compilare un programma C++ per QtWebView, ma staticx non gestisce un sacco di file di runtime di Qt che non sono librerie native. E usando direttamente la roba CEF, senza Qt di mezzo, fa comunque errori irrisolvibili. È la fin. ️
Credevo quasi di aver fatto grazie a WebKit2GTK (ad esempio tramite “webview“), con una procedura hackerina (copiando libwebkit2gtk-4.0.so.37 nella cartella di lavoro da /lib/x86_64-linux-gnu/, e con un hex editor sostituendo poi le occorrenze di questo percorso con ./ al suo interno, poi copiando dalla stessa cartella i file WebKitNetworkProcess e WebKitWebProcess, e applicando staticx sia a questi due che al mio programma C dopo aver settato LD_LIBRARY_PATH=.)… però il programma, su un altro sistema, apre solo una finestra bianca e dice “Could not create default EGL display: EGL_BAD_PARAMETER. Aborting…” ️
Un disastro!!! Forse si può buildare #WebKit2GTK da sorgente per disattivare proprio tutta la roba di OpenGL che da errore, visto che non freca, ma mancano un sacco di dipendenze, non compila un cazzo… Mi sa che faccio la cringiata, e pacchettizzo un intero file system + binario chroot/proot in un solo eseguibile, alla faccia delle #librerie…