Open GeopJr opened 1 year ago
I don't know if this counts but I saw someone running tuba in WSLg on windows. Will post a link if I manage to find it.
IIRC that also got stuck on libsecret :shrug: Honestly this is why I want to port Tuba to other platforms so all the stack can be tested. I thought libsecret was cross-platform but right now I can't find much evidence to support that. I believe it can use a local backend now however which would be good enough for other platforms (even though I'd rather use keychain on mac and vault or however it's called on windows).
Figuring this out would also benefit Dino and maybe Fractal (though I'm sure Rust has its own alternatives)
I'll see about dual booting windows (though mac is a different story on its own. Maybe wait for darling to mature?)
tada
macOS at commit 26be6de9292fa9a856c700c1d515ae66fec60a0f
** (dev.geopjr.Tuba:66060): CRITICAL **: 13:11:29.476: SecretAccountStore.vala:46: Error while searching for items in the secret service: Ein Nachrichtenbus kann nicht ohne eine Rechner-Kennung erzeugt werden: /nix/store/xd22d3mi2f2382ixx71lh9hijh6y5i9x-glib-2.78.4/var/lib/dbus/machine-id oder /etc/machine-id kann nicht geladen werden: Datei »/nix/store/xd22d3mi2f2382ixx71lh9hijh6y5i9x-glib-2.78.4/var/lib/dbus/machine-id« konnte nicht geöffnet werden: No such file or directory
** (dev.geopjr.Tuba:66060): WARNING **: 13:11:29.476: SecretAccountStore.vala:47: If you didn’t manually cancel it, try creating a password keyring named "login" using Passwords and Keys (seahorse) or KWalletManager
read more: https://github.com/GeopJr/Tuba/wiki/keyring-issue
And after manually creating /etc/machine-id
:
** (dev.geopjr.Tuba:66285): CRITICAL **: 13:14:59.378: SecretAccountStore.vala:46: Error while searching for items in the secret service: D-Bus kann nicht automatisch ohne X11 $DISPLAY gestartet werden
And after manually setting $DISPLAY
:
** (dev.geopjr.Tuba:66318): CRITICAL **: 13:16:57.978: SecretAccountStore.vala:46: Error while searching for items in the secret service: Kindprozess »dbus-launch« konnte nicht ausgeführt werden (No such file or directory)
Thanks for taking a look! Could you try #785? It will use the same workarounds used for Windows (aka the file backend for libsecret)
That works, amazing! :)
Some icons seem to be missing though:
The icons that are missing are provided by the environment but by the looks of the home icon, homebrew is shipping an older version(?)
I installed it through Nix. In that regard, I guess it's good news the Tuba package in nixpkgs works without much modification, I only had to change the git commit rev and add libicu to the dependencies:
pkgs.tuba.overrideAttrs (prevAttrs: {
src = prevAttrs.src.override {
rev = "c5625d49804d13daf0dad3243817338e15419928";
hash = "sha256-UVjrbdXzCuQa2u+UoTuPFCjAHbFxEyf528UDNjI9y1Q=";
};
buildInputs = prevAttrs.buildInputs ++ [
pkgs.icu.dev
];
})
GTK4 is at version 4.12.4
and libadwaita at 1.4.3
.
The package with the adwaita symbolics is called adwaita-icon-theme
, it looks up to date to me, not sure why it uses the old home icon in your screenshot or why starred-symbolic
(and others) are missing :shrug:
This looks somewhat relevant https://github.com/NixOS/nixpkgs/issues/150516
So installing adwaita-icon-theme in my user profile (through Nix home manager) indeed makes them show up:
Now I wonder how that could be handled in the package definition instead so it does not depend on the user specific environment 🤔 (but that's a problem for nixpkgs, not for Tuba^^)
Now I wonder how that could be handled in the package definition instead so it does not depend on the user specific environment 🤔
chances are this is going to cause a conflict between people who prefer adwaita, yaru (ubuntu), breeze (kde) etc :weary: Personally, I'd prefer if adwaita-icon-theme was used for tuba as it'd match the bundled icons
(FWIW the rule for what's getting bundled or not is: either the icon doesn't match the exact use case (for example the boost icon is media-playlist-repeat-symbolic
(included in the spec and all the icon packs) but since it's not used as a media player's repeat button, it's bundled (because an icon pack might draw it as a spinning disc instead)) or is not included in the spec/all icon packs (e.g. loupe, filled bookmark, small lock/globe/envelope...))
I think it's perfectly fine that this depends on the user environment on Linux so it integrates nicely into the rest of the DE, but on macOS users will likely prefer that it matches the rest of the app as it already looks completely different from the rest of the system^^ I'll experiment a bit if this can be solved as part of the Nix package definition.
I've made a Homebrew formula for this and it seems to have worked well, so that should be a super easy way to get Tuba running on a Mac!
Only things that seem lacking is the lack of a macOS app bundle and I noticed maybe profile pictures are a little too low resolution? Not sure if that's a Mac issue or not.
macOS style app icon design attempt? :eyes:
I'm not a designer I just like messing with Figma, lemme know thoughts on this though!
I've made a Homebrew formula for this and it seems to have worked well, so that should be a super easy way to get Tuba running on a Mac!
Only things that seem lacking is the lack of a macOS app bundle
Thank you so much!
I do not have access to macOS so I can't really help much. Maybe I'll see about setting up a KVM again...
You can probably also add ninja test -C build
under test.
Next step from Tuba's side would be to add darwin builds to the CI and upload a bundle? zip? to artifacts so it gets tested too. Is homebrew-bundle
the appropriate tool for the job? (I don't really mind if it's not super user friendly with installers and whatnot)
I noticed maybe profile pictures are a little too low resolution
Unfortunately, many parts of the GTK stack are not tested thoroughly on mac and windows (e.g. https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/39). Hopefully these cross platform builds of Tuba will bring more eyes on it.
You can try running Tuba with a different renderer, though I doubt it will make a difference:
GSK_RENDERER=ngl
or GSK_RENDERER=vulkan
I'm not a designer I just like messing with Figma, lemme know thoughts on this though!
:shrug: My guess is that GNOME's design language will conflict with Mac's but feel free to give it a try!
Otherwise, the same as Tuba's pfp would probably do somewhat, similar to chrome's
You can probably also add
ninja test -C build
under test.
I did at first, but then I remembered that by the time brew test tuba
would ever be run, the build folder would've been deleted already.
Is
homebrew-bundle
the appropriate tool for the job?
Oh wow I actually never knew about that until now! I'll have to look into it more.
🤷 My guess is that GNOME's design language will conflict with Mac's but feel free to give it a try!
Honestly, in my opinion, all a Mac app icon really needs to look normal is that rounded square. The image that macOS loads for app icons is actually bigger than what most app icons utilize, so just setting the app icon to fully take up the available space tends to look weird. I tried constraining the tuba icon to the rounded square, but I thought it was hard to differentiate at small sizes, so I let it sort of sit on top of the square, which is also pretty common actually and is detailed in Apple's HIG.
Otherwise, the same as Tuba's pfp would probably do somewhat, similar to chrome's
If I'm understanding what you mean correctly, even Chrome changes its icon a little for Mac:
Just using the same tuba icon on Mac could be okay, but it has to at least be scaled down a little bit or it'll look weirdly big compared to other apps.
All of what I said about the app icon on Mac though is assuming that making it look good on Mac is a priority, it would be understandable if it's not.
Next step from Tuba's side would be to add darwin builds to the CI
Would it be better to do that in build.yml
or in a new dedicated macOS workflow file? (I'm starting work on this now)
All of what I said about the app icon on Mac though is assuming that making it look good on Mac is a priority, it would be understandable if it's not.
I don't mind having a custom icon for mac but I'll let it be for now. I wouldn't mind resizing the current one in the CI with rsvg or something (we already do that for windows)
Would it be better to do that in build.yml or in a new dedicated macOS workflow file? (I'm starting work on this now)
A separate one sounds good! Thanks for working on it!
I wouldn't mind resizing the current one in the CI with rsvg or something (we already do that for windows)
Oh that sounds great, here's a reference image for later when we do that then:
(The outer bounding box should be considered the very edge of the image and the icon grid bounding box should be where we want to resize Tuba's icon to be within.)
(svg)
I'll have to compare with references on my Mac when I'm able but from viewing on my phone right now, looks good!
Reasoning
I don't expect Tuba to be used on other platforms nor will any bugs for them be treated as anything but low priority - but Tuba could be used as a way to test the GNOME stack on them since it heavily depends on it (libsoup, libsecret etc) as well as to improve the tooling around Vala for those platforms. There are no plans for code signing on those platforms even after successfully fixing everything.
Results
Windows
Report: Windows is done.
Issues:
OSX
Report:
Same as Windows. Packaging still need to be done.
Issues: