Electron: Consider replacing GTK2 w GTK3 in Linux builds

Sounds good to me after we upgraded to Chrome 47.

Chrome 47 was released three days ago. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

Dug into it a bit but still not sure where to put the use_gtk3 flag.. @zcbenz willing to do it?

@zcbenz or can you give us pointers on where to put it?

I am no expert in the building behaviors behind the build system for Chromium, but reading from the Chromium related bug there, it should be fine we add it to the variables to common.gypi. The relevant line is here.

Actually I am testing on a Linux box for that, too. My current development box runs Elementary OS, and whenever a Gtk2 application is executed it would display a warning Gtk-Message: Failed to load module "pantheon-filechooser-module" (Ref). If things go smooth (hopefully) let's see if I can get a PR too. Would definitely love your inputs there though.

Any update on this? As a atom user I would like to see it using GTK3 instead of GTK2.

@netsgnut does it work well?

what do the “%” mean?

is the only change this one?

diff --git a/common.gypi b/common.gypi
index 7c41c36..d00d7f7 100644
--- a/common.gypi
+++ b/common.gypi
@@ -9,6 +9,7 @@
     'chromeos': 0,
     # Reflects node's config.gypi.
     'component%': 'static_library',
+    'use_gtk3': 1,
     'python': 'python',
     'openssl_fips': '',
     'openssl_no_asm': 1,

Any news ? The GTK2 open file dialog is quite a pain to use !

@flying-sheep Ah, sorry for the long radio silence. Been committed to other projects off GitHub, my bad.

Back to our case, that was what I originally think should work, but mysteriously fails to build proper Gtk3 applications on my box. In my case, my original intention is to make an Electron build that would not emit error under my development box (which is running Elementary OS Freya). However it seems building that way won't really make the warning go away.

in #4642, @zcbenz said:

The use_gtk3 flag is only meaningful under Chromium's side, to enable GTK3 we need to enable it in libchromiumcontent first, and then change the link settings in Electron.

so what exactly needs to be done?

1. enable using GTK3 in libchromiumcontent: will adding a flag in chromiumcontent.gypi be sufficient? is this of importance or does electron not use that target build?
2. change the link settings in Electron: where to do this?

I am no expert on this field, and not sure if I have misapprehended @zcbenz's comment; just my 2 cents.

Regarding the questions:

1. Probably not. libchromiumcontent seems, from the look of it, a bunch of scripts that downloads chromium source from upstream, patches, and repackages for use in Atom. Apart from changing a flag on chromiumcontent.gypi as you have mentioned, at least dependency libraries are packaged properly as well. See the instances of libgtk2ui.
2. There are fragments in Electron that references to libgtk2-specific UIs. Those point to a dependency within chromium (and/or derivatives). "Links" as in @zcbenz's comment probably refer to those.

The tracking bug on Chromium reflects some sort of status from upstream. One of the commenters note:

IIRC, it would require building a libgtk3ui library to match chrome/browser/ui/libgtk2ui/, and have these two libraries switched at startup time.

And, as of writing, libgtk3ui does not exist yet :( You may have a look at the code on libgtk2ui as well.

I was between personal laptops after I originally posted this and had been using my company issued MBP for a handful of months since. But I finally have my new machine, downtime and decided to take a stab at this. My progress thus far:

I was able to get libchromiumcontent to build with gtk3, it entailed the following:

• add 'use_gtk3': 1 in chromiumcontent.gypi.
• disabled sysroot by manually commenting out the call for install_sysroot() in script/update. Note: Depending on the libchromiumcontent version, you might need to set use_sysroot in chromium/src/build/common.gypi to 'use_sysroot': 0. I'm assuming the right approach in the future would be to switch to debian_jessie for cross-compiling ability in builds?
• ran pkg-config:

pkg-config --cflags gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk --libs gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk && export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig

• ran script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• waited for hours :)

However, I was unfortunately a little too optimistic after the build finished, thinking it be a drag n' drop for an electron build, but of course it wasn't. I think the next step is to get a local brightray built out and whatever other gyp files updated to use my system libs and not sysroot.

