KDE project is planning on announcing QtGTK library which was written by one of its core developers. The library integrates Qt event loop with GNOME. Thanks to that whole KDE framework can be used from any GTK+ application just like it would be a native part of it. The library itself is already available here. There seems to be also a tutorial on how to use it here. Reportedly Gimp already works with it.
Integrating KDE in GNOME Applications
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
What about the license?
If I wanna write a gtk application with those libraries, Can’t I keep it close source, Or do I have to pay a license?
The proof is in the pudding. Where are the screenshots?
What does this mean for the end-user?
I don’t think this is just themeing. This is more like an api integration. GTK+ uses signals and callbacks, and i’m pretty sure KDE uses a different system. More like the harvesting events technique (like X), if i remember correctly. So this library is probably much more substantial than themeing.
Very cool, but i’m not sure how useful this will be (realistically speaking) – i mean, cross-desktop is great, but will it actually be done that much (seems like WAY too many dependencies and such). Maybe a common configuration editor could use this.
I don’t care what anyone says, or what distro we talk about.. The fact is Microsoft and Apple have both been in the “Game” for 30+ years and yet Apple is being out installed by Linux and MS with 50 Billion in the bank spends more time and money worrying about Linux then it does making better products to counter Linux.
That says a lot about the quality and innovation of Linux and Open Source!
And you can say “Windows is more stable and has more software!” Well it should it’s got a 20 year head start on Linux yet it still has no better features in it then Lindows or Xandros at this point. And once more vendors start making apps for Linux it’s all over! (By vendors I mean Adobe, Macromedia and MS it’s self!)
So tell me? Besides more apps and games what makes Windows better? More drivers? Please!
Show me one application, one idea (Besides putting Windows on cheap computers) that Microsoft came up with first??
ONE?
I would think that the proof is the source code…
Seriously, though, this is pretty spiffy. Between this and the native-Qt GTK theme, applications like Gimp should integrate pretty nicely into the KDE desktop. Certainly, the UI in these apps are specialized enough that they won’t feel a whole lot like regular KDE apps anyway. I mean, as of 6.0 anyway, Photoshop doesn’t exactly look/feel a whole lot like a regular Windows app.
I’m so glad that the Windows developers decided to stick with one solid, proven toolkit instead of mucking around with this unification stuff. Can you imagine developers at a company refusing to work together like GNOME and KDE? No! I want to put the desktop in ~/.desktop, no I want to put the icons in /opt/local/X11/usr/share/KDE! Maybe it’s time the developers set aside their pride, and stop acting like immature kids fighting over a piece of stale bread, and work together for a common good.
People, people READ! This is not about look of the applications. This is about using KDE libraries/dialogs/frameworks in GNOME applications. It was considered impossible, this library proves otherwise.
So, it allows one to use the KDE frameworks from Gtk…what does this mean? If Gimp is using it, what does that look like? Or does it look any different at all? Details would be nice.
Can you imagine developers at a company refusing to work together like GNOME and KDE? No! I want to put the desktop in ~/.desktop
Recent versions of Gnome and KDE now use the same Desktop folder and the same Desktop icon specifications. There are plenty of other areas where Gnome and KDE are collaborating.
Since you seem like you’ll be trolling these threads for a while, let me be the first to direct you to
http://freedesktop.org
where you can learn all about the growing collaboration between KDE and Gnome developers.
By the way, /opt/local/X11/usr/share/KDE is not a real directory. You should learn more about Linux before criticizing it every chance you get.
It is a wrong direction. The biggest problem with KDE is the Qt and it’s license. And the commercial Qt is too expensive: the M$ Visual Studio pofessional is cheaper (and far better) then Qt profressional. Because GTK is totally free, IMHO the GTK based QT compatible lib is a better idea then Qt based GTK.
Theres a lot of posts here that just arn’t very clear. Let me give it a try:
This appears to be a library that, when included in the code, alows someone making a GTK app to impliment some intigration with QT as well, such as calling KDE dialogs when its running on KDE desktops.
Quote from that linked tutorial:
Introduction
Historically a choice between KDE and GNOME frameworks has been a permanent one for application developers. People were lead to believe that using functionality of one toolkit while using the event loop of the other is impossible. So even though many GNOME developers would love to integrate their applications more closely with KDE by using our native dialogs it was simply impossible. Up till now…
Integration
We wanted make the life of the developers who think about integrating with KDE more closely a lot easier. The basic goals of the whole undertaking were:
* make is incredibly simple to integrate Qt event loop into a GTK+ application for the application authors
* make it possible for developers to start incrementally switching GTK+/GNOME applications to Qt/KDE without loosing any functionality
We achieved those goals with a trivial implementation of a GSource which integrates Qt event loop into Glib event loop.
@Anonymous: I realize that you’re just a troll, but I don’t want anyone to get the wrong idea. Which “solid, proven toolkit” would be be talking about on Windows? The MFC one? The Microsoft Office one? The common controls one? The .NET one? On HP machines, you can now add the ported Aqua iTunes one.
But why do people think Windows uses a single toolkit?
…wait for it…wait for it…
Because they look the same!!! OMG! So you mean, like, this “integration” stuff is what MS has had to do all along? Naw, can’t be…
@LC: Are you a programmer by any chance? Because most software houses spend a whole lot more than that on tools. You need copies of Perforce ($500 apiece) or ClearCase (your first born child apiece). Then factor in copies of Rational Rose (several thousand apiece), as well as visual Studio ($1000 apiece), and you’ve dwarfed the cost of Qt licenses. And Qt has nothing to do with Visual Studio. The former is a toolkit, and the latter is an IDE.
Was just wondering….isn’t it surprising that this is coming out after UserLinux’s decision to go with Gnome ?
> Where are the screenshots?
Ask Eugenia, she did this “pre-announcement”. The KDE announcement will have screenshots.
I think it would be nice if they (or someone else) would also come up with a very low-level interface for dialogs, independent on the toolkit used, a bit like the ‘cdialog’ for text-based dialogs works. Sort of a ‘any-gui’.
This would be very simple to do for at least simple yes/no kind of dialogs, file selectors, etc, for example:
result = ExecYesNoDlg( “Do you want to quit?” );
if ( result == 0 ) quit();
Then, this could be expanded with a wiki-like dialog specification language, like for example:
| Enter name and address |
| — |
| name|StringInput |
| age|NumberInput |
| — |
| Ok : Button | Cancel : Button |
This way, you could make a large part of dialogs used in your applications toolkit independent.
And you can say “Windows is more stable and has more software!” Well it should it’s got a 20 year head start on Linux
Isn’t that a bit exaggerated? Say Windows started in the early ’80s, Linux in 1990, maybe some years later when you talk about DE’s.
I would think of a 10 year head start?
And then I think *I* am still exaggerating, but I’m not positively sure about all those numbers, one could argue I guess.
Hopefully this means that stuff like kde kioslaves can be used in gtk apps.
Besides if u run gtk apps from the kde environment and it they can use kde dialogs and other stuff it provides for a nice and consistent desktop
.
>If I wanna write a gtk application with those libraries,
>Can’t I keep it close source, Or do I have to pay a license?
You have 2 choices.
1. GPL the application.
2. Buy a license from Trolltech.
Ok guys maybe this is a bit offtopic bu seing Gimp in the title made me remind you all that the Gimp 2.0 final is going to be released in a few weeks. Check about this on gnome-i18n mailing list. It was post yesterday!
Cheers…
is here: http://dot.kde.org/1073599985/
and here:
http://dot.kde.org/1073557624/
screenshots included
Actually, that’s not related at all. The links you gave point to a GTK theme that uses QT to draw its widgets and a OOO version that uses QT to draw its widgets.
AFAIU, it’s totally unrelated to this gtk-qt lib, whose aim is to let you use QT dialogs from within a GTK app.
Of course, combining the GTK-QT theme engine AND this gtk-qt library would be a good idea to get KDE-integrated GTK apps.
> 1. GPL the application.
> 2. Buy a license from Trolltech.
Not at all. The QT libraries are provided with a *double* license, and you can chose which one to use: GPL or QPL. QPL allows for linking with the library without any extra requirements.
Read points 4, 5 and 6 of the QPL.
> […] without any extra requirements…
… other than distributing the sources of the application. So, no closed source SW can use the free QT, but it doesn’t have to be GPL’d either.
1. Commercial per developer etc $$$
2. QPL (Qt Public Licence) which RMS & similar thought was not sufficient so:
3. GPL, the full one, not the LGPL like GTK. (eg: no non-open-source commercial software, for that pay Qt)
Now, My opinion: Qt is a much better model, and Is it really so hard to see why commercial apps want to use GTK? LGPL anyone (Sun and others)? LGPL plays very nicely with proprietary software development. GPL doesn’t.
The license of the QtGTK library is LGPL, so your GTK app can use KDE dialogs, no matter what license you use for it.
Everytime Qt/KDE are mentioned here on OSNEWS, some people start to argue that Qt has to be LGPL or people wont use it.
The long term goal of the FSF and the GNU project is, to provide a completely free operating system. Richard Stallmann himself says, that the GPL is the better licence to archieve this goal.
For companies, the LGPL may be better because they can use LGPL’ed libraries and do not have to give back the source code to the community. But is this what we really want? Does this help to create a completely free operating system? Does this, in the long term, help the Linux and OSS community? In my opinion, it doesn’t.
One may see the dual licensing of Qt this way: if you write GPL applications, everything is fine. If you don’t do so, you are punished and have to pay a fee to Trolltech. This encourages people to write OSS apps and this, in my opinion, is a very good thing. I don’t like closed source applications for Linux, because if I would like to have that, I can just stay with Windows or use MacOS X. I don’ prefer Linux to Windows or MacOS X because it is technically that much better (it probably isn’t), I prefer it, because it is free and I want it to stay free.
By the way, when I worked at Siemens, everyone in our department used JBuilder professional, which is probably about $1000. Big companies ARE buying expensive tools to develop their software. They will use a toolkit if it allows them to develop applications more rappidly, not because it is free, because developers are much more expensive then toolkits or IDEs or whatsoever.
Ok, I take it back, you have 3 options. Apart from the 2 I gave, you can:
3. QPL the application
Read the QPL license, seems somewhat similar to GPL.
Among others, section 4b statest that any recipients of the “executable” library(Qt) must also be able to get the source code.
Section 6b states that anyone who gets an executable built on top of that, must also get the source code of that.
So no closed sourced apps.
“You must explicitly license all recipients of your items to use and re-distribute original and modified versions of the items in both machine-executable and source code forms. The recipients must be able to do so without any charges whatsoever, and they must be able to re-distribute to anyone they choose.”
>The license of the QtGTK library is LGPL, so your GTK app can
>use KDE dialogs, no matter what license you use for it.
No. You still link with Qt, so its license applies.
Do you think that because QtGTK itself is LGPL, it automagically removes the license of Qt ?(or any other library you link with for that matter)
This sort of solves the problem of outdated gtk file chooser dialog
Now an application can have the overhead of needing two huge application frameworks instead of one. It’s a good thing we have fast processors now to keep up with the BLOAT.
Well you could point at when MS started putting out Windows as 1983, but then you would have to take away the work done on OS2, and DOS.
(Also remember Linux started as a hobby while Windows has always been a business and always had investment from companies like IBM)
SO I guess 20 years was a stretch but I was really looking at when Linux became a business (Which was the end of the 90’s)
The biggest problem is the price. Visual Studio 2003 prof. is about $700, Qt Professional is $1660, but if you want to write multiplatform application you need dual ($2490) or trial($3320) license.
Qt is relative good thing but only a little toy if you compare it to V$2k3. Yes, Qt is multiplatform, but the most of profit comes from windows.
that would rock!!!
“Everytime Qt/KDE are mentioned here on OSNEWS, some people start to argue that Qt has to be LGPL or people wont use it.”
Yes, but that statement is wrong anyway. It looks those people have no expierience as ISV, and they shouldn’t make assumptions about what ISVs want or should use. Most ISV choose Qt and not GTK+. That tells something.
“Big companies ARE buying expensive tools to develop their software. ”
They do so because those expensive tools reduce their total development costs. The software licenses are usually just a tiny part of the total costs.
@Arend
Sort of a ‘any-gui’.
Your plan for a ‘low-level’ ‘any-gui’ seems destined to failure. While it might provide a few advantages to the current system, the disadvantages it will have will far outweigh them, even if many programmers don’t realise this and end up adopting it.
The problem with your plan is that it won’t have a native feel on any platform but the one the designer used. Compare, for instance, six GUIs: Mac OS X, classic MacOS, NeXTSTEP/GNUStep, ROX, Windows, Gnome. The first three have many similarities, which is not suprising given the close relationship; the first and last have similarities; the last two have similarities. However, all of them have differences. Consider just for a moment menus: the MacOSes and *Steps have a single, application-wide menu; Windows and Gnome have window-wide menus; ROX only has context (popup) menus. But you can divide the differences even more: Because the *Steps have application-wide menus, they become relatively application- (rather than window-) centric. Because ROX only has context menus, the programs have to be relatively light.
I could go on, and plan to elsewhere if no-one else has (though I admit much ignorance to the way Qt works). The only way you’ll be able to have something cross-platform without recoding for each platform is to have an extremely high-level language. (Preferably, the language—which would be for UIs alone—would be so high-level that it’d support console/textmode apps, and an enduser could even change the libraries and come up with a UI that was totally unthought-of before, for free (and, of course, all their applications would convert over to it).)
If you are running KDE, you already have qt and kde loaded. There is no bloat at all.
So think more and stop the FUD.
> 3. QPL the application
That’s an option, it’s not a requirement. QPL is an as valid license as any other license as _any other one_, provided that you give the source code of your app to whoever’s got the binary.
> Read the QPL license, seems somewhat similar to GPL.
Similar, but not equal. For example, LGPL is a perfectly good license for your program/library if you want to link it against QT, you can’t mix, however, GPL with LGPL.
>> 3. QPL the application
>That’s an option, it’s not a requirement. QPL is an as valid
>license as any other license as _any other one_, provided
>that you give the source code of your app to whoever’s got
>the binary.
So we agree. I said you have 3 options. Put an OR between them, or an AND if you like(to dual/triple/etc license it)
>> Read the QPL license, seems somewhat similar to GPL.
>Similar, but not equal. For example, LGPL is a perfectly
>good license for your program/library if you want to link
>it against QT, you can’t mix, however, GPL with LGPL.
And we agree again. I said “similar”, you said “similar”. None said “equal”.
Just remember that any GPL compatible license + GPL equals GPL. That is, for the resulting binary, GPL applies. Not for the source-distribution of individual components.
Great Idea and a cool Project
But as usual, the trolls, ‘geeks’ and other specialists in this Forum don’t seem to understand what it’s all about.
With this, the gtk qt theme and OOo’s similar qt theme announced today, all your apps will look like KDE apps.
Not exactly _feel_ like KDE apps, though, but it’s a step forward if you are a KDE user.
You have 2 choices.
1. GPL the application.
2. Buy a license from Trolltech
That sucks, pay $2000 for using the KDE dialogs?
No thanks.
That sucks, pay $2000 for using the KDE dialogs?
If you develop and sell closed application you either use GTK in which case the preferred desktop would be GNOME anyway. Or you use Qt in which case you already should have paid for the license. I don’t see a point for bitching about imaginary “problems”.
But as usual, the trolls, ‘geeks’ and other specialists in this Forum don’t seem to understand what it’s all about.
>>>> <<<<<
Well, it’s just the usual OSnews thing <<I don’t know what I am talking about, but I say it nevertheless>>
It’s not only in the forums : I remember titles of news, which were calls to trolls totally unrelated to the article, like this one http://osnews.com/comment.php?news_id=4526
I also just read this review of the upcoming Mandrake 10, and I had a good laugh : http://osnews.com/story.php?news_id=5577
– Note that the installer expects names like hda5 while asking for the package location. It won’t understand what C: means.
-Xine is not present and neither is libdvdcss even though there is a package present called xine-plugins.
[Note from me : totem, a front-end to xine was the default media player present]
-KOffice is still very buggy. KWord froze up 2-3 times on opening the same file and just won’t get refreshed. Personally, I think these guys should merge with OO.org.
-Flash plugin is not present and neither is Java. What is the point in putting ton of new features in each version if it can’t do the basic stuff right?
Well, if I only use Qt/KDE apps in KDE then why have an app that has to load GTK as well? The same applies in the reverse. So instead of creating slow, bloated applications that can interoperate with every environment under the sun, choose your platform and write to it. BTW, just becuase you are OK with software that runs slower and slower even though hardware gets faster and faster doesn’t make my opinion about the matter FUD.
http://xaraya.com/~marco/
Even if QtGTK let you use Qt stuff like filedialog, inputbox, etc. I don’t see the benefits of this integration between KDE world and GNOME world.
The results, like this screenshot shows, are really ugly!
>>>> <<<<
I don’t quite follow you here : it’s not an integration between KDE and GNOME, it’s an integration of gtk-only apps into KDE. So, your screenshots in Gnome have no sense.
Ever wanted that Mozilla and OpenOffice.org use the same open dialog box as others, and not their own ?
Plus, there is nothing at freedesktop.org currently to handle this issue
It does because you’ve got a very fuzzy understanding of how all this fits together. There is no runtime performance hit, because its not GTK+ on top of Qt, but rather GTK+ next to Qt:
—————–
| App |
—————–
| GTK | Qt |
—————–
If the app is running on KDE, it calls the KDE file dialogs. If it is running on GNOME, it calls the GTK file dialog. The only overhead is a space overhead, that comes from having both GTK+ and Qt loaded into memory at once. The other poster’s point is that if you are running a GTK+ app in KDE, you already have both GTK+ and Qt loaded! So the only space overhead you have is the sum of the unshared data in the GTK+ and Qt shared libraries, which is minimal.
>BTW, just becuase you are OK with software that runs slower and slower even though hardware gets faster and faster doesn’t make my opinion about the matter FUD.
KDE is getting much faster every release. 3.2 is amazing. So you must be talking about Gnome.
And btw, if I want to use GIMP in KDE, I should not do it because it bloat my system? I should rewrite it in order to use it? Are you out of your mind?
How could this option be bad?
>> Ever wanted that Mozilla and OpenOffice.org use the same open dialog box as others, and not their own ?
That’s the point: IMO no!
Because they’re consistent with themself.
>> Plus, there is nothing at freedesktop.org currently to handle this issue
Because it’s not an issue, qt has its own opendialog and soon gtk will have one.
Since a GTK+ app is a foreign app in KDE who cares if it has the same opendialog as all KDE applications!
Plus consider that the library requires that you modify your GTK application to enable KDE support, so what about distros that ship both KDE and GNOME?
1) the don’t enable kde support in all gtk apps that could use kde api
2) they modify the apps to use kde api if the user is runnig kde or to use gtk in other cases
So where’re the benefits?
Big companies ARE buying expensive tools to develop their software.
When this tools provide a value added or save dev time or dev cost.
When they have another tool to use and it’s free and does the same thing in the same time and allows them to close the source code — they don’t license copies of paied tools.
Why did Sun choosed GTK+ for the “Sun Java Desktop and not Qt ?
Why did HP tought about replacing CDE for Gnome ?
Was it because GTK+ is superior or lighter ?
_________________________________
GTK+ is not that lighter than KDE/Qt and it doesn’t allow the same widget flexibility and is not as complete as Qt.
License restriction apply.
Sorry, but you obviously don’t get it…
Do another screenshot on KDE, load GTK-QT as GTK theme, and the purpose of those two libraries will become pretty obvious (maybe even to you).
What you’ll get:
A GTK application looking like the rest of the KDE desktop using the same dialogs as any other native KDE application.
Maybe diehard Gnomers won’t care about it, but as a user, I don’t care about zealots – I wan’t a nicely integrated Linux desktop, and only the KDE people seem to understand that this is _exactly_ what the user(!) wants.
Maybe diehard Gnomers won’t care about it, but as a user, I don’t care about zealots – I wan’t a nicely integrated Linux desktop, and only the KDE people seem to understand that this is _exactly_ what the user(!) wants.
I couldn’t agree more. Very well said. I’ve been running the GIMP with the GTK-Qt theming engine, and it does look a lot better if you’re using KDE. With the addition of this library, GTK+ programs can just blend in in the KDE environment.
“Why did Sun choosed GTK+ for the “Sun Java Desktop and not Qt ?
Why did HP tought about replacing CDE for Gnome ?
Was it because GTK+ is superior or lighter ?”
Is your agument like if these two companies which are tiny on the desktop made contracts with ximian and thus ship GTK+ and thirty times that many companies (you should take a look at the list at troll techs’ website) choose Qt that GTK+ is superior or lighter? Think.
Why is OSNEWS running so slow today?
@Marco: Since a GTK+ app is a foreign app in KDE who cares if it has the same opendialog as all KDE applications!
——–
KDE users? First, its a matter of consistency. you can make a GTK app look quite a bit like a KDE app using the GtkQt theme, so having the file dialogs the same is natural. Second, and more importantly, you can uniformly use features like KIO in the file dialog, just as you can with your KDE apps. This also opens the way to embedding KParts in GTK+ applications, which further increases consistency.
@Anonymous: Only Sun chose to replace CDE with GNOME, and the did not do it for licensing reasons. $1500 a developer is nothing to Sun. They did it because:
– At the time (before the 2.x transition) GNOME was less mature than KDE. This means that Sun got to have a huge influence (especially in the HIG area) on GNOME 2.x. A lot of the usability research for GNOME was funded and conducted by Sun.
– At the time, KDE wouldn’t build with the native Sun Forte compiler. That means that not only would GCC be required to build KDE, but Sun Forte couldn’t be used to develop any apps that linked to KDE either. Their engineers were also much more comfortable with C over C++.
– The GNOME design utilizes some standard technologies like CORBA, that Sun engineers were already comfortable with. In retrospect, CORBA turned out to be a mistake, because its sheer complexity kept anybody from really using it, but at the time it was a selling point for GNOME, and made it easier for Sun engineers to get used to the code base.
“The problem with your plan is that it won’t have a native feel on any platform but the one the designer used.”
That doesn’t have to be the case. By the way, this idea was not meant to replace the application level GUI. You’re probably right that the menu’s, etc are quite different.
I was more thinking about libraries that might need simple user inputs, like a file selection, a color selection or simple questions that can be answered with “Yes/No”.
And, of course, error handling.
That way, you could write platform independent math libraries, for example, that could still pop-up an error box if something goes wrong.
Furthermore, in my experience an application contains a whole lot more dialogs then main windows with complete menu structures, etc.
Therefore, you could write a large part of an application toolkit independent if you could write the dialogs using a wiki like description language.
You could ‘draw’ a dialog using a simple table-layout, such as the one I showed above. Then, dependent on the toolkit actually used, the dialog could be built up, without ever needing to know what toolkit you use.
Actually, there is already an ‘anygui’ for python:
http://anygui.sourceforge.net/screenshots.php
This requires too much programming in my view, but shows that look@feel can be very different depending on the toolkit used.
“The problem with your plan is that it won’t have a native feel on any platform but the one the designer used.”
That doesn’t have to be the case. By the way, this idea was not meant to replace the application level GUI. You’re probably right that the menu’s, etc are quite different.
I was more thinking about libraries that might need simple user inputs, like a file selection, a color selection or simple questions that can be answered with “Yes/No”.
And, of course, error handling.
That way, you could write platform independent math libraries, for example, that could still pop-up an error box if something goes wrong.
Furthermore, in my experience an application contains a whole lot more dialogs then main windows with complete menu structures, etc.
Therefore, you could write a large part of an application toolkit independent if you could write the dialogs using a wiki like description language.
You could ‘draw’ a dialog using a simple table-layout specification, such as the one I showed above. Then, dependent on the toolkit actually used, the dialog could be built up, without ever needing to know what toolkit you use.
You would probably not be able to get callbacks or event handling, but you would be able to make a dialog, execute it and interpret a returned result.
You would also be able to query the current values in the dialog once it finished.
Actually, there is already an ‘anygui’ for python:
http://anygui.sourceforge.net/screenshots.php
This requires too much programming in my view, but shows that look@feel can be very different depending on the toolkit used underneath.
I think that a common codebase of the two DE underlying libraries(Orbit/DCOP, Gconf/Kxconfig, arts/gstreamer) would be more useful instead of mixing the two toolkits, the look can be merged with a common theme, and different toolkit apps could run with the same libraries
“I’m so glad that the Windows developers decided to stick with one solid, proven toolkit instead of mucking around with this unification stuff.”
Why, exactly? And what choice did Windows developers have, anyway?
“I’m so glad that the Windows developers decided to stick with one solid, proven toolkit instead of mucking around with this unification stuff.”
Can I go to the store, buy a copy of Windows XP Professional and a book on Windows development, install “evertything in the box”, and start writing Windows applications? Last time I looked into this (quite a few years ago,) doing Windows programs with any kind of depth was going to cost me at least $600, which I don’t have (I use that kind of money to pay for essentials like food, cooking/heating fuel, clothes, and shelter.)
Qt is relative good thing but only a little toy if you compare it to V$2k3. Yes, Qt is multiplatform, but the most of profit comes from windows.
Well, I have worked with both and while VS2k3 is nice the C++ api that Qt offers is, at least for me, a whole lot nicer. Microsoft’s C++ APIs have always seemed a bit like hacked C to me.
Look here Hawaiian Chuckle, do you have the skill set to even install WinXP Pro?
So, name-stealer, what you’re saying is that WinXP Pro is harder to install than Linux? Finally, you’re making some sense!
Seriously, how old are you? 12? 13? Grow up already.
Should be : Integrating GTK Applications in KDE
It’s not about Gnome <==> KDE, but GTK==>KDE
Gnome != GTK
Do you mean MFC? There is no *comparison* between MFC and Qt! Qt is like the BeOS C++ API, clean, elegant, and logical. MFC is the most abhorrant mass of C++ ever concieved. Macros everywhere, weird language tricker, unreadable code generation, ugh!
If you develop and sell closed application you either use GTK in which case the preferred desktop would be GNOME anyway. Or you use Qt in which case you already should have paid for the license. I don’t see a point for bitching about imaginary “problems
But if I dont want KDE users bitching about my application using GTK file dialog and I want to please them would take me $2000 for it.
Thats my point.
But if I dont want KDE users bitching about my application using GTK file dialog and I want to please them would take me $2000 for it.
Thats my point.
So? You want to please your paying customers while demanding the necessary tool for free? For you it practically boils down to the question: Is the market of KDE users big enough that the addition of a KDE file dialog is worth an investment of eg. $2000? If not why bother at all?
Are you really a proprietary developer?
Or just a Gnome troll?
Could you please tell what application you have for sale? Or are you just FUDing around?
I am tired of this ridiculous licence discussions.
1) Yes, Qt is GPL, QPL, or for a reasonable fee.
2) No, you can’t sell *proprietary* software using it for free.
3) Yes, it is a very fair business model. The main cost of development is developer time, and it saves a lot of it. Even your time.
4) Get a life and stop complaining about free software getting better. Or go complain about all software in the world *except the one you sell* that is not for free, like Windows, MacOSX, etc…
Here are other “informative” comments by you:
>With the qt kind of license all is useless.
>Gnome > KDE
>I don’t know waht are you talking about, I hate KDE UI and I >love GNOME UI, to me GNOME > KDE.
>Gnome for ever.
Im glad to see how much you all care about me. =)
I think Eugenia purposedly did it. The current title attract more than the other way round. She is very good in doing things like this — making sure many reads her articles.
By the way, this integration is good thing. And to my understanding, at the end KDE user can use GTK application without the need to install GTK itself since GTK support is inside Qt itself.
And I think GTK team should do the same so that more consistent desktop will be available to those who love Gnome but like to use Qt application.
I am uneasy about companies taking the hard work of OSS developers & forking it off Linux onto a proprietary ‘Linux based’ OS.
I am choosing keep my suppport with OSS based Linux’s.
As soon as you go with highly proprietary Linux’s you’re back with the same problems as M$.
ie :
you never now what is the truth of their marketing.
you are beholen to them & their pricing etc.
> at the end KDE user can use GTK application without the need to install GTK itself since GTK support is inside Qt itself.
Your understanding is wrong.
Your understanding is wrong.
Well, all I can say is let wait and see to know whether what I wrote is correct or not. If Wine can emulate Windows dll, why can’t Qt have a translation layer of GTK API?
Furthermore what is the need of having both toolkit installed just for the sake of a few number of favourite applications?