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

[Rallos Zek]

What kind of stupid shit is it? Made up shit, that's what kind. You're spouting nonsense, since everything you've just said is absolutely untrue. GTK3 *supports* client-side decorations, but it doesn't require them, and they're not in use on any released version of Gnome (though may be used on Wayland).

Bullshit! Gnome 3.12 is using CSD as we speak.

http://blogs.gnome.org/mclasen/2014/03/21/dialogs-in-gtk-3-12/

[psychoticmeow]

Bullshit! Gnome 3.12 is using CSD as we speak.

http://blogs.gnome.org/mclasen/2014/...s-in-gtk-3-12/

No shit? As he said Gtk supports CSD but doesn't require you (as a developer) use them.

[Temar]

AFAIK gtk has no plugin infrastructure for anything. And possibly not the man power to add that stuff. Adding linking dependencies on c++ to the core library is out of question... Not a pretty excuse.

You don't need a plugin infrastructure for that. A simple dlopen(3) can be used to check if the wrapper library is available and if it is, it will be used to open the file dialog, else the default dialog is used. This is only a few lines of code which even beginners can code in a few hours. This also solves the c++ linking dependencies problem.

So all I hear is excuses.

It was never part of any distribution, because nobody cared enough about file dialogs.

I doubt that. Having different file selection dialogs is one of the greatest usability nightmares of the Linux desktop. I doubt you will find any usability expert who disagrees with this statement.

Not on my desktop.

Then you should install Qt's GTK integration theme. It's only one apt-get/yum/zypper/... away.

Perfect examples, really... Most of them use their own toolkit anyway. Any pure gtk app that has kde file dialogs?

Yes, they are perfect examples as they show that many developers do care about usability and go the extra step, the GTK devs are refusing to go.

Any kde app, that has gtk file dialogs?

Every KDE application can use the GTK file selection dialog. It's only one kwriteconfig command away.

The only existing solution I know is the ld_preload wrapper. You can't include that into gtk. Distributions could provide it, however obviously, there is not enough interest. If YOU would contact the gtk developers and ask politely under what circumstances what method for using native dialogs could be added to the library AND develop the code yourself instead of whining in this very forum, then it would surely be included. But there are more pressing issues than this and gtk is understaffed anyway.

All I would get are excuses. Unfortunately I can't find the thread on the GNOME mailing list right now but people before me have already tried.

[m4tx]

Bullshit! Gnome 3.12 is using CSD as we speak.

http://blogs.gnome.org/mclasen/2014/...s-in-gtk-3-12/

Well...

Of course, GTK+ is used in many places, and client-side decorations may look foreign in some of them. Together with these changes, we introduced a dialogs-use-header setting. Built-in dialogs will fall back to a more traditional appearance if it is not set:

So, that means that you are still not obligated to use CSD when using GTK+ - in other DEs too.

[Akka]

Gtk should be a toolkit not a platform abstraction layer. Platform abstraction not related to the core duties of gtk should not be in gtk. I think something like abstract the file picker should be in a third part lib. Also a different file picker can break apps work flow so it is important the dev of the app and not the distribution activate something like this...

Also I like Gtk is a (almost) "native" toolkit. Even if Qt is very good I am hope its never take over the linux desktop space.


Also it is suicide for firefox to switch to Qt on Osx (and probably at windows). Qt is not sufficient native and mac user is way more picky with native feelings than most linux user. So even if they switch to qt they still need to support the same numbers of tookit.

[boudewijnrempt]

Also I like Gtk is a (almost) "native" toolkit.

No, it isn't.

[Akka]

No, it isn't.

Philosophically not technically. I don't like the idea of using a cross platform layer as main toolkit.

[boudewijnrempt]

You're out of luck then:

"What is GTK+, and how can I use it?

GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites.

Where can I use it?

Everywhere! GTK+ is cross-platform and boasts an easy to use API, speeding up your development time. Take a look at the screenshots to see a number of platforms GTK+ will run."

(From http://www.gtk.org)

I guess you'd best go back to Athena... That really only runs on X11.

[Ardje]

The best thing about firefox using gtk3 is that you can now export it as a broadway HTML5 application.
Now you can just use a browser to use firefox.
Then I can finally configure my netgear gs108t which seems to be build specifically for IE6, so I cannot configure it from my chromebook. But with a firefox through html5 export I can :-).

[Cyber Killer]

Gtk should be a toolkit not a platform abstraction layer. Platform abstraction not related to the core duties of gtk should not be in gtk. I think something like abstract the file picker should be in a third part lib. Also a different file picker can break apps work flow so it is important the dev of the app and not the distribution activate something like this...

A file picker has only 1 role in an application (from the devs point of view) - to give the path to a file or directory. Properly written apps do not interact with file picker dialogs, they only spawn them and take their output (the file path). There is no application workflow in this, it's only for the user.

Qt is not sufficient native and mac user is way more picky with native feelings than most linux user. So even if they switch to qt they still need to support the same numbers of tookit.

Whaa? Now that's just plain wrong. Qt uses native system APIs to draw widgets wherever possible. On windows and mac you will not be able to tell a Qt widget app from a base system API app. Hell, Qt apps look more native on windows than microsofts own .net apps!