And in regards to the libgtk2ui - I'm having trouble locating the reference to where I read this (maybe gentoo forums, chromium issue tracker or an arch linux community thread) - but I believe that Chromium builds the libgtk2ui regardless of gtk3/gtk2 because the devs were doing the bare minimum to get a build with gtk3 to work. I could be wrong and I don't know how this might effect any Electron-based patches that were written specifically for gtk2.

I do a weekly chromium-gtk3 build for my personal browser and libgtk2ui is still present and I'm assuming used.

I'll come back here hopefully in the next few days and link to my POC repo's with prebuilt binaries and some screencaptures.

Done and I'll hopefully have atom-gtk3 up and running soon!

The biggest hurdle was debian_wheezy_sysroot being used throughout libchromiumcontent/electron/brightray. Maintainers of those repos will probably need to have some discussions and make decisions whether to switch to jessie or possibly making sysroot optional.

Over the weekend I'll try and put together a node or bash script to build a distributable electron gtk3 executable. I don't think any pull request I'd make will be accepted, so for now this will probably be the must efficient way for fellow gtk3 users to get and use the build. And over the next couple weeks I might even attempt to get some AUR packages going for my fellow Arch users.

These were the gtk3 warnings during the electron build https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry Is there a way for us to keep sysroot but copy in GTK+ 3.x into the sysroot?

@paulcbetts I think only if Wheezy is upgraded to Jessie (I could be wrong but I'd be willing to bet you'd find yourself in dependency hell if you tried to just sneak gtk3 in there). In addition to gtk3, we also need the following modern libs for gtk3 to build: wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0.

Sounds awesome @nikolowry, thank you for your work. Is the source code available somewhere? I would love to get a PPA ready to make life easier for us Ubuntu users.

I would also like to add that this issue is not only a question of providing modern widgets. GTK2 is not useable on HiDPI systems (at least not with ubuntu 16.04) due to all of the icons in buttons and toolbars being rendered extremely small. Fortunately in Atom's case this seems to affect only the file open dialog, at least as far as I can see, so Atom itself remains fairly useable.

@EiNSTeiN I will link back shortly to an electron-gtk3 repo by weekend's end.

A little backstory first - the main reason why I was determined to get this working was because I use Atom as my daily driver and couldn't stand to see the file dialog anymore! However, that build took longer than expected due to complications with asar/compiled-cache/npm-not-running-post-install-scripts, but I'm good to go now.

I had been mulling over the best way to do this - so maintainers will have a good reference(it'd be tough coordinating pull requests in all the individual repo's) and also so gtk3-would-be-users could get up and running as quickly impossible.

But I won't be doing automated builds, so everyone should be prepared for 4-6 hour build times or to get some servers ready. I might end up doing the occasional release until these changes are reflected in the official repo.

I've narrowed in on making a repo with electron as a submodule and writing a single bash script for building electron with all the gtk3 goodness. Then every distro can have an easy starting point to eventually distributing packages until these changes are actually in offically.

And onto the hidpi note - my exec cmd for atom-gtk3 is GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U. The GDK scale flags also fix chromium-gtk3 ui font sizing. Here's some screens of atom-gtk3:

https://goo.gl/ydHspu

Hi,

I was able to compile Electron 1.1.2 with GTK3 on Arch Linux, passing use_gtk3=1 to libchromiumcontent and changing gtk+-2.0 into gtk+-3.0 in brightray.gyp.

Now the default app of Electron chrashes whenever I press a key.

Details here: https://github.com/tensor5/arch-atom.

The build script repo:
https://github.com/nikolowry/electron-gtk3

Hopefully will have it wrapped up by week's end. It's a WIP and doesn't yet build anything meaningful.

@EiNSTeiN and @tensor5 - https://github.com/nikolowry/electron-gtk3 should be building now. Note that it builds only the release version unless you specifically tell it to build both debug and release. check out the README and open an issue if something isn't working.

@zcbenz is there any historical reason in using Debian Wheezy (I know Chromium likes to be LTS compatible)? Maybe adding a build flag to use Jessie/GTK3? I could work on a proper pull request if you aren't opposed to the idea, otherwise you atleast have a reference build script on what it takes to get GTK3 to build.

