uWolf (LibreWolf)

ChromiumOS-Guy

@domubpkm
I'd estimate the total time spent to be around 110-120 hours.

Here's a breakdown of how it was spent:

The first 5 hours were completed a couple of months ago building version 0.1.0, which involved creating a setup script for running LibreWolf with no modifications, @Fuseteam helped a lot with this considering his experience with uFirefox.
The remaining work was done over the course of 2.5 weeks, with daily work sessions averaging around 7 hours, and some days going up to 12 hours.
To avoid burnout, I took a few days off, roughly every 3 days, which helped to maintain productivity.
It's worth noting that a significant amount of time was spent exploring and testing different ideas, many of which were eventually scrapped, which made the work more time-consuming, especially in the beginning.

ChromiumOS-Guy

@domubpkm also kinda not related but genus level move, I moved the settings menu (3dot button) to the bottom left where the tabbar starts, this frees just enough space to make the XUI work with almost no other modifications.

domubpkm

@ChromiumOS-Guy Thank you to you and @Fuseteam . It is good to realize in a concrete way all the investment time that this requires voluntarily to obtain an app which will make great service to all. It takes a lot of skills of course, but also above all a lot of passion for that.

And this comment is of course valid for all developers who spend number hours to develop apps for UT.

haagch

@ChromiumOS-Guy Thanks, extensions are accessible now. Form filling from the browser's saved passwords doesn't work, I guess it's because of copy&paste not working? But the bitwarden extension can fill form fields so it's good enough for me.

For my point 9. I found the privacy settings and that by default it deletes a lot of stuff on exit. Might be good to call these defaults out in the readme.

Not sure if this is for location access https://github.com/ChromiumOS-Guy/uWolf/commit/c27cf41b4b3bd9d1e84519ca0c7abe17637ac19c#diff-9f6e9f7df1d5f0a60e077fa35efd7d122e78595f3852769e59834397b9860c07R3-R5 but still only the browser itself asks for its internal location access permission, it still doesn't ask the OS. I think you should be able to test this far even without the smartphone actually being able to get a fix, right?

ChromiumOS-Guy

@haagch im currently working on the nix-manager project + in between somethings, so it will take me a while to test.

LibreWolf is secure by default like that and i will not change it, maybe a call out that this is an extremely hardened version of firefox.
location is not something i can fix, this is something for librewolf devs/ ut devs to work on.
UI bugs relating to clipboard are due to xwayland and will be "fixed" by running under wayland when subsurface support is introduced.

domubpkm

@ChromiumOS-Guy Hello. Is the next step a responsive interface?

ChromiumOS-Guy

@domubpkm the next step is to wait for Noble, i have somethings i can fix right now
bit i rather just do one big bug sweep session when switching to wayland.

as soon as the transition to noble happens i can automatically make the phone install the subsurface patch (until it goes to upstream) and then i can run wayland which means a host of bugs will be gone but i already know some stuff breaks (and my workarounds for the xwayland bugs) so i will probably need to do a refactor of the entire app so i might as well do everything in one big concentrated push.

edit:
other then that?, really only cleaning up the UI mostly.
i can't really do anything else, though i am toying with the idea of making another startup script to mimic webapp-container so webapps can use this (they'll need to be unconfined)
also finding a way to make uWolf the default browser, after the switch to wayland it should be a lot more usable so it stands to reason people will want to be able to make it open links.

domubpkm

@ChromiumOS-Guy It is true that you are right to concentrate your energy intelligently: Noble is the near future.

domubpkm

@ChromiumOS-Guy Can't test vO.10.29 : doesn't launch on Volla 22 last RC.

ChromiumOS-Guy

@domubpkm provide me the crash log, preferably on github.
i don't own you're device i can't tell you why it doesn't launch.

domubpkm

@ChromiumOS-Guy See https://dpaste.com/F7MPSR2CF Volla 22 last RC

ChromiumOS-Guy

@domubpkm what does this say:

cat /sys/class/drm/card0-DSI-1/modes

ChromiumOS-Guy

@domubpkm please try version 0.10.30

domubpkm

@ChromiumOS-Guy doesn't launch yet

https://dpaste.com/9MQW4RNWL

ChromiumOS-Guy

@domubpkm okay can you run this in shell:

cat /sys/class/drm/*/modes | awk -F 'x' '{print $2}' | sort -nu | tail -n 1

also just this in general so i can see if theres different syntax here

cat /sys/class/drm/*/modes

domubpkm

@ChromiumOS-Guy

ChromiumOS-Guy

@domubpkm can you search around a bit and see if you can find these:

phablet@ubuntu-phablet:~$ ls /sys/class/drm
card0  card0-DSI-1  renderD128  sde-crtc-0  version

I need access to card0 so i can see resolution size of the screen.
its probably somewhere in a different directory, if you can find it I would appreciate it if not I'll figure out another solution.

ls /sys/*/*/*/modes

check this out, if its simply renamed then this should return something.

domubpkm

@ChromiumOS-Guy i did only the second command line at this point

ChromiumOS-Guy

@domubpkm yeah idk how or why you use a virtual framebuffer that means no hardware acceleration in most cases,
try running the command

cat /sys/class/graphics/*/modes
fbset -s

if this gives you a list of resolutions tell me, I'll implement reading this as a fallback.

also not related but because you use a virtual framebuffer you could potentially hack together a way to have nightlight.

domubpkm

@ChromiumOS-Guy