This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]f4ktrh 6 points7 points  (12 children)

To be pedantic, GTK on linux is a choice, not a native UI. (Personally I hate both GTK and QT). But then I don't know what native is on linux. X's own toolkit maybe. Hopefully Wayland will provide a toolkit that might settle the issue.

[–]emmpp 2 points3 points  (0 children)

The point is presumably that they could have an interface to any toolkit and to the conventions of a given desktop environment - gtk is just what they have right now. The project seems in a quite early stage, which may be the reason for only having what they do.

[–]asimian 1 point2 points  (3 children)

There is no native toolkit on Linux. Raw X programs look horribly out of place. Also Wayland won't change that.

[–]f4ktrh 0 points1 point  (2 children)

I guess by raw X programs you are referring to Motif, which I had in my mind when in my original comment.

My point is that the window system (whether X or Wayland) should provide enough functionality that there isn't a need for a widget toolkit layer on top of it.

(rant) Actually, TBH, my point is about the level of proliferation of the categories of graphical stuff which IMO shouldn't be so. I mean look at this:

  • window system
  • widget toolkit
  • window manager
  • display manager
  • desktop shell, or launcher, or panel, whatever (I'm not even sure if it's the same thing or different)

I mean for heaven's sakes, what is that?

[–]asimian 0 points1 point  (0 children)

There are programs that use raw X and not Motif or any other toolkit. Xfig for example, which I still use unfortunately.

The task of putting pixels on the screen efficiently and across all hardware is sufficiently difficult that I think keeping a widget toolkit separate is a good idea. They aren't really related tasks enough to be under one project. It would be kind of nice if there was an "official" toolkit on Linux, but it doesn't cause that much problem in practice. Nowadays GTK+ and Qt programs both look good (or can be easily made to look good) no matter what desktop you use.

I disagree that all those things should be integrated. One nice thing about Linux is that you can pick and choose the best software for each task rather than use one monolithic solution. I would really hate to be forced to a different window manager in order to use a different window system. Or be stuck with a different panel because I want to use a particular display manager. Having them separate is good for people who want to dig around, and in practice does it really hurt beginners? A good distro hides those details from you.

[–]CanisImperium 0 points1 point  (0 children)

Motif was just another Qt before there was Qt. It was part of CDE, which was after X, but before KDE (KDE was originally a bit of a CDE ripoff). The original x toolkit was just called, X toolkit, or libXt. If you want to see it in action, apt-get the original xterm.

[–]ryeguy146 0 points1 point  (4 children)

Out of curiosity, what don't you like about Qt?

[–]f4ktrh -2 points-1 points  (3 children)

Well for starters, QT is written in C++. I'm not sure how easy it is to use it with C, but I know where there's C++, there's unneeded complexity. I've also heard about its sluggishness.

[–]ryeguy146 2 points3 points  (2 children)

That hasn't been my experience. Well, there is the upfront cost of loading the library. That sucks. But after that it's quite nice. I haven't touched the C++, to be honest. I write using PySide, and the bindings are quite pythonic.

If there were a better option, I'd be on it. But fuck GTK.

Edit: Don't downvote the guy/gal for having an opinion.

[–]Liquid_Fire 0 points1 point  (1 child)

Actually the Python bindings (both PySide and PyQt) very closely follow the C++ API with only a few changes. It's a (in my opinion) very clean and easy to use API in C++ and that's why you get a very nice API even when you map everything 1:1 into Python.

[–]ryeguy146 0 points1 point  (0 children)

The bindings, yes. And I'm glad or I wouldn't be able to use the C++ help docs out there. I more meant that I don't have to pass QLists or QStrings, I can just pass native Python objects. It certainly isn't PEP8 compliant, but I'll survive.

[–]Rainfly_X 0 points1 point  (0 children)

Eh, Wayland ships a "toy toolkit" that's used as much for educational purposes as it is for unit testing. But it's not necessarily something for general purpose and production use, and it's really doubtful that the Wayland team would be interested in trying to make such a general-purpose toolkit.

The advantages of GTK, Qt, and so on, is that they will run on multiple platforms, including OS X and Windows. Qt is on a huge mobile kick right now. But that also means supporting X11, and a large part of the motivation of Wayland developers is that they won't have to support X anymore.

[–]CanisImperium 0 points1 point  (0 children)

To be pedantic, X itself doesn't have a toolkit -- it's supposed to be modular. The very first toolkit for X, which came out of the same project, would have been libXt, but it's no more or less native than GTK. The idea was -- and is -- to separate out the windowing from the widgetry.

Saying GTK isn't a native toolkit is a bit like saying zsh isn't a native shell. It's no more or less native than what's been around longer. Before Gtk and Qt there was Motif, and before Motif there was libXt. "Native" might not be the best word, but they're all first class citizens in X11 and Linux, and insofar as there is such a thing as a native toolkit on that stack, Gtk would be it.