Slashdot Mirror
GTK-- vs. QT
spirality asks: "The company I work for is getting ready to decide on a GUI Toolkit for
our Computational Modeling Toolkit (CoMeT, www.cometsolutions.com). We would like C++ compatibility and ports to various Unices and Win32 platforms. Not supprisingly we've come up with two choices, GTK-- and QT. I've attempted to compare the two by doing alot of web surfing and searching, but I've come up with things that are consistently one or more years old. So, the question I pose is what are the (dis)advatages of GTK-- and QT, and why would I choose one of these toolkits over the other? Overall functionality, momentum for future growth, ease of use, licensing, and pretty much anything else is relevant to our decision." With QT now at version 3.0 and GTK now in the 1.2.x revisions, maybe it's time to give the two libraries some fair comparison and discuss the new features, advantages, and disadvantages of each?
what next Taco, how about a rousing vi against emacs story?
Oh, first post for Jesus !!!!
I've recently got my Sharp SL-5000D which comes with a cute embedded version of QT. I'm starting to play with it some more, and I have to say I'm impressed. I've not done much GUI dev. under 'nix before, but I've followed many threads in the past elsewhere that suggests GTK is a hodge-podge and is getting out of control, with no coherent design.
I'm not experienced, but as a lay-man, I'd have to say go for QT.
Is this my first first post? ;-)
:-)
Seriously, I'm interested in this myself - I'm working on a universal chip programmer and I need a toolkit to do this. I'd rather not use VC!
Grab.
Im here...but i frankly have to opinion since i only use and never hacked those libs before.
Maybe its a point to choose a central maintained Lib such as QT if your product is going to be commercial. As far as i can tell Trolltech is doing a good job with it.
Personally i prefer the GTK as a User, i find the Applications more coherent to use, but thats mostly thanks to Gnome, i guess.
So, thats as much as i can say about it...wont help you a bit, i bet!
Have a nice Weekend all you slashdotters out there..
Lispy
I actually prefer GTK+ and I think it's a better bet long-term, but I don't think the cross-platform aspect of the library gets much developer attention.
Being cross-platform is a major selling point for commerical Qt users, however, so if you need your apps to work on Windows then it's clearly the way to go.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
You may also want to take a look at the wxWindows toolkit. It's a wrapper over what's available on a given platform (the native API in Win32, GTK in the Unix world, and there's a Mac port in progress, I believe). Good stuff, definitely, especially if what you want is C++ and portability. Note that your apps will look totally windowsy on win32, so your users will not be confused by their look.
-- B.
This sig does in fact not have the property it claims not to have.
... both suck! Motif forever!
...but a little slow on Solaris 8. Maybe it is just me, but my build of Mozilla really jerkey on a workstation (UltraSPARK III, 2G RAM). On the other hand The Gimp runs like a dream on my Windows box, and Mozilla is zappy on Linux.
--
Dooferlad
To pick up your point on licensing, Qt is either GPL or pay. So if your application will also be GPL, it's free, if your application will not be GPL you will have to pay up for Qt. GTK is LGPL AFAIK (enough acronyms for you? ;-) so that will not stand in the way of making your app non-free.
BTW, if you know C++ and want to get to know a bit about Qt, they have a pretty good tutorial online here. Just walking through the examples made me realize just how cool it is, and how much you can do in just a few lines of code.
... a "flamebait" or "troll" story category ...
If you intend to develop a closed-source product, the licence of both library will probably need to be evaluated too. If you go for
an open licence, then it's of minor importance.
(Qt requires licencing fees if you want to keep
your sources closed).
Are you going to develop two versions -- one for Windows using MFC and one for Linux using GTK or QT? -- or do you plan to use one library for both?
Using GTK excludes the latter, as while it can be used on Windows, and thus makes it possible to port programs such as Gimp to this platform, it's not exactly its most supported feature. And it doesn't look like native Windows.
On the other hand Qt is really supported on Windows -- actually, you have to pay for it.
If MacOS-X might be a target platform for you, your choice should be QT.
I have only scratched the surface of both GTK-- and QT, but I found QT to have a *very good* documentation. It has a complete class hierarchy documentation and comes with a load of example programs.
Another observation is that GTK-- is much more low-level than QT. If you want to extend it's components you might have to delve into the depths of the gdk library (which, in my view is only a thin wrapper around the X11-libs). QT on the other hand has a very good abstraction of windowing system details. Being mostly a Java programmer, I found the QT model very easy to use.
Of course, YMMV.
I worked on a rushed project earlier this year, and used the gtk-- C++ wrapper for GTK, as well as the gnome-- wrapper (then still very much under development) for the Gnome libraries, specifically the canvas.
Personally, I found it frustrating to use. As these wrappers are still being worked on, the documentation is sketchy. The object-owning semantics are confusing (at least to me) - I was forever leaking memory or prematurely destroying objects. Trying to destroy something from within a menu callback I recall was particularly noisome. The gnome-- canvas wrappers were a moving target, though they may have since stabilised, and didn't fully expose the canvas API. Writing one's own canvas items is done in C, and then wrapped.
Perhaps with more persistance I might have figured out how to set up keyboard acceleration, but it is at anyrate a real battle to find documentation that explains what is going on with it. AFAIK, there is no straightforward way of making a multiple file selection in GTK+ 1.2. In gnome canvas (not GTK+, but a close cousin) there is promised functionality that is simply not implemented - I'm thinking here of smoothed lines, for which the code reads:
I haven't used QT yet. It certainly looks pretty, and a quick glance at the example code and docs provided seems to indicate that it's not too complicated, and well documented. I'd certainly shy away from GTK+ if a C++ interface is required.
The new version of GTK under development should address many of the shortcomings of the current toolkit, and includes goodies such as Pango. It is not yet in a stable state, however, with the API still undergoing final tweaking I believe.
wxWindows has a very rich feature set for building GUIs, plus many other benefits like portable classes for threads, networking, ipc, file i/o, serialization and much more. It is available for almost any kind of UNIX-like OS, for any Windows version, and some more platforms like VMS.
It is a shame that wxWindows doesn't yet get more attention.
If you want cross platform compatibilty with C++, then check out wxWindows. It has ports to Windows, MacOS (9 & X), UNIX + Motif, UNIX + GTK. It also has a very well developed Python binding -- so well developed that quite a few people want it adopted as the official Python GUI instead of TKinter.
-- Help Digitise the Public Domain at DP.
Didn't they port gimp to win32?
gimp is THE flagship gtk application, bar none.
My suggestion - try them out.
;-)
Come up with a few small use cases and let your developers loose on everything you can get your hands on. Both Qt and GTK+ are freely available enough for that to be a useful exercise.
You might find that, while Qt has nicer abstractions, and provides a familiar set of classes which are (IMO) far superior to MFC... perhaps GTK has a slight edge for lower level work (which it sounds like you might get involved in). Also, see which interface builder tools your team feels most comfortable with.
The problem with this question is that the replies are likely to degenerate quickly into a C vs. C++ rant-a-thon. Yes, GTK is entirely written in C. But it *is* object oriented. It seems strange to everyone at first, but just because a language doesn't support particular features, doesn't mean that you can't use a particular programming style. OO methodology is just as relevant to C programmers as to C++ or Java programmers.
If your programmers are good, they'll write good code whatever the toolkit. Just make sure everyone thinks that they got a say in the decision.
These sigs are more interesting tha
AFAIK, the Win32 port of GTK+ is more or less a one-man show, making GTK pretty unstable and lagging behind on Windows.
In addition, Qt now has a Mac OS X port.
Add this to the excellent commercial support from Trolltech.
Design and language issues not taken into account.
An example is the Komodo IDE by ActiveState, which uses XUL.
XUL is the next generation browser application platform. Simply speaking, the Mozilla team chose an approach very similiar to JAVA to come closer to a platform independent graphical user interface:
XUL goes one step farther, as there is no compilation step.
The XUL application implementation language is a XML language that together with cascading style sheets and JavaScript glue will yield an application one starts in the browser by opening the .xul document.
A possible advantage of XUL might become the relative ease of application development, change and distribution.
Possible problems will be similiar to the ones known from JAVA. The qualitiy of XUL applications will stand and fall with the quality of the XUL implementation for a specific platform, which right now means the quality of its Mozilla or Netscape implementation.
Of course, compared to JAVA, which has underwent several larger development cycles and now features mighty libraries, XUL is a bleeding edge technology at its beginnings.
However it is still possible to make direct use of the various Mozilla widgets as well from C++.
Developing for a professional product I would always go with as many professional tools as possible.
To me QT seems to be the FAR better decision. It has true interoperablity between Win32, MacOS X and X11.
QT is C++ from the ground up, GTK-- is wrapping GTK++.
Furthermore with GTK you definitely write more code to accomplish the same.
QT 3 gives you access to SQL-databases from its widgets.
QT comes with a very good interface builder.
QT based programes feel snappier than GTK based ones.
One drawback might be that you have to preprocess (actually your Makefile has to) your code before its ready for the compiler, but that's not a big deal.
With Kdevelop you have access to a very good IDE.
One thing I don't know is how QT works in terms of different GUI threads, but I neither know for GTK.
So please, go with QT and be happy
A much harder decision would be: What should I use for my Web-Frontend, mod_perl or PHP... but that's a different story!
I'm not trying to sound stupid or off-topic here, but have you considered Mozilla? Beyond ther browser, they've developed a really interesting cross-platform C++ (and JavaScript) development platform. For a start there's a cross platform implementation of COM and you can develop your UI's in an XML dialect called XUL.
Ever tried wxWindows? I and my company use it. IT IS REALLY nice and easy to use. And it is open source. Best of all it does "little" things like printing...
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Don't forget that an all-new GTK+ version is just coming out, a cleaner design, vastly improved i18n support, and all. I suggest you look at GTK2 (and it's C++ wrappers) as well, as this is what's going to be used, rather than the current version.
/Janne
Trust the Computer. The Computer is your friend.
Geez. Talk about flamebait topic. Personally (and personal opinion only, here), I'd say, Qt is better designed, clearer, and easier from a programming standpoint - but it's actually not clean C++, what with its dodgy signals/slots stuff, that gtk-- manages to do within the bounds of the language.
If you're writing commercial, proprietary software, then you have to pay to use Qt - but Trolltech provide a thoroughly professionally supported toolkit to you for your money.
The Qt class library is actually more akin to the standard set of Java classes than just a widget set - there's decent cross-platform support for sockets, xml, threads, unicode, etc. It really makes C++ programming very easy.
OF course, there's other cross-platform C++ tollkits like FLTK... The gui toolkit page lists many more.
Choice of masters is not freedom.
I wanted to take Friday off too, but the boss said I couldn't.
Guess you'll have to do your own homework.
...go for Qt. Gtk, IMO, has the huge disadvantage that the current 1.2 revision doesn't support Unicode, whereas Qt fully relies on it and even provides GUI-independent helper classes for all kinds of Unicode conversion that you can use anywhere in the program. This would also help for the mathematical symbols that you probably want to display. It looks like Gtk2 will use Unicode and Pango, thus potentially blowing away the competition, but as long as there's no stable version of Gtk2, I'd go for Qt.
From a conceptual point of view, I like Gtk-- better. It actually uses the modern C++ language, including the C++ type system. This way you avoid the need for a preprocessor, and get static typechecking instead of "dynamic typechecking" (i.e. "the user does the checking"), which is the entire point of using C++ in the first place. It also use the standard C++ library instead of duplicating it poorly, so you don't have to deal with multiple string types and the like. Since the application is a GUI frontend to a library written in standard C++, using the standard C++ library classes, this matter a lot. Qt is written for an ancient subset of C++, something closer to "C with Classes" than the C++ standard.
However, Qt is simple to use, well documented, and have stable API's. In practice, these make it much easier to use than Gtk--.
As an extra plus, Qt is GPL and therefore more gnulitically correct than Gtk--, which is only LGPL.
Have you looked into the FOX Toolkit? It's written in C++, is available on many UNIX and Windows platforms and has many bindings to other languages (Ruby, Python, Eiffel). You can find it here.
The big difference is that gtk-- is based on the C++ standard library, and so allows you do use familiar and efficient constructs like std::vector, std::string and so on.
QT has reimplemented all those things as a rather dodgy set of proprietry classes, which lock you into, for example using QString rather than std::string throughout your application, or doing a lot of extraneous conversions every time you need to talk to the GUI.
In its favour, QT does have much better documentation than gtk--, but all the same, I prefer the standards based gtk--.
i can't wait till the day the lameness filter gets so complex and convoluted and normal post will never get through.
"The company I work for is getting ready to decide on a GUI Toolkit for
our Computational Modeling Toolkit (CoMeT, www.cometsolutions.com)."
It was nothing more and nothing less than a way of getting tens of thousands of nerds to visit the company URL.
The only other possibility is that he _really is_ asking Slashdot readers for programming advice. In which case he should just save us the trouble and link to fuckedcompany.com.
Qt is 3.0
Gtk is 1.2.x
Sure it's friday, but come on, thats easy 3.0>1.2, so the choice must be Qt!
Same reasoning shows that Windows 2000 are MUCH better than Windows 98 which in turn is slightly (by 3 point) better than Windows 95, which again are MUCH better than windows 3.11.
Sigh. Does you youngsters not learn anything today?
Thomas S. Iversen
I have been using Qt for some years now starting with Qt 1.0 some years ago. I have also tried to both patch GTK+ programs and in one instance port one of my Qt applications to GTK+ (I was preferring gnome at the time).
The advantages I can see from using Qt is:
* Superb design. The OO design of Qt is really thought out. There are virtual function to do all the basic things you can think of and if you think of something really clever there are lowlevel routines to do that too.
* Superb documentation. A comprehensive, hypertext help and in Qt3 an included help browser. This is really an advantage since GTK+ not really being supported by a commercial entity suffer from lots of "I'll rather code than document" in the libraries.
* Good migration path to new versions. I have a program consisting of ~100000 lines of code (An Oracle client http://www.globecom.net/tora) which I migrated to Qt3.0 in about 2 hours, some of that time was spent using Qt3 specific features also like docked windows where appropriate.
* Not only a GUI toolkit. It also includes primitives for handling threading, I/O (files and sockets), UNICODE conversions and also some basic template classes made mostly obsolete now that STL is starting to actually work in GCC.
* Truly multiple platform. The application above was ported to Windows in about a day, all of the problems related to the fact that Visual C++ understands a different dialect of C++ than most of us are used to and that took some time write around, none of it was Qt specific. The extra thread and I/O classes really helps here as well.
/Mauritz
GlobeCom AB
The downside is that QT is slow, which is because they fake all the high-level UI calls with low-level code. That's how you can run a QT program on the Mac, but with Win32 or Motif look-and-feel.
:-/
The HUGE disadvantage is that QT programs will never be as fast as "real" Mac programs, because all the UI stuff (bitmaps for buttons, for instance) will eat up memory space and disk access time. The other programs get the UI for free.
It's also a practice Apple doesn't like. At all. Remember the Mozilla port?
There's also the danger that OS X will pick up some new feature, like for instance voice-controlled mouse movement to UI elements or whatever. Every program will magically work with them, except for QT-based programs which will just sit there and look stupid until Troll gets around to update their (closed-source!) Mac port.
...as everyone knows that the software with the highest version number is obviously the best.
(Score:-1, Sarcastic)
..make your application interface independant. The idea is to make your program a basic application that can run without a gui. The gui is then a plugin or something. That way you can take one application and write a gui using gtk, QT, win32, whatever you want and never have to rewrite the application. This is how licq works. The licq application is stand alone and you can download interface plugins for it, QT plugins, gtk plugins even command line plugins. This is great for me since QT doesn't run on the platform I use, so I have to use the commandline plugin.
Don't lock yourself into one gui and hope that it will cover all the platforms you need, most of them don't. Allow any kind of gui to work with your program, not only is it more cross platform compatible, but other people can create guis for your application without ever have to touch the applications code.
Outdoor digital photography, mostly in New Engl
Both libraries you mentioned have their disadvantages (one isn't always free and isn't normal C++, the other doesn't exactly have the best windoze support), but IMHO, FLTK and FOX both seem to avoid these pitfalls. Both support windoze and unixy platforms with X. FOX is capable of doing more things, but FLTK is as fast a heck.
______________________________________
Ever notice how fast Windows runs? Neither did I...
As your're searching for a "GUI Toolkit for our Computational Modeling Toolkit" I guess you'll need also OpenGL support for your app. I'm doing crossplattform computer graphics together with OpenGL and I'm very satisfied with QT's OpenGL support. I also want to underline the high quality in terms of stability, consistency and documentation of the QT toolkit.
GLUT, the widely used cross-platform wrapper for OpenGL, has problems when used in a multi-window application, and those problems affect GLOW programs. I've been documenting the problems and sending them to the current maintainer of GLUT, and they may eventually get fixed. Supported platforms are Win32 and X.
These alternatives are only useful if you're writing a 3D application. Otherwise, use one of the 2D toolkits.
Something to keep in mind even though it's still in it's very early stages... IBM is behind a new Java API for GUI's called SWT (Standard widget toolkit). In a nutshell, it's sort of a combo of AWT and Swing. It uses mostly native widgets (like AWT) for better performance, memory footprint, and native L&F... but also makes use of emulated widgets (like Swing) for the occasions when a particular peered component may not exist on a given platform.
More info on SWT can be found at the Eclipse website as well as a good intro article here. Right now it supports Win32 MFC as well as (somewhat ugly) Motif for Linux, but Qt and GTK ports are being worked on. As always with Java, portability is a strong consideration, and the hope is that an app written with SWT will work on a wide variety of platforms and native toolkits.
QT is clearly superior. If you can get your
company to pay for it, use it. This would be
good for two reasons: you'd get a clearly
superior toolkit that would give you a much
cleaner and shorter development cycle and you
would send troll tech some support for their
excellent work. (What they've done for the Linux
community by writing QT is immesurable.)
As far as my take on the gnome/kde holy war, I
think the above paragraph speaks for itself.
There is no substitute for coherent design. QT
has it, GTK-- doesn't.
I think Qt comes out ahead on the free/licensing issue; if you want to use it for free software, then Qt is GPL'd, but if you want to use it for commercial software you need to buy a licence - but most importantly that also brings you commercial support. In either case you have the source so that you can fix bugs or figure things out for yourself, but if you're working on a commercial project and under deadline pressure it's nice to have that commercial support available.
Now that we have been using Gtk--, we have relatively few regrets. The documentation was poor, for a time, but they have semi-recently improved the documentation, and it is quite workable. There are some small things that you would think would be done differently, but overall they are very minor and easy to live with.
Since we aren't concerned (yet) with porting our software, that wasn't much of an issue. Of course, your situation may be different there.
Finally, echoing what other people have said here, Gtk-- can be quite low level at times. I would recommend that if you decide upon Gtk--, you do what our company has done. We created our own set of libraries that provide standard looks to things with minimal hassle, derived from the Gtk-- classes. An example of this would be windows. We have our own window class that sets up standard options that Gtk-- allows to vary considerably. (Additionally, it automatically checks for certain keystrokes, like the F1 key, and signals that fact.) Making a button class would be similar, so all of your buttons are approximately the same size, have the same shading, etc. We were late in figuring this out, but it has greatly simplified our code and made our program look much more consistent.
People complain already about Mozillas lack of speed. You cant use XUL, its just too slow, if its slow on Mozilla and Komodo its going to be slow on anything else.
ITs a good idea, but its not practical, Java would be more practical than that.
If you use Linux, please help development of Autopac
SPEED.
If you want apps that run slow, You are better off using Java than Mozilla, while java is slow, at least a fast virtual machine will make java seem fast.
XUL is slow no matter how fast the comp is you are running on.
Lets just say XUL sucks.
If you use Linux, please help development of Autopac
> The downside is that QT is slow,
No, in fact, quite the opposite is true. It'd be faster than solutions that simply wrap around native API calls.
It is like in the Java world between AWT (Java 1.0.x) and Swing (Java 1.2.x). AWT tried to simply wrap around the native toolkits. As a result, it was quite slow. Swing does it like Qt, and provided an API for drawing widgets, much like Qt does with QStyle.
> eat up memory space and disk access time.
I think they alleviated this by using QPixmapCache. It should be only a tad bit slower, if not the same speed as regular OSX apps. Either way, an user would not know the difference in speed.
Abiword is cross platform application using native widgets (GTK on Unix). You might want to have a look at how they did it. They must have sorted out cross platform printing as well and some other none GUI issues.
One thing I don't know is how QT works in terms of different GUI threads, but I neither know for GTK.
The Qt docs have a note on threading here. From the page: In Qt, one thread is always the event thread - that is, the thread that pulls events from the window system and dispatches them to widgets. The static method QThread::postEvent posts events from threads other than the event thread. The event thread is woken up and the event delivered from within the event thread just as a normal window system event is.
Personally, I have found that the QThread implementation is a piece of cake to work with. It's a very nice abstraction away from the syntactic ugliness of pthreads.
Al Stevens provides a column in Dr Dobbs Journal titled "C Programming". In the Sept-Oct 2001 columns he described issues he ran into testing both the Qt and GTK-- class libraries. I do not have the articles here but Al gave some pretty good C++ aesthetical reasons for staying away from Qt. Specifically he mentions having to re-compile some of the Qt libraries so that he could extent their class to properly convert from a STL String to their Qt string class.
He had many other reasons for not using Qt. When I get back to work from this long holiday I will post an outline of his specific reasonings.
Just to clarify. I am not an Al Stevens "fan". The man really seems off his rocker sometimes. However, the articles on Qt and GTK-- were very informative. And yes, I did investigate a few of the items for myself. (Do not trust my word though, get the article, read the article, try it out for yourself!)
"A sample size of one is really just statistical masturbation."
GTK
QT
Post Comment Lameness filter encountered. Post aborted! Reason: Don't use so many caps. It's like YELLING.
Bush's education improvements were
Gtk on Windows... well, I have difficulty imagining users accepting it, even with the Redmond/Raleigh/whatever theme enabled.
In contrast, wxWindows uses native controls. This means it will follow the look and feel of the desktop.
Native look and feel can make a suprising difference in the acceptability of a product.
The FLTK web site is http://www.fltk.org/.
I print, therefore I am.
That contamination is one aspect to watch out for. Start commercial, or stay free. You just can never change your mind
Actually, this is one point where Qt comes out way behind. Gtk++ is LGPL, which frees you to build commercial apps using it with no cost. Qt has a very infectious license where if you at any time use a free version of Qt on your project, then you can never release your project commercially.
And Trolltech dismisses shareware completely. They consider it to not be a viable approach, and so Qt can't be used for it.
It hasn't even been settled yet, which is better: emacs or vi. And you're worrying about GUI libraries?
Not True !
The AWT was much _much_ faster than Swing ! Swing effectively uses low level AWT code (drawing routines) to draw its own platform independent widgets, called "lightweight" components [ because they dont use native "heavyweight" peers ]. If you've ever used swing, you'll know its a dog!
The moving cursor writes, and having written, blinks on.
Others wrote there are other toolkits as well but IMO they are nowhere near the usability of Qt. The often mentioned wxWindows is a wrapper around native widgets meaning that things like widget alingment issues become a pain in the butt as each platform will have widgets drawn in their native size. Also widget toolkits that wrap native widgets are diffucult to extend (by class derivation) so if you need to create your EnhancedComboBox from their ComboBox it's sometimes difficult to accomplish with wrapping toolkits. Personally I think going with an emulating toolkit is better than using a wrapping toolkit (fewer headaches). If you don't agree think for a minute why Swing in Java is considered an improvement over AWT. Same reasons.
FLTK is sweet if you don't need advanced widgets and i18n. They finally got their issues with keyboard focus fixed so it begins to look more and more like a real alternative. However, they use char* for text handling all over the place so it's certainly a disadvantage if you need unicode support. However, it is small and it is fast but it's only good enough for simple UIs.
You can't go wrong with Qt it gives you the power of something like MFC in a more digestible form with cross platform portability to boot! Also the sheer number of widgets available for it is pretty amazing. Oh, and the slot/signal thing isn't half as bad as some people here make it out to be.
1 vote for QT here.
Your pizza just the way you ought to have it.
If we could add more detailed features to this grid, it could become a useful summary.
-I like my women like I like my tea: green-
If you are developing non-GPL'd, commercial software, then the fact that you have to pay for Qt is not the worst problem.
The worst problem is that it locks you in to Trolltech as your only vendor for your UI toolkit. No one is is allowed to fork the version of Qt required for commercial apps (at the moment it happens to be the same as the open version of Qt, but there is no guarantee it will continue to be).
Being locked in like that tends to negate the whole reason for going with Linux in the first place. It not only costs you money, but it limits your freedom, and puts you back on the upgrade treadmill.
You are better to go with GTK, which is completely open source (LGPL), even if you are building commercial apps.
Or, if you prefer C++, look at using the Mozilla libraries, which have also been released under the LGPL license (as well as the MPL, and GPL licenses).
A lot of people seem to have missed that the question was asking for opinions on GTK-- (now gtkmm), not GTK+. The difference being that gtkmm is the C++ interface to GTK+, so no C vs C++ dilemma exists here - both are C++.
Well, nearly. If you're from a standard C++ background (as I am), you will find gtkmm preferable, as they don't reinvent parts of the standard library (eg QList vs std::list), they use namespaces and templates (including giving familiar, STL-style interfaces to container widgets etc), and it's implemented entirely in C++ (whereas Qt is in a C++ like language that must be first preprocessed to produce C++).
But, as someone before me said; get both, try them, see which you prefer - there are obviously people who disagree with me, as KDE and Qt are popular.
Mozilla's XP (Cross Platform) Toolkit would seem to fit your needs.
Mozilla's XPToolkit is:
- Written in C++.
- Cross platform (Windows, Linux, Solaris, MaxOS, and others).
- Open Source and free of charge.
- LGPL'd - You can link it and distribute it with binary-only applications.
- High quality.
For proof of the last point, try running Netscape 6.2 on Windows, or Mozilla 0.9.x on Linux.
Swing was initially much slower than AWT. However, as optimizations were made, it became almost as fast as AWT. If you have used a modern java, you'd know this :)
> Qt has a very infectious license where if you at any time use a free version of Qt on your project, then you can never release your project commercially.
Huh, what FUD. Qt has nothing of the sort.
> And Trolltech dismisses shareware completely. They consider it to not be a viable approach, and so Qt can't be used for it.
No they don't. If you have a commercial license, you can sell as much properitary, close source shareware as you want. If you use free Qt, you can sell as much of open sourced shareware as you want.
That's complete bullshit. Qt's commercial license has no clause like that. Only Qt's educational program has something like that, and no one is talking about that here.
Go away, troll.
I was examining cross platform GUIs a couple years ago, and gave wxWindows a try; it's ugly (full of arbitrary little macros) and, as the subject says, when I installed it and tried their example programs, some either failed to compile (or more likely) failed to work (my memory is unclear). Overall my impression was that it was a mess. Now, that was 2 or more years ago, but I haven't heard much about wxWindows since. We went with Qt, and it's clean & fast; I prefer it even to MFC (which admittedly may not be saying much).
Someday we'll all be negroes
[disclaimer: my real email address is @wxwindows.org]
> Not supprisingly we've come up with two choices,
> GTK-- and QT.
This surely is surprizing to me. I wouldn't consider GTK-- a serious choice for writing Win32 programs - sure, it "works", but have you seen it and/or used any GTK+ programs under Windows? But I would consider FOX, FLTK and wxWindows as serious contenders to Qt.
I can't speak of the others but let's compare wxWindows and Qt:
1. wxWin has almost all of the features Qt has
(it doesn't have some, but then it has some extras)
2. wxWin is free (as in beer too) for all uses
3. wxWin has native LNF, even under Windows XP
(which can be a serious advantage if you
target this platform).
But try it for yourself - wxWindows 2.3.2 is scheduled for Dec, 2 and has quite a few interesting new features. And see www.wxwindows.org for more info.
GTK:
GTK
QT:
QT
Excellent QT Tutorial
wxWindows:
wxWindows
wxPython
Mozilla:
Mozilla
Cross-platform implementation of COM
develop your UI's in an XML dialect called XUL
Others:
FLTK
Fox Toolkit
Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page
I needed this list for my own use. Maybe it will be of interest to you.
Bush's education improvements were
You are talking about something that 2 years old... I work every day with wxWindows and it rocks... There is very few bugs, it's fast, it's native, very good documentation... and it's on the lgpl.
That's what I do for a living, and you're quite daft if you think Swing is faster than AWT...
AWT's problems have nothing to do with execution speed, and everything to do with trying to stick one shoe on everyone's foot without chopping off toes...
Damn Java trolls and their karma.
I've been working on a Voice-over-IP research prototype during almost the whole last year. I had been using Qt up to then and decided to switch to GTK-- mainly because it doesn't need a meta compiler as Qt does.
Frankly, that decision was a mistake (I'm not speaking of GTK+ here, no flame intended). Gtk--'s documentation is far from being complete, or even up to date. I had massive problems with threading, too (Especially thread termination behaved very odd at times). Furthermore, some of the cooler widgets from GTK+ were missing, ie. you'd have to roll your own wrapper class for those..
If the choice is restricted to using Qt or GTK--, go for Qt.
You know this is just one kind of crap that is really killing slashdot. There is nothing trollish about this post. If someone's opinions differ from yours, that doesn't make them a troll. If someone's experiences don't favor your favorite toolkit, that doesn't make them a troll. Read the moderator guidelines or, if you can't, go into your user preferences and remove yourself from moderator participation.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
unbiased moderation! three cheers for slashdot dumb-fucks!
To pick up your point on licensing, Qt is either GPL or pay.
Heck, Qt is either X11 or pay. If you use the free version of Qt, you need to install Cygwin/XFree86 on all Windows machines that deploy your app.
Will I retire or break 10K?
FLTK -- cross-platform, C++ gui, and it works: 'nuf said.
The biggest trick the devil pulled was letting lawyers become politicians so they can write the laws.
no, I said that the diffence in speed between Swing and AWT can't be felt anymore.
This is my first look qt QT and based on the comments here, it is obviously the way to go for cross platform GUI development.
Now, I have my love with Perl too and I'm trying to find the latest Perl QT binding but couldn't find one! All I have found is PerlQT which really stopped 4 years ago. Is there no interest for this?
> > The downside is that QT is slow,
> No, in fact, quite the opposite is true. It'd
> be faster than solutions that simply wrap
> around native API calls.
The difference can be felt in memory consumption and rendering glitches and a reduction in responsiveness...
There's nothing wrong with the theory of Swing, but they still need to hammer on the implementation...
Ever try to compile large non=Qt C++ code in HP/UX with quite broken compilers?
Easy.
Will I retire or break 10K?
It is a officially supported first-rate platform being developed in the main Gtk+ CVS tree.
got drum'n'bass?
http://mp3.com/vitriolix
The Ask Slashdot was for QT versus GTK--, not GTK. From http://gtkmm.sourceforge.net/:
Just FYI.
It's very cross platform widget set and application frameweork and it's development is pretty advanced.
I have switched from GTK to Qt because the documentation in GTK became exceptionally frustrating to use. Qt's programming model seems to be much better as well.
it also is a cross platform development platform. So it provides cross platform facilities for many activities - file access, sockets, database access
Just MySQL and PostgreSQL, or does it also talk to common proprietary DBMS such as oracle, sybase/mssql, etc?
printing, font handling, Unicode and internationalisation
How big does a distribution have to be to include glyphs for all 50,000 or so Unicode UCS-2 characters?
preference handling, XML support including SVG, various image formats
How much of the price of a Qt license covers the Unisys royalty for a popular "various image format"?
regexps, data and time classes, multimedia classes
Multimedia as in video playback? Is Qt trying to become like the other QT?
Does it handle press/release semantics for keypresses, or just press/repeat? Does it handle joysticks (erm, "industrial control devices")? Does it handle reading mouse motion not limited by the four walls of the screen (necessary for object manipulation in a 3D environment)? Does it handle sound?
Yes, I'm getting into the domain of Allegro or SDL, but only to show that Qt isn't the be-all and end-all of application toolkits.
Will I retire or break 10K?
Heh. I wish I could get that story posted :)
-- spiralx
I thought someone was doing an alternative (to gtk--) C++ gtk wrapper, but I can't find it now.
I've been using GTK in HMI/HCI area as a rapid prototyping tool for military simulators/trainers for over a year now. I've have no complaints and have no plans to stop using it. It's great.
I did have a look at Qt when I started. I wasn't impressed with it. It looks pretty drab and is controlled by one company. What if they go belly up or change the licensing?
FLTK is very lightweight and easy to use. It is used extensively on handheld Linux devices. FLTK1 lacks some functionality that you may need, but FLTK2 is shaping up to be quite complete.
Also, Qt is not the only game in town for commercial toolkits. If you want something commercial, look around. In the past, other commercial toolkits had much better tool support than Qt.
now includes STL compatibility. So basically you can take iterators from the containers that the widgets work, QList for example, on and run them trough an STL algo like, say, sort(), which is pretty sweet.
Now if you'll excuse me I have to get back to my Junkyard Wars marathon.
And awt was slower/had less features on some platforms than others. I distinctly remember awt on MacOS being much slower than on windows, and not even using the System8 Toolbox calls, but rather using very antiquated calls.
Well, sure there is a difference between "designed for" and "ported to" (tho for some "designed for" means "press release for").
GTK 1.x was always portable -- designed so -- because the GDK was an abstraction layer that allowed porting to nearly anything someone had a desire to port onto (win32, framebuffer, whatever). I've used GTK under Python, and while it's slower than native Windows UI, it's more than acceptable for GIMP.
This fellow really needs to prototype some stuff using *each* of the closest candidates. If his schedule does not include time for prototypes, the software will be ready for a code rewrite MUCH sooner than they expect. I do Software QA, and I've seen the effects of rushing a project without proper homework up front. You *always* throw away some code, like it or not...
>However, Gtk2's win32 port will likely remain a very unsupported port.
Opinion presented as fact. There are *many* projects using GTK on Windows... just like there are many Qt projects on Windows. They're just ot very prominent (aside from GIMP).
.. And from what I read on the mailing lists, GTK 2.0 will be "officially supported on Windows (whatever that means), and the rendering rewrite has eliminated that "slow redraw" problem of GTK 1.x.
Cheers..
Both Gtk and Qt look bloated when compared with FLTK. It is LGPL so it can also be used to build commerical applications without additional licensing. Qt on the other hand is GPL for free or commerical license for purchase. And FLTK is a true C++ UI like Qt.
So Qt has one less layer of abstraction, and can be designed to take full use of the OOP facilities of the language. GTK-- is an unholy mess. Inti is the best attempt to wrap it for OOP, but that's still in the alpha stage.
So you can access the flipping databases without worrying about half a million other libraries which are different across each platform. It's a simple multiplatform solution - the vast majority of custom apps these days use databases to story their information.
What kind of a dozy answer is that. You muppet! I can cobble together a full dialog, complete with references to callbacks, in less that three minutes with Designer. It'd take at least 15 to type out all that shit in Vim. Please not, that Vim, unlike Emacs say, is *just* a text editor, and was never supposed to be anything else.
I've no experience here, the only Qt programs I use a lot are Designer and Opera. They certainly feel good, but I haven't noticed the difference.
Does VIM automagically create autoconf/automake files, AUTHOR, CHANGELOG and README files, and automatically add license text to all your files when you create them. Does it have project management facilities. Does it have a built-in debugger and CVS support. No! And why... because it's a flipping text editor!.
Clearly you've never worked in a company before. Time is paramount. People don't have the luxury of trying out several memory management issues - it's gotta be done, and done fast and safely. Even GTK programmers agree Gtk-- got a bit carried away. Look out for the Inti project in the Redhat Advanced Labs for a better option created by disgruntled Gtk-- developers
Depends. Qt is used far more by businesses than GTK (in fact I haven't heard of any commerical app written in GTK, where's the Gnome equivalent of theKompany and Opera - Ximian doesn't count - it's mainly just a UI distro). Part of being a company's product means there's professional and comprehensive documentation, and support also (for a price admittedly), but for a professional product it's the best solutions.
Also don't forget theres's stable versions for almost all Unices, Win32 and MacOSX. Gtk is currently only stable on Unices, and beta on MacOSX and Win32
As it was mentioned before (and many times) GTK+ is coded in C, but is still object oriented. It uses an ad-hoc object system with dynamic typing, single inheritance. It's clean, but it's rather clumsy looking. If it had some kind of pre-processor it would look much nicer... wait! that would be just objective C! Wouldn it be nicer to have implemented gtk in Objective C? Just a random thought..
Try FLTK { www.fltk.org }
You won't be disappointed with the Fast and Light Tool Kit.
For download, go to ftp://ftp.fltk.org
Muchas Gracias, Señor Edward Snowden !
Before you've tried FLTK, you won't know how powerful and intuitive a ToolKit suppose to be.
You can download the ToolKit from ftp://ftp.fltk.org
Muchas Gracias, Señor Edward Snowden !
Emulation doesn't have to be slower. It's not as if the OS widget drawing code uses special hardward acceleration that is not available to user space apps.
Many applications (even applications developed by the OS vendor) have custom widgets that are drawn by the application. If custom widgets can be drawn fast then emulated standard widgets can be drawn fast.
In regards to QT programs never being as fast as 'real' Mac programs because real programs get the UI for free. Well that's false, Mac programs don't get the UI for free, every button created costs memory. Furthermore since QT is a high level toolkit it can save memory through caching (eg of clip regions), and data sharing (eg of string data). Lower level toolkits (Carbon) have less opportunity to benefit from such techniques (the application developer must take care of it).
Regarding QT not being able to benefit from new features on Mac OS X. I can only guess you are not a developer. Qt apps are carbon apps, if Apple introduces new features that all Mac Apps can benefit from then Qt apps can benefit. If a new feature doesn't work on a Qt application then I wouldn't be surprised if it doesn't work on applications that have custom drawn widgets (which is most large apps).
You claim Qt on the Mac is closed source. It is not closed-source in the sense that the full source code is provided. (Note, this doesn't mean it is open source).
In general your criticisms are based on unfounded assumptions and you appear to lack first hand knowledge of developing with Qt on the Mac.
Yes it does. You should at least read the Trolltech FAQs. Check this one on their General FAQ:
Q: Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?
A: No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software. [emphasis added]
Again, no you can't. Check their FAQ on that on the Qt Free FAQ or the one on their non-commercial FAQ. Basically it says that you should either go free or full commercial.
IANAL, but you need to get one to go over the license agreement carefully. Given current and past Trolltech FAQs and statements, and their interpretation of the contracts, you need to tread carefully here. Trolltech's position seems quite clear: start by paying or stay forever free/open.
-- Could you use my software consulting serv
Hello everyone...
:)
I'm working on a PhD at the moment, and I've been trying to build an application which was relatively cross-platform, which essentially needs database and socket support, eventually with some developed UI for administration.
At the moment I'm stuck with Java, which for speed of operation and ease of programming sometimes leaves a lot to be desired. I've also had more than a few issues with making the code operate on different versions of VMs and on different operating systems. Java is not the compatibility panacea that people sometimes make it out to be.
What has been said here, especially with regard to QT's I/O capabilities has been very interesting, and I will investigate further. Many thanks to all of you
I have been meaning to develop a KDE version of my appication parallel to my Java development, and now it seems that this might be the better route. I don't know if it is, but I will research it...
The problem with the most GUI toolkits is that the implemenation is in a programming language.
When you look at a GUI and strip the application functionality, it is "described", not "programmed". Thus, it is best to use a description language, and not a programming language to create GUIs.
The main benefit of this is that you get separation of the GUI and functionality in a very natural way, and also have flexibility to change the GUI without having to touch functionality of the application, thus achieving object-oriented design throughout the GUI.
Toolkit such as Mozilla/XPToolkit/XUL is designed with this in mind, and is cross-platform, so I would recommend it as the toolkit to use.
Also, same applies to Motif with libXmt, but it lacks cross-platform support of Mozilla.
Any other description-language based GUI toolkits out there? Let me know.
Lenny Primak PP-ASEL-IA,Heli
If you were willing to be flexible with language, then I would take a very serious look at Borland's Delphi and Kylix. You'll get a toolkit that's been extremely well-tested and is thoroughly evolved, an extremely fast Pascal compiler that compiles thousand-line apps in literally seconds, a GUI builder, strong use of components, and literally a recompile with no changes to move from Windows to Linux. The one major problem I see here is that Kylix is still is more of a Linux than a Unix app. However, it and its executables ought to run fine really on pretty much any Unix that can run a Linux emulation layer (which includes Solaris, FreeBSD, and a few more). At any rate, if you could deal with the language (which is extremely pleasant to work in if you take the time to learn) and the potential Linux lock-in doesn't bother you tremendously, it would probably be the easiest and fastest development solution you could pursue.
No, it's not. All the free licenses have that. non-commercial, free, educational, etc. Check the TrollTech General FAQ
That, along with the FAQs, statements, etc. from Trolltech's past seem to make it clear. Go check their site yourself. Perhaps have a lawyer check the mentioned Professional and Enterprise Edition licenses and let us know if you're right and Trolltech is wrong.
I'm not trolling, just trying to point out issues with the Qt licenses. If you start with a commercial license and never want to ship shareware with it, or if you start with the proper free license of your project and keep it open-source forever, then it's not bad.
I certainly wouldn't recommend you change from Qt to wxWindows... I do think Qt is technically superior to wx, but there are reasons why you might find wx more appropriate for future projects with different needs. Try installing wxPython and have a look through the demo app - I find this a great way of showing off the features/functionality/look/feel of wxWindows to people, even if all the demo apps are written in Python. You can get a good feel for the way the same apps would look in C++ even if you don't know much about Python.
Pete.
Yes, vim is just a text editor. Which is exactly my point. You have an application for each function you need to do, and thats it. No bloat, no mess.
Why would I want an app to do my Automake/Autoconf stuff? So I can spend days debugging it? So I don't learn anything and become dependant clicking a mouse? Its so easy to click those buttons in Kdevelop when I'm ssh'ing to my application server.
I must admit that I've never used Gtk--, as I don't write code in C++. I have written code with Gtk+ and Gtk-perl, and I found it quite easy and enjoyable.
Sorry to sound like a Java booster,
But you should really take another look at Java and the Swing toolset. Swing is fully MVC-based (well, MV mostly), has good visual builder tools available, is fast (contrary to popular opinion), and has tons of features, and support from a vibrant community of developers.
Unless you're tied to C++, you should strongly consider this, as porting is (virtually) a no-brainer. In fact, even if you need to use C++ for some parts of your system, it is still possible via JNI to tie these in, and write the GUI in Java.
As far as I know, the only GUI toolset that has more features than Swing is Motif, and that's saying a lot since Motif was under development for years and years.
Furthermore, there are tons of decent components (beans) available, both freely and commercially. Also, tons of documentation exists for this platform, most of it of excellent quality due to the nature of javadoc.
You're doing yourself a disservice if you're ruling it out because you (subjectively) consider it to be slow or otherwise unfit for the job.
f u cn rd ths, u r prbbly a lsy spllr.
I don't think anyone here has mentioned Korelib. Korelib is a The Kompany project and currently supports: Linux, FreeBSD, BeOS, AtheOS, and Win32.
It has a signal/slot mechanlism that is similar to what's in Qt, is supports scriping via Python, and supports plugins.
There are lots of things in the world of software development. Lots of languages, lots of miscellaneous helper tools. Lots of IDEs. I've never used automake/autoconf in my development career, and I've never needed to. Hard as it may be for you to believe, autoconf/automake familiarity is neither necessary nor sufficient to be a good software developer, in C++ or any other language.
I get the feeling you'd say that a UNIX sysadmin who wasn't familiar with (and confident enough to modify directly)Personally, I actually do think that WYSIWYG "HTML editors" have a place. I also think applications like Lyx have a place. It's just a shame that at the moment there aren't any standout contenders in the HTML side that focus on generating standards-compliant HTML (at least as far as I know, I'd be happy to be corrected on this point).
As an aside, is there any particular reason you say "my 10 year old female cousin," rather than just "my 10 year old cousin" or "a 10 year old child"? Are you trying to imply that she's doubly disadvantaged in being ten years old and female? Or perhaps even more disadvantaged in that she's your cousin?
I assume you meant to say "GUI toolkit" there... as a statement like "there's no reason to tie SQL into a database toolkit" would seem more than a little bit senseless.Hard as this (again) may be for you to believe, but Qt is not just a GUI toolkit. GUI stuff is a large part of it, but not the only part. I mentioned in another comment that I know of one app, Doxygen, that used Qt without using any of the GUI stuff - simply because the author really like the fact that it abstracted the low-level platform-specific stuff so nicely.
I love it when people say something "sucks" and offer absolutely no explanation as to why they think it sucks. Try. Come on, have a go. Tell us why the terrible Qt licensing system sucks. Lots of other people in this topic have at least made an effort (and in the process demonstrated that they don't know what they're talking about), but I'm sure you can do better than them. Um... yeah... I'd like to see you use Quake on a piece of paper.WTF are you babbling about? If you want to restrict yourself to using a text environment, do so. Nothing stopping you. Of course, if you're supposed to be developing a GUI application, you might not be able to test it at all, but I'm sure that doesn't matter for someone like you.
Gee. A whole "nickle". Thanks.Pete.
Just choose one and fly with it. I like C so I use GTK. It has a wrapper for C++ and extensions for perl, fortran, and etc. GTKPerl. QT is also nice but I think your limited to using C++. Don't quote me on that statement. I got this from a friend, read it, its funny. I don't really know if its true or not. Heres the link. http://www.geocities.com/jss1228us/cplusplus.html
GTK has Glade, which will develop the UI, and export the code in a variety of formats. Furthermore, with use of libglade, one can alter the UI without recompiling. Since I don't use Qt, I cannot say if it has something similar.
As far as code writing, I've found that with glade, I basically just write my back end.
Personally, if I were a C+fuss nut, I'd just use wxWindows. IMO, though, I think the question is more appropriately GNOME vs. Qt, but that is just MO.
My Suburban burns less gasoline than your Prius.
Please mod parent UP, and mod grandparent down. mughi's original comment was unjustly robbed of karma. QT's strange licensing restrictions need to be brought to light.
Sig goes here
C++ is a language. Being a language, it doesn't *do* anything, let alone preprocess something. C++ compilers do contain preprocessors, though, if that was your point.
uhh, that was valid a few years ago, but not now.
Or not...
Gtk+ is actually much more organised and beautiful than many other toolkits I've seen in my day. It is well maintained, and the object-oriented design on top of C is actually quite consistient throughout. Standards such as using g_ for prefixing Glib calls, gtk_ for Gtk+ calls, gdk_ for Gdk calls, and Gtk for Gtk+ datatypes (the same for Gdk, but just a 'g' for Glib) help keep things organised.
The signal and callback model of Gtk+ is also a winner, in my opinion. Using gtk_signal_func() to attach a function to a widget when a given signal is emitted also keeps things organised.
On the other hand, Gtk+ programs generally take a few more lines to write than Qt apps. Even so, even the simplest of Qt 'hello world' programs outweighs one of Gtk+ by many kilobytes of RAM.
Although Gtk+ isn't quite as cross-platform as Qt (Gtk+ makes it possible using the Gdk layer), Gtk+ is still a definant winner in my opinion, in terms of performance, stability, and consistiency.
Then again...Photon isn't that bad... ;)
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
Well, that is currently on their website, and not hidden either. They reference all other FAQ's there, and still have it as-is. Their FAQ's were even reved just this past mid-July and then late-September, so there's no excuse on their part. (Oh, and their GPL faq also includes the no-shareware mention)
If TrollTech has changed their position (and not just made an exception here or there), then the burden is on them to 1) Change their FAQ's that state all this (non-free and no-shareware), and 2) actually put the commercial licenses somewhere that they can be easily accessed.
If they have changed their terms, then at the least this looks like scare tatics on the part of marketing to try to get more developers to cough up the per-seat licensing.
1). It's not in the FAQ in their souce code.
2). It's not enforced. I know of several apps that this case has happened with. For example, Quanta Plus->Quanta Gold, KDE Studio->KDE Studio Gold, Pixie->Pixie Plus.
So, I think that this is probably an honest mistake on their part for leaving it up in their general FAQ (it belongs in their academic licenseing FAQ).
Allegro and SDL aren't application toolkits.
SDL may not be (doesn't even have drawing primitives), but Allegro is much closer, provided that the application falls into the 2D or 3D multimedia domain. For example, Allegro includes its own Unicode implementation and its own file access API (to allow transparent use of compressed datafiles). It also has a wealth of addon libraries including AllegroGL for hardware accelerated graphics. Check it out.
Will I retire or break 10K?
Heard of Qt non-commercial on windows?
Will I retire or break 10K?
5. Sit in front of you machine, waiting for gcc taking minutes to compile even simple and small sources.
6. See you shared loader producing bus errors on several "valid" executables compiled by gcc
7. Ask your third party software vendor to supply a gcc compiled version of the library you are desperately needing.
8. Compare the speed of the executables compiled with aCC and gcc; start crying.