The GTK3 Port Of Firefox Is Making Progress, Firefox Can Run On Wayland

[jimbohale]

The window manager and decorator should be responsible for drawing window decorations. The application should be free to request that decorations are not drawn and then it can go ahead and style its window however it wants. There should be a separation of duties the way I see it.

However, I also see the window bar as being used for managing the window, and not being a place to cram all kinds of garbage shit from the app in there because somewhere along the line somebody got "inspired" and decided that menu bars and tool bars are "dated" concepts. So now we have 300px tall title bars with hidden menus and ugly icons. Big problem solved there.



CSS is awful, idiotic, and slow as shit. There shouldn't be any web technologies in anything other than a browser and that's only because we have no choice in the browsers at this point. JS, CSS, HTML -- all that crap is absolutely awful means of programming anything. They are some of the worst software technologies in the world, completely made by the limitations of the browser. All those things do is drive developers to alcohol.

You consistently post uneducated idiotic shit. You obviously know absolutely nothing about anything. Please prove anything you are saying, and since I know you can't I will preemptively tell you to fuck off because you are ACTUALLY dumb. I mean, I know you are a troll, but your trolling only hurts Linux, so please can you just stop?

[CrystalGamma]

However, I also see the window bar as being used for managing the window, and not being a place to cram all kinds of garbage shit from the app in there because somewhere along the line somebody got "inspired" and decided that menu bars and tool bars are "dated" concepts. So now we have 300px tall title bars with hidden menus and ugly icons. Big problem solved there.

Not sure about the rest of your comment, but to this, I agree 100%.
These 'modern' GNOME apps that replace the thin titlebar with another big-ass toolbar (that I don't use, because there are keyboard shortcuts for things I do frequently and menus for things that I don't) and take away the window manager's/my ability to move the window whereever it wants without the application's consent (window management is the window manager's, not the application's responsibility) as well as the ability to have consistent title bar styling (My XFCE desktop has dark title-, menu- and task bars, which is respected by all GTK2 apps, all Qt apps, most older GTK3 apps and apps like Firefox, but gedit, evince et al. decided "hey, the user definitely wants a huge white title bar, let's do that!". That's the point when I stopped using them.).

I'm glad Kwin still wants to draw decorations itself under wayland, and that's why I'm waiting for that before trying to build a WL desktop.
Or does Enlightenment do the same?
Anyway, none of these have full wayland modes present in my distro (Arch)'s packages AFAIK. (Correct me if I'm wrong)

[Karl Napf]

You also make the odd conclusion that "The very fact that so many projects are switching, and the switch is pretty much entirely one-directional, should tell you that there is something different." Corellation doesn't equal causation.

True, but some of those projects have made public statements on why they are switching. Just think about the presentation on subsurface at linux conf in Australia for one example.

I was hoping to see some reaction from the GTK/Gnome side about whether they consider the criticism raised to be valid or not and whether they do want to improve the situation. So far I am out of luck.

That *some* projects are switching can say many things, but that doesn't lead to the conclusion that Qt is generally better than Gtk+ and that all projects should switch.

Agreed.

The reason can be very project-specific reason, for example the choice of programming language (C or C++), or licensing ideology.

I would be surprised if language considerations are actually encouraging projects to move from GTK to Qt: Those projects already have working GTK code, so I would be very surprised if they are not fine with C;-)

It could also be jumping on the bandwagon. Trends are funny: in 5 years, there might be something really annoying happening with Qt (too much focus on mobile or something) and then "so many projects" will want to switch back. We've seen these changing fashions a lot.

Do you know of any project moving from Qt to GTK? I can't think of any -- not even going back the 15 years or so I have been watching this circus. I am 100% sure there were some, especially during the time Gnome was founded. You have also witnessed the changing fashions a lot, do you remember some?

[Karl Napf]

Do you really want to go back to the days where the theme engine had final say over what it was possible for designers to implement?

It still does... it is just a different theme engine which may or may not offer more options to the designers.

[psychoticmeow]

It still does... it is just a different theme engine which may or may not offer more options to the designers.

Actually it now does offer more features, and in a way more people will understand.

[anda_skoa]

Read the article - they've added the ability to have the main Firefox process run GTK3 while the plugins can still link to GTK2 in their own process.

I was surprised to read about this bit. I had assumed that like any other browser out there they had been running plugins out-of-process for ages already.

Cheers,
_

[Gusar]

I was surprised to read about this bit. I had assumed that like any other browser out there they had been running plugins out-of-process for ages already.

They have. Since Firefox 3.6. What's a recent addition is the ability to use GTK2 plugins in a GTK3 Firefox, changes to the plugin container and IPC with Firefox were required for that.

[Karl Napf]

I was surprised to read about this bit. I had assumed that like any other browser out there they had been running plugins out-of-process for ages already.

Oh, they did. they just use libxul in the plugin runner process to talk to the UI process. Libxul is linking to GTK3 even though they do not need a UI at all in the plugin runner. So any plugin loading GTK2 caused all kinds of havok, since GTK3 is already (needlessly) loaded and the two share symbols.

The obvious approach is of course to add a new library called libmozgtk that provides the symbols for *both* GTK2 and GTK3 and have two implementations of that library, one using GTK3 and leaving the GTK2-only symbols blank and the other using GTK2 and leaving the GTK3 symbols blank. The idea apparently is that the UI process will use the GTK3-flavor and never access any of the GTK2 symbols (which will cause a core dump) while the plugins are using the GTK2-flavor and will never use GTK3 (which would again cause a core dump).

Now let's wait for the first plugin to use GTK3 and watch this whole thing blow up.

Never mind the maintenance overhead of keeping the two flavors of libmozgtk in sync with GTK3 (and GTK2, but that is rather stable by now).

[Alexander Kurtakov]

Exactly. Too bad Eclipse has moved to GTK3. I should try Intellij IDEA...

Oh, and let's not forget GIMP is also moving to GTK3. Probably in 2018 though

I would happily accept your patches adding QT backend to Eclipse to prove that it's so much better .

[anda_skoa]

They have. Since Firefox 3.6. What's a recent addition is the ability to use GTK2 plugins in a GTK3 Firefox, changes to the plugin container and IPC with Firefox were required for that.

Ah, I thought that was about content plugins, i.e. NPAPI plugins like Flash
Didn't know Firefox had application plugins as well, I only knew about extensions

Cheers,
_