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

[oleid]

The arrogance of the GTK developers, who can not even be bothered to implement support for other fileselection dialogs, makes every day an application switches to Qt a good day.

How much sense does it make for a C library to add a link-time dependency on the whole C++ stack?

By the way, there used to be (dunno if it's still working) a seperate library which would be LD_PRELOADed to add Qt file choosers to Gtk+.

By the way 2: Why doesn't KDE provide GTK+ (or even Qt -- last time I checked, they didn't) file choosers, if it's so important?

We are at a point where application developers are implementing support for different file dialogs, even though this clearly is the job of the toolkit.

Are we?

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.

Congratulations! You just described how CSD is handled in GTK+.

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.

The header bar is just another GTK+ widget. The application developer decides to use it or not. Applications with header bars save vertical space on my notebook, thus I don't think it's a bad idea per se.

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.

CSS is only the file format of choice. How can a file format be slow? I doubt that GTK+ includes all the complex rendering and layouting a browser has. CSS is, however, a good choice for testing themes *in* the browser, according to this bugzilla entry:

Make GTK CSS be compatible (syntax and semantics) to Web CSS. So a theme
written for GTK should also apply to a Website. In fact, I write most of my
tests on http://www.jsfiddle.net and run them in Firefox and WebKit to know how
to implement things. I consider this pretty much done since 3.4.

[oleid]

It's long overdue to abandon GTK3 and move to Qt.

There was a Qt version of firefox... But it seems as if there is a lack of interest from mozilla in a Qt port.

Edit:
Here is the current code of Gecko/Qt: [github]

[dee.]

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.

Oh no, that horrible, horrible CSS! Quick, you'd better switch to some other modern toolkit which has nothing to do with CSS and doesn't use CSS in anyway, like Qt. Oh wait...

CSS is just a markup language, like XML. Saying it's "awful and slow" makes about as much sense as saying the latin alphabet is "awful and slow" for writing traffic signs... hey, if you're in a country where most people use eg. Arabic, then you might be right, and it might make more sense to write traffic signs in Arabic. But if you're putting down CSS, what better alternative do you suggest for describing the style and appearance of widgets? Which language choice would work better than CSS, would be faster, would be understood by more people, is easier to learn, parse, write and test? I'll be waiting for your answer.

[ninez]

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.

I agree with the separation of duties, but in terms of a decorator - I'd rather have the toolkit handle drawing window decorations / shadows. let the WM manage windows, it doesn't need to handle drawing decorations... SSD/X11/GLX has shown just how awful not doing so is.

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.

You must not like any window bar in any modern OS then, i take it? I feel like you are exaggerating quite a bit. My gtkbuttonbars do not feel crammed. They have a handful of buttons per app, condensed menus, no menubar and feel minimalist. You know what i think is stupid? making wild claims that are demonstrably false. you say 300x titlebars. 1st off; gtkbuttonbar takes up less space and uses it space more efficiently than the window decoration + menubar combo. 300x my ass;



yup. that's right, takes up less vertical pixels than SSD/decoration+menubar... and aside from all of that - it's not like you are restricted to having gtkbuttonbars any particular size.

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.

that may be your opinion. but i can tell you straight up; I much prefer using gtk/css [i say that, because it's a gtk-implementation/subset of CSS]. You can claim it is slow; but I've had ZERO performance problems and my theme is chalked full of CSS animations/transitions/states. I think the gtk+ devs have worked around any of the performance problems in their css implementation. Obviously, you can also compile your theme into the binary format, as well. [gtk.gresource]

[anda_skoa]

How much sense does it make for a C library to add a link-time dependency on the whole C++ stack?

Isn't platform integration handled via plugins?

By the way 2: Why doesn't KDE provide GTK+ (or even Qt -- last time I checked, they didn't) file choosers, if it's so important?

Qt does that, doesn't it?
At least I see GTK dialog code in the GTK platformtheme plugin files.

Cheers,
_

[bkor]

Isn't platform integration handled via plugins?


Qt does that, doesn't it?
At least I see GTK dialog code in the GTK platformtheme plugin files.

Qt does NOT show the Gtk+ file opening dialog under GNOME. Very strange discussion IMO to have. I know that for the last 5 years or more someone is really focussed on the file dialog and the printing dialog, but that really is just a minor point.

[emblemparade]

Morten Welinder is challenging that point in his recent blog post. The blog post was on planet gnome and I have not seen anybody challenge it there, so I assume there is some validity to the claims Morten makes.

Do you think he is over the top with his criticism?

