Re: [PATCH] gnu: icecat: Enable gtk3 support.

[Mark H Weaver]

David Craven <address@hidden> writes:

> * gnu/packages/gnuzilla.scm (icecat)[inputs]: Add gtk+.
>   [arguments]: Use --enable-default-toolkit=cairo-gtk3. Force light
>   gtk theme in desktop file to avoid unreadable input fields.
> ---
>  gnu/packages/gnuzilla.scm | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
> index 4927a51..059ae23 100644
> --- a/gnu/packages/gnuzilla.scm
> +++ b/gnu/packages/gnuzilla.scm
> @@ -410,7 +410,8 @@ standards.")
>         ("glib" ,glib)
>         ("gstreamer" ,gstreamer)
>         ("gst-plugins-base" ,gst-plugins-base)
> -       ("gtk+" ,gtk+-2)
> +       ("gtk+" ,gtk+)
> +       ("gtk+-2" ,gtk+-2)
>         ("pango" ,pango)
>         ("freetype" ,freetype)
>         ("hunspell" ,hunspell)

Is gtk+-2 still needed as an input?  Do the two versions of gtk+
conflict with each other at all?

> @@ -468,7 +469,7 @@ standards.")
>         ;; practice somehow.  See <http://hydra.gnu.org/build/378133>.
>         #:validate-runpath? #f
>  
> -       #:configure-flags '("--enable-default-toolkit=cairo-gtk2"
> +       #:configure-flags '("--enable-default-toolkit=cairo-gtk3"
>                             "--enable-pango"
>                             "--enable-gio"
>                             "--enable-svg"
> @@ -628,7 +629,11 @@ standards.")
>                   (("@MOZ_DISPLAY_NAME@")
>                    "GNU IceCat")
>                   (("address@hidden@")
> -                  (string-append "Exec=" out "/bin/icecat"))
> +                  ;; Force gnome light theme to avoid unreadable input 
> fields.
> +                  ;; https://wiki.archlinux.org/index.php/Firefox
> +                  ;; #Unreadable_input_fields_with_dark_GTK.2B_themes
> +                  (string-append "Exec=env GTK_THEME=Adwaita:light " out
> +                                 "/bin/icecat"))

If we were to do something like this, the call to 'env' should be via an
absolute pathname, rather than relying on whatever happens to be in
PATH.

However, I'm ambivalent about this whole idea of hardcoding a particular
theme to prevent potential problems that may not arise.  This workaround
prevents the user from conveniently using *any* other theme, even other
light themes.  It also prevents the user from using a dark theme and
working around the issue in a different way, e.g. by customizing
userContent.css as described in the link you provided:

  
https://wiki.archlinux.org/index.php/Firefox#Unreadable_input_fields_with_dark_GTK.2B_themes

So, my inclination would be to drop this last hunk of the patch.

What do you think?

      Mark