If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Yes, you successfully irritated people with your idiotic posts. Congratulations, you must be very proud.

Do you disagree that Gimp is a piss-poor porting job on other operating systems? Just use its file open dialog on KDE and you'll understand.

KDE isn't an OS.

Or do you disagree that GTK fails to offer a native experience on every WM...

Apparently OS, DE and WM are all substitutable terms.

outside of Gnome? Tango icon set...

There's not much of a 'native' icon set to really speak of on Windows, you've got the option of either hacking resource files for specific apps (explorer), or creating your own; it's otherwise slim pickings in terms of the stock API icons. Integration with KDE is hit-or-miss, depending upon how completely the icon theme covers the (current) freedesktop icon specs, which are kind of troublesome in themselves. This argument was a reach back when you were just bitching about OSX integration.

wrong button order

Which Gtk+ apps are we talking about? Dialogue button orders can be configured in the gtkrc, it just so happens that The GIMP porters fail to toggle that setting (which is great if you spend most of your time on *nix but obviously a bad thing for Windows users).

wrong widget sizes

Because Gtk+ is the only toolkit that has problems, here.

If you have a counter-argument I'd love to hear it.

Yeah, it's called pages two and three. I recommend reading them sometime.

Originally Posted by NoEffex

GTK isn't meant to bring a native experience on every WM outside of gnome. In fact it's primary aimed at GNOME/Xfce these days.

If you don't like it's "awful job" on KDE/Win/Mac which it's not made for, then don't bother with it.

This is wrong. Gtk+ is aimed at whatever hackers and financiers, for the project, aim it at. There's a reason why Gnome and Xfce have so many external libraries, which essentially just provide an extended/tweaked set of unofficial Gtk+ widgets. Hell, even The GIMP uses custom widgets which (unfortunately) haven't found their way back upstream and The GIMP was the original reason for Gtk+'s existence. Gnome undoubtedly has the biggest interest share in Gtk+ (although they're now sleeping with clutter/mutter on the side) but not long ago, you could have said the same thing of Maemo. Xfce has very little presence within the Gtk+ project.

All of the things you mentioned are such different platforms (C/C++/Objective-C) that integrating them screams bad idea and messy code.

This is a bizarre statement. Gtk+ has competent bindings for C++. Unsure about Obj-C but then again, Gtk+ doesn't use Cocoa on OSX; it runs on an X11 server. Windows plays just fine with pure C and the problem of integration really isn't as low-level as language bindings, it's different UI philosophies and graphical/multimedia architectures: getting Gtk+ to run natively on Quartz poses a bigger challenge than creating Obj-C bindings (again, I have no idea where progress is on either of these fronts and CBFed googling it).

Yes, you successfully irritated people with your idiotic posts. Congratulations, you must be very proud.

Trolling is an art. You have a lot to learn.

KDE isn't an OS.

Thanks for stating the obvious.

Apparently OS, DE and WM are all substitutable terms.

No, they are not. You are mistaken.

There's not much of a 'native' icon set to really speak of on Windows, you've got the option of either hacking resource files for specific apps (explorer), or creating your own;

The same as gnome, then?

it's otherwise slim pickings in terms of the stock API icons.

The problem is that GTK is using Tango icons for icons that do exist natively on Windows. Like the folder icon, for instance.

Integration with KDE is hit-or-miss, depending upon how completely the icon theme covers the (current) freedesktop icon specs, which are kind of troublesome in themselves.

Mostly miss.

Which Gtk+ apps are we talking about? Dialogue button orders can be configured in the gtkrc, it just so happens that The GIMP porters fail to toggle that setting (which is great if you spend most of your time on *nix but obviously a bad thing for Windows users).

GTK should automatically use the correct order for the OS it is running on. It shouldn't be an option.

Because Gtk+ is the only toolkit that has problems, here.

The fact that other toolkits get things wrong doesn't make GTK suck less.

GTK isn't meant to bring a native experience on every WM outside of gnome. In fact it's primary aimed at GNOME/Xfce these days.

Yet,

Originally Posted by http://www.gtk.org/

GTK+ is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API.

In that case, they should really remove or clarify the bolded part. It's rather misleading.

If you don't like it's "awful job" on KDE/Win/Mac which it's not made for, then don't bother with it. That's why KDE/Win/Mac all have their own applications.

Totally agreed. If proper integration is a priority, GTK is not an option. In fact, the only approach is to separate the presentation layer and code it for each platform separately, like Google Chrome or Opera do.

That's like complaining that your iPod theme doesn't match your USB cable or something. It's not made to do that. It's made to be a base toolkit (only above X11) that provides it's own widgets and themes and doesn't rely on the underlying platform to provide them.

Your analogy doesn't make sense.

Qt also uses its own widgets and themes but it somehow manages to look more or less correct on Windows and Mac OS X.

All of the things you mentioned are such different platforms (C/C++/Objective-C) that integrating them screams bad idea and messy code.

That's nothing but a minor inconvenience if you design your code correctly. You can write your core logic in one language and interface with the underlying platform in a different language if need be.

Same as above. You're basically inviting me to start using explicit /sarcasm tags, as if I'm dealing with some kind of retard who needs labels to tell them that the coffee is hot, or that it's not a good idea to use that toaster in the bathtub.

The same as gnome, then?

Gnome/Xfce/KDE/etc rely upon the freedesktop specs, with implementations abounding and an elegant path for filling in the gaps: with any custom icons going into the hicolor theme, where they can be easily overridden by subsequent implementations of the spec, or used as fallbacks in the absence thereof. So no, not the same.

GTK should automatically use the correct order for the OS it is running on. It shouldn't be an option.

Says who, you? And to the developer who ports their app to Win for the benefit of extant *nix users, what, tough shit? You're veering into pedantry in order to salvage your ill-conceived criticism. Let it go; yours is not the only valid use case.

The fact that other toolkits get things wrong doesn't make GTK suck less.

The fact that I can't think of a toolkit that gets this right does tend to make such criticisms look dumb, however. Especially considering your defence of another culprit toolkit and on a platform which doesn't seem to define widget sizes to begin with:

Qt also uses its own widgets and themes but it somehow manages to look more or less correct on Windows and Mac OS X.

Of course it looks, "more or less correct on Windows", how could it not? You could stick a workbench 1.0 window on a Windows desktop and it wouldn't look out of place. Windows is an exercise in (font size and colour palette dependant) eclecticism.

If proper integration is a priority, GTK is not an option. In fact, the only approach is to separate the presentation layer and code it for each platform separately

Uh huh...

like Google Chrome or Opera do.

Could you possibly have picked worse examples? Chrome and Opera are both exercises in providing a consistent experience across platforms. You know, the opposite of integration; that thing you were arguing one sentence prior. Never mind that Opera is a 90's dinosaur (software suite and MDI anyone?) and Chrome is an experimental curiosity, so novel in it's design that Google took it to it's logical extreme and is busy turning it into an environment all it's own, like so many tired emacs jokes. Oy vey.

This is a bizarre statement. Gtk+ has competent bindings for C++. Unsure about Obj-C but then again, Gtk+ doesn't use Cocoa on OSX; it runs on an X11 server. Windows plays just fine with pure C and the problem of integration really isn't as low-level as language bindings, it's different UI philosophies and graphical/multimedia architectures: getting Gtk+ to run natively on Quartz poses a bigger challenge than creating Obj-C bindings (again, I have no idea where progress is on either of these fronts and CBFed googling it).

Let me elaborate. I don't mean writing bindings in said languages, I meant drawing native widgets using said languages for every platform (Like how Java does it). It'd be nearly impossible to keep it consistent.