feat: Add support for librewolf also

[niksingh710]

LibreWolf is a Firefox fork that has gained popularity following recent changes to Firefox's Terms of Service.

This update introduces LibreWolf as an optional entry for TextFox. If a user has programs.librewolf.enable = true; enabled alongside TextFox, the theme will now be applied to LibreWolf as well. Also textfox exposes option to enable librewolf.

Note

I have not updated the readme.md would like to have the pr first reviewed and discuss how this can be added in readme?

[adriankarlen]

Hi, as noted in some other PRs/issues I am not using nix so it is quite hard for me to say anything constructive regarding the syntax. But this seems fine to me. I am trying to think of less of a "on your nose" kind of way to add support to other Firefox-forks, but I can't think of a solution to this that seems 100% satisfactory.

[niksingh710]

I agree with your point. While the current implementation works, a more structured approach is needed to facilitate the seamless addition of other forks.

I will update the PR once I develop a cleaner implementation and will tag you when I have the time. In the meantime, any suggestions for a more elegant solution would be greatly appreciated.

[snaeil]

Thanks for the approach @niksingh710

To add my two cents: Maybe we can have options like we are used to in home-manager, e.g. "enableFirefoxIntegration" (default=true) and "enableLibrewolfIntegration" (default = false)?

How would your PR behave if I wanted to use both Firefox and Librewolf with textfox?

[adriankarlen]

I think the way I'd prefer it was that it defaults to assume you are using firefox, but should be editable by a user to point to any firefox-fork of their choice. I'm thinking of these lines for instance:

 configDir =
    if pkgs.stdenv.hostPlatform.isDarwin
    then "Library/Application\ Support/Firefox/Profiles/"
    else ".mozilla/firefox/";

  configDirLibreWolf =
    if pkgs.stdenv.hostPlatform.isDarwin
    then "Library/Application\ Support/LibreWolf/Profiles/"
    else ".librewolf/";

If we add an option that is an array of strings (the application names the user wants installed), we could iterate over the array and install the theme for each user defined program. The default would obviously be ["Firefox"], but in this case the user could set it to ["Firefox", "LibreWolf"] if they want to use the theme for both Firefox and LibreWolf.

[niksingh710]

@snaeil rn the pr exposes an option to enable librewolf.

  textfox = with colors;{
    enable = config.ndots.browser.firefox.textfox;
    profile = "default";
	librewolf = true;
  };

this will enable textfox for librewolf and keep it for firefox also.

after the pr i didn't got much time to clean the implementation; but yes you are right

e.g. "enableFirefoxIntegration" (default=true) and "enableLibrewolfIntegration" (default = false)?

we should do it in this way; but my hunch is on how to stream line the configDir's for other firefox forks as mentioned by @adriankarlen.

like if we want to add the support of waterfox is adding another variable configDirWaterFox should be the way or there should be a

forks = { librewolf = { path = "<path>"; profile = "<profilename>"; }; waterfox = {...}; }

option attr type containing path and profileName as this will be a great option; then we can iterate in the attr fork and install textfox for all of the above definations.

I am leaning towards this forks attr approach rn becaus this will allow user to define multiple profile for the same fork.

forks = rec { 
  librewolf = { path = "<path>"; profile = "<profilename>"; };
  librewolf2 = { path = librewolf.path; profile = "<profile2name>"; };
  customfork = { path = "<user/path/for/their/custom/fork">; profile "<profilename>"; };
  waterfox = {...}; 
}

now we can iterate over this attr and add textfox for all the defined forks.
This will give user the power to define any type of firefox fork they are using even if it is their custom build; coz textfox only need path and profile location to get itself installed.

@snaeil what are your thoughts on creating a forks type option as mentioned above? any improvement thoughts on this as if we take the forks attr option path then enableFirefoxIntegration and enableLibrewolfIntegration is not required

[snaeil]

The ideas that came up, sound good to me.
I would add that it would be nice to not talk about forks, but to treat firefox and all forks equally as "distributions" (or similar).
This would not mean giving up Firefox as a single default distribution.

[nyukuru]

This should be possible using the existing wrapTextFox package exposed in the flake.