Edit: @tensor5 are you using X or Wayland? I know chromium gtk3 builds are crashing on key input events in Wayland.

@nikolowry: yes I was using Wayland, and indeed it works fine with X, thank you. Do you know if this Chromium issue is been discussed somewhere?

Found this: https://bugs.chromium.org/p/chromium/issues/detail?id=615164.

@nikolowry We are just following Chromium's building configurations, there are lots of Linux distributions and we are not able to test all of them, while Chromium is fully tested everywhere, so it is safe to follow Chromium.

I'm good adding a flag to build for GTK+3, and adding a link to your build script also looks good to me. It can be part of the advanced topics of Linux build instruction.

@zcbenz sounds good - they do have a python script one could run that uses Jessie instead of Wheezy for sysroot, but I guess it be best to wait for it to be set as the default in upstream Chromium.

In general, building against the oldest distro you can find is a Good Thing when it comes to distributing software because of glibc++ versioning - the upgrade to Jessie could (though I'd consider it way safer in general) orphan people who had working Electron in the past. We hit this issue a lot with RHEL users

@tensor5 figured out how to launch in Wayland. I commented on that Chromium ticket and updated my gtk3 repo.

Just need to run GDK_BACKEND=x11 electron as Chromium doesn't hook into the XWayland module automatically.

@nikolowry AWESOME!

So if I understand correctly, the problem is that GTK3 thinks electron is a pure Wayland application, while it's not.

@tensor5 exactly! GTK3 assumes all apps using the toolkit are Wayland ready (thus responsible for loading up XWayland if needed).

I was prepping to go knee-deep into the Chromium source-code this weekend to figure it out, and as I was trying to generate some logs I stumbled onto the simple solution via https://fedoraproject.org/wiki/How_to_debug_Wayland_problems.

Chromium and Atom were my last non-Wayland-ready apps - so happy my Skylake laptop won't be crashing via xrandr anymore when hooked up to multi-monitors in mixed dpi mode!!!!

Edit: I know you maintain some AUR packages as well, so you might want to edit the desktop files to include "env GDK_BACKEND=x11", it will allow the apps to run in both X and Wayland and save everyone else plenty of headaches in the future!

@nikolowry I'm already on it!

Eventually this should be fixed in electron source, using a launcher script is not the most elegant way.

BTW the AUR package is not mine. I maintain a repository

@nikolowry Firefox is also a GTK3 application that relies on Xwayland, but it works fine. So I took a look at it: as you can see here it tries the X11 backend first, and then uses the detected display_name for gdk_display_open.

Probably a similar thing can be done in Chromium.

On elementary OS we need GTK3 to use the pantheon-file-chooser, or we'll get these:

Gtk-Message: Failed to load module "pantheon-filechooser-module"

why not just support/port to Qt5-WebEngine? it uses chromium's engine anyway, and on Qt everything looks way more native unlike on gtk...

plus qt5 is not broke all the time like gtk3 that changes their F**king APIs everytime just because they dont care about anything else than gnome development.

here is a great video presentation why gtk is bad and qt is better (2y old but still good and relevant)

Qt 5.6.x is now in LTS and their license changed with 5.7, that is way better for open source users/devs

I personally dont get why people are using gtk outside of gnome stuff, when it's not designed for that.

@ahjolinna Actually GTK+ is meant to be used for application development outside of Gnome stuff too. Either way changing the APIs to QT would be a nightmare for the Electron team since it would require a lot of patching of things from the Chromium upstream. It isn't worth the trouble.

GTK+3 _is_ intrinsically married to GNOME, since basically(?) all GTK devs are GNOME devs, employed by red hat.

the mentioned GTK API breakage happens because red hat priorizes driving GNOME forward. @ahjolinna is right that Qt5 is more stable, _but_ it only provides limited access to the chromium instance.

the reason is also stability: chromium itself breaks enough that they can only commit their resources to maintain their stable API in some areas.

@nikolowry if I were to use https://github.com/nikolowry/electron-gtk3 to build electron with gtk3 support, what would I need to change in the atom build in order to build an atom-gtk3?

For those using a gtk3 build, you are probably seeing white text on the menu bar when using a light theme. This patch solves the problem.

I'm going to fix the other gtk3 build warnings in the next days.

The menu in Chromium with Gtk2 is not 'native gtk style', and is very ugly. Will Gtk3 build fix this?

@Menci. No, the menu bar with gtk3 looks exactly the same as with gtk2. You are right, it's not completely native, simply the colors of the text and background follow the gtk theme.
I looked at the code in the past days, to see if that could be fixed. One problem is that native gtk code is hidden behind layers of cross platform wrappers. Maybe gtk experts out there can help out with this.

@tensor5 I think the menu should be implemented in the cross platform wrappers. Just like OS X's menu is native and the native Cocoa code is also hidden behind layers of cross platform wrappers.

@Menci Of course, it's the only way such patch could be accepted.

It would also be nice to have a Gnome app menu.

You can look at how LibreOffice did it, it's in a similar way.

I think LibreOffice's menus are not really native. Thay don't have the drop shadow and show/hide animations.

http://caolanm.blogspot.sk/2016/02/native-gtk3-menubar-in-libreoffice.html

GTK+ apps have never looked native outside of gnome (and other gtk spinoffs), they have always looked horrible on KDE, LXQt) and Unity 8 will have the same problem when it arrives (its Qt5 based). KDE team has tried to work with gtk team with issue this but they have been complete 100% assholes and they don't care that their API changes/break with every damn update and that will break (some) KDE stuff like breeze-gtk theme, which btw. had to be hardcoded because of gtk teams stupid reasoning.*

