Closed RoyalOughtness closed 1 month ago
Yeah I've always wanted to do this but the PWA apps haven't been very good when we looked last. Like if you go into Yafti under office suites we could have "Google Workspaces" and "Microsoft Office", they'd look awesome on the dock too.
How do you envision the setup? My biggest issue so far is things like profile sharing has been awkward. We also tried the epiphany/PWA setup but that was a non-starter due to it not using a major browser.
they'd look awesome on the dock too.
my thoughts exactly :smile:
How do you envision the setup?
Behind the yafti toggles im envisioning a script in the justfile that:
--createprofile
(docs), (other docs)~/.local/share/applications
My biggest issue so far is things like profile sharing has been awkward
What kind of awkwardness did you run into? Any insight you can provide that will steer me in the right direction while making a proof of concept would be helpful
Any insight you can provide that will steer me in the right direction while making a proof of concept would be helpful
Yeah, usually they end up mixed up with Firefox, so when I click on the dock it ends up just being another firefox window and not in it's own window. So alt-tabbing just ends up showing another browser windows instead of the application.
Maybe let's start with an example one, say MS Word and post it somewhere and we can all start dogfooding it? It'd be nice to figure this out.
so when I click on the dock it ends up just being another firefox window and not in it's own window. So alt-tabbing just ends up showing another browser windows instead of the application.
got it, yeah that's an ugly experience
Maybe let's start with an example one, say MS Word and post it somewhere and we can all start dogfooding it? It'd be nice to figure this out.
yeah I'll start hacking at it and see what I can come up with
Chiming in. I had a good experience with https://addons.mozilla.org/en-CA/firefox/addon/pwas-for-firefox/ for the past years. What started as a way to workaround Electron's poor Wayland integration ended up being a very important tool in my workflow.
Specifically, whenever I create (install) a new WebApp, I toggle full-screen-api.ignore-widgets to true and then install https://addons.mozilla.org/en-CA/firefox/addon/i-auto-fullscreen/ to have seamless integration on my desktop.
On the extension side, Wayland must be enabled in the setting:
The end results is:
One caveats is that you must enable (per webapps)
and
To prevent hyperlink from hijacking the WebApp page, but this in turn will cause the App to quickly exit on first launch when booting the PC - quite easy to mitigate with some startup scripts.
At last, you can also mix in some custom CSS to disable mouse hover from showing the title bar when used with full-screen-api.ignore-widgets and auto fullscreen. I personally don't, but some may find that annoying.
See also:
https://github.com/wroyca/blue/tree/main/rootfs/etc/skel/.local/share https://github.com/wroyca/blue/blob/main/rootfs/etc/yum.repos.d/firefoxpwa.repo and https://github.com/wroyca/blue/blob/137c1bccc0fc50569487bf078129f009824ce4a4/Dockerfile#L183
@wroyca I looked at this earlier and I don't think it supports flatpaked browsers, so it won't be suitable for images like bluefin that are shipping without an rpm browser.
@wroyca I looked at this earlier and I don't think it supports flatpaked browsers, so it won't be suitable for images like bluefin that are shipping without an rpm browser.
Ah yes indeed - https://github.com/flatpak/xdg-desktop-portal/issues/655 is needed for that
@wroyca I looked at this earlier and I don't think it supports flatpaked browsers, so it won't be suitable for images like bluefin that are shipping without an rpm browser.
Seeing https://github.com/ublue-os/bluefin/issues/1321, perhaps switching back to RPM may not be an absolute no-go if the desire for webapp is strong enough
@wroyca I don't see how that ticket relates at all to using firefox as an rpm instead of a flatpak. I highly doubt the intent is to do that.
I think there are other ways to accomplish this with flatpak browsers, and I'm working on that now.
@wroyca I don't see how that ticket relates at all to using firefox as an rpm instead of a flatpak. I highly doubt the intent is to do that.
I think there are other ways to accomplish this with flatpak browsers, and I'm working on that now.
Relaxing containerization would mean that we don't need to enforce the Flatpak variant for Firefox, meaning we don't need to run Firefox in a Flatpak container (though, whether Flatpak is truly a container is debatable) - Anyway, that's what I was hinting at with the ticket.
I think there are other ways to accomplish this with flatpak browsers, and I'm working on that now.
Neat! I have no experience with web apps other than through Native Messaging, so I am interested to try other solutions. :partying_face:
we don't need to enforce the Flatpak variant for Firefox
flatpak is used because of its utility as a packaging format for gui apps independent of the base image. its use of containerization for sandboxing is incidental and not related I assume to what the ticket you mentioned is referring to.
also the firefox flatpak is not enforced. it can be removed
adding the rpm would be much more forceful because it would be building it into the base image. anyhow this is all offtopic for this ticket :smile:
@castrojo
I spent a good amount of time digging into the options here. I've concluded that, as you probably already knew, there aren't any particularly good ones
Nevertheless I'll lay out what I believe to be the options below.
pros: lightweight, easy to integrate with yafti cons: not actually a solution, because application matching (the separation between browser and PWA) only works partially on Plasma and not at all on gnome, so this solution would only work on aurora (and partially at that) and not bluefin.
pros: a reasonably nice solution for MS office cons: electron (>100MB), only works for ms office and not other desktop suites, painful to maintain because of non-standard sources (no flatpak)
It seems I've ended up just rediscovering what was already figured out by previous efforts on this.
Yeah, same conclusion we came to last time. "Let's hope Firefox prioritizes PWAs on the desktop".
@wroyca we did evalyate the firefox PWA option in the past, the problem with that is we'd be stuck with a browser on the image, which we don't want. I wonder if the firefox PWA thing could be done as a flatpak extension to Firefox?
Yeah, usually they end up mixed up with Firefox, so when I click on the dock it ends up just being another firefox window and not in it's own window. So alt-tabbing just ends up showing another browser windows instead of the application.
If I am understanding the problem correctly, you can fix this by running firefox -P example-xyz --name example-xyz
and then creating a .desktop file with StartupWMClass=example-xyz
.
(being the --name argument in firefox and StartupWMClass the same, or just naming the .desktop file as example-xyz.desktop)
@alexjp I was trying stuff along those lines, and it was partially working on plasma and not working at all on gnome.
If you get something working, please upload it to a github repo and link it here. That would be awesome
@alexjp I was trying stuff along those lines, and it was partially working on plasma and not working at all on gnome.
Why was it only partially working on Plasma? Sorry, haven't tested it on Gnome.
@alexjp
On plasma I could launch the desktop file, and initially it would show the correct icon and label. I thought it was working. Only to launch Firefox separately and plasma merged the new firefox window with the existing PWA window and relabelled them both as firefox :pensive:
On gnome it didn't work at all.
Let me know if you get something working
On plasma I could launch the desktop file, and initially it would show the correct icon and label. I thought it was working. Only to launch Firefox separately and plasma merged the new firefox window with the existing PWA window and relabelled them both as firefox 😔
Strange... that doesn't happen to me. I have the "default startup profile" the default one. When launching the custom ones with -P
and --name
arguments, and then if I do a /usr/bin/firefox
it opens a new window on the default profile, and does not mix it up.
As a sidenote, I am actually using librewolf, but should be the same. I will test it on a blank VM with default firefox to check it out.
Are you using flatpak firefox?
@alexjp yes, I'm using flatpak firefox.
If you're using /usr/bin/firefox then that's why it's working for you. It's known to work in that case. The issue here is for the flatpak version. bluefin/aurora use flatpak firefox.
https://github.com/ublue-os/bluefin/issues/1345#issuecomment-2130604023
@alexjp yes, I'm using flatpak firefox.
If you're using /usr/bin/firefox then that's why it's working for you. It's known to work in that case. The issue here is for the flatpak version. bluefin/aurora use flatpak firefox.
ohh sorry! didn't read everything. :( sorry ! I will test it in the flatpak version !
This isn't coming any time soon, closing
@castrojo Please accept my apologies, I tested this and then became somewhat convinced that I had answered.
Bad luck that nobody replied and I didn't got any notification until now.
So I had tested this, and re-tested again to see if anything changed, and it all worked properly here.
My command line testing was:
flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.firefox -P test --name testing
and
flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.firefox -P default --name default
The first command correctly made a firefox browser window with profile "test", and WMCLASS "testing". The second command, gave a "default" profile with a WMCLASS of "default".
The plasma task manager properly grouped the windows, according to their profile/name (which is basically the name part).
The only thing that does not work, is first launching a profile, say "default" with --name "default" and then launching again that same profile but with another --name argument. (firefox will keep using the previously launched one). But this does not work with /usr/bin/firefox
(non flatpak) also.
Sorry for the blunder on my part.
No need to apologize, it'd be nice if this was just built into firefox, maybe someday!
No need to apologize, it'd be nice if this was just built into firefox, maybe someday!
Maybe look at zen-browser! It has a nice and cool way to switch profiles, and a nice profile/workspace/container workflow! (and it is built in)
The down side is that it is in heavy development (well... not really a downside at all)
Prior context here.
Functionality
I'm proposing the addition of ujust commands for DE-integrated installation of common office suites (or subsets of those suites) that are only available as PWAs. This would be accomplished by maintaining a set of .desktop files configured to open office suite PWAs in a shared firefox profile (for identity consistency). These profiles would then be installed to
~/.local/share/applications
on execution of theujust command
. e.g.:ujust install-microsoft-office
ujust install-google-docs
Value add
While it's entirely possible already to simply use these as webapps by navigating to the right page in your browser, providing the same apps but integrated into the GNOME/Plasma UX provides a more elegant and familiar experience to users of those office suites.