Thanks for the tip. Yes, I think he is over the top. He is complaining a lot about Ubuntu-specific changes to the Gtk+ implementation, and making somewhat crazy claims about the lack of multiscreen support in Gtk+ (as if that has anything to do with Gtk+). I dunno, I worked through similar challenges and didn't find them so problematic. I prefer Xfce over Unity for my own needs, but I found that my apps moved from Gtk+2 to Gtk+3 without any issues, nothing beyond the normal involved in upgrading a major release of a toolkit.

Look, I'm a seasoned programmer and I had my share of many frustrations with 3rd party libraries that don't do exactly what I want. I sympathize with this sort of venting, really I do. Thing is, the grass always looks greener on the other side, but you have to remember that the "other" library you want to use is developed, like your current library, with specific assumptions and specific purposes in mind. Always, always, your mileage varies. Some people might have a better experience switching to Qt at this time. Some won't. And some might want to switch back in a few years.

My personal experience (as someone who finds C++ to be more trouble than it's worth: there's the background) is that Qt is extremely annoying in many ways, not any less so than Gtk+. From my point of view, Gtk+ is actually far more conservative than Qt in terms of breaking legacy code: if anything, Gtk+ suffers from a lack of progress due to some really antiquated methodologies (see: grids) being maintained in order not to shake the boat too much.

I admit that this is a challenging time to pick a good toolkit: the UX world is changing a lot, adapting to the mobile/touch/beyond challenge in innovative ways that of course can't entirely predict how things will be in a few years. So you see a lot of flux, a lot of effort to allow rendering "flexibility", in Gtk+ and in Qt. By the way, it "amuses" me to no end that people complain about CSS in Gtk+, whereas Qt embraced web technologies 100% with QML. Gtk 3.X, Qt 5.X... they are both going to be quite ephemeral. I advise developers to NOT PANIC and stick to what they do best, make great apps with a great user experience. Wait for the dust to settle, and then, if it's really necessary, refactor your application to a different library.

[Temar]

How much sense does it make for a C library to add a link-time dependency on the whole C++ stack?

A very cheap excuse, couldn't you come up with something better which is not so obviously just a petty excuse? They could easily create a small wrapper library which is linked against the c++ stack and gets dynamically loaded by GTK or even preloaded.

By the way, there used to be (dunno if it's still working) a seperate library which would be LD_PRELOADed to add Qt file choosers to Gtk+.

This should be part of the GTK distribution as obviously it does not exist/work anymore or it would be included in distributions.

By the way 2: Why doesn't KDE provide GTK+ (or even Qt -- last time I checked, they didn't) file choosers, if it's so important?

Qt has been supporting GTK file dialogs for many years. At least since 2008.

Are we?

Yes we are, e.g. Chrome did this before they switched toolkit and also look at all those extensions that are created e.g. for firefox, libreoffice, etc. We are at a point where application developers are doing the work which should be done by the toolkit developers. And the GTK developers are too arrogant to include any of these solutions into their toolkit. They'd not even need to develop it on their own, they could just copy an existing solution.

[Cyber Killer]

I see people are still forgetting that Qt is way more than just a gui library. Most projects that switched to Qt did so because keeping a codebase, that is linked to many many different libraries that do different stuff, is a lot of maintenance work. With Qt they could drop a lot of extra dependencies and just use what is provided with the toolkit (and it provides a hell of useful stuff! networking, opengl, multimedia, there's even a full blown web browser engine in it + various language improvements that are only now being put into C++ as part of C++11). The gui is usually one of the least relevant reasons.

On these grounds there isn't really any base for comparing Qt to GTK. GTK is a competition for wxwidgets, etc, but Qt is something entirely different.

[dee.]

My personal experience (as someone who finds C++ to be more trouble than it's worth: there's the background) is that Qt is extremely annoying in many ways, not any less so than Gtk+. From my point of view, Gtk+ is actually far more conservative than Qt in terms of breaking legacy code: if anything, Gtk+ suffers from a lack of progress due to some really antiquated methodologies (see: grids) being maintained in order not to shake the boat too much.

Well personally, I find that Qt is pretty much the only thing that makes C++ tolerable... a lot of the things in Qt really help smoothing over some of the weirdness and, shall I say, odd design decisions of C++.

Qt has its annoyances sure, but Qt/C++ sure as hell beats plain C++ in my experience... also, Qt's documentation is simply superb, that's something the GTK devs could really follow the example on.

Other than that, I totally agree that people should just use whatever toolkit suits them best, be that GTK or Qt or whatever.