btw. with KDE, LXQt and Unity 8 + Ubuntu Touch and SailfishOS, Qt5 "marketshare" is become way bigger than gtk and that will have huge affect at least in the long term

PS. about libreoffice, you can build it without GTK and have it using native filepicker, this what for example ChakraOS does, PKGBUILD , why? because its KDE/Qt focused distro that likes to avoid using GTK as much as possible

edited

*GTK developers blocked access to the theme engines, which were used previously for GTK integration in KDE, so now the only way is to try the "CSS way"

few apps that I know that uses Qt:
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, vapoursynth-editor, SVP, teamspeak3, mkvtoolnix-gui, hplip, scribus WPS-office...

other DE using Qt5: http://papyros.io/ and https://lumina-desktop.org/

@ahjolinna I think you are trying to convince the wrong crowd. If Chromium isn't making the switch then I highly doubt Electron would make the switch. To ask the Electron team to maintain this project as well as a QT5 fork of Chromium is asking for too much.

Additionally this issue is about replacing GTK2 with GTK3. If you want to have them consider a switch please make a new issue. Otherwise it is off topic and fills this thread with noise.

@alzadude you have to edit some of the grunt build scripts so that it doesn't download the prebuilt electron, edit the package.json version to match the electron build you did locally with gtk3 and maybe a python edit or two(sorry going off memory right now) . It's not difficult but it always takes me a minute when I do a new build because I always seem to forget the few steps I took in the past previous build.

If @tensor5 is starting to use gtk3 in his arch-atom repo I'd suggest maybe trying that out - otherwise I'll pop back in here the next time I do a build and document the changes for you (usually do them on the weekend)

@nikolowry thanks, some documented changes would be great :)

I'm on Fedora so I'd be looking to incorporate the changes based on this Fedora copr:

https://copr.fedorainfracloud.org/coprs/mosquito/atom/

This Copr seems to currently be the closest thing to a standard package on Fedora. It is based on these upstream rpm spec files:

https://github.com/FZUG/repo/tree/master/rpms/atom

And is mentioned in this Bugzilla bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1132661

Based on the existing work I'd possibly look to make my own Copr, for gtk3 builds of Electron and Atom (forking the upstream rpm spec files to incorporate the necessary patches, based on the documented changes). Unless someone else beats me to it of course :)

I'm trying to write a gentoo ebuild for this, but with no sucbess. I'd be very grateful, if someone helped me to do this.

@eternal-sorrow Did you already have a look at dev-util/electron, the ebuild that is currently in the official Gentoo tree?

@devurandom, I did. It's very old version of electron (0.36.12). I modified it for current version (1.3.1), adapted all the patches, but still getting a v8 linking issue (a lot of undefined v8 symbols).

@eternal-sorrow

1. Get in contact with [email protected], the maintainer of that package.
2. Setup an overlay repo with your ebuild here on GH, maybe we can work it out together.

@eternal-sorrow in Arch Linux we build the latest version of Electron with GTK3, take a look at it.

Any progress on this?

@nikolowry, which version of atom and electron you are using in your atom-gtk3? I realised that current versions of atom require electron-0.37 and cannot run with current versons of electron. Am I wrong?

@eternal-sorrow Atom was recently updated to a newer version of Electron.

https://github.com/atom/atom/blob/efae2e08c3f902149431732cbd550aea09748acc/package.json#L15

Is there any way to use gtk3? Would love it especially for the better file dialog.

Since archlinux already has a gtk3 build what is missing to have this is electron core ?

I think they want the switch to happen upstream. And it is officially planned now, see https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3.

Extra info, chromium/google chrome dev channels are using gtk 3 so it's just a matter of time now.

Confirmed for Chrome 59 at https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110.

Just a matter of time now...

Chrome 59 is out! :tada:

Now that Chrome 59 is out it would be great to see an Electron pre-release built with GTK3 for Linux.

GTK3 support is now in Chromium stable (59), which means it will soon be supported in Electron! As a Linux novice, I am not really familiar with GTK3. Reading through this thread and googling, I gather that this upgrade will improve the appearance of menus, windows, dialogs, etc. I think this might be a blog-worthy update, but would love to know more about how this change affects users.

I have a few questions:

• Why do you want GTK3 support?
• I see the "file dialog" mentioned a lot in this thread. What was wrong with it in GTK2 and how is it improved in GTK3?
• Does this update improvements things like performance, compatibility, etc? Or just UI?
• What other improvements might people expect?
• What Linux distros use GTK(3)?

@zeke:

Why do you want GTK3 support? I see the "file dialog" mentioned a lot in this thread.

One improvement I am interested in is that Electron applications running inside the Flatpak sandbox will now seamlessly use a portal to a filechooser on the host. This would even use the correct Qt one if the user has the Qt portal installed.

Does this update improvements things like performance, compatibility, etc? Or just UI?

In theory the hidpi support of Gtk3 might be relevant but I don't know how this interacts with Chromium's rendering which would bypass most of that. So it probably only changes theming.

What Linux distros use GTK(3)?

Effectively all distros have Gtk3. Unity, GNOME, MATE, Cinnamon, Budgie, and eventually XFCE use Gtk3 as their main toolkit for applications.

@zeke

What Linux distros use GTK(3)?

All major Linux distros use GTK3 for their desktop (shell). Some also have a KDE flavour but the default for all ot them is GTK3.

I see the "file dialog" mentioned a lot in this thread. What was wrong with it in GTK2 and how is it improved in GTK3?

Yes, althrough GTK2 and GTK3 applications can live together in the same system, GTK3 applications are better integrated with the current desktops. The File Chooser dialog is one good example.

@zeke

Why do you want GTK3 support?

I value consistency – the file dialogue is quite different on GTK 3, themes are often slightly inconsistent between GTK versions. I also like keeping my system minimal, Atom dropping GTK 2 will mean one less reason to have GTK 2 installed.

I see the "file dialog" mentioned a lot in this thread. What was wrong with it in GTK2 and how is it improved in GTK3?

As above, for me the most important thing is consistency. The GTK 3 dialogue is actually considered inferior by some, since it uses recursive name search instead of incremental search in the directory.

What other improvements might people expect?

The menus should use GTK too, instead of a custom implementation that does not seem to support mnemonics and jumping between adjacent menus using arrow keys.

Atom dropping GTK 2 will mean one less reason to have GTK 2 installed.

Just so I understand what you're saying here, @jtojnar: If you have a newer version of Linux that uses GTK3 by default, then you have to manually install GTK2 to support apps that haven't updated to GTK3? Besides Atom (and every other Electron app), what other popular apps have this problem?

@zeke Installing dependencies is usually done automatically by your distribution’s package manager, installing GTK 3 app will also download libgtk3 and installing GTK 2 app will obtain libgtk2. You can safely have both installed, it’s just that with an SSD low on space, I want to get rid of every legacy package I can.

Why do you want GTK3 support?

GTK3 is newer and has HiDPI support.
GTK2 is not developed anymore and is not modern.

I see the "file dialog" mentioned a lot in this thread. What was wrong with it in GTK2 and how is it improved in GTK3?

Don't know about this one.

Does this update improvements things like performance, compatibility, etc? Or just UI?

GTK3 is said to better utilize some CPU and RAM features, but I'm not sure otherwise. It would be a big UI update though.

What other improvements might people expect?

Better theming support.

What Linux distros use GTK(3)?

All distro's have GTK3 in their repositories.
Many major desktop environments use GTK3, like Gnome 3, Budgie, Deepin, MATE and soon(tm) XFCE too.

A prerequisite for this is Chromium 59 which there is a pull request for #9946.

@zeke Main takeaway is better UI consistency as on Linux you're more than likely to see apps using either GTK(2 or 3) or Qt as the UI toolkit. Windows and macOS have their own and you'll usually find most apps on those platforms use those, Steam doesn't have that native look though for example as it's not using the native UI toolkit.

I see the "file dialog" mentioned a lot in this thread. What was wrong with it in GTK2 and how is it improved in GTK3?

GTK2 compared to GTK3 might be best explained as earlier versions of Windows or macOS where the UI had a different visual look(layout/functionality differences of things like file browsers). If you run Windows 10 and get a file dialog that looks like Windows Vista or XP, it would look out of place and possibly lack certain features/UX.

On a desktop environment(DE) like KDE, this still creates a GTK3 dialog instead of the more common toolkit for that DE, Qt. So there is still some inconsistency there, but it's nicer than GTK2.

Here is some examples on KDE with default Breeze theme:

GTK2 Dialog with current Electron apps - GitKraken:

GTK3 Dialog - Meld:

Qt Dialog - Kate:

Mono/.NET(?) Dialog - BundleModder - Uncommon on Linux, Java applications can also use an uncommon toolkit:

As you can see the style consistency is quite different across the different UI toolkits. That can be confusing as a casual user why they are different, leading you to wonder if they are for the same purpose or frustration with navigation/presentation details being different across them(GTK you might double click on, while Qt may be setup for single click folder navigation) or just seeing the lack of consistency as unprofessional.

Gnome(GTK focused DE) is able to handle this better than KDE(Qt focused DE) with consistency between GTK3 and Qt, as Qt's toolkit is designed to integrate across platforms well giving a native feel/experience. GTK devs are reluctant to support their toolkit on DEs other than Gnome, despite KDE devs wanting to contribute code to address the issue on their DE. If the user isn't using older applications that use GTK2 or uncommon toolkits, they'll have a nicer experience.

Often you'll find a mix of GTK and Qt apps when a toolkit does not have as strong of an offering as the other toolkits equivalent app, for some users just using a single toolkits apps is viable(KaOS is a distro that caters to Qt5 experience, with optional GTK apps like Chrome available). With the popularity of Electron applications, avoiding GTK isn't always desirable.

Why do you want GTK3 support?

Consistency, file dialog being one that sticks out the most to me as a KDE user.

Does this update improvements things like performance, compatibility, etc? Or just UI?
What other improvements might people expect?

While I don't know much about FlatPak(sandboxed, distro-agnostic apps, sort of like a Docker/containers for GUI apps), I think GTK3 has a better story there than GTK2, including integration with the DE(FlatPak theming is another story for consistency, GTK3 in FlatPak recently got theme support, other toolkits need to add this as well). FlatPak as mentioned can also alleviate the file dialog issues via it's portals support.

I don't know too much about GTK2 vs GTK3 personally, but HiDPI story will be better for GTK3 I imagine(GTK2 might not even get such?). Theme support I guess is better, or at least you're more likely to get themes for GTK3 than 2 especially in future. On Gnome the file dialog might be a bit different with client side decorations(CSD) improving UX for those users. On KDE I think GTK3 support might work better with the Global Menu feature(still WIP, macOS like menu bar instead of being tied to the applications window).

What Linux distros use GTK(3)?

Majority of modern distros are using GTK3 or supporting it as far as I know. GTK2 is quite old. If you're using Chrome or Electron apps you're using GTK(probably a mix of 2/3, but leaning more towards 3).

@polarathene, you did not mention that GTK3 support allows to add Wayland support in the future, while GTK2 doesn't.

JFYI Chromium GTK2 build is broken in the latest stable 60.0.3112.90 and in the beta 61.0.3163.31.
It works in the latest master though.

And btw, it is not officially maintained anymore.
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

Awesome feedback on the virtues of GTK3, everyone. Thanks for your input.

Unfortunately it sounds like the GTK3 update won't land in Electron 1.8 with Chrome 59. It is currently blocking the build, so we'll have to wait until the next Chromium bump to 61 (we're skipping 60) before GTK3 is supported in Electron.

Is that correct, @alexeykuzmin?

@zeke do you have any rough estimate of when the chromium 61 bump will happen? We'd like to plan our move to native ES6 web components to align with that release. Historically the bumps come a month or so after release?

@zeke
Yes, we did have some troubles with the GTK3 in Chromium 59 branch.
But we should make a switch from GTK2 to GTK3 in the upcoming Chromium 61 upgrade.

@cpoole we don't currently have an estimate for when Chromium 61 will land in Electron, but it's being worked on now in https://github.com/electron/libchromiumcontent/pull/335. Our goal is to eventually be more in step with Chromium releases. Some awesome folks from Microsoft (@tonyganch, @cifratila, @alexeykuzmin, @alespergl, others?) have been helping in that process, which is freeing up GitHub's Electron team to focus on improving CI and smoothing out the Electron release process. So I'm optimistic :)

Why do you want GTK3 support?

@deikatsuo What browser is that? It looks like chrome and epiphany had a baby...

@mdsitton epiphany 👍

Any news on this?

@ziggy42 it should be there already in the latest chromium 61 (https://github.com/electron/electron/pull/10213). I guess it's only a matter of merging in master and making a release at some point.

Can't wait, those ugly file pickers burn my eyes :fire:

Will this change allow CSS in Electron apps?

So, chromium 61 is merged, shall gtk3 come with it?

Electron is now using GTK3 in the master branch, will be shipped in next minor/major release.

@ahjolinna

Thanks that you spend some sanity on this discussion.

You might be really interested into KaOS, which was already mentioned.
It is maintained by the very person who made Chakra great for several years, IMHO.

@all

GTK+ 3 got released when?

7 years ago.

Let that melt in your mouth for a while.

And a huge bunch of software projects are still sitting on 2.
Since porting is that of a pleasure..

XFCE, Mate and a huge bunch of others took 6 years to port the code.
Other projects switched completely from GTK to Qt within 2.

And yes: GTK+ is developed by GNOME, even the repo is sitting there.
It is - by nature and definition - developed for GNOME and nothing else.

Qt is developed for true and native integration into several platforms.

Electron is what?

A GNOME shop?

Nice one.

Clever thinking.

Its the same as in imperative and functional programming, as well as in so many other aspects here in this scene: Redundant, old, outdated software is often treated as an addictive drug, which makes it to one.

And new, clever, innovative software gets treated by misconception and pure ignorance.

10, 12 projects switched from GTK+ to Qt while I dont know of a single case, where the other way around happened.

Let this melt on your tongue again: That means a complete rewrite of their whole, integrated UI code.
Deeply nested, often.

Which means they prefer that, compared to a major upgrade of their existing tool.
And all of them are happy with that decision, until today.

Ask them.

Before your follow the herd without considering alternatives.

@ahjolinna posted you a video of one of these persons, VLC, Wireshark, LXQt and other remarkable software projects are also formerly based on GTK.

GTK is just used in Chromium as a binding to Aura and this only at Linux/freeBSD/Solaris and so on:
Windows and macOS builds are free of it.

:wink:

Though I get your points @ShalokShalom, no need to be rude, Electron follows what is delivered by the Chromium team.

The fork button is at the top btw, feel free.

Yeah, this was unnecessarily abrasive.

But I agree. GTK has too much unnecessary breakage that causes pain, Qt would have been a better choice

• IF QtWebEngine provides enough access to the underlying chromium instance
• IF QtWebEngine tracks the newest Chromium quickly enough

I suggest we move the discussion to a more appropriate place. @ShalokShalom, how about you just open a new issue here and describe the problem in a more civil manner than you did just now?

VLC, Wireshark, LXQt and other remarkable software projects are also formerly based on GTK.

That isn't true. VLC was using wxWidgets before Qt, not GTK: https://wiki.videolan.org/WxWidgets_Interface/

Seems to me GTK folks have since quite some time acknowledged that they did not communicate breakage and versioning well enough in the 3.x series and will try harder in the future with better and more clear long term stability as can be read at https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/.

I would also say that Qt and GTK cannot be fairly compared one to one due to different history, backing and goals and in my opinion they both have pros and cons depending on your point of view.

Stating that GTK is made for and only for the GNOME project is also in my opinion an unfair blanket statement.

ha! i really didn’t know about those plans. seems like they’ve learned at last. let’s hope they start considering any breaking change in CSS a real breaking change.

the last thing i heard was the… umm… excentric GTK 4.0 is not GTK 4. so the’re finally arriving at something almost as good as semver! they do almost as good as Qt did 20 years ago! 😁

We should see Electron with native GTK3 support by default soon based on this twitter post:

Electron 2.0.0-beta.1 is out with updated Chromium and Node.js, macOS in-app purchases, GTK3 support for Linux, and much more.

Yes. The real work for this was done by the Chromium authors and Electron got it through the Chromium upgrade in Electron 2.0.0.

In addition, Electron's own code got GTK3ified in https://github.com/electron/electron/pull/11879

Yeah, this was unnecessarily abrasive.
But I agree. GTK has too much unnecessary breakage that causes pain, Qt
would have been a better choice
IF QtWebEngine provides enough access to the underlying chromium instance
IF QtWebEngine tracks the newest Chromium quickly enough

Well, this is the main issue. People consider what is the quickest to implement for them, which is fine, while they forget very often that the actual implementation to get it running is something very different from the long term maintainence.

Its crystal clear from my point of view, that the mentioned issues can get tackled.

Once you compare the amount of coders who actually work on GTK3 ports and those who port their whole UI code on a new toolkit, can you see how amazing the difference is. I think I already posted a video about it, called 'From GTK to Qt: A strange journey.'

Why focusing on outdated software, simply because it seems ready to use, instead of hacking in the support in Qt?

Its that 'I use what _seems_ to be ready' dogma, which completely ignores long term decisions. Yes, it might look like that it takes a bit more effort in the first place, while you guys surely benefit from the modern toolkit once implemented.

Its also not that drastic, that QtWebEngine does not follow Chrome that quickly:
Its quick enough and Qupzilla proves that you can do amazing stuff with it - especially in a suitable environment, such as KaOS.

Do you really think you need 'more access to the underlying Chromium' and that 'QtWebEngine does not follow Chromium quickly enough' since Qupzilla and other software proves to ship amazing software, maintained by one single coder?

You think you need more access and quicker following as a full fledged web browser in Electron? How so?

Now, you sit on this clumsy software stack in so much projects and small teams manage to port 40-60% of their deeply nested code to Qt quick and efficient;

Something they did not manage to do from GTK 2 to GTK 3, which is quite amazing. As said: Most projects took 6-7 years to upgrade a major version

And nearly everyone seems to ignore that? Its so sad, that in an initially scientific community, so primitive decisions continue to spread.

Peace :)

@ShalokShalom, what do you mean by "outdated software"? GTK+? Any reason you say that?

Please stop with this Qt spam, this is an issue about GTK 3 port. If you feel the need to convince maintainers to switch to Qt, open a separate issue. I want to receive news about the implementation progress, not messages from Qt fanboys.

Locking this conversation due to excessive off-topic discussion.

Locking only addresses a symptom, but is a reasonable quick fix since the move to GTK3 is wrapping up and there's not much left to discuss on this issue's topic of moving from GTK2 to GTK3.