Qt Becomes LGPL

Aequo writes "Qt, the highly polished, well documented, modern GUI toolkit owned by Nokia, will be available under the LGPL starting with version 4.5! It was previously only mainly available under the GPL and a commercial license. Selling licenses was an important part of Qt under Trolltech as it was the company's main source of income, but Trolltech is a fruit-fly compared to Nokia, who want to encourage and stimulate the use of Qt Everywhere [PDF]. This is fantastic news for all commercial developers looking to create cross-platform applications without the need to buy a $4950 multi-platform license per developer."

Comments

Hello Moto

[Dupple]

Let's hope Motorola sign up. Their UI is consistently inconsistent and awful

Re:Hello Moto

[kb]

People who adapt their business model to their choice of UI toolkit deserve to fail miserably anyway, so where's the damage?

Re:Hello Moto

[jonwil]

I have a Motorola Z6 that contains QT binaries (most likely QT embedded) on it so they are already using it on their linux phones at least.

Re:Hello Moto

[FishWithAHammer]

The GPL is inherently corrupt and restrictive, so this is a great move.

(The LGPL isn't the best of licenses--the BSD license in a perfect world, or the CDDL/MPL otherwise--but it's a hell of a lot better than the GPL!)

Bravo, Nokia, and thank you.

Re:Hello Moto

[Anonymous Coward]

You mean copyright law is inherently corrupt and restrictive?

Re:Hello Moto

[Improv]

Rather than you attempting to restrict what people do with their computers :) How horrible it is that someone might tell you not to restrict others! That's telling someone what to do! It's bossy and mean!

Re:Hello Moto

[afabbro]

No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it. Which is within their rights, but thoroughly corrupt and domineering of them.

Which makes sense, as Stallman is the ugliest type of human being--the zealot.

cough Kettle, pot, black, what?

Re:Hello Moto

[gparent]

You wouldn't be able to do anything if it wasn't from the author. He's not restricting you, either, just sharing the product of HIS work. Once you understand that, you'll know why most people don't care about your freedom that never existed in the first place.

Re:Hello Moto

[Nick Ives]

No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it.

Flat out wrong. The GPL restricts what you can do with other peoples code who have chosen to license it under the GPL. If you don't want those restrictions on your code then don't creative derivative works from GPL code.

Don't bitch because you can't leech other peoples code: Your code, your rules means their code, their rules.

Re:Hello Moto

[SanityInAnarchy]

So you're pissed because they just saved those people a bunch of work?

I'm confused -- until this moment, wouldn't they have been hoping exactly this would happen, and cursing the fact that they had to deal with the GPL?

Re:Hello Moto

[ShieldW0lf]

No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it. Which is within their rights, but thoroughly corrupt and domineering of them.

Which makes sense, as Stallman is the ugliest type of human being--the zealot.

Stallman is a member of a Jewish political movement from the first century AD whose primary goal is to incite the people of Iudaea Province to rebel against the Roman Empire?

Re:Hello Moto

[N3Roaster]

Don't worry. Qt has support for changing how widgets look with style sheets. While there are some legitimate uses for this, it also makes it easy to use Qt to produce a consistently inconsistent and awful UI.

Re:Hello Moto

[cellurl]

How to put this...
They only sell the cow when the milk is gone.
OpenOffice, Qt...

Linus, we need that new Palm WEB-OS thing ASAP.

Re:Hello Moto

[ShieldW0lf]

I'm confused -- until this moment, wouldn't they have been hoping exactly this would happen, and cursing the fact that they had to deal with the GPL?

The whole point of the GPL is to strengthen those who are materially sharing your ideals while diminishing those who are materially acting against them. I personally believe in the ideals behind the GPL, and I personally think it sucks to see that those who are materially acting contrary to those ideals are sharing the benefits of this code.

I would like to see the day arise where the closed source commercial software industry dies because it's forced to re-invent more and more wheels that open source software developers do not have to re-invent and is unable to remain competitive. That day just got further away.

Re:Hello Moto

[Anonymous Coward]

It WOULD explain a lot.

Re:Hello Moto

[FishWithAHammer]

Of course they can license their code under it. I didn't say they couldn't. That said, it's an immoral license. I do not use GPL-based code for my own work if I ever have any intent on distributing it. I license my own code under BSD and MPL/CDDL, which are both ethical licenses. The former because there are no meaningful restrictions to use of the code; the latter because it is a true quid pro quo, as opposed to the false one of the GPL (the GPL isn't "give back your changes to my code", which would be fine, but rather "give me your code") and the problematic one of the LGPL (no static linking reduces where code under the LGPL can be practically used).

Re:Hello Moto

[G3ckoG33k]

"No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it."

That IS an interesting view, which I have never heard of before. To me that sounds like Patent Law!

Re:Hello Moto

[FishWithAHammer]

I didn't say that they don't have the right to license their code under it. I said that they're wrong to do so, but I would not presume to take that right away from them.

Had he the authority, Stallman would take away my right to write code that was not under his perverted idea of "freedom".

MIT/X11/BSD, MPL/CDDL, Artistic. Even the LGPL (though the problems with static linking make it kind of suck for some applications, it's still head and shoulders above the GPL). Those (and some others, of course) are ethical licenses, because they don't presume to tell you what you can do with your code.

Re:Hello Moto

[rk]

Stallman is a member of a Jewish political movement from the first century AD whose primary goal is to incite the people of Iudaea Province to rebel against the Roman Empire?

No, he's a ground melee fighter armed with psi-blades, serving as the core of many Protoss forces, especially in the early-to-mid game.

Re:Hello Moto

[Nick Ives]

It's a bit of a stretch to call it immoral though. You don't like the terms so you don't use it and that's fair enough.

Re:Hello Moto

[aztracker1]

No one forces you to use GPL libraries. Though I agree that LGPL is much more appropriate for base libraries. This is probably the main reason I haven't used GPL libraries like Qt and don't use mySQL as a database engine. I understand in the case of mySQL it's different, legally vs. what mySQL AB likes to interpret, but I respect their position, and don't use their product for a lot of things.

I don't have a problem with the GPL, I usually use more liberal licensing like BSD, Creative Commons Attr. or MIT myself, and find GPL incompatible for inclusion. If you use GPL code, your code is GPL, it's that simple... if you don't like it, don't use it. There's LGPL, MPL, BSD, MS-PL and a host of other options. You have no place to bitch about it. I like the GPL for applications, it prevents people from subverting your application without giving back (not so great in web/SaaS models though). I think that SaaS using modified GPL apps does subvert GPL a bit. It's a balancing act, trying to preserve your rights as the original developer, while allowing people to utilize your code.

I happen to kind of like MS's MS-PL license. It's kind of like BSD with a nuclear deterrent clause (anti-patent/anti-lawsuit). I feel it's probably more appropriate in most cases over BSD. Since it would allow you to protect yourself, at least a little, from the patent trolls. Sure it works better for larger companies like MS, but is a kind of cool idea just the same.

Re:Hello Moto

[SanityInAnarchy]

I personally think it sucks to see that those who are materially acting contrary to those ideals are sharing the benefits of this code.

Out of curiosity, how do you feel about Samba? Or Wine?

I have somewhat different priorities -- I would rather see end-users benefit. Most often, this means I'd rather see something open than closed (I'm looking at you, Flash), but not always.

For example, many games, by their very nature (FPS, for instance), are only secure against cheating through obscurity. It might be possible to make a dual-licensed version of that work, given sufficient "trusted computing" to ensure that only the official binary is used in certain settings. A GPL3'd version wouldn't work at all.

I would like to see the day arise where the closed source commercial software industry dies because it's forced to re-invent more and more wheels that open source software developers do not have to re-invent

That actually has very little to do with open or closed, and everything to do with communication and cooperation.

I've been doing a lot of Rails work lately... Seems just about everything Ruby (especially Rails stuff) is MIT-licensed. The idea is that if an idea is good, and generic enough, you'll release it back to the community rather than try to maintain it yourself -- but when you use that stuff in your own proprietary project, you don't have to worry about licensing.

The net result is, only the stuff which is actually relevant to the site in question are at all subject to re-invention. And even then, not necessarily -- provide an API, and others will just use your service instead of reinventing it.

Nor is an aversion to the GPL strictly a proprietary thing. If you've got a large codebase in an OSI-approved, but GPL-incompatible license, it's a problem, and the GPL is about the least compatible FOSS license out there.

As a simple example: We absolutely do have to reinvent the wheel with ZFS, if it's to ever exist in the Linux kernel, largely because the kernel is GPL'd. And if btrfs ends up being good, and anyone wants to port it to OS X, BSD, or OpenSolaris, they're going to run into the same problem. We do each of those using things like FUSE, not for any technical reason, but to avoid licensing problems.

The only way to avoid reinventing the wheel is to follow sqlite's example, and go public domain -- or to define "proprietary" as "not using the GPL", which is just stupid.

Re:Hello Moto

[Anonymous Coward]

You don't have any inherent right to prevent other people from using your work however they like. The *only* reason you get to do so: the people as a whole *let* you do so for a limited time because we think that will give us more works to use.

Re:Hello Moto

[gbjbaanb]

I used to be with you here - public domain licences are better than the GPL (and to an extent I still think that, be altruistic and give your code away under a BSD licence is the ultimate is philanthropy), however, the GPL does have an important part to play in opening up software to the world in general. I think that, because the GPL mandates the subsequent free-ness of derived works, its asking for a kind of payment for using the code licenced under it. Obviously you don't have to pay that 'fee', but if you do, the cost to you (of re-using someone else's hard work) is to be similarly generous.

If everyone released code under the GPL, all we'd have to do is find different ways of being remunerated for it (probably in support and maintenance licences, which is where my company, a software house, make most of our money anyway), but the benefit of being able to use lots and lots of library and other code makes that an attractive proposition in itself.

We write a lot of code for windows, and I know if it wasn't for Microsoft producing a lot of libraries and frameworks, Windows wouldn't be nearly as attractive a development platform as it is. The GPL is nature's way of making Linux similarly attractive.

Re:Hello Moto

[ceoyoyo]

If you want to release your code under the GPL, great, thank you very much. If you want to release your code under a commercial license, or not release it at all, I also support that decision.

Allowing a GPL option for QT was great for the open source community. However, since QT is a library, the LGPL is a very good choice now that the owner of QT doesn't need the income from selling commercial licenses, and has an interest in having the library used more extensively. It's a good move on Nokia's part.

QT gets all the benefits of the open source community development, but is now also compatible with small closed source development that can't afford an expensive commercial license.

Re:Hello Moto

[FishWithAHammer]

But the GPL doesn't make it similarly attractive. It makes it much less attractive.

Re:Hello Moto

[mweather]

Motorola is focusing on Android and Windows Mobile.

Re:Hello Moto

[mweather]

The GPL doesn't tell you what you can do with your code. It doesn't cover use of the code at all, only distribution.

Re:Hello Moto

[geminidomino]

It's a bit of a stretch to call it immoral though. You don't like the terms so you don't use it and that's fair enough.

It goes both ways. If it's a stretch to call the GPL immoral, it's a stretch for RMS to call commercial software developers immoral. But he did/does.

Re:Hello Moto

[mweather]

(the GPL isn't "give back your changes to my code", which would be fine, but rather "give me your code")

The GPL doesn't affect the ownership of code at all, you still own the copyright and thus still own the code.

Re:Hello Moto

[geminidomino]

For example, many games, by their very nature (FPS, for instance), are only secure against cheating through obscurity.

I always wondered about this assertion (not saying it is inherently wrong, but it does get me thinking). If a game is "only secure against cheating through obscurity" wouldn't that imply that it's committing a cardinal sin of online game design: "Never trust the client"

There are some cheats (using your FPS example) that you would not be able to stop even with closed clients. For example, there is a tool commonly used by Guild Wars players called "TexMod" which sits in DirectX and replaces textures. Pretty useless for the most part, allowing for local-only custom skins (leading, of course, to the inevitable nude mods). But for a game like COD4 (assuming that's even on PC), you could replace the skin for the terrorists/SAS uniforms to a bright orange with full reflection to make it easier to see them, or replace the wall with a similar texture at 80% transparency. A closed client doesn't stop that.

On the other hand, if the server does all the real legwork and the client is only trusted for user input... I suppose you still have to deal with aimbots, but you get those with closed clients too...

Re:Hello Moto

[Anonymous Coward]

Err, no, cheating in games isn't eradicated by closing the source, but by having decent admins. I've been playing Tremulous in some shitty servers and have yet to see anyone cheating.
  Yet cheating in closed source games is rampant, even with all kinds of crapware used as a 'defense'.

Re:Hello Moto

[FishWithAHammer]

This kind of hair-splitting is painful to look at. Surely you're smarter than that. Distribution of code is "doing something with" that code. And while they're within their legal rights to make the demand that they do (licensing linked work under the GPL as well), that doesn't make it any less immoral or unethical.

Re:Hello Moto

[CarpetShark]

Stallman is a member of a Jewish political movement

You mean... The Judean People's Front?

Re:Hello Moto

[SanityInAnarchy]

it's committing a cardinal sin of online game design: "Never trust the client"

That's only possible if the game design in question allows for it. Almost no genres today fall into that category.

For the simplest example, suppose we take a card game, or a game of chess. Something like that, where there's no advantage to moving superhumanly fast -- purely strategy, everyone takes their turn. There's still the possibility of computer enhancement -- for example, a chess computer to show you the best possible move.

There are some cheats (using your FPS example) that you would not be able to stop even with closed clients. For example, there is a tool commonly used by Guild Wars players called "TexMod" which sits in DirectX and replaces textures.

Commonly known as a "wallhack", among other things. It's not DirectX-specific. It is, however, something closed clients try to adjust for.

On the other hand, if the server does all the real legwork and the client is only trusted for user input... I suppose you still have to deal with aimbots

Well, taken to an extreme, you don't, until AI has advanced to the point where it can recognize (fast enough to matter) the appropriate images from a video feed.

The point is, you have to trust the client for practical reasons. You have to send enough information for the client to render on its own, otherwise the bandwidth and server resources required are impossible.

you get those with closed clients too...

Well, again, a closed client at least has a chance. There still has to be some reverse engineering, possibly of the OS as well as the game, and if you tie it into a network like Steam, you also raise the stakes -- if you cheat, and you're discovered, you're gone, and you have to buy all your games again.

This mostly works. It's obviously not perfect, for the same reasons DRM isn't perfect. But I do believe it's more effective than leaving the source open, and doing nothing about the problem.

However, the fact that we're even having this discussion supports my point -- insisting on GPL/FOSS everywhere completely removes one possible way of fighting cheats. Whether it would have worked or not is up for debate, but things like a GPL'd Qt make that decision for you -- either you try to make a FOSS game, or you don't use Qt.

Re:Hello Moto

[mweather]

Use != distribution. That's not hair splitting.

Re:Hello Moto

[JoeMerchant]

Wow, that's crappy news. There's a whole group of people out there who couldn't afford the commercial license and were trying to make their business/development work around the GPL who now no longer have any need to make the effort, and therefore won't.

Thanks Nokia.

Whaaaaa? You can still execute your plan, this just opens an option to take your project closed source, if that's of any use to you.

Re:Hello Moto

[SanityInAnarchy]

I doubt very much that this has anything to do with admins. I suspect it has much more to do with the kind of community that's attracted to Tremulous.

And I never said it was eradicated. I suggested it might be lessened.

Re:Hello Moto

[Ant P.]

The GPL is nature's way of making Linux similarly attractive.

The GPL isn't the reason why people use Linux (barring a small handful of nutjobs, the type that make up a significant amount of BSD users). People use it because it's better.

Re:Hello Moto

[Phisbut]

If everyone released code under the GPL, all we'd have to do is find different ways of being remunerated for it (probably in support and maintenance licences [snip]

I've always thought that if you provide support and maintenance enough that you can make a living off of it (and let a whole company survive), then your code is horribly hard to support and maintain. A good application needs little support or maintenance.

Re:Hello Moto

[Nick Ives]

Commercial software is immoral. The comparison was being made against BSD and MPL which I doubt RMS would describe as immoral.

Re:Hello Moto

[Randle_Revar]

How to put this...

They only sell the cow when the milk is gone.

OpenOffice, Qt...

What?

And what does Linus have to do with Palm WebOS?

That is like saying "Linus, we need Gnome 3.0 ASAP"

Re:Hello Moto

[brainiac ghost1991]

No, we're the People's Front of Judea!

Re:Hello Moto

[synthespian]

Where you GPL zealots get it all wrong is that what matters is not code. What matters are humans. They are the ones who need to harness resources, be productive, and contribute to the general well-being of others and their families.

"Code" is an abstract entity. It's a stupid concept to talk about "the freedom of the code." The real concept is "freedom of the human to use code."

The willingness to contribute code to a common repository must come about out of a rational choice. Because it's advantageous for me and for you. That's how cooperation comes about - when mutual interests are served. not because some moralists of the Church of Stallman would have you follow his religious view that all proprietary software is "evil."

As to the claims of licenses such as BSD allowing people to steal code, that is simply bad logic. Code is not a material thing. It's an information thing and can simply be copied. The claims that someone who doesn't contribute to an open source project with a business-friendly license would have done so under the GPL are not provable. It's sort of like attempting to prove logically whether God exists or not.

Stallman doesn't care about any of this because, like religious leaders, he lives from donations of a non-profit and carries his life as single man with no family.

Linux PR (quite a few people, with a budget too) would have you believe the GPL is the best model. That's because the GPL as used in Linux regards the production of software by firms that sell per-seat licenses (Red Hat), or, in fact, hardware manufacturers that use Linux for their own reasons, such as competing with other Unices (e.g., putting Sun Microsystems out of business).

Re:Hello Moto

[Kamots]

The definition of derivative work is the issue.

I'd love to be able to utilize GPLed code, provide the code, credit the author(s), and create a work that utilized that functionality, intact, as an accoutrement to the rest of the application.

Unfortunantly, a strict reading of the GPL leads me (and my companies OSS group) to believe that this would mean that my entire application is a derivative work that would fall under the GPL. I've gotten around this in the past by having the GPLed code in a plugin form that is dynamically specified and then dynamically loaded so that the application is significantly distanced from the GPLed code.

Perhaps that's not how the GPL is intended to work, but there's enough leeway in interpreting it, that you have to be really careful.

Re:Hello Moto

[cellurl]

I always complain to the top...
I guess I could have said:

hey Jeff Dionne or Michael Durrant (inventors of uClinux), we need a port of the Palm-WEBOS.

Sometimes I feel like Gnome/KDE are like the Dems/Republicans, big and past-useful, but not exactly the new-world-order. Having an open source PALM-WEBOS would be cool.

My comments come off rough, but I really love Linux and want it besting itself!

-jim

Re:Hello Moto

[geminidomino]

it's committing a cardinal sin of online game design: "Never trust the client"

That's only possible if the game design in question allows for it. Almost no genres today fall into that category.

For the simplest example, suppose we take a card game, or a game of chess. Something like that, where there's no advantage to moving superhumanly fast -- purely strategy, everyone takes their turn. There's still the possibility of computer enhancement -- for example, a chess computer to show you the best possible move.

I guess I'm thinking of cheats in terms of "exploits" rather than just "poor sportsmanship". In the chess/card example, for instance, that's really no different than having a chess master sitting next to you doing the same thing...

There are some cheats (using your FPS example) that you would not be able to stop even with closed clients. For example, there is a tool commonly used by Guild Wars players called "TexMod" which sits in DirectX and replaces textures.

Commonly known as a "wallhack", among other things. It's not DirectX-specific. It is, however, something closed clients try to adjust for.

That was the word that was escaping me. Thanks. :) I know the exploit isn't DirectX specific, I was just being specific on TexMod.

On the other hand, if the server does all the real legwork and the client is only trusted for user input... I suppose you still have to deal with aimbots

Well, taken to an extreme, you don't, until AI has advanced to the point where it can recognize (fast enough to matter) the appropriate images from a video feed.

The point is, you have to trust the client for practical reasons. You have to send enough information for the client to render on its own, otherwise the bandwidth and server resources required are impossible.

Oh absolutely. But that would be all on the server-to-client direction, no? The server sends the map layout, current x,y,z and facing, and let the client render it. The client sends user input (w,a,s,d,fire, grenade, duck,etc..) to the server, which can trivially validate it ("Hey, I just received 2^n requests to move straight ahead in 1/100th of the time I should have.") I beleive WoW implemented something like this back in the 1.4-ish days to counter a speedhack.

you get those with closed clients too...

Well, again, a closed client at least has a chance. There still has to be some reverse engineering, possibly of the OS as well as the game, and if you tie it into a network like Steam, you also raise the stakes -- if you cheat, and you're discovered, you're gone, and you have to buy all your games again.

This mostly works. It's obviously not perfect, for the same reasons DRM isn't perfect. But I do believe it's more effective than leaving the source open, and doing nothing about the problem.

However, the fact that we're even having this discussion supports my point -- insisting on GPL/FOSS everywhere completely removes one possible way of fighting cheats. Whether it would have worked or not is up for debate, but things like a GPL'd Qt make that decision for you -- either you try to make a FOSS game, or you don't use Qt.

Oh, I'm not insisting on GPL/FOSS. I'm just an application programmer who plays with thought-experiments about game developing. :) I do think, though, that it's not as ineffective as you make it sound, and I think the best method is what you mentioned: ban-hammer.

Re:Hello Moto

[mweather]

Troll...

Re:Hello Moto

[bucky0]

the day I let RMS speak for my morality is the day I eat razor blades.

You and GP are having a conversation, it's ridiculous to say that because of something a third party has said, that GPs point is invalid (assuming, of course, that GP disagrees with the third party).

Re:Hello Moto

[FishWithAHammer]

Disagreeing with you isn't trolling, buddy.

Re:Hello Moto

[synthespian]

The whole point of the GPL is to strengthen those who are materially sharing your ideals while diminishing those who are materially acting against them.

What kind of flawed logic is this? This isn't a game-of-life board, you know. There's nothing "the GPL" can do to "diminish those" who don't adopt it.

How bizarre that the same ontological mistake is made again and again: code is confused with living, thinking, entities (i.e., humans).

The GPL is an abstract entity that doesn't do anything, that has no power over anyone except for those who chose to throw that yoke on their shoulders. This isn't an algorithm that "starves" a cell.

People who don't want to use the GPL will just turn their backs on it and they have done so. The fact that there's no ecosystem for third-party vendors on Linux shows this. The fact the Qt was licensed under the LGPL reinforces this POV.

In fact, you look at the statistics for open source software and you see they are flawed. The majority of software is under the GPL - but they are little projects, short-lived. In fact, it's amazing how people who manage SourceForge and the likes are completely clueless it terms of making the site machine-readable and ready for information-gathering. See, for instance:

The perils and pitfalls of mining SourceForge
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.1175

The bigger projects, Apache, GWT, the web development stuff, languages, etc, all are under business-friendly non-GPL licenses. Why is that? Think about it.

You wanna contribute to a project in which someone can just take you code, dual-license it, sell it for businesses under a proprietary license while you must open up all your secrets, algorithms, etc, so the competition can crush you? Be my guest.

Re:Hello Moto

[Hurricane78]

The problem is that you're criticizing the GPL for not living in your perfect dream world.
I think the GPL is way better, because I know, that in reality, businesses tend to rip you off, fuck you in every hole, and leave you bleeding on the street, (metaphorically speaking) if they just can!
It's the rule of profit maximization. The first rule of every business. And more often than not, it's unfortunately the only rule.

And that's exactly why we need the GPL to enforce giving back something. Because in reality, businesses will not give back anything. Why would they? To lose money and then to lose against their competition who is winning because they are not giving anything back? Makes no sense.

But why would you care about your reality, if you can perfectly continue to rant about your dream world not coming true, while ignoring it?

Re:Hello Moto

[gbjbaanb]

...then your code is horribly hard to support and maintain.

you've seen our product! :-)

Its big and complex and solves many problems, even if it was well-documented and well-implemented and intuitive, you'd still need someone to help support you.

Re:Hello Moto

[ShieldW0lf]

The whole point of the GPL is to strengthen those who are materially sharing your ideals while diminishing those who are materially acting against them.

What kind of flawed logic is this? This isn't a game-of-life board, you know. There's nothing "the GPL" can do to "diminish those" who don't adopt it.

How bizarre that the same ontological mistake is made again and again: code is confused with living, thinking, entities (i.e., humans).

It's no different than if I believed that guns should be used for self-defense, and only for self defense, and so I gave away free guns with the restriction that only those not convicted of murder were permitted to use them. Assume for arguments sake that I'm able to enforce this.

Now, all those people who want a gun for self defense will no longer pay arms dealers for the guns. Instead, they will take them free from me.

Now, the arms dealers have a dramatic drop in volume of sales, because only those who are interested in murder and aggression will be buying from them. Maybe 2/3rd of the arms dealers go out of business, and the per unit cost of the guns goes up dramatically.

This scenario strengthens those who agree with me. Some have more economic power in their pocket because they saved money, others have a gun for self defense even though they have no money at all.

But it also weakens those who disagree with me. Indiscriminate arms dealers find it harder to make a profit, and murderers pay more for their guns, leaving them with less economic power in their pocket. Some of them no longer can afford one.

This is how the GPL works. In the general sense, it destroys economic value by destroying scarcity and creating plenty, but it also increases scarcity for those who refuse to be bound by its covenants.

Oh, and with regards to your ontological comments, stop being such an idiot. If I run you down with my car, and someone says "He was killed by a speeding car.", it's not a false statement, and it's not implying that the car is alive. Get your head out of your ass.

Re:Hello Moto

[Slime-dogg]

It doesn't restrict your choice to use GPL'd code or not. If you link to code that is GPL'd, and you have issues with the GPL restricting your freedoms, then you seriously need to rethink your methodology.

Re:Hello Moto

[EQ]

Splitter!

Re:Hello Moto

[osu-neko]

No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it.

Um, no, that's simply not true. The GPL presumes to tell you what you can do my MY code. You are perfectly free to accept the license terms or not. Your own code is unaffected by anything other than your own decisions and their consequences. You're just not allowed to deny me the right to control what's done with *my* code. If you think you should have that right, you're certainly more corrupt and domineering than RMS.

Re:Hello Moto

[Anonymous Coward]

No, the GPL is not corrupt (at least, not GPLv2).
It's a very clear and simple license. It may not fit everyone's requirements, but it's goals are clear, and its text reflects them.

The LGPL on the other hand, is a convoluted mess, and some of what it "allows" doesn't constitute a copyright infringement in the first place, and so doesn't even require a license.

Merely writing your program so that it links to a shared library is _not_ creating a derivative work, and is not a copyright issue - it's only when you want to distribute the library with your program that a license is required, and that's where the LGPL comes in. But the FSF, and the text of the LGPL try to give the impression that simply _using_ a shared library (and distributing the resulting executable that links to it) requires a license.

Re:Hello Moto

[ShieldW0lf]

It's sort of like attempting to prove logically whether God exists or not.

God is the universe, and the universe is God. That is the definition of God, and because that is the definition of God, logic is irrelevant to the equation. I am ShieldW0lf. That is my name. I exist, and logic is irrelevant to the question.

If you find it necessary to debate the existence of God, it's because the person who described God to you implied that their opinions and conclusions as to the nature of God is an essential part of the definition of the word God, when they are not.

Easy.

Re:Hello Moto

[digitalunity]

Without the GPL, it would just be another Minix clone.

There is a reason that Linux took off, not the least of which is the relatively permissive licensing.

Re:Hello Moto

[Haeleth]

The GPL is a true quid pro quo. It says "I will give you my code if you give me yours."

"Give back your changes to my code", on the other hand, is an unequal bargain. You can't realistically claim that a handful of bug fixes are of equal value to an entire library.

You don't have to like the GPL, but please stop spreading FUD. There is nothing "immoral" about a license that merely requires repayment in kind.

Re:Hello Moto

[petermgreen]

I always wondered about this assertion (not saying it is inherently wrong, but it does get me thinking). If a game is "only secure against cheating through obscurity" wouldn't that imply that it's committing a cardinal sin of online game design: "Never trust the client"
Unfortunately following "NEVER trust the client" is impractical for FPS games with our current technology if you want acceptable performance.

and the more trust you put in the client the better you can make the game perform. For example most games handle movement and sometimes even hitscan on the client side to make the gameplay appear smoother. This obviously requires the client to have a lot of information.

There are some cheats (using your FPS example) that you would not be able to stop even with closed clients. For example, there is a tool commonly used by Guild Wars players called "TexMod" which sits in DirectX and replaces textures. Pretty useless for the most part, allowing for local-only custom skins (leading, of course, to the inevitable nude mods). But for a game like COD4 (assuming that's even on PC), you could replace the skin for the terrorists/SAS uniforms to a bright orange with full reflection to make it easier to see them, or replace the wall with a similar texture at 80% transparency. A closed client doesn't stop that.
A possible way arround that would be to subtuly alter the textures and change thier IDs each time the game was loaded to make it much harder for the software to spot which textures to replace.

Also many games are now starting to include scanners for cheat programs. They aren't perfect but combined with permanently banning players by their CD key or eqivilent they can be pretty effective against all but the richest cheaters.

Re:Hello Moto

[scorp1us]

I take a different approach. If we have a mono-culture of software development tools, then we all can participate in advancing computing as a whole, and not worry about factions (i.e. platforms)

Thus far, every software platform has been factioned from the start:
C/C++ & POSIX - was good but required POSIX compliance, never fully achieved, notably by MS. .Net - MS only. Mono is a 2nd rate knock off. C++/CLI is a joke. Really you'r looking at C# and VB
Java - was only recently open-sourced. Limited "official" JVMs

Now we have a completely platform agnostic (You want it on a PC, Mac, Linux, and your phone!? No problem) way to make advanced apps using any C++ compiler.

This is about bringing software development together (Oh, you want GNUCash on your phone!?!)

The goal of yours to eliminate closed-source commercial software isn't even a noble goal. But you've come to desire that through use of bad commercial software. The fact is, some people, like me need to sell software to put food on the table. The better engineering and implementation I do, the harder it is to sell support.

Re:Hello Moto

[WNight]

How is it not immoral to build a product you know is going to be sold with a EULA that purports to make it illegal to look disassemble, run on the OS of your choice, modify, etc...

That's pretty much trying to steal from the user, take their money and not give them what they expect from a sale.

Very little commercial software actually provides an honest product (no false disclaimers of liability, no exclusions of normal usage, etc). Not none, but certainly nothing that comes with a post-sale contract. Nothing that disclaims any actual use, and all liability.

Re:Hello Moto

[gangien]

it took me so long to not immediatly think of that when i read/heard the word zealot.

my life for Aiur!(sp?)

Re:Hello Moto

[HiThere]

I have to presume that you haven't read either the GPL or the CDDL. Possibly both.

Either that, or you have poor reading comprehension skills.

And in any of the above cases, you don't seem to be able to clearly explain your objections.

Or you could be a troll.

Re:Hello Moto

[Brandybuck]

No, your app is not a derivative work of the library. GNU does not have the authority to rewrite copyright law. Just because they say it's a derivative work does not make it so. Unfortunately, GNU probably has a bigger legal team than you do. Winning in court is not about who is right, but whose lawyers are bigger.

Re:Hello Moto

[HiThere]

Interesting. I have to wonder what makes that code "*my* code". If the GPL restricts the licensing terms that you can use, I have to suspect you of knowingly copying the code from a GPL program. Even in the case where you want to do a static link you could compile and distribute the two sections separately and link them after they were on the end users machine. (Granted that would be a tremendous bother...so you'd normally be better off using a different library to link against.)

But if the GPL is "actually forbidding"(see next paragraph) the distribution of code that you are claiming as your own, then I must suspect you of illegal copying of copyrighted material. (Well, it's not illegal until you distribute it, because of how the GPL is written, but if you distribute it that it would become illegal.)

In that case what is doing the actual forbidding is the copyright law, and you should take your objections to the legislators.

Re:Hello Moto

[ShieldW0lf]

the day I let RMS speak for my morality is the day I eat razor blades.

Six of one, half dozen of the other...

Re:Hello Moto

[Vexorian]

Oh gawd... Did anyone notice the most stupid posts ever are getting very high mod points lately?

Re:Hello Moto

[ShieldW0lf]

The goal of yours to eliminate closed-source commercial software isn't even a noble goal. But you've come to desire that through use of bad commercial software. The fact is, some people, like me need to sell software to put food on the table.

It is my larger goal to eliminate currency by replacing it with a democratic system so effective that it blurs the line of separation between government and citizen, leading to a situation where the vast majority of people would actually prefer to govern their affairs with a democratic political system and a communist economic system because it gives them more for less. If that goal can be achieved, your needs will be met, and you will no longer have any motivation to support the concept of commercial software, but will become my ally and supporter out of a sense of vested self-interest. If it can't, I'll change my name to Don Quixote...

Re:Hello Moto

[HiThere]

Sorry, but there are lots of necessary programs that no programmer is interested enough in to work on or maintain for free...or even for a merely competitive salary.

One example appears to be tax law programs. There are lots of good reasons why those programs are all commercial. One of them is that the legal requirements keep changing.

So commercial software will never disappear. Nor should it. This is the reason that the LGPL is available, and this is the reason that similar provisions were made in GPL3.

Re:Hello Moto

[Vexorian]

You're being an idiot and hair-splitting in order to dodge the fact that the majority of software's "use" (by the creator) is at least in some form predicated on distribution

No, actually, you are resorting to flaming and starting to make things up (Such as that jewel I just quoted)ps because the fact that the GPL does not govern use but distribution shows two things:

• You didn't really know heck about the GPL back when you were making your non-sense claims.
• Your claims on the GPL being restrictive remain as the bunch of BS that it always was.

Try to actually know about a subject before opening your mouth next time. As of the current discussion, just give up, you are embarrassing yourself.

Re:Hello Moto

[lgw]

The only safe work around for the GPL IMO (IANAL OMGWTFBBQ) if to *not* distribute anything GPLd. Distribute your code with a readme that directs the user where to get the GPL code. Even that makes me nervous.

I *really* like the Boost license

Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:

The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

[warranty disclaimer snipped]

That's the entire license. The Boost team hired a lawyer to write this in such a way as to be calming and soothing to other lawyers. If you don't distribute your own source, you don't have to distribute the Boost source - simple as it gets.

Re:Hello Moto

[Anonymous Coward]

Whyisit when someone posts the GPL they get marked Troll? I guess you religious freaks are embarassed by it. I would be too, if I was supposedly for "freedom" and had that much weaselese for confusing and entrapping people.

Re:Hello Moto

[lgw]

I'm sorry, but that was agun analogy, and we only accept car analogies here.

Re:Hello Moto

[lgw]

Your goal should not be to get more for less, but to advance the amout everyone gets over time. That is the fundamental flaw of communism: short term thinking. Competition fosters technological growth, which in the long run gives everyone more than any "fair" system of distibution.

Re:Hello Moto

[Bill Dog]

If my disallowing, via restrictions, your use of my software "restricts what you can do with your computer", then so does my not writing the software in the first place.

Re:Hello Moto

[FishWithAHammer]

I've read the GPL repeatedly. I've had discussions on the ethics of the GPL with a lawyer friend of mine on a number of occasions. He's drafting a modification of the CDDL for me that covers web services (similar to the Affero changes to the GPL, minus the bullshittery of the GPL itself) for me now. I know a hell of a lot more about the GPL--and the history of the GPL, the history of the FSF, and the aims of the FSF--than most Slashdotters. I know very well that the GPL covers distribution. For fuck's sake, it says so in the preamble. But for virtually everything I and most developers use libraries for, distribution is usage. Saying "but you can use it, you just can't distribute it" is disingenuity.

Re:Hello Moto

[FishWithAHammer]

Yours do seem to be getting modded up, yes.

Re:Hello Moto

[gladish]

This is one of the major downfalls of the various opensource licenses. Just like another reader posted about the fragmentation of the linux dekstop applications, we have a worse problem with licensing. How can we expect commercial software vendors to extend, build upon, contribute, etc. if the geeks can't even explain what the license means. Can I link? Can I change and sell? Who's gonna sue me? It's way too complicated. The licensing thing. And it's the same theme as the desktop application world. What toolkit does a commercial software vendor use? KDE, QT, Gnome, Mono? I think the open source philosophy in general suffers from too much chaos.

Re:Hello Moto

[Chryana]

I'm with you on that. I tried making an album from all the greatest Beatles songs with lyrics of my own inspiration, but Apple Records came sent its lawyers after me, so I'm not allowed to sell it.

Re:Hello Moto

[Improv]

Kinda, except you wouldn't be able to tell others that you think you own things you put on their computer. Distributing cakes to hungry people, laced with laxatives or poison is a dick move. Likewise, going to poor people and asking them to sell themselves into slavery isn't kosher - don't be surprised when people decide that that way of behaviour isn't cool and start locking you out (or invalidating or ignoring your claims to own information). You care about the freedom of developers to restrict society, we care about the freedom of society from restrictive developers. These freedoms are incompatible - we choose the latter.

Re:Hello Moto

[plantman-the-womb-st]

The GPL doesn't tell you what you can do with your code.

*yawn* Yes, we hear this over and over and over. Thank you for pointing this out, but please come to grips with the fact that distributing is something you DO with the code. It is in fact a way to USE the code.

Now, that statement may cause you to think that I dislike the GPL or the LGPL. I don't dislike them at all. What I strongly dislike is this pointless semantics crap.

The GPL restricts the conditions under which you may distribute modified and created code. Therefore the GPL has restrictions and is not 100% freedom.

It's just the way things are. Deal with it.

Saying, "but, that distrbution and not use," does not in anyway at all cause this to suddenly not be a restriction.

Re:Hello Moto

[Ilgaz]

As a UIQ3 (recently dead variant/GUI of Symbian) user, I would really hope that Motorola (and Sony-Ericsson) stays away from _any_ kind of smart device or anything can be applied on smart device and keep shipping their "design" dumb phones.

They are inconsistent and have awful management. That is why their UI is too. I am not joking.

They, along with the schizoid company Sony Ericsson killed the UIQ. Hope Nokia never answers any of their calls regarding Qt.

They had the interface which is ages ahead of anything running on rock solid Symbian kernel in hand. Know what happened?

http://www.newmobilecomputing.com/story/20734/UIQ_Files_for_Bankruptcy

Trust me, don't expect anything consistent from Motorola and SE. One day they sign up for Google Android and next day they ship a high end Windows Mobile device thinking developers will trust them and spend months coding for it.

Re:Hello Moto

[horza]

Indeed. People forget that you can allow or disallow others to use your code as you wish. I can put some code under the GPL, but if somebody was polite and asked if they could have a commercial license for their product in exchange for a couple of hundred bucks via PayPal I don't think I'd object.

Phillip.

Re:Hello Moto

[damsgaard]

Splitter!

+0 Funny Flamebait!

Re:Hello Moto

[Anonymous Coward]

If you find it necessary to debate the existence of God, it's because the person who described God to you implied that their opinions and conclusions as to the nature of God is an essential part of the definition of the word God, when they are not.

Like you just did?

Yes, that is what you just did.

No, that wasn't your point.

And yes, that is what you were going to say.

Go ahead and prove me right by backpedaling to some other desperate lie about what you really meant.

Re:Hello Moto

[Anonymous Coward]

The GPL doesn't tell you what you can do with your code.

Use != distribution. That's not hair splitting.

When the argument is "cannot do stuff" and you try to bring in a distinction between "use" and "distribution" (both subcategories of "do") then it most certainly is hair splitting.

Re:Hello Moto

[aweraw]

Saying "but you can use it, you just can't distribute it" is NOT disingenuity.

It's the objective truth.

Use = executing the code. In this respect, there are no restrictions imposed by the GPL.
Distribution = making copies and giving them out. The GPL simply states that if you take advantage of code licensed under the terms of the GPL, you must pass those same terms along to anyone who receives a copy from you. You are restricted from imposing further arbitrary restrictions... that's all.

You're the one who's splitting hairs by trying to claim that distribution _is_ use. No, it's not I'm sorry. Use is what occurs after distribution.

Re:Hello Moto

[Draek]

The willingness to contribute code to a common repository must come about out of a rational choice. Because it's advantageous for me and for you. That's how cooperation comes about - when mutual interests are served.

Exactly. Hence the GPL, it specifies what is an acceptable exchange for the original developer to give up control of his work, in this case the code of all derivative works. Don't think it's enough of an advantage to you, then don't use it, you're perfectly free to do so.

The claims that someone who doesn't contribute to an open source project with a business-friendly license would have done so under the GPL are not provable.

But based on the ratio between contributors to GPL'ed projects and to BSD'ed projects, we can deduce a rough ratio. And things *don't* look good for your argument, from what I've seen.

hat's because the GPL as used in Linux regards the production of software by firms that sell per-seat licenses (Red Hat), or, in fact, hardware manufacturers that use Linux for their own reasons, such as competing with other Unices (e.g., putting Sun Microsystems out of business).

So in other words, they use Linux and promote it because it's advantageous for them to do so?. Fuck, remove your dumb "OMG the GPL is a religion with RMS at the head!" comments, and you'd make a great argument *for* the GPL.

Re:Hello Moto

[FishWithAHammer]

Under their definitions of "use" and distribute, perhaps. Not under the definitions I use from a utilitarian point of view as a developer; to me there is no difference. My "use" of the library is to distribute it to my consumers.

And that's not what the GPL says, BTW. Well, it is, but it's not the whole story. The GPL says that the same terms must also infect any code that links to it. Hence the immoral aspect of it and why I advocate against it.

Re:Hello Moto

[aweraw]

It attempts to force ideological conformity.

Only in the sense that you're being forced to incorporate GPL code into your project.

Re:Hello Moto

[SanityInAnarchy]

In the chess/card example, for instance, that's really no different than having a chess master sitting next to you doing the same thing...

In the same sense that an aimbot is really no different than having Fatal1ty sitting next to you, using the mouse?

But that would be all on the server-to-client direction, no? The server sends the map layout, current x,y,z and facing, and let the client render it. The client sends user input (w,a,s,d,fire, grenade, duck,etc..) to the server, which can trivially validate it ("Hey, I just received 2^n requests to move straight ahead in 1/100th of the time I should have.") I beleive WoW implemented something like this back in the 1.4-ish days to counter a speedhack.

All of which does nothing to counter wallhacks or aimbots, unless you're talking about sending all the polygon data back periodically, which would be impractical.

No, what you're actually doing is sending game state back and forth. And yes, you can prevent people from teleporting around, or otherwise bending the physics of the game. But you can't prevent people from significantly enhancing themselves in other ways, like aimbots.

I do think, though, that it's not as ineffective as you make it sound, and I think the best method is what you mentioned: ban-hammer.

That assumes you know who's cheating, and that's difficult. The old admin_mod for hlds/counterstrike would simply flag people who were "too" accurate -- but humans can, in fact, be close to that accurate, and aimbots could deliberately add a degree of error, forcing the detection to be fuzzier. Admins will often ban people for doing things like shooting through a door, or a box -- but people do that, even if they can't see the target. So a lucky shot could mean a ban.

In practice, what it means is that people are simply banned for being "too good", not for any actual cheating.

The actual ban-hammer that, say, Valve wields over every game you've ever bought through Steam, is something which (I believe) is triggered by the "anti-cheating" stuff embedded in the client. It would kind of suck if you could lose access to all your legitimately purchased games by simply being too good.

Re:Hello Moto

[aweraw]

Under their definitions of "use" and distribute

Their definition - where 'their' is the person licensing the code. Just because they are words which can be used in contexts different from those implied by the licenser, doesn't mean that they are incorrect definitions. In the context of the GPL, they are the correct definitions.

The GPL says that the same terms must also infect any code that links to it. Hence the immoral aspect of it and why I advocate against it.

It's not immoral, because no one is forcing you into that position. You have to willingly submit to the terms in order to be bound by them... i.e. no one is forcing you to distribute code under the GPL, unless you take their GPL'd code and willingly incorporate it into your own.

By your logic, any consensual act you don't like the ramifications of is immoral...

Re:Hello Moto

[grumbel]

No, your app is not a derivative work of the library.

Your app *is* a derivate work of the library, at least when you distribute binaries and are using C or C++. The reason why the GPL works the way it does for libraries is because how C works. In C using a library starts with "#include ", that statement doesn't just say that you are going use the library as in some dynamic languages, but it copies parts of the library straight into your source code. In some cases of course not much is copied or none at all, while in other cases the whole thing is copied (C++ template based stuff). If this wouldn't happen the GPL really could do very little against using it in a proprietary app. Even the FSF itself argues that you can't or at least shouldn't be able to copyright a pure API, which is one of the reasons why using a GPL tool via exec() is perfectly fine.

If the GPL has one big flaw its really the weirdness that it based around C-like, instead of having a more meaningful way to being applied to all software.

Re:Hello Moto

[neonsignal]

I don't agree with this blind assertion that the GPL is more "restrictive" than the BSD. Exactly who are we talking about? Sure, it can be a bit more complicated for a developer trying to work with code from different sources, but the people that matter are the users. With BSD licensing a middleman can take away rights from the end user.

The GPL is a way to try to make sure that the end user is more likely to have freedom.

Freedom is a more complex idea than just "anybody can do what they want". The ability to place constraints on others (which is what the BSD license allows, and which most commercial licenses actually do directly) results in a less free world when looked at from the point of view of the whole society.

Obviously the GPL is not perfect, but to call it 'corrupt'? Weird.

The BSD license is a compromise. A pragmatic one that allows the participation of 'amoral' corporate players, who don't care how restrictive they are, since all that matters is the bottom line.

Re:Hello Moto

[mOdQuArK!]

The other way besides providing support & maintenance to make money off public domain code is to actually USE the public domain software to provide a service to your customers (i.e., you don't need to distribute the code or mods, just USE it to provide a service to your customers superior to your competitors).

Re:Hello Moto

[mcvos]

The GPL is a true quid pro quo. It says "I will give you my code if you give me yours."

"Give back your changes to my code", on the other hand, is an unequal bargain. You can't realistically claim that a handful of bug fixes are of equal value to an entire library.

But they do increase the value of the library. It's not a zero-sum game. You can both win.

Re:Hello Moto

[Bill Dog]

But here's where you're wrong: You're trying to feed dog food to my cat, which is uncool. You care about fish and I care about unicorns, and they don't get along, so I win. <rolls eyes>

Re:Hello Moto

[Anonymous Coward]

> I've gotten around this in the past by having the GPLed code in a plugin form that is dynamically specified and then dynamically loaded so that the application is significantly distanced from the GPLed code.

Dynamic loading is not sufficiently decoupled. See the GPL FAQ:

http://www.fsf.org/licensing/licenses/gpl-faq.html#NFUseGPLPlugins

Re:Hello Moto

[scorp1us]

It is my larger goal to eliminate currency by replacing it with a democratic system so effective that it blurs the line of separation between government and citizen, leading to a situation where the vast majority of people would actually prefer to govern their affairs with a democratic political system and a communist economic system because it gives them more for less.

And as soon as you accomplish that, we're going to have a vote that your sister sleeps with us all. At least when she does it now, she gets paid.

Re:Hello Moto

[ShieldW0lf]

Your goal should not be to get more for less, but to advance the amout everyone gets over time. That is the fundamental flaw of communism: short term thinking. Competition fosters technological growth, which in the long run gives everyone more than any "fair" system of distibution.

That's why everyone on earth is dependent on communist China for practically everything they own, and the USSR was so powerful it was able to take on the entire western world for decades and build rocket ships. Because communism is fundamentally flawed.

You know what the fundamental flaw of communism is? Bad neighbors.

Re:Hello Moto

[ToasterMonkey]

The reason why the GPL works the way it does for libraries is because how C works. In C using a library starts with "#include "

So... define the prototypes and constants yourself then? It's fairly simply to discover the interface of an open source library after all. I'm fairly sure it's the dependancies themselves, not in the details of how things are compiled. Even better, don't GPL the freaking header files. I don't think this is the real problem.

If the GPL has one big flaw its really the weirdness that it based around C-like, instead of having a more meaningful way to being applied to all software.

I don't know what you're talking about, it already is more abstract then you make it out to be. What dependancies on C are there? Look, I'm by no means advocating the GPL, I some of it is pushing it, like the "anti-tivoization" crud. I guess I can understand their intent though.. you can't do what you want with the software if the only device it runs on disallows your modifications. It breaks the spirit of the GPL... kind of I guess. But what GPL software is there on a Tivo you can't run on a PC? Ehh.. I'm not crazy about it, but whatever.

GPL v2

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

I still don't understand how this prevents me from distributing proprietary, closed source software linking against unmodified GPL libraries. It's pretty f'ed up to consider linking against a shared library a derivation of that library. Even then, as long as you don't distribute your "derivative" with the library you'd be fine. I think this was originally to protect against someone trying to 'extend' a GPL program in some evil way, and distribute the whole deal with non-GPL extensions intact. This is obviously NOT what most people linking closed software to GPL shared libraries are doing; shared libs are MEANT to be used exactly like that. Ahh beats me. I think free, free, and open source software are all just dandy, but I disagree with FSF and OSI's methods of promoting their ideals. They make it really hard to be on their side sometimes.

Re:Hello Moto

[FishWithAHammer]

Their definition - where 'their' is the person licensing the code. Just because they are words which can be used in contexts different from those implied by the licenser, doesn't mean that they are incorrect definitions. In the context of the GPL, they are the correct definitions.

And they are not the definitions I am using because it is, as far as I'm concerned, an irrelevant distinction. For me, "use" by necessity involves distribution.

It's not immoral, because no one is forcing you into that position. You have to willingly submit to the terms in order to be bound by them... i.e. no one is forcing you to distribute code under the GPL, unless you take their GPL'd code and willingly incorporate it into your own.

Setting aside for a moment that the Stallmans of the open source world would in a heartbeat force everybody to do precisely that if it were up to them, there is a difference between "compulsory" and "immoral." The idea that you somehow have the right to dictate terms over something you had no hand in creating is immoral (or at the very least unethical) regardless of whether it's forced or not.

Please note that I'm not saying they shouldn't have the right to do so. I am saying that it is immoral and unethical. They disagree. That's fine. It doesn't mean I have to agree with them and it doesn't mean I shouldn't advocate avoidance of GPL licensing.

Re:Hello Moto

[lgw]

Did you somehow miss the complete economic collapse of the USSR due to communism?

Did you somehow miss the fact that China is the home of much manufacturing because it has the lowest wages of anywhere that has the rule of law?

Post WWII, capatalism (to the extent it exists in America) has produced 4% growth per year, socialism 2%, and communism negative growth. Relative to socalism, capitalism doubles your standard of living every 35 years or so. Yes, socialism has some short-term advantages, but how much do you think it increases you standard of living? Twice as much? Four times? You're still fucking over your great grandchildren to make things better today.

Re:Hello Moto

[Anonymous Coward]

NO NO NO! We are the Popular Front for the Liberation of Judea!

Re:Hello Moto

[Brandybuck]

You cannot copyright an interface, as you say. There was even a court case on this, IIRC. That means you CAN include a header file meant to define the interface! It's a case of usage, not derivation. (Header files meant for internal use are a different matter).

Think of it in terms of music. Imagine a song in the public domain. You can put that song on paper with musical notation and copyright that, but you cannot claim copyright privileges against those who use your sheet music to play the song.

Re:Hello Moto

[Kamots]

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

My reading of that is that if I were to write an entire online game, integrate a GPLed IRC client into it for use as a chat mechanism, and then release it... is that my entire game would then be GPLed as I have "[distributed] the same sections as part of a whole which is a work based on the Program"

If I were to instead, write an entire online game, integrate a blank spot for chat, setup an interface satisfiable by several plugins, allow the user to dynamically specify which plugin they would want to use, and then distribute the GPLed IRC plugin as a seperate entity from the rest of my work... that then I would be ok, I'd only need to release the source for the GPLed plugin.

However, as the GPL is worded, it causes me and my company a lot of worry. Hence why I've gone to lengths to dynamically specify and dynamically load GPLed code as a plugin when I've had to use it. That allowed us to, if we ever needed to distribute, distribute as seperate works; and maintain complete independence from the GPLed code.

I still don't understand how this prevents me from distributing proprietary, closed source software linking against unmodified GPL libraries.

I'd suggest contrasting the LGPL with the GPL, there's some significant differences in the licenses.

On a side note on my hypothetical, if I simply had to release the code for the GPLed IRC client along with any modifications I made to get it to work as I wanted, then fine and dandy. I'd be just fine with that, and I'd even venture that my company would as well (well, if they were involved with games at all... :P). However, that isn't how the license reads; so I get to go through a lot of hoops.

Re:Hello Moto

[ShieldW0lf]

Did you somehow miss the complete economic collapse of the USSR due to communism?

I wholeheartedly disagree with your conclusion that the USSR collapsed because their economy was communist.

Did you somehow miss the fact that China is the home of much manufacturing because it has the lowest wages of anywhere that has the rule of law?

That is a pretty common argument against communism. But it ignores a very important question: If everything you need is provided to you because you're participating in a communist economy, what do you need a wage for in the first place?

People only care about wages when their country is poor, life is hard and things are scarce.

Post WWII, capatalism (to the extent it exists in America) has produced 4% growth per year, socialism 2%, and communism negative growth. Relative to socalism, capitalism doubles your standard of living every 35 years or so. Yes, socialism has some short-term advantages, but how much do you think it increases you standard of living? Twice as much? Four times? You're still fucking over your great grandchildren to make things better today.

I attribute American growth to the fact that it is the center of an oppressive global economic empire with a history of making, selling and using terrible weapons to intimidate and massacre any group that does not submit to their system and be exploited.

They've got one of if not the largest gap between rich and poor of any nation on earth, so it's self evident from that fact that most of their citizenry is poor.

They've also got a higher criminal/citizen ratio than most of not all the nations on earth, which means their citizenry are oppressed enough and desperate enough to violate the law more frequently than any other place on earth.

The US is basically an oppressive society ruled by group of dynasties, where many people attempt to buck the system and end up in jail or executed and unless you're one of the people on top, you're a poor, hard working slave, life sucks, and you've most likely been too heavily brainwashed by your masters to even comprehend the realities of your situation, so you're pretty much fucked.

Re:Hello Moto

[palegray.net]

If you use GPL code, your code is GPL, it's that simple... if you don't like it, don't use it.

This is incorrect. You are only required to honor the GPL for code you distribute to others (outside your company, for example). What you do with it in-house is completely up to you.

Re:Hello Moto

[lgw]

God I hope you're trolling. Communism has caused the worst atrocities in modern times. Millions starved to death while food rotted in rail cars, as no one was sufficiently motived to ship it. An end to scientific progress, as any scientific claim that had an unwanted political consequence would lead to exile or death for you and your family. Engineering practices so bad that they led to the largest engineering disasters in modern times, from dams failing along a river in China to Chernobyl.

Communism in practice is abject poverty, totalitarian oppression, and an end to progress. Do you know no one who lived in Russia during the bad times? Your fantasies about communist utopias are not just wrong, but actively harmful to humanity.

Re:Hello Moto

[aztracker1]

No, that doesn't make your code not gpl, it's just you don't have to worry about redist. Personally, I respect GPL to the point that if I use it internally, and modify, I give my mods back. I try to respect the intent of licensing, not always the letter of the legal notes.

I personally feel that it's way more important to respect intent, over the letter. I only wish more judges treated the law that way. I mentioned this in my prior post, I just wanted to reiterate. I also understand that your code doesn't fall under redist needs if you only use it internally, however you are mistaken that it isn't GPL, it is.

Re:Hello Moto

[palegray.net]

I also understand that your code doesn't fall under redist needs if you only use it internally, however you are mistaken that it isn't GPL, it is.

I'm sorry, that's just plain wrong. As far as any licensing considerations go, my code carries only an automatic copyright under United States law until it gets distributed to another legal entity. I can take additional measures, such as licensing it under a particular agreement, or placing it in the public domain, but these don't matter either until someone else takes possession of the code. The very fact that I cannot be held liable for any of the terms of the GPL prior to redistribution makes it impossible to consider any privately held code to be automatically GPL. Reference this portion of the GPLv3:

"To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well."

Emphasis is mine. Also consider this portion:

"You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you."

In other words, I can pay someone to make modifications to GPL software for my own use, and that new code isn't considered covered by the GPL unless I say so. I just can't go distributing the modified work while attempting to limit freedoms associated with other authors' code.

Unfortunately, Microsoft (along with some other orgs) went to great lengths to spread FUD about the "virus-like" nature of the GPL, implying that any in-house use of GPL software would forever taint code that touched it. This is ridiculous, of course: software developers are free to license the same code simultaneously under different licensing models if they so choose. It's still their code; they just can't place additional restrictions on what others can do with the portions of the codebase that aren't theirs under copyright law.

time to port gnome!

[SolusSD]

Seriously though- Reasons to write applications for the gnome desktop environment are getting fewer every day. When QT4 became available under the GPL on all 4 major platforms- Windows/BSD/Linux/OSX the argument for GTK was weak. Now, I'd argue its virtually non-existent.

Re:time to port gnome!

[geminidomino]

Agreed. I was all set to start learning GTK so I could finally write GUI apps instead of unix-tastic command line pipes.

Hopefully 4.5 comes out before this summer (too much coursework + realwork to start before then) so I don't have to! (I have no desire to write GPL software).

Re:time to port gnome!

[Anonymous Coward]

Not having specifically used either GTK or Qt (okay, so I gave Qt a quick spin in 2001, wasn't too impressed, but I usually use either LabView or web programming with C++/PHP)...is there something particularly nice about Qt vs. GTK?

Re:time to port gnome!

[Anonymous Coward]

Since GNOME is currently brainstorming over how to make GNOME 3, I'd say this announcement come right on time.
Let's focus on the applications and not on reinventing the wheel.
The toolkit feud has gone on for far too long. Let's share a common toolkit. GNOME is using more Vala and C#/Mono these days and Vala/C#/Mono on top of Qt would make gnomies very happy I think.

Re-implementing GNOME on top of Qt with the traditional focus on HIG should not be all that hard.

This is an exiting opportunity for GNOME. I wonder if they'll embrace it and make the Linux desktop go forward.

Re:time to port gnome!

[Anonymous Coward]

GTK+ is object oriented C. (Yes - object oriented C.) It relies on a ton of crazy libraries to work. It's only cross-platform if you mean "Windows and Linux" and even there "cross-platform" is a giant stretch.

Versus Qt, which is C++, has a much cleaner set of interfaces, and is really "cross-platform" on Windows, Linux, and Mac OS X.

The only reason I ever used GTK+ over Qt was due to licensing concerns. (And not just for closed software, also due to GPL/Apache licensing incompatibilities.)

So, yes, Qt is much better documented and much cleaner than GTK+.

Re:time to port gnome!

[puetzk]

Qt Designer is part of the core package, and is excellent.

Re:time to port gnome!

[carnalforge]

Qt Assistant, included with Qt. Add to it kdevelop, probably the best tools for GUI programming on qt/kde supported platforms.

Re:time to port gnome!

[AlXtreme]

When QT4 became available under the GPL on all 4 major platforms- Windows/BSD/Linux/OSX the argument for GTK was weak. Now, I'd argue its virtually non-existent.

The argument was primarily a licensing one: LGPL versus GPL. Going for GTK+ because it was LGPL wasn't a weak argument.

With both QT and GTK+ being LGPL, the argument will be about toolkit quality, third-party support and language experience (C++ versus C). This is a much more useful comparison, and as a developer well-versed in GTK+ I'm looking forward to using both.

From QT4.5 onwards, the best tool for the job wins. Thanks Nokia!

Re:time to port gnome!

[vurian]

Actually, thanks to http://doc.trolltech.com/4.4/license-gpl-exceptions.html, there were no licensing incompatibilities with Qt and the Apache license.

Re:time to port gnome!

[robot_love]

I second this. It takes a bit of time to learn to use Qt Designer, but it saved my hours in the long run. And it's not really that hard.

Re:time to port gnome!

[Anonymous Coward]

Qt Creator

Re:time to port gnome!

[gomek-ramek]

Qt Designer

Re:time to port gnome!

[betterunixthanunix]

Qt has a better set of widgets, at least for some applications. I have a friend who works for a major financial services company, which standardized on GTK only to discover that certain table related widgets were just not available, but were available in Qt.

I am told, though I have not tried it, that it is harder to develop multithreaded programs in GTK than in Qt. This matters a lot more than people like to think; how many times have you seen a UI not getting updated because of some background operation, and then had some uninformed user think that the program was freezing or crashing?

Finally, while both are object oriented, GTK is written entirely in C. Object oriented programming in C is pretty harsh, and the only other option you really have is to use the Python binding, which introduces a whole new set of issues. Qt is a C++ toolkit, which makes for much cleaner code when it comes to object orientedness. They did extend C++ somewhat with MOC, but that just introduces some new keywords that fit in very well with the general structure of C++.

Re:time to port gnome!

[IceFox]

Should be out before summer, on #qt people are saying March.

Re:time to port gnome!

[Cthefuture]

There is also now Qt Creator which show some promise as a cross-platform IDE.

Re:time to port gnome!

[gentlemen_loser]

This is an exiting opportunity for GNOME. I wonder if they'll embrace it and make the Linux desktop go forward."

I do not think that having multiple desktops and libraries are a bad thing, by any means. Firstly, without competition, things tend to languish. Granted KDE still has to compete with OS X and Windows, but having another competitor never hurts. If nothing else, Gnome and the Gtk+ toolkit would offer yet another flavor of experience for people with those specific tastes. Gnome has always felt a little more UNIXy to me.

With (obviously) enough people willing to work on and develop both projects, why not let them/encourage them to do so? Also, there is nothing stopping you from running your Gnome apps under KDE and your KDE apps under Gnome. With the cost of hard drive space today, why not?

Re:time to port gnome!

[Enderandrew]

Furthermore, both Gnome and KDE could share many core underlying technologies if this happened.

If I recall, Gnome was created because people didn't feel the Qt/KDE license was "Free" enough. Oddly enough, Qt and KDE are the "free" ones now, where as Gnome is now firmly entrenched with Mono.

Even Mark Shuttleworth has said there is something to said for a Gnome built on Qt. It would be faster, use less memory, and they could start on it tomorrow. Redesigning a GTK+ 3.0 from the ground up would take time, and slow down Gnome.

Qt ships with a Clearlooks engine. Please, please someone make this happen.

Re:time to port gnome!

[wild_berry]

Qt Creator is the official Qt IDE. But don't overlook KDevelop, which provides great autocomplete and semantic tools for your program code, if you're going to go a bit further than Qt 4.4 and use some of the KDE4 libs.

Re:time to port gnome!

[washort]

"Not using C++" is still an argument for GTK.

Re:time to port gnome!

[Anonymous Coward]

Object oriented programming in C is pretty harsh

if you don't know what you are doing...

like most things.

Re:time to port gnome!

[Anonymous Coward]

I am told, though I have not tried it, that it is harder to develop multithreaded programs in GTK than in Qt. This matters a lot more than people like to think; how many times have you seen a UI not getting updated because of some background operation, and then had some uninformed user think that the program was freezing or crashing?

If you think your application needs to be multi-threaded to be responsive, you may be the one who's uninformed.

Re:time to port gnome!

[Directrix1]

Did you mean to say exiting or were you going for exciting? Also, Vala compiles down to C code, if I'm not mistaken. If Qt is C++ I don't know how well that would work ;-).

Re:time to port gnome!

[Anonymous Coward]

I am told, though I have not tried it, that it is harder to develop multithreaded programs in GTK than in Qt.

Nope.. it's probably easier in fact... but that's not the point here. Lots of people compare GTK programming in C, with Qt programming in C++.

Qt programming in C++ is quite nice (not counting the MOC mess horror). GTK in C looks horrible, but with the C++ bindings it looks nice. GTK is a more - umm - bindable (for want of a better word) toolkit... it is shockingly easy to make bindings for. There are still all the issues around the C++ ABI which makes KDE (NOTE: not Qt itself, although it affected) such a horrible big-blob-o-code and a disgusting mess written by people who've never done a day's computer science.

So it's not as simple as licensing. However, this release is good news. There are a great many nice things about Qt (which is why it is quite popular for mobile stuff)... we'll really just have to see what comes out of it all. A unified desktop is not, I suspect, one of them... at least not for a good long while. Still, it may revitalise KDE's future - which was already looking bleak, but after the v4 debacle is/was looking desperate. This might give it another chance.

Re:time to port gnome!

[SpinyNorman]

Qt supports more than just Windows/Linux/Mac OSX... It also supports embedded applications (Qt/Embedded - used for Qtopia, which assumes nothing more than a framebuffer graphics interface), and most recently also Windows CE.

I think Google's decision to go with their own graphics API for Android is looking very much like "not invented here". The Qt API is excellent (I've been using the free version for years), and it's available pretty much everywhere. Now with LGPL licensing, any remaining objection has pretty much disappeared. Qt Jambi (the Java API for Qt) would be perfect for Android.

Re:time to port gnome!

[Constantine XVI]

You mean the Qt docs program also designs GUIs? I'm sure you meant Designer.

Re:time to port gnome!

[Richard W.M. Jones]

Presumably your "arguments" don't include the vast developer and language support for Gtk?

Also we're using and compiling Gtk on Windows just fine. It even has nice native look and feel.

Re:time to port gnome!

[siride]

Uhhh...if you have some background portion of the process that is CPU or IO intensive, you will want that to be in a separate thread, not in the same thread as the UI. If you don't, you get a UI that locks up completely, which is a real pain for the user.

Re:time to port gnome!

[Carewolf]

Multithreaded programming is always hard, but while Qt has tried to simplify it, it is actually very very tricky. Many things simply doesn't work in other threads than the main thread. The most obvious is all graphics due to X11 limitations, but also IO uses a handler that have to be installed in the correct main-loop, which means objects using IO can only be accessed from the thread that created them. Signals are really clever between threads, but behaves differently than normal which you have know. All in all you have to understand pretty much everything about the Qt loop engine to do multithreaded Qt programming.

Re:time to port gnome!

[pembo13]

Gtk is mostly a widget toolkit. You get a lot more with Qt. And I find Qt Designer to be much more thorough than Glade.

Re:time to port gnome!

[Anonymous Coward]

Since GNOME is currently brainstorming over how to make GNOME 3

Oh give me a break that is never going to happen.

Re:time to port gnome!

[jbolden]

If I recall, Gnome was created because people didn't feel the Qt/KDE license was "Free" enough.

It wasn't that. It was that the Q public license was incompatible with the GPL. QT was Q public and KDE was GPL. KDE is clearly a derived work of the Q public license. That means as far as Debian legal was concerned redistribution of KDE was a license violation.

TrollTech handled this by licensing QT under the GPL (they actually first went through the QPL but that didn't solve the problem). That fixed the legal problems but it meant that any and KDE app had to be GPLed because the userspace exemption (as per Linux kernel) wasn't there. Now KDElib is LGPL which means with QT being LGPL you don't uneed the exemption.

Re:time to port gnome!

[SpinyNorman]

Just to clarify for anyone new to Qt...

Qt Designer and Qt Creator are two entirely different things.

Qt Designed is drag-n-drop interactive GUI design tool that lets you design the GUI portion if aplication windows, dialogs, etc without coding. You just drag widgets and layout managers off a menu and drop them into the interface your building. It's an awesome tool. Your interface gets saved as a ".ui" file from which Qt automatically generates the corresponding C++ code as clean C++ classes. To add callback/etc behavior, or to further customize the GUI, you just subclass the generated classes and take it from there. It's done very well so that almost always you can further change the user interface using Qt Designer without affecting the subclasses you've added. Qt Designer has been there since early on and just keeps getting better and more powerful.

Qt also includes a tool "qmake" that makes building Qt apps ridiculously easy - qmake takes a high level ".pro" file that lists the various types of file making up your project (source files, header files, Qt designer .ui files, resource files, etc) and what type of target you're building (application, DLL, etc), and from the .pro file generates a Makefile that you then run using your normal make program (e.g. GNU make, or mingw32-make under MinGW).

Qt Creator is an IDE for development of Qt based applications, and seems to deliver the expected functionality of an IDE. It's pretty much brand new, and I havn't personally used it (nor intend to since I don't find IDEs to help my productivity).

Re:time to port gnome!

[Enderandrew]

Thanks for the clarification. I recall reading that years back, but I didn't recall the specifics.

GTK wasn't designed to power a full desktop platform originally. Gnome is at a crossroads where they either completely rewrite GTK, they bandage it while trying to preserve some compatibility, or they consider a move to Qt.

The single largest objection I hear from Gnome devs about Qt isn't that Qt isn't a good toolkit, but rather that they prefer to code in C. Color me ignorant, but aren't there language bindings that allow you to use Qt in C?

I'd really love to see a proof-of-concept simple app like GEdit converted to Qt, but I assume that would also mean porting the Gnome libs to Qt first.

Re:time to port gnome!

[Anonymous Coward]

GTK has been ported on all the above platforms. What is your point?

Re:time to port gnome!

[Hairy Heron]

How about people who don't want to use that monstrosity of a Frankenstein language known as c++ and prefer to program in c instead?

Re:time to port gnome!

[tchuladdiass]

I can agree on the bindings issue. I've started writing gtk+ bindings for my small scripting language (lang2e.sourceforge.net), and all that was required was for me to add a callback mechanism (that is, a way to pass a pointer function written in the scripting language to a gtk function). But so far I haven't figured out a clean way of adding qt or kde bindings. Especially since my language doesn't have much in the way of object-oriented features yet.

Does anyone have any good pointers on writing language bindings for qt?

Re:time to port gnome!

[Anonymous Coward]

Reasons to write applications for the gnome desktop environment are getting fewer every day.

*cough*cough*Ubuntu*cough*

*clears throat*

*cough*cough*Most popular consumer-level Linux distro out there*cough*cough*

*cough*HAAAACK*coughcough*The default desktop environment of which is GNOME and is therefore what the vast majority of Ubuntu users use*COUGH*COUGH*

*cough*cough*Not to mention the fact that the offshoots of Ubuntu, such as the KDE-centric Qt-based Kubuntu, are far less popular and not as well-maintained as the main product*HACK*COUGH*

Re:time to port gnome!

[jbolden]

Color me ignorant, but aren't there language bindings that allow you to use Qt in C?

Probably but every binding I've seen for QT sucks, including the commercial binding for Java that trolltech themselves wrote. Note that Trolltech even admits it sucks. QT is designed top down and bottom up as a C++ library not as a library that happens to be implemented in C++. QT gets advantages from not having to have language abstraction but also gets disadvantages in that binding are: really buggy and complex or low featured.

I think the Gnome developers are being fair. If you use QT you want to use C++.

Re:time to port gnome!

[Anonymous Coward]

You may want it to be in a seperate process(I know I do). All modern OS's have concurrency built in. Using it let's me get responsive apps without having to wrestle with threading issues in my app. This is not a panacea(sometimes you still want threads), but it is a heavily underutilized approach, especially on Linux and Unix, and especially for UI.

Re:time to port gnome!

[Talchas]

C++ is perhaps better than object oriented C, but it is generally much much easier to use a C library from some other language than a C++ library, if it is possible to use C++ at all. Since many people prefer languages that aren't either of these, C has portability advantages in this respect.

Re:time to port gnome!

[redxxx]

Kinda a false dicotomy, no?

QT has support for C++, Java, Python, Ada, Pascal, Perl, and PHP. Some of those are more useful than others, but if you want to develop in something other than c++, particularly if you want a cross platform application, there are more options than just c++ or GTK.

Unless you are talking about hacking QT v GTK themselves, what does it really matter when they both have support for a good variety of languages?

Re:time to port gnome!

[Enderandrew]

Fair enough, though I have read some praise for their Python bindings.

Re:time to port gnome!

[SCHecklerX]

I don't develop these days, but GTK is most certainly cross-platform. Sylpheed, Pidgin, Gimp, gvim, and several others are all very clean ports to windows that look as good, and run as fast as their originals in linux.

Dunno what that effort entailed, but the fact that there are quite a few of them seems to mean that it's not too bad?

Re:time to port gnome!

[TheQuantumShift]

I think it's more exciting for RAM sales...

But seriously, I like gnome and other stuff built on gtk. I tried KDE 4 and I didn't like it. I tried K3B, and I prefer Brasero. To me Amarok is just an unintuitive mess, while Rhythmbox is straightforward without sacrificing features. I did like the new prefrences dialog lifted straight from osx, but the vista-esque taskbar/menu has to go. Of course thats my opinion, as I'm sure others out there feel the exact opposite. I've given up on the whole "Unite under one desktop and crush microsoft" mentality, I use what works for me. Personally, the whole KDE project and all related projects could shut down tomorrow and I wouldn't notice. And for some folks, the same could be said about gnome. That's the beauty of open source: Choice.

Re:time to port gnome!

[Anonymous Coward]

Crazy libraries... you are an idiot. GNOME/GTk has always been split along functionality grounds into separate libraries - why... because those libraries can be used in other apps without everything else, plus it makes maintenance and development easier. KDE doesn't do this... why... it's because of C++ and the ABI stability issues surrounding it, plus the fact that the average KDE developer tends to be a 17 year old fanatic whose experience of coding comes from Visual Basic. Hence the KDE model of massive libraries with everything and its dog lumped together.

Re:time to port gnome!

[Anonymous Coward]

WORNG!@!@1!1212!2!@1!1@121

At the time that GNOME was created, Qt was available exclusively under a **proprietary licence that banned modification of the code** and was free-as-in-beer for only free software. Qt only changed its licence to the QPL after GNOME came along.

Re:time to port gnome!

[JimDaGeek]

Firstly, without competition, things tend to languish.

Competition is great, however GNU/Linux should not be competing against itself. There is too much fragmentation in Linux-land, 10 apps that all try to do the same thing, but each one does certain aspects better, yet none get it all right. Instead consolidate all that effort to 2 or 3 apps.

Linux gets to compete against Windows and OS X. Are you old enough to remember the Unix-wars? All the big Unix versions were all doing things their own way whilw MS and Apple were working on more consistent offerings. We all know what happened to the major Unix players.

Sadly, Linux desktop seems to be repeating the past. Constantly reinventing the wheel with tons of yet-another-app-X syndrome.

I have been using Linux since early Red Hat days. Then I used Slack, built my own Linux based on LFS for about 2 years. Then on to Gentoo, then to Fedora then finally Ubuntu.

Ubuntu made things a lot better IMO, however it still suffers with a felling of many apps tacked together instead of a more cohesive product. This was the main reason I switched to OS X 2 years ago and have been happy with that choice.

I still find myself missing Linux and would love to see a more unified final product. I don't want to have to be bothered with looking for a Gnome/GTK+ based app for Ubuntu so it works/integrates best.

There have been too many times I where I couldn't find a good Gnome/GTK+ based app but found it with a KDE based app. However, that one app pulls in a lot of KDE based bloat that I don't want/need. So I would try to switch to KDE from Gnome for a while, but found the same issue where I would have to pull in/use a Gnome/GTK+ based app.

Lather, rinse, repeat.

Re:time to port gnome!

[Abreu]

The Linux kernel has flourished without any real competitors for while now...

Re:time to port gnome!

[Anonymous Coward]

You say qt is C++ only as if that was somehow desirable. It is better than GTK+, but the language only substracts from its value. GUI toolkits should be language independent without ugly wrappers and abi bullshit. And that means written in C. Object oriented C when done right is a much saner platform than C++. GTK+ is crap, but that has nothing to do with C.

Re:time to port gnome!

[Abreu]

Use the QT C language bindings?

Re:time to port gnome!

[Jeremi]

All in all you have to understand pretty much everything about the Qt loop engine to do multithreaded Qt programming.

Not really, no. What you have to understand is that unless the Qt documentation explicitly says otherwise, the Qt GUI APIs are off-limits to your non-main threads. But most of the time your non-main threads are there to do non-GUI background tasks anyway, so that usually isn't as big a problem as you might think.

Re:time to port gnome!

[RiotingPacifist]

Last time i checked kubuntu still had 30% of ubuntus users (or 40% if you want to play numbers) but it is poorly maintained.

Re:time to port gnome!

[Anonymous Coward]

wait a second, you mean BSD is *really* dead?

Re:time to port gnome!

[jedidiah]

You make it sound like there aren't 5 different apps to do the same
thing on MS-DOS or Windows. This isn't a bad thing. Not everyone
wants to do things the same way. Some apps expose more functionality
and complexity than others. Some are essentially a single button
whereas others are every widget that a relevant serious professional
would want to have access to.

There isn't necessarily "one true way" and different groups can
develop and share different approaches to a given problem.

Re:time to port gnome!

[Tweenk]

Let's focus on the applications and not on reinventing the wheel.

How is porting to another toolkit (which would involve an incredible amount of resources and bring no tangible benefits) not "reinventing the wheel"?

Re:time to port gnome!

[swillden]

C++ is perhaps better than object oriented C, but it is generally much much easier to use a C library from some other language than a C++ library

That's not really relevant, since there are Qt bindings for all of the major languages, including Java, Python, C, Ruby, Perl -- even Haskell.

if it is possible to use C++ at all

Wherever it's possible to use C libraries, it's possible to use C++ libraries. If nothing else, you can always just wrap the C++ code in C code and call that, but it's usually not that bad.

Re:time to port gnome!

[aztracker1]

I like gnome's desktop interface better than KDE's myself. However, I do use a few Qt based apps, Amarok and K3b are two of my fav's. I've avoided Qt in the past, but this will allow me to reconsider. It's possible to use a LGPL library from an MIT/BSD licensed app, where as GPL is incompatible.

Re:time to port gnome!

[swillden]

there are Qt bindings for all of the major languages, including Java, Python, C, Ruby, Perl -- even Haskell.

Oh, I forgot C# and Visual Basic. There are Qt bindings for them, too.

Re:time to port gnome!

[ultrabot]

I've started writing gtk+ bindings for my small scripting language (lang2e.sourceforge.net), and all that was required was for me to add a callback mechanism (that is, a way to pass a pointer function written in the scripting language to a gtk function).

Why reimplement the wheel? Perhaps you could use something like the python virtual machine (interpreter) to host your language. Then, you could expose all the python stdlib (and 3rd party libs) to your own language.

Of course this will involve reading some docs and other people's C code, but will avoid leaving your own language as an isolated island.

Re:time to port gnome!

[aztracker1]

How long have those exceptions been there? Thanks for the info, though no longer even needed (as of 4.5).

Re:time to port gnome!

[ultrabot]

How about people who don't want to use that monstrosity of a Frankenstein language known as c++ and prefer to program in c instead?

... and reimplement all the complexity explicitly in C?

It's not like you can't do

g_return_if_fail(my_business_object_init(MY_BUSINESS_OBJECT(self), 23))

in C++.

Re:time to port gnome!

[aztracker1]

Well... one advantage of C over C++, is that C compiled code libraries can be implemented consistently across platforms, while C++ libraries and your apps need to be compiled specifically per platform. With GTK+, if the libraries are installed, my app doesn't need to include them. With Qt, it's harder to do that with. I still like Qt's portability better myself, but pointing out that C libraries are more portable than C++ libraries.

Re:time to port gnome!

[aztracker1]

I think having a unified themes application would be a better place to start, to be honest. And probably easier to accomplish having KDE themes apply to gnome apps, and vice-verse... Also, there is a bit more portability to Gnome in C vs. the way Qt is implemented in C++. Personally, I don't have a problem with mixed apps. Hell windows has made people very used to inconsistent apps.

Re:time to port gnome!

[gbjbaanb]

I don't think its about scrapping gnome and only having KDE, but using the same widget toolkit that KDE uses. The user interface would still be the same as gnome currently has, but consistency across apps would be better, developing would be easier, maintenance would be improved, memory usage would decrease.. etc etc.

So its not scrap Gnome, more like create Qnome.

Re:time to port gnome!

[mweather]

There's no reason to wait until summer, unless you think you'll finish and release your app by then. Write it with QT, then fix whatever breaks (likely nothing at all).

Re:time to port gnome!

[gbjbaanb]

that was one of the good things about Windows development - the GUI style guidelines that stopped apps looking like whatever the author felt like, and made them all consistent (even if that was grey dialogs, with the same old file menu). This was a good thing - witness the howls of outrage with Office 2007 as people can't find the print command (hint: its behind the round icon/button), or that the UI looks nothing like any other windows application.

With WPF becoming a popular choice for new apps, Windows will fragment into all kinds of 'innovative' user interfaces, none of which bear any resemblance to any other. Linux should take this opportunity to bring sanity to the desktop.

Of course, having a common development toolkit brings its own benefits in training new developers. I think a desktop based on QT would benefit Linux far, far more than is immediately apparent.

Re:time to port gnome!

[immcintosh]

According to this, GTK is cross-platform as well. I know I've certainly used GTK applications under Windows.

Re:time to port gnome!

[Anonymous Coward]

*cough* There are more Fedora users than Ubuntu users. *cough*

Re:time to port gnome!

[gbjbaanb]

and don't forget a goodie - it makes porting MFC apps reasonably simple. Won't nobody think of the poor, recently-discarded Windows C++ GUI developers :)

(any excuse to get them to port stuff to Linux, now if we can just get a good kernel replacement for WaitForSingleObject...)

Re:time to port gnome!

[jbolden]

That kind of license wouldn't be enforceable.

A is code that uses the QT and is free as in beer but no right to redistribute.

B is code that uses A but makes no use specifically of QT and is completely proprietary.

QT&A&B are distributed together commercially and there is no enforcement of any violations for A.

Re:time to port gnome!

[Anonymous Coward]

Qt/Embedded, especially with WebKit allows you to make some really nice apps that you can run on your Linux console WITHOUT X. You just need to enable the framebuffer and setup the environment properly. You can run all types of GUI programs directly on the console with minimal additional libs required for your server, for example DBS status/config, system admin, system test, etc. WebKit allows for you to even include browser capabilities and using Arora allows you a full browser capability -- on the console!

Re:time to port gnome!

[Anonymous Coward]

Linux absolutely should be competing against itself. Fragmentation isn't a problem, it's a natural and unavoidable occurrence.

The root of fragmentation is that there are competing visions into what 'the right way' actually means, this is a social issue rather than a technical issue.

Through fragmentation (mutations?) software evolves, the strongest and most successful solution is more likely to reveal itself, but the really nice part is that less successful mutations will still be available -- it's not the end of the blood line if your project isn't #1, in fact, someone from the more successful product may implement the good ideas from your project into theirs, and that's what makes open source strong.

If everyone were on the same team on a micro-level such as same exact project with same exact requirements and goals, nothing would get done due to in-fighting and politics. Fragmentation keeps inbreeding down and allows for social change within projects without the termination of any blood line of source.

Competition is good, diversity is good. Open source software should not be considered in terms of business (best product is top of the heap), it's an ecosystem fostered by the ability to borrow genes from other software genetic pools.

We've seen what non-competitive windowing systems turn into when everyone plays on the same team, stuff like _Common Desktop Environment (CDE)_. Bleagh!

Re:time to port gnome!

[Hairy Heron]

No, more like you only do app development in C cause C++ is a crap language.

Re:time to port gnome!

[JoeMerchant]

I think Google's decision to go with their own graphics API for Android is looking very much like "not invented here".

Qt had some pretty serious graphics performance inefficiencies, even as recently as 4.4. In 4.5 they have been "working on it" and making some impressive gains, thus proving the presence of the inefficiencies in 4.4 and earlier.

If I were Google and I saw that I could draw my screen 6x faster by rolling my own API, I'd be tempted to do that rather than trying to fix Qt's codebase that I don't really have control of.

Re:time to port gnome!

[JoeMerchant]

it is harder to develop multithreaded programs in GTK than in Qt.

I haven't done the GTK side, but I have used Qt and "others" to do multi-threaded apps - Qt makes threads easier than I have ever seen elsewhere.

Re:time to port gnome!

[JoeMerchant]

Firstly, without competition, things tend to languish.

Competition is great, however GNU/Linux should not be competing against itself. There is too much fragmentation in Linux-land, 10 apps that all try to do the same thing, but each one does certain aspects better, yet none get it all right. Instead consolidate all that effort to 2 or 3 apps.

Nice thought, but combining the developers from 10 working groups into 2 or 3 means the working groups get 4x larger, and thus 50% less productive ;-P

Re:time to port gnome!

[richlv]

btw, qtopia is now named qt extended - http://qtopia.net/.
i liked qtopia name better - shorter, easier to remember, more distinct...

Re:time to port gnome!

[Jim4Prez]

I think a good design with flexibility and extendability is far better than fragmentation/mutation/forking. Take a look at all the largest and most successful OSS projects. How many of them have fragmented and have successful mutations/forks?

Apache?
Python?
OO.org?
Perl?
Linux Kernel?
Etc.?

These all are successful because they have a good base design and are flexible and allow for a lot of extensions to add functionality.

Smaller projects may evolve better by mutations/forks, however for larger efforts, forking just kills things because now you have thinned out the pool of developers with the skills needed by the original large project.

Re:time to port gnome!

[Luke-Jr]

Qt already permits linking from non-GPL-compatible code. It has exceptions for virtually every major license, so your code could even be BSD-licensed and closed source if you don't mind giving Nokia/TrollTech the code on request.

Re:time to port gnome!

[spitzak]

The Linux kernel has flourished without any real competitors for while now...

I seem to remember there is something called BSD. Maybe you should look it up.

Actually an interesting thing I have noticed is that in open source there tends to be exactly TWO "popular" versions of everything. Whether there are a hundred competing versions (such as chat programs and music players) or very few (toolkits), it seems that exactly two are used by 90% of the users or more. Not one, not three.

Anybody have any explanation for this?

Re:time to port gnome!

[Rob Y.]

No, BSD isn't dead, but a BSD user can still feel right at home with a familiar POSIX environment on Linux, Unix and even OS/X.

Yes, standards matter - at least ones that are visible to users.

If Linux hadn't followed POSIX, it would have gotten exactly nowhere. That's why it's nuts that the various desktop environments went as far as they did down the 'roll your own' routes. As far as their UI libs are concerned, there's no getting around it. But even the KDE and GNOME core folks recognize that they need to be able to share common dialogs, etc. It's just that they recognized it too late to build it in from the start.

Re:time to port gnome!

[spitzak]

Wrong. Qt's license did not allow modification of the Qt code, and did not allow commercial distribution of the result (whether or not the source was included). This is not a BSD/GPL type of comparison. Qt was in fact completely unusable by an open source application.

Qt did not put any license that allowed commercial redistribution until long after Gnome was forced to use GTK because of this.

Re:time to port gnome!

[Luke-Jr]

Uh, C libraries can't be compiled for all platforms. Even just the OS barrier requires a recompile. Then you have CPU architectures on top of that...

Re:time to port gnome!

[slapout]

What about the people who would rather write in C instead of C++?

Re:time to port gnome!

[geminidomino]

There's no reason to wait until summer, unless you think you'll finish and release your app by then. Write it with QT, then fix whatever breaks (likely nothing at all).

Sure there is. Full time work + 11 credit hours of coursework. ;)

Re:time to port gnome!

[Guy Harris]

*cough* There are more Fedora users than Ubuntu users. *cough*

*cough*The default desktop environment for Fedora is GNOME*cough*

Re:time to port gnome!

[Luke-Jr]

*cough* QGtkStyle makes Qt native on GTK/GNOME environments.

Re:time to port gnome!

[dargaud]

I also want to learn a Linux graphics toolkit to code user interfaces, although I fully welcome the GPL. Where can I learn besides some half baked online tutorials or humongous and mostly obsolete man pages ? Yes, I'm ready to pay for a week of formation. Suggestions in Europe ? I searched on the web and didn't find much.

Re:time to port gnome!

[sharperguy]

I just did learn GTK (to an extent).

Personally I prefer the GTK layout format to QT.

Re:time to port gnome!

[Anonymous Coward]

"Instead consolidate all that effort to 2 or 3 apps."

Yeah, we'll get right on that. Just as soon as someone dies and makes you Grand High Poobah of Everything.

Honestly, it amazes me how many people say things like this without ever apparently putting one second of thought into how idiotic such statements are.

Re:time to port gnome!

[Anonymous Coward]

I am told, though I have not tried it, that it is harder to develop multithreaded programs in GTK than in Qt. This matters a lot more than people like to think; how many times have you seen a UI not getting updated because of some background operation, and then had some uninformed user think that the program was freezing or crashing?

Yes, that is true - Qt provides you with very nice and easy to use threading abstraction, that is - yes - platform independent.

Qt is not only a windowing toolkit, or GUI-toolkit, but it also handles database connections, net/socket libraries abstraction layer for handling Internet protocols, WebKit module and more - all multiplatform.

Re:time to port gnome!

[Randle_Revar]

>Gnome is now firmly entrenched with Mono.

No, it isn't. Gnome-the-platform has no dependency on Mono, and the only apps at http://projects.gnome.org/ that use mono are tomboy (a note taking app, there are others), f-spot (photo management, non-gnome alternatives are digikam and picasa, otherwise you could use beagle/tracker and an image viewer) and hipo (ipod management, many music player can do this).

And a connection with Mono wouldn't make Gnome less free anyway, because Mono is free, even if it is *potentially* in danger from MS.

Re:time to port gnome!

[Enderandrew]

Evolution is dependent on Mono as well these days.

http://www.itwire.com/content/view/22434/1154/

"Remove mono-core and here's a list of what gets removed along with it: banshee-1-backend-platform-gnome, banshee-1-extensions-default, banshee-1, banshee-1-backend-engine-gstreamer, banshee-1-backend-platform-unix, beagle-evolution, beagle-gui, beagle, avahi-mono, boo, evolution, dice, f-spot, ggreeter, gnome-do, gnome-desktop-sharp2, gnome-keyring-sharp, gsf-sharp, gtkhtml314-sharp, podsleuth, taglib-sharp, tasque, evolution-sharp, tomboy, gnome-panel-sharp, gmime-sharp, mono-addins, mono-zeroconf-provider-avahi, mono-zeroconf, monsoon, mono-web, mono-winforms, mono-data-sqlite, mono-data, gconf-sharp2, glade-sharp2, gnome-sharp2, art-sharp2, gnome-vfs-sharp2, notify-sharp, ndesk-dbus-glib, ndesk-dbus, gtk-sharp2
and glib-sharp2."

Re:time to port gnome!

[msaavedra]

Oddly enough, Qt and KDE are the "free" ones now, where as Gnome is now firmly entrenched with Mono.

Do you have any evidence of this? To the best of my knowledge, the Gnome community is deeply ambivalent about Mono. There are very few official Gnome apps that use it.

Re:time to port gnome!

[Brandybuck]

Qt was (is) under the GPL+exceptions. You could write an app linking to Qt with any common FOSS license and it was okay. Only if you were proprietary developer did the licensing cause problems.

Last I looked 90 out of 100 apps written for GTK+ are GPL, of 9 of the remaining under a different FOSS license. Nothing was preventing those developers from linking their GPL applications with a GPL library.

Re:time to port gnome!

[Carewolf]

And unless you want to do IO which is a very common thing to offload to other threads. I still program multithreaded Qt today, but it is not something I would recommend to most developers. It is quite tricky, and requires a lot more insight that you normally need to program with Qt.

Re:time to port gnome!

[Enderandrew]

Evolution, Banshee, Tomboy, and F-Spot are all dependent on Mono these days, and the list keeps growing.

Re:time to port gnome!

[Anonymous Coward]

Lots of people aren't using a major language, though. In which case you'd normally default to the C bindings, but I'm having a hard time finding them for Qt. Are they actually in use, or is it just a proof of concept some guy hacked together over five years ago and never touched again?

If nothing else, you can always just wrap the C++ code in C code and call that, but it's usually not that bad.

That's exactly how bad it usually is. Nothing of significance talks to the twisted realm of madness that is C++, except through C's portals of sanity and simplicity.

Re:time to port gnome!

[Brandybuck]

While the C++ language might have some truly scary corners, Qt hides them away from you. Unlike gtkmm, Qt mostly keeps to the mainstream object oriented parts of C++. You don't have to write functors, exceptions won't be thrown at you, etc. You may need to know what templates are in spots, but you don't need to create your own generic classes or write template specializations. Of course, some C++ "purists" hate it for that reason.

Yeah, you can do OO programming in C, but so what? You can do OO programming in assembler too! Writing GUI applications in a language meant for OO is sooooo much nicer than writing it in plain vanilla C. The premier compiled OO language is C++, which is why it is used.

Re:time to port gnome!

[Anonymous Coward]

I couldn't find a good Gnome/GTK+ based app but found it with a KDE based app. However, that one app pulls in a lot of KDE based bloat that I don't want/need.

Oh cry me a river. What are you running, a 386SX with a 50MB hard drive? Just download the damn KDE libraries and kwitcher bitchin. There is no good reason you can't have both KDE and GNOME libraries installed on your machine.

Re:time to port gnome!

[Brandybuck]

I've even seen Qt used with OS/2 and QNX.

Re:time to port gnome!

[jbolden]

The FSF doesn't agree with you, "This [QPL] is a non-copyleft free software license which is incompatible with the GNU GPL. It also causes major practical inconvenience, because modified sources can only be distributed as patches."

QPL is a fine software license.

As for not being able to modify the license itself says the opposite:

3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications:

        a. Modifications must not alter or remove any copyright notices in the Software.

        b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer.

_______

Now there was a license called the FreeQT license which existed when objections were being made but well before Gnome. That license was an open source, free as in beer license with heavy restrictions on patches.

But again the issue came up because of the GPL conflict with redistribution. There are other packages with restrictive licenses that put downsteam code requirements on (for example LaTeX) but it was when this licenses were linked that the problems got severe enough that Debian felt they were non compliant.

That is had QT just used this license Debian would have just stuck it in non-free and moved on. The problem came from the major user of QT being KDE which was GPL at the time.

Re:time to port gnome!

[w000t]

...every binding I've seen for QT sucks, including the commercial binding for Java that trolltech themselves wrote.

Bullshit.

Note that Trolltech even admits it sucks

Double bullshit.
Your last sentence might be informative, but still you're mostly trolling.

Re:time to port gnome!

[vurian]

Yes, the python, the ruby, the php, the C# bindings are in actual use. If you hang out on irc in #qt, you're going to be surprised how many people are using them. The C bindings to Qt were dropped a long time ago: they existed to make it easier to generate, for instance, Objective C bindings. But generating bindings for C++ libraries using sip or smoke is so easy, they were obsolete. And of course, nobody who isn't start raving bonkers would try to write an application in C if he can use any other language, so nobody used them directly.

Re:time to port gnome!

[w000t]

Don't forget Ruby and C#. Qt has bindings for those languages too.

Re:time to port gnome!

[msaavedra]

Of the apps you listed, only Tomboy is an official Gnome app. The others are just third-party apps written using the gnome libs and Mono. Furthermore, there are (in my opinion) better gtk or gnome apps in each category that that don't use Mono. I don't see how this makes Mono "firmly entrenched" in Gnome.

For the record, I am a long time user of gnome, but am deeply skeptical about Mono, and avoid it like the plague. This attitude seems to be fairly common in the gnome community in my experience.

Also, to keep this message on topic, I don't use QT or even have it installed on my systems, but I think this license change is a smart idea, and I hope it increases QT usage in areas where it makes sense.

Re:time to port gnome!

[Mystra_x64]

plus the fact that the average KDE developer tends to be a 17 year old fanatic whose experience of coding comes from Visual Basic

Your personal experience != truth.

Re:time to port gnome!

[PitaBred]

Yes, let's all move in the same direction on the same projects, thereby destroying that which makes Linux so successful.

Linux works BECAUSE of the fracturing, not in spite of it. Yes, there are downsides to that where applications and such aren't terribly cohesive. But there are upsides, where you get the source to everything and no one can ever take it away from you. You don't get that benefit with your beloved OS X. It may look shinier, but OS X still has a ton of UI inconsistencies. Don't kid yourself... no OS has the consistency thing down, and I'd rather take the more stark inconsistency of Linux for the benefits it provides than pay through the nose for OS X + hardware, then all the little nickel and dime utilities you need for OS X.

Re:time to port gnome!

[Enderandrew]

I've posted it elsewhere, you removing Mono from an openSUSE 11.1 install removes:

banshee-1-backend-platform-gnome, banshee-1-extensions-default, banshee-1, banshee-1-backend-engine-gstreamer, banshee-1-backend-platform-unix, beagle-evolution, beagle-gui, beagle, avahi-mono, boo, evolution, dice, f-spot, ggreeter, gnome-do, gnome-desktop-sharp2, gnome-keyring-sharp, gsf-sharp, gtkhtml314-sharp, podsleuth, taglib-sharp, tasque, evolution-sharp, tomboy, gnome-panel-sharp, gmime-sharp, mono-addins, mono-zeroconf-provider-avahi, mono-zeroconf, monsoon, mono-web, mono-winforms, mono-data-sqlite, mono-data, gconf-sharp2, glade-sharp2, gnome-sharp2, art-sharp2, gnome-vfs-sharp2, notify-sharp, ndesk-dbus-glib, ndesk-dbus, gtk-sharp2
and glib-sharp2.

That is just what is installed by default with the distro. There are Mono hooks for apps like Nautilus as well. How much longer will those Mono hooks be optional?

Also, these sure seem to be official Gnome apps:

http://projects.gnome.org/evolution/
http://projects.gnome.org/beagle/
http://projects.gnome.org/f-spot/
http://projects.gnome.org/tomboy/

I've also yet to see a distro that doesn't include these apps as part of their Gnome desktop.

Re:time to port gnome!

[Randle_Revar]

Dunno why that would be the case in SuSE, but here in Debian Sid, Evolution 2.22 has no Mono dependency.

Looking into it a bit more it is a simple bug:
http://bugzilla.gnome.org/show_bug.cgi?id=549025

Evo can support Mono plugins (but no default plugin is Mono) and this bug (now fixed) forced the main Evolution package to require Mono when built with Mono plugin support.

So Evo is not, in fact, dependent on Mono.

Re:time to port gnome!

[hereschenes]

A more reputable confirmation of the March release date.

Re:time to port gnome!

[Anonymous Coward]

consistency of look and feel is absolutely welcome. And it would help linux compete against osx. But windows, seriously? Every friggin desktop machine comes with the vendor personalization. A plethora of crippled apps each one with the most flashy and inconsistent look. Then XP vs Vista, office 03 vs 07, ie 6 vs ie7. Backup procedures. Antivirus and anti malware. You buy the german app, you don't get all the other localizations so your english speaking pals can't use your PC. keyboard shortcuts which vary from one localization to the other. Really gnome vs kde is nothing in comparison.

Re:time to port gnome!

[NuShrike]

Considering how light-weight WTL is, is it worth porting WTL apps to Qt? (versus going from heavyweight MFC to heavyweight Qt).

Re:time to port gnome!

[JimDaGeek]

Linux works BECAUSE of the fracturing, not in spite of it.

I don't know what numbers you are looking at, but Linux is not "working" at least in the sense of user base. It has very low usage on the desktop. Very low.

than pay through the nose for OS X + hardware

Ok troll, nice try. Where did I say "my beloved OS X"? No where. Pay through the nose? Not quite. I did a price compare before I switched. Very competitive when you go feature for feature.

then all the little nickel and dime utilities you need for OS X

Nice try again troll. I have been using OS X for more than 2 years now and have never needed nor bought any of the apps listed on your link. I guess you are suggesting that there are not 10's of thousands of shareware apps out there for MS Windows?

Go back under your bridge.

Re:time to port gnome!

[Anonymous Coward]

Me want KNOME!

Re:time to port gnome!

[JohnFluxx]

Qt Creator is a programming IDE. Qt Designer is a for designing the GUI. Qt Creator uses Qt Designer.

Re:time to port gnome!

[Anonymous Coward]

Good maybe Gnome will finally die a much deserved and long overdue death. Let the flame war begin!

Re:time to port gnome!

[macshit]

Reasons to write applications for the gnome desktop environment are getting fewer every day. When QT4 became available under the GPL on all 4 major platforms- Windows/BSD/Linux/OSX the argument for GTK was weak. Now, I'd argue its virtually non-existent.

I dunno, I like gtk because it's a good looking, popular, fairly nice to use toolkit, with good bindings in many languages.

You obviously like qt a lot, which is fine, but don't be blinded by your enthusiasm into thinking it's obviously superior -- it's not.

Re:time to port gnome!

[mrchaotica]

Finally, while both are object oriented, GTK is written entirely in C. Object oriented programming in C is pretty harsh, and the only other option you really have is to use the Python binding, which introduces a whole new set of issues.

There's also GTK#. C# is nice, despite being created by Microsoft.

Re:time to port gnome!

[Draek]

There is too much fragmentation in Linux-land, 10 apps that all try to do the same thing, but each one does certain aspects better, yet none get it all right. Instead consolidate all that effort to 2 or 3 apps.

Define "better". And please provide a list of the three music player apps you'd choose to live on, with reasoning for why (and if you say "mpd", pick at most two interfaces for it. Gotta make it fair).

All the big Unix versions were all doing things their own way whilw MS and Apple were working on more consistent offerings. We all know what happened to the major Unix players.

Yeah, they went on to make nice money selling expensive server to big businesses, while Apple almost went broke and got sold by a negative amount of money to NeXT, a minor Unix vendor. History books may say they bought it, but which company's CEO took control afterwards? ;)

Plus the great problem of the UNIX wars was that all different version were not only different but incompatible between themselves. Not so in open-source.

Ubuntu made things a lot better IMO, however it still suffers with a felling of many apps tacked together instead of a more cohesive product. This was the main reason I switched to OS X 2 years ago and have been happy with that choice.

Ohh, it's easy. When using Ubuntu, just tell yourself GTK is Linux's Aqua and QT is its Brushed Metal and voila! instant perfect consistency ;)

Re:time to port gnome!

[Pseudonym]

Even if you do know what you're doing, it's still pretty painful.

Re:time to port gnome!

[Draek]

My eternal issue with QT has always been that it's tied way too much to C++. I, personally, hate C++ with a passion, and when I last tried the QT bindings to Python (admittedly, a long time ago) it felt more like a whitespace-aware version of C++ rather than the Python I knew and loved, so I switched back to PyGTK and never looked back.

Has that changed? does it have bindings to Java and/or C#? how mature are they? my favorite thing about GTK has always been that, since it's written in C, it's much easier to bind it to any language you can think of, I mean even Pascal for God's sake! something that me and the other five guys who still program in that thing for fun appreciate a lot.

Hopefully, the new-found attention QT is sure to get with this announcement will make it improve in those areas, but GTK still has various strenghts that make it attractive for people like me. Still, it's always nice to see these kind of news so thanks Nokia.

Re:time to port gnome!

[MemoryDragon]

Actually you obviously do not know KDE, this system is so advanced compared to Gnome you cannot believe it. KDE is more along the lines of NextStep OpenStep than on Gnome which resembles Win32 more than anything else. The entire KDE system is made of loosely message coupled service objects which are bound together, you can see that in a clear and precise way, in many apps simply using parts of other applications. KDE sort of is the NextStep of the Linux world!
KDE is one of the few systems which were able to be pulled off that way, the other one is NextStep/OpenStep/OSX!

Re:time to port gnome!

[MemoryDragon]

I cannot agree here as well, I had a look at the KDE sources and they were so clean and well structured it was amazing.
Definitely not the work of an average 17 year old fanboy :-)

Re:time to port gnome!

[Daengbo]

Gnome apps are preferred to be in Vala now, which is a high-level, C#-like language which translates code into straight C before compilation.

Re:time to port gnome!

[IBBoard]

Qt bindings for Mono/.Net? Where? When I looked a few months ago Qt# was dead and Qyoto seems to have gone missing when I searched a in the past few weeks (all the sites are either dead or being squatted).

Re:time to port gnome!

[Anonymous Coward]

The old Unix wars were not because of competition, they were because of being closed.

If KDE does something great, Gnome will copy it. If Gnome does something great, KDE will copy it.

When differences appear, it's because one project thinks that it can do the same thing better, or because of disagreement over what is good.

Aside from that, as a Gnome user, I already made the choice. I don't like QT, so I use Gnome. If Gnome was to become QT, I would have to go back and select a preferred desktop again. This time it would just be XFCE vs OSX, rather than XFCE vs Gnome.

Re:time to port gnome!

[Anonymous Coward]

None of them are fragmented from a code point of view, just as KDE and Gnome aren't. They didn't come from the same code base.

However, all of them are fragmented from a user base point of view. Just as Gnome competes with KDE and XFCE, GTK competes with QT, Apache competes with thttpd and lighttpd, Python competes with Ruby and Perl, OO.org competes with Koffice and Linux competes with at least three different BSDs.

Re:time to port gnome!

[vipw]

Why don't you buy a book on QT?

http://www.amazon.com/C-GUI-Programming-Qt-4/dp/0131872494

http://www.amazon.com/Book-Qt-Art-Building-Applications/dp/1593271476

http://www.amazon.com/Foundations-Development-Experts-Voice-Source/dp/1590598318

And the QT reference docs are well organized in my experience.

Re:time to port gnome!

[swillden]

Sorry, I don't use .Net or anything related to it, so I was just going off of what I could find via Google. Sorry if I mislead... the pages I found made them sound like going concerns, and I didn't check the dates.

Re:time to port gnome!

[Anonymous Coward]

Well... I believe you... you don't sound like a feverish 17 year old fan boy with no knowledge of computer science... at all... no sir. It's a good job you posted and not some sweaty ardent fan - 'cos that would have made the original poster's point perfectly... yes indeedy.

Re:time to port gnome!

[kojot350]

I second Qt Creator, although it's in beta now, but it's a really good lightweight IDE.

Re:time to port gnome!

[kojot350]

It's pretty much brand new, and I havn't personally used it (nor intend to since I don't find IDEs to help my productivity).

You should try then, because Qt Creator isn't just another IDE, it's lightweight, fast and keyboard centric and minimalistic. I find it very helpful to boost productivity actually.

Re:time to port gnome!

[kojot350]

GTK is most certainly cross-platform. Sylpheed, Pidgin, Gimp, gvim, and several others are all very clean ports to windows that look as good, and run as fast as their originals in linux.

They are not as fast nor as stable on windows unfortunately. And Qt is more than "just" cross-platform it's an OS abstraction layer, phonon multimedia framework, webkit integration, native look support, and all that stuff.

Re:time to port gnome!

[kojot350]

Presumably your "arguments" don't include the vast developer and language support for Gtk?

Also we're using and compiling Gtk on Windows just fine. It even has nice native look and feel.

Yea, and Pidgin hangs every 5 minutes on Windows. And it does not feel like windows app.

Re:time to port gnome!

[Anonymous Coward]

FWIW, I always remove all of those but F-Spot.

More..

[Thyamine]

FYI: This article needs more acronyms. STAT. ASAP.

Re:More..

[evil_aar0n]

WTF? KFC BBQ! FTW!!

Re:More..

[Anonymous Coward]

FYI, Stat isn't an acronym.

Re:More..

[Anonymous Coward]

"Stat" is not an acr. but an abbr.

Re:More..

[Anonymous Coward]

Umm... what does it abbreviate?

Re:More..

[marcosdumay]

Well, if you don't know what are QT, GTK, LGPL and GUI, that article is really of no interest for you.

Re:More..

[Anonymous Coward]

Qt is not an acronym.

Re:More..

[Anonymous Coward]

in the manner I believe you are using it, "stat" is an abbreviation, not an acronym

Re:More..

[kLaNk]

statim

Re:More..

[Anonymous Coward]

Shut up. You'd soon be fucking complaining if there was too much to read. Yeah, call me a troll; bite me bitch.

Re:More..

[boaworm]

QFT!

Re:More..

[ianare]

sorry to be pedantic, but 'stat' is an abbreviation, not an acronym.

Re:More..

[Anonymous Coward]

"Stat" is not an acronym, actually. It's a an abbreviation derived from the Latin "statim," meaning "immediately."

Re:More..

[Anonymous Coward]

sorry, stat is not an acronym. It's just short for statum.

Technically, neither is ASAP, unless you are one of those people who actually pronounce it aysapp. The point is it has to be a word to be an acronym; otherwise it is just an abbreviation.

Ars Technica report

[Eukariote]

Ars Technica has a good report on this development: http://arstechnica.com/news.ars/post/20090114-nokia-qt-lgpl-switch-huge-win-for-cross-platform-development.html

Re:Ars Technica report

[Anonymous Coward]

And there is another analysis of the implications of the lgpl at

http://www.ics.com/files/docs/Qt_LGPL.pdf

Re:Ars Technica report

[bcrowell]

Thanks for the useful link! I didn't understand this:

The commercial licenses will still be available, however, for developers who don't wish to be constrained by the terms of the LGPL.

Can anyone suggest any realistic situation where the LGPL would be undesirable for a commercial app? According to the WP article, if you link your code to an LGPL library, the "non-(L)GPLed program can then be distributed under any chosen terms if it is not a derivative work," and it's not a derivative work if all you do is link to the library. All I can think of is that some commercial software house might want to make custom modifications to the source code of Qt, but then not release those modifications. However, that seems extremely farfetched to me. The most likely reason for such custom modifications would be that something in Qt was simply not working right on a particular OS or hardware. In that situation, I'm having a hard time imagining why the developer would want to take on the task of maintaining their own fork of Qt forever, instead of just committing their patches to the Git repository and being done with it.

A point that nobody seems to be mentioning is that the Linux world has essentially gone off in two different directions. On a default install of Ubuntu, almost everything is GTK. On a KDE-oriented distro, almost everything is Qt. Users generally want their apps to look similar, work the same way, and interoperate properly with their WM. So at least for Linux users, I would expect this to have relatively little effect.

Re:Ars Technica report

[pherthyl]

>> Can anyone suggest any realistic situation where the LGPL would be undesirable for a commercial app?

One example and something that I do with Qt+commercial license is static linking to get the exe size down and contained within one executable with zero dependencies. I can't do that with LGPL Qt. Other than that there just isn't much point in getting the commercial license anymore. You'd be better off just buying support when you need it.

Re:Ars Technica report

[tchuladdiass]

Both Sharp (with the Zaurus line) and Motorola (with their EZX phone platform) used modified QT (actually, QTE, QT Embedded). Not sure what their reasons were though.

Re:Ars Technica report

[JimDaGeek]

The LGPL only comes into play if you make changes to the QT code base. So, if you do a closed source app and add a feature to the QT code itself, then you will have to release the QT code change(s), however NOT your applications code.

Re:Ars Technica report

[djcapelis]

I think that's for people who want to maintain a private fork of Qt specially modified for their project. Qt has always given source code with their libraries and the commercial edition allowed modified versions of that library to be distributed. The LGPL does not change this restriction and those commercial users who have altered Qt and do not want to make those changes available still can buy a commercial license to allow for this.

Re:Ars Technica report

[spitzak]

The main problem is that the LGPL forces you to use Qt as a shared library if your program is closed-source. You cannot statically link with it as this violates the LGPL (technically it requires that end users have some method of relinking with a new version of the LGPL code, but the only practical solution is a shared library, as object files make your distribution twice as big and makes reverse-engineering your program a lot easier).

This is a problem for commercial developers who want to distribute a program to machines that don't have Qt installed.

It also is a problem for developers that want to modify Qt as they have to figure out how to make it call their own version and not cause DLL hell.

Re:Ars Technica report

[spitzak]

Replying to myself:

Personally I think the LGPL is not doing what it was intended to do, because when it was written they were thinking only about libc and not libraries that might not be included with the operating system.

Static linking should be allowed. The requirement that should be enforced is that if you modify the code in the LGPL library itself, you have to distribute the modifications. The rules are a bit more complicated so that you are not allowed to modify it to call a pointer that is set to point at a secret implementation, and other tricks.

The LGPL requirement for shared libraries is actually a big hindrance to complex libraries. It pretty much requires the binary api to be frozen. As anybody who has tried to write anything that complicated knows, that is quite impossible.

The other popular solution is to add a "linking exception" to the GPL/LGPL. Something called Classpath has the most popular wording. This pretty much makes the LGPL work like most people expect. One problem with this is that the "linking exception" completely hides all the differences between the GPL and LGPL (ie the result is exactly the same if you add the linking exception to either one). But without the name "LGPL" people don't think they can use the code in closed source. I think it would help a lot if GNU would standardize the wording of the "linking exception" and make it commonly known, so that people who see "GPL+linking exception" would know that it is even more useful than LGPL.

Re:Ars Technica report

[larry bagina]

you can still static link with LGPL, BUT you must provide object files so the end user can replace the QT library and rebuild the executable.

Re:Ars Technica report

[petermgreen]

You also have to release enough that the user can use your app with a new version of the library. If you are dynamic linking to Qt this is easy but if you are static linking for some reason (say to make an installer or a utility app that does not require installation) it adds complexity to your distribution process.

Re:Ars Technica report

[Anonymous Coward]

Personally I think the LGPL is not doing what it was intended to do, because when it was written they were thinking only about libc and not libraries that might not be included with the operating system.

If you look at the shared library clause from a security point of view, it seems that it is doing exactly what was intended, because they were thinking about needing to fix security holes in LGPL'ed libraries, without needing an update from every vendor that have used the library.

A long time ago, there was a critical zlib bug. Apps that used zlib as a shared library were fixed by simply updating the shared library. On the other hand, vendors that had static linked against zlib, were standing in line to send out updates to their apps, each including the exact same fix.

Re:Ars Technica report

[spitzak]

I agree that if you think the binary API is unlikely to have to change, the LGPL is a good idea.

However for a big library like Qt, it is far more likely that the binary api will change each version. With C++ especially this is almost impossible to prevent (believe me I have tried and been a complete failure at it). In this case the LGPL is a huge hindrance to allowing people to use your library, and in fltk's case we ended up putting in a linking exception.

It's official...

[sznupi]

...no reason for Gnome to exist anymore! ;)

Re:It's official...

[bartok]

Correct me if I'm wrong (and I hope I am) but since KDE and it's libraries is based on the GPL'ed version of QT, it is itself GPL'ed, which means that you need to GPL your code is you want your app to integrate with KDE..????????

Re:It's official...

[Anonymous Coward]

Correct me if I'm wrong (and I hope I am) but since KDE and it's libraries is based on the GPL'ed version of QT, it is itself GPL'ed, which means that you need to GPL your code is you want your app to integrate with KDE..????????

The KDE libraries have always been LGPL.
Read http://techbase.kde.org/index.php?title=Policies/Licensing_Policy for details.

Re:It's official...

[entrigant]

KDE is based on Qt. There are not separate versions of Qt. There is one version of Qt, and _you_ choose which license you want to abide by. The KDE app/library need only be licensed with a license that is compatible with one of the available Qt licenses. The kde libraries have been LGPL for a long time, but you still needed a Qt license if you wanted to develop a closed source app because Qt was GPL or commercial only.

Re:It's official...

[NetCow]

Correct me if I'm wrong (and I hope I am) but since KDE and it's libraries is based on the GPL'ed version of QT, it is itself GPL'ed, which means that you need to GPL your code is you want your app to integrate with KDE..????????

You are correct. KDE applications currently must be licensed under the GPL.

Re:It's official...

[Anonymous Coward]

You are wrong. Kdelibs is LGPL !!!

Re:It's official...

[jopsen]

AFAIK the source for the KDE libraries are LGPL, which means that if you bind them against a LGPL version of Qt you'd have LGPL KDE libraries...
At least I remember to have read so somewhere....

Re:It's official...

[Anonymous Coward]

yes, you are wrong. All kde libraries (kdelibs, kparts, plasma, phonon, solid, etc) are all LGPL.

Re:It's official...

[Tatsh]

...no reason for Gnome to exist anymore! ;)

KDE is Qt-based but with a lot of CRAP added on top, just for desktop integration reasons, much like GNOME on top of GTK+. I do not need GNOME to run many GNOME apps; this is not so much the case with KDE (at least with version 3).

I love Qt 4 by itself. It's stylish, looks good on Windows and Mac, very portable and a VERY easy API IMO. (Only thing I do not like very much is C++.)

My problem with desktop environments (which is the problem interoperability is SUPPOSED to solve) is there is barely any. You might be able to IMPORT settings from one desktop email app to another's (say they both use MBOX format). I found that KMail imports Thunderbird MBOX files terribly. Besides, if you have Kaffeine for a media player, how do you import those settings to another? Do we need standards here too (a standard settings file for media players)? (Personally I think it is a bit over the line, but could be very useful). Maybe a whole set of standard preferences files?

Right now I cannot move to KDE 4 or GNOME. I am a little bit stuck on KDE 3 (at least till KDE 4 can do everything correctly) and my life is in Kontact. I love KDE, but the ability to switch at any time with ease would be great.

Re:It's official...

[Anonymous Coward]

If Gnome did not exist, it would be necessary for developers to invent it.

Re:It's official...

[stilborne]

That is factually incorrect: KDE applications can be (and are) released under a number of Free software licenses, including the BSD license, LGPL, GPL, MIT, X11, etc... you can see the licensing policy here: http://techbase.kde.org/Policies/Licensing_Policy ... you can also purchase a license from Qt Software and build proprietary applications. Qt itself has quite a permissive set of license exceptions as well: http://doc.trolltech.com/4.4/license-gpl-exceptions.html

So what really changes here is people not being required to purchase a license to do proprietary development and the people in the FOSS world who felt that was such a problem that they wouldn't touch Qt can now rest easy and use it.

Re:It's official...

[alexme]

Look Here

License(s):
Libraries: LGPLv2
Some helper binaries: GPLv2
Some code may have more permissive licenses.

Re:It's official...

[Brandybuck]

It a perverse way, it's true. GNOME as a desktop only started as a direct result of Qt not being Free Software. That has no bearing on GNOME's current existance, of course. It's now going to have to stand on its own technical merits, however, and not hide behind silly licensing issues.

Re:It's official...

[Brandybuck]

You are incorrect. Qt is under the GPL **PLUS** exceptions allowing all commonly used Open Source licenses. Your KDE applications must be under an Open Source license, but you can choose GPL, LGPL, BSD, MIT, MPL, etc, etc.

Let Joy Be Unconfined

[netpixie]

Whilst being very good at code and generally geekery, Trolltech are total rubbish at the support game, leaving paying developers (i.e. me a few years ago) feeling massively shafted when being told "here's the code, fix it yourself". WTF am I paying for If I have to not only find your bugs, but fix them as well?

Now everything is back as it should be - free code and no support, the way God intended.

Re:Let Joy Be Unconfined

[pherthyl]

Huh, I've always gotten great support through their commercial support. Usually things were fixed ASAP. But I guess it depends on the issue.

Re:Let Joy Be Unconfined

[RiotingPacifist]

Before you used to pay trolltech for the license so you could keep your code closed, now you pay them nokia for support. Id think if the entire business plan has changed, its a bit harsh to assume that the support will be poor.

Re:Let Joy Be Unconfined

[Anonymous Coward]

Whilst being very good at code and generally geekery, Trolltech are total rubbish at the support game, leaving paying developers (i.e. me a few years ago) feeling massively shafted when being told "here's the code, fix it yourself". WTF am I paying for If I have to not only find your bugs, but fix them as well?

Now everything is back as it should be - free code and no support, the way God intended.

"Here's the code, fix it yourself"? I'll happily do that with QT. It's a great starting point, where we'll _all_ be in ten years will be astounding.

Re:Let Joy Be Unconfined

[Anonymous Coward]

Really ? I've been a commercial Qt developer for more years than I'd like to remember;I find their support to be top notch. From what I understand Nokia will still offer a commercial license for those who aren't totally convinced about the predictability of open source support. When you do this thing for a living you really need some guarantee that someone is going to answer your cries for help within a day or two, not just whenever 1) someone who already experienced the same problem as you 2) happens to see your post and 3) takes the time to reply and 4) provides a useful answer.

Re:Let Joy Be Unconfined

[DrinkDr.Pepper]

Trolltech are total rubbish at the support game

As a commercial licensee, I've found Trolltech's support to be very good. Actually, they are one of the best I've dealt with.

So which is better "free code and no support"; free code and expensive support; or no code and no support (e.g. the way MS does it)?

Re:Let Joy Be Unconfined

[netpixie]

Let's put it like this: Since we migrated our software to GTK, the free support I've had from the GTK mailing list has been head and shoulders above any "support" I ever had from Trolltech, and that was when we were paying them.

Obviously you are a happy camper, and I'm pleased, and I'm even more pleased that you never ended up in the situation we did where the "guarantee that someone is going to answer" failed to materialise.

The tuth is, paying Trolltech only ever increased your chances of getting a decent answer, it never guaranteed it.

The happy situation now is that they can carry on providing the same crappy, random, non-deterministic, substandard, unhelpful "support" as they have been doing all along, but now they won't be charging through the nose for it.

Which can only be good.

Re:Let Joy Be Unconfined

[JoeMerchant]

Whilst being very good at code and generally geekery, Trolltech are total rubbish at the support game, leaving paying developers (i.e. me a few years ago) feeling massively shafted when being told "here's the code, fix it yourself". WTF am I paying for If I have to not only find your bugs, but fix them as well?

I've had mostly the opposite experience with Trolltech support - I don't ask them for much, but the things I do ask about have been 90% fixed within 2 releases, not necessarily for me but fixed nonetheless.

I had a funny exchange with a Troll a few months ago regarding the availability of memory mapping for files via Qt, he said it was coming "eventually" - turns out it had been available since the last release a few weeks earlier, neither of us had bothered to slog through the documentation recently.

Re:Let Joy Be Unconfined

[JoeMerchant]

Concur - MS actually had a programmer support line (18+ years ago), it was a total joke, but of a completely different style than the total joke of MSDN. I think I was on (800 line speakerphone) hold for 4 hours once....

Re:Let Joy Be Unconfined

[Anonymous Coward]

You got me until the "free support from the GTK mailing list" bit. IME you are very lucky if a) someone answers your mail b) the answer is actually useful.

My worst programming months were dealing with GtkTreeView. Pure misery, little docs, no answers on the mailing list.

Re:Let Joy Be Unconfined

[Brandybuck]

Trolltech support was absolutely awesome. But since the Nokia aquisition it has been in a serious decline. Sigh.

Re:Let Joy Be Unconfined

[IceFox]

Fun small world :) mem mapping was a feature I added to Qt 4.4. I even wrote a blog entry on it on labs.trolltech.com http://labs.trolltech.com/blogs/2007/10/15/file-mapping/

Re:Let Joy Be Unconfined

[JoeMerchant]

Fun small world :) mem mapping was a feature I added to Qt 4.4. I even wrote a blog entry on it on labs.trolltech.com http://labs.trolltech.com/blogs/2007/10/15/file-mapping/

I think I added the labs.trolltech.com RSS to my startup page shortly before after that happened, but after your post ;-)

Keep up the good work! It really is like having extra staff compared to the "bad old days" when we'd have to keep up with shifting OS requirements on our own.

Re:Let Joy Be Unconfined

[elysiuan]

GtkTreeView and it's buddy GtkListView are pretty much the most over-engineered and terrible bits of GTK.

I feel your pain brother :(

It's not great news for everyone

[Anonymous Coward]

It's great news for everyone, except for Trolltech. Good luck paying the bills, or hiring new developers, when your revenue stream goes away.

Re:It's not great news for everyone

[Anonymous Coward]

Ummm...I think Nokia, who now owns Trolltech, will be paying their bills.

Re:It's not great news for everyone

[Tetsujin]

It's great news for everyone, except for Trolltech. Good luck paying the bills

Ummm...I think Nokia, who now owns Trolltech, will be paying their bills.

Well, I have to admit I had the same concern when I read this story. If they're decreasing their push to get people to buy commercial licenses, and if the whole Qt business is now insignificant relative to the overall business of Nokia anyway, then how strong will their commitment to future development and maintenance of Qt be?

Not like I can see the future or anything, it just concerns me a little.

Re:It's not great news for everyone

[Rhapsody Scarlet]

Well, I have to admit I had the same concern when I read this story. If they're decreasing their push to get people to buy commercial licenses, and if the whole Qt business is now insignificant relative to the overall business of Nokia anyway, then how strong will their commitment to future development and maintenance of Qt be?

Not like I can see the future or anything, it just concerns me a little.

My impression of this is that Nokia think they can make more money by getting Qt spread far and wide then selling support for it than they could by having a small amount of people paying for commercial licenses. They may be right, and I certainly hope they are.

Hurrah

[caluml]

Well, thank heavens for that. Hopefully now the horrible, oldfashioned looking, bad file-selecting-dialogs GTK will slowly disappear. The number of times I've had to select something in /usr/bin, and have started to type /usr/bin only to have it try and go to /usr/sr or some nastiness.

Re:Hurrah

[SCHecklerX]

yet another reason I use rox-filer. Select thing, it is in your cut buffer. Bypass the gnome crap and just middle-click after selecting using your file manager.

Re:Hurrah

[RiotingPacifist]

my main cause of that is firefox, which can be worked around by setting ui.allow_platform_file_picker to false [1]
hopefully the qt port of firefox will eventually work too.

Re:Hurrah

[caluml]

Oooh, that's interesting - very nice tip! Merci beaucoup!

Wierd...

[Anonymous Coward]

It's not every day that a cross-platform GUI framework suddenly turns into (becomes) a licence...

Re:Wierd...

[Anonymous Coward]

And it's not every day that "weird" is spelled "wierd", except here on slashdot. :)

Large uptick in Qt usage?

[Mad Merlin]

The only complaint I've seen before about Qt is that it's too expensive for proprietary apps, and that's not an issue anymore. I won't be surprised to see a large uptick in Qt usage now, and that's a big plus for cross platform apps, as Qt is quite portable.

Re:Large uptick in Qt usage?

[GooberToo]

The only complaint I've seen before about Qt is that it's too expensive for proprietary apps

Then you've not been listening. Many don't like the noteworthy long start up times of Qt apps compared to say Gtk. Many don't like the need for obtuse tools like SIP. I know for a while they were working to address the long start up times I've not followed where that went. Perhaps it's no longer an issue.

Frankly, the API of Qt make Gtk look like a pile of vomit, but simple fact is, Qt is not the perfect GUI programming environment.

Re:Large uptick in Qt usage?

[vurian]

Nothing human is perfect. However, having used GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt, I have to say that Qt beats the others consistently in look & feel, ease of development, clarity of documentation, orthogonality of API and breadth of features. Not to mention cross-platformity :-) Plus, the tools, like Designer, Linguist, Creator and Assistant are top-notch.

Re:Large uptick in Qt usage?

[arendjr]

Then you've not been listening. Many don't like the noteworthy long start up times of Qt apps compared to say Gtk.

Long start-up times have been fixed ever since Qt4 was released quite a while ago.

Many don't like the need for obtuse tools like SIP.

I've never used SIP myself, but it's that tool for generating bindings for other languages, right? So that's only required if you're generating your own bindings. And even then I fail to see how that's worse than writing the bindings by hand...

Re:Large uptick in Qt usage?

[siride]

Qt apps start up pretty damn fast for me. I can't really tell a difference between Qt and GTK+ start up times, honestly. Using "time gedit" and "time kedit" and then clicking the close button as fast as I can yields nearly equal times, at about half a second.

Re:Large uptick in Qt usage?

[LWATCDR]

To expensive? It seemed fair to me. My company bought it. I just hope they keep selling it. LGPL means that you can not legally statically link it in a close program. That can actually be pretty handy at times.

Re:Large uptick in Qt usage?

[IceFox]

On the startup issue I think it was many times applications and not Qt that were slow. For Arora ( http://arora-browser.org/) I spent time making it startup very quick. I wanted to be able to launch the browser from nothing whenever I clicked on a link. Feel free to check it out yourself and see how fast startup can be. Qt 4.5 has improved performance across the board and no doubt some of that will help on startup also.

Re:Large uptick in Qt usage?

[radtea]

GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt,

I've used most of those, although NEXTStep rather than GNUStep. I used Qt very heavily in the late 90's and early 2000's, but moved to wxWidgets a few years ago, in part due to Qt's licensing costs, and now never plan to go back.

I've found wx easy to use, well-documented, well-supported across platforms and languages (using wxPython heavily at the moment as well as C++) and generally lighter weight than Qt.

The things wx "lacks" are things that I don't need and don't want anyway, like a nice GUI builder--although arguably BOAConstructor fits the bill for wxPython, and I guess maybe DialogBlocks for C++. I use code generators for all my UI coding, which gives me far more flexible and robust layouts much more rapidly than a GUI builder can.

Re:Large uptick in Qt usage?

[Anonymous Coward]

> LGPL means that you can not legally statically link it in a close program.

It may not help you, but that is wrong.
You must only do it in a way that still allows swapping out the Qt libs,
e.g. by providing a tarball with the .o files from your code and a Makefile that links those together and against the Qt libs.

Re:Large uptick in Qt usage?

[DrinkDr.Pepper]

Long start-up times have been fixed ever since Qt4 was released quite a while ago.

That's a joke, right?

Re:Large uptick in Qt usage?

[0xABADC0DA]

The only complaint I've seen before about Qt is that it's too expensive for proprietary apps

Here's a problem with Qt... it's C++. They sat down and said "lets build the very best C++ widget API", and they did. That's great, but lets think about this for a second:

* C++ is a terrible language to use for applications. Lack of garbage collection, incoherent error messages, poor error handling and recovery, no closures, etc. You know the drill.

* C++ is a terrible language for interoperability. 'Name munging', difficulty calling overloaded methods from C or other languages, compiler differences, etc. And Qt adds a few more problems like MOC and macros.

GTK is written in C which is an even worse application language, but far better for interoperability. Any language implementation can trivially easily bind to GTK functions. So I grant that Qt is an excellent C++ UI toolkit, but that's like saying a platypus is an excellent duck; the comparison has some merit, but mostly just leaves people scratching their heads.

Re:Large uptick in Qt usage?

[Anonymous Coward]

The only complaint I've seen before about Qt is that it's too expensive for proprietary apps

Then you've not been listening. Many don't like the noteworthy long start up times of Qt apps compared to say Gtk.

I disagree. I have written several QT apps and have run them on Mac, Win and Linux and I have never felt them to be sluggish.
-Kaushik

Re:Large uptick in Qt usage?

[LWATCDR]

Maybe you missed that in a closed program part?

Re:Large uptick in Qt usage?

[geminidomino]

I have to say my experience differs. Same test (flawed due to the human interaction part of it, admittedly) gives a huge difference

domino@foamy:~$ time gedit

real 0m1.639s
user 0m0.624s
sys 0m0.116s

domino@foamy:~$ time kedit
kbuildsycoca running...
Reusing existing ksycoca
DCOP Cleaning up dead connections.

real 0m8.329s
user 0m0.404s
sys 0m0.112s

In fairness, an immediate second run of kedit closes the gap nicely (and I knew where the window would be, so I'd put it at about parity with gedit):

domino@foamy:~$ time kedit

real 0m1.384s
user 0m0.580s
sys 0m0.084s

Re:Large uptick in Qt usage?

[Anonymous Coward]

One issue I had with Qt, and one reason it might be less popular, is that an writing for an OS not based on *nix is considered to be a pain, at least in some circles. For many the only reason to use Qt is so the software can run on MS Windows, but if one is running on MS Windows then one has to use the functionality of MS Windows. This means that in many cases while the GUI is cross platform, the underlying functionality is not. The most glaring example of this is pipes.

Qt was one of several solutions to the cross platform problem, particularly if the code is going to based on C. C, and C++, however, have not proven to be as cross platform as they might be, at least outside the *nix world. I think other solutions have gained more traction. Java is language of choice for application that have to be very cross platfrom. Then there is the option of executing code on the serve and rendering the output on a browser, something which is the often the safest option.

If Nokia really pushes Qt the Qt GUI and process control to be on par with Java, and the C++ libraries get updated much more quickly than they have, QT has a chance to be more than the GUI of choice for *nix.

Re:Large uptick in Qt usage?

[siride]

Are you running that from GNOME? I didn't have to have all that kbuildsycoca because I was already running KDE so everything is ready to go. I admit that that's a bit annoying, but it's a one time thing per session and usually doesn't take that long on moderately modern hardware.

Re:Large uptick in Qt usage?

[JoeMerchant]

Nothing human is perfect. However, having used GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt, I have to say that Qt beats the others consistently in look & feel, ease of development, clarity of documentation, orthogonality of API and breadth of features. Not to mention cross-platformity :-) Plus, the tools, like Designer, Linguist, Creator and Assistant are top-notch.

For QtGUI, I concur, at least for the 50% of your list that I have worked in personally. As for the tools, I wouldn't call Designer or Creator top-notch, and Assistant became a royal pain in our ass when it came time to deploy on Windows (oh, you want to install your app in a directory with a space in the name? Yeah, like C:\Program Files\xxx, sorry, can't do that.)

Re:Large uptick in Qt usage?

[JoeMerchant]

Long start-up times have been fixed ever since Qt4 was released quite a while ago.

That's a joke, right?

Not for me, I've got a big app that does lots of initialization before even trying to open a window, the splash screen is up before you hear the mouse button release click, and the main window is open and drawn less than one second later. (we need the splash to show some legal stuff, otherwise we wouldn't have one at all.)

Re:Large uptick in Qt usage?

[Anonymous Coward]

Then you've not been listening. Many don't like the noteworthy long start up times of Qt apps compared to say Gtk.

Long start-up times have been fixed ever since Qt4 was released quite a while ago.

Then he's not been listening.

Re:Large uptick in Qt usage?

[mr_da3m0n]

Many don't like the noteworthy long start up times of Qt apps compared to say Gtk.

While I will agree with you that Qt is not the holy grail of toolkits, I wonder if maybe you are not confusing Qt with kdelibs in general here.

A KDE Application on a non KDE desktop will take forever to launch at first because it must launch all the other kde communication processes, like dcopserver. It has been a while since I used KDE, but I recall it then launched all the generic processes that would provide kioslaves and friends.

Again, It's been a while since I used KDE, I could be wrong, but this is at least how I recall it.

Re:Large uptick in Qt usage?

[stilborne]

"the noteworthy long start up times of Qt apps compared to say Gtk"

take today's Qt (e.g. 4.4 or the upcoming 4.5) built with a modern c++ toolchain (e.g. something from the last year or two) and compare it with Gtk (or any other toolkit). you'll find that start up times are really not an issue anymore. if the app is starting slowly, it's not because of Qt.

"Many don't like the need for obtuse tools like SIP"

SIP is used to do bindings. unless you are making bindings, you never see or use SIP. if writing in C++, that statement about SIP becomes even more absurd.

perhaps you were thinking of moc, which adds introspection and signal/slot glue to C++ classes. that, also, is never seen. the build system handles it transparently for you.

class MyObject : public QObject
{
        Q_OBJECT ....
};

is all you do.

Re:Large uptick in Qt usage?

[stilborne]

your entire post is moot, as there are high quality Python, Ruby and Java bindings for Qt and KDE. in-application scripting with JavaScript is also fairly common now as well, though that's a bit of a different topic. bindings for Perl and other languages also exist, but the Ruby and Python bindings are the ones i recommend to people doing application development.

heck, KDE even ships an app written in python (the printer manager) these days.

so whether or not C++ is a good language, not a good language, easier or harder to bind compared to C or not is neither here nor there. bindings exist for "better" (according to your metrics) languages and work damn well. use them, be happy and step off the rather irrelevant soapbox.

Re:Large uptick in Qt usage?

[Randle_Revar]

I just started Psi (cold start) in less than 2 seconds (profile loaded, connected to server). Granted, this is a C2D @ 2.66 GHz with DDR2 800, but I remember it being quick on my Athlon XP @ 1.8 GHz with DDR 333.

In general, I have found KDE4 apps to start up fast, faster than the KDE3 counterparts. Starts are very reasonable even when all the KDE background services need to be stared first (most of the time, since I use Awesome, not KDE).

4-5 second start for background + Konqueror just now.

Re:Large uptick in Qt usage?

[Anonymous Coward]

GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt,

I've used most of those, although NEXTStep rather than GNUStep. I used Qt very heavily in the late 90's and early 2000's, but moved to wxWidgets a few years ago, in part due to Qt's licensing costs, and now never plan to go back.

I've found wx easy to use, well-documented, well-supported across platforms and languages (using wxPython heavily at the moment as well as C++) and generally lighter weight than Qt.

The things wx "lacks" are things that I don't need and don't want anyway, like a nice GUI builder--although arguably BOAConstructor fits the bill for wxPython, and I guess maybe DialogBlocks for C++. I use code generators for all my UI coding, which gives me far more flexible and robust layouts much more rapidly than a GUI builder can.

Please, don't say something like that, I hate using applications made in wx. They look ugly as hell on most platforms, and I hate having to use aMule on my mac just because it's made on wx

And as they aren't native gtk applications, they also look like shit on some gnome themes, and I'm not even talking about how it looks on KDE

Re:Large uptick in Qt usage?

[Ilgaz]

I got KDE 3.5.9 (Fink compiled) installed to my OS X Leopard on Quad G5 (quad is not very relevant in this case) and kicker, the main component of KDE and the stuff it triggers (most of KDE shared libs) runs in less than 2 secs.

Konqueror takes 2 more secs to start. Psi (which I have in native form) is really hard to time, must be way less than 1 secs.

I wonder where that "Qt apps start slower" thing comes from. Windows? Well, Opera would have horrible load speed if it was the case while we all know it starts even faster than IE sometimes. Linux? Filesystem? Some really badly coded application or a real complex scientific application?

Re:Large uptick in Qt usage?

[mrchaotica]

I missed the part where distributing .o files (i.e., not source files) for a closed program is inherently a problem. (I can see where it's perhaps inconvenient, but that's not a deal-breaker.) You could even mostly pre-link the thing, so that all the user has to do is link together my_closed_program.lib and KDE.lib.

Re:Large uptick in Qt usage?

[elysiuan]

On Linux wxWidgets uses GTK to render it's widgets.

That's the whole point of wxWidgets. It uses the native system widgets where ever it happens to be running not some weird copy of them it makes.

Re:Large uptick in Qt usage?

[GooberToo]

Please, don't say something like that, I hate using applications made in wx

So you have the look of your native widget set? WX apps look like native applications. I'm not 100% sure that's the case on Mac, but I believe it to be true.

Re:Large uptick in Qt usage?

[GooberToo]

I wonder where that "Qt apps start slower" thing comes from.

Actually it's a well documented issue. Feel free to do some searches. As I originally said, I'm not sure it's still an issue. The responses seem to be a mixed bag.

Re:Large uptick in Qt usage?

[GooberToo]

Actually you're right, I was thinking of moc. It's been a while since I last did some Qt coding.

Re:Large uptick in Qt usage?

[pherthyl]

Huh? I was using assistant as my help system on windows. No problems with spaces in paths.

And now they have the QtHelp system, which is even better.

Re:Large uptick in Qt usage?

[JoeMerchant]

Our problem came (comes) at deployment time onto systems that don't have the developer libraries installed.

Re:Large uptick in Qt usage?

[pherthyl]

Yeah I didn't have any problems with that. Hard to tell what was going on in your case though. I just put assistant.exe into the same directory as the app (program files/blah) and the appropriate qt libs and everything worked.
Now I switched to my own custom help viewer written with QtHelp, so I don't have to distribute assistant.exe or individual html files (since it's now compressed)

Re:Large uptick in Qt usage?

[geminidomino]

Yeah, that's where I figured all the extra time went.

Re:Large uptick in Qt usage?

[Anonymous Coward]

My company bought it. I just hope they keep selling it.

Yes, they will continue offering Qt under a commercial license as well as under the GPL. Its on their FAQ page which was linked to by someone above.

(posting anon coz I've mod'd)

Re:Large uptick in Qt usage?

[Anonymous Coward]

Audacity.

It is a mistake to even think of porting

[WindBourne]

I use to be a KDE developer, and I have to say that I love QT/KDE platform (and still use it). But with that said, I find that OSS moves faster BECAUSE of friendly competition, not in spite of it.

Wow, great news

[Anonymous Coward]

Over the years I have said many times that TrollTech should have lowered their prices considering things like the Apple Developer's kit and MSDN are significantly cheaper for more functionality.

I have been in need of a good GUI toolkit for years. I have used just about all of them but for my own projects I either use the native toolkit of the OS I'm working on or FLTK for cross-platform stuff. Qt is much more functional than FLTK though with all their SQL and other utility classes. This is really cool. I bet Qt is now going to become the defacto GUI toolkit for everything.

I wonder how long until someone makes a Qt version of GNOME (ha, I can't imagine how much work that would take). You could start with making a Qt version of The GIMP.

Re:Wow, great news

[sucker_muts]

You could start with making a Qt version of The GIMP.

A lot of people don't know this, but GTK stands for 'The GIMP Toolkit', and Gnome used this toolkit. Not the other way around! :-)

http://en.wikipedia.org/wiki/Gtk

Re:Wow, great news

[xtracto]

What about wxWidgets, have you tried it?

Has anyone used both of them enough and can do an informed comparison of their functionality/easy of use [programming]?

Re:Wow, great news

[pherthyl]

Yep, I spent a few months using wxWidgets a couple years ago. I just didn't like it. Obtuse MFC style message maps just screamed ugly at me. Same with lots of macros that needed to be there for certain automated tasks. The documentation isn't as solid as that of Qt, and I found a lot more bugs just playing with it than I ever found in writing serious code with Qt.

When Qt was expensive, wxWidgets was an option (even though I still elected to pay for Qt myself) but now I just can't see any reason why you would want to use it apart from legacy support.

Re:Wow, great news

[Hairy Heron]

Why would you make a version of the GIMP that doesn't use the GIMP's own toolkit?

Re:Wow, great news

[Jane_Dozey]

I'm currently using wxWidgets and have used Qt in the past. I'm using wx as using Qt would have meant having to get a paid license but with this news I'm considering talking to my boss about maybe making a pyQt version.

I like Qt better as it's always felt just more complete and functional. wxWidgets is good but it lacks in areas and doesn't seem to have a really decent UI designer. I've also been warned that for more complex applications it can be a headache to get unit testing (important in my job) to work nicely with wx in comparison to other python GUI toolkits.

Re:Wow, great news

[VZ]

Yep, I spent a few months using wxWidgets a couple years ago. I just didn't like it. Obtuse MFC style message maps just screamed ugly at me.

Strange things is that people still don't realize, even after many years spent explaining this -- and not only on Slashdot, mind you -- that MFC-style message maps are just one way of connecting events in wxWidgets and that there exists a superior and more flexible, but somewhat more verbose, way to do it with Connect(). In my biased-but-still-struggling-to-be-objective opinion Connect() beats the horror that is moc hands down.

Re:Wow, great news

[Lysdestic]

Fair enough, but by my understanding GTK began as something for GIMP, which stands for GNU Image Manipulation Program, the east way around this being that you could call it QIMP.

Sure it's weird, but it works. =\

Re:Wow, great news

[qbast]

You could start with making a Qt version of The GIMP.

It is called Krita. And actually has usable GUI as a bonus.

Re:Wow, great news

[Tetsujin]

You could start with making a Qt version of The GIMP.

It is called Krita. And actually has usable GUI as a bonus.

Usable GUI is a standard feature with GIMP, though, why is it a "bonus" with Krita? :D

Ah, but I kid. I don't share people's complaints with the GIMP UI but I am familiar with the complaints.

I would say other features of Krita are more significant - things GIMP sorely lacks like 16 bit color channels. Even if a person doesn't have the need to output their files with that kind of color resolution, it's simple math to realize that the extra resolution is helpful if you're doing any transformations of the data - and if you're not doing transformations of the data, then why use the app in the first place?

Re:Wow, great news

[psydeshow]

You could start with making a Qt version of The GIMP.

Or better yet, a Qt version of Photoshop 7.

If you're going to re-engineer an image manipulation interface, why start with one that gives graphic designers hives?

I like The Gimp, except for the horrible type engine, but I'd still rather use a pre-CS version of Photoshop.

Re:Wow, great news

[larry bagina]

Great, instead of the GIMP (a gay sex slave or cripple) we can have QIMP (quim is british slang for pussy). Actually, that would be an improvement!

Re:Wow, great news

[Game_Ender]

PyQT is made by another company, http://www.riverbankcomputing.co.uk/ and is still under the same license as the old QT. It remains to be seen whether or not they will change license now that QT itself has. They did change there windows licensing when QT did, so there is hope.

Re:Wow, great news

[__aabvlw4075]

I'm pretty sure (almost) everyone who knows what GTK is knows that. The only people that don't know it are those who use Windows or a Mac and have never heard of GTK, anyway.

In any case, what does that have to do with making a Qt version of the GIMP? If it's an idea with technical merits, I'm sure the GIMP developers would consider it, regardless of the history behind their current toolkit.

Re:Wow, great news

[pherthyl]

As commenters in that article also mention, the docs recommend (or at least did for a very long time) the event table approach. Not surprising that people are using it and not aware of an alternative.

What exactly is "the horror" of moc? In normal programming you will never be aware of its existence and it does a lot more than signal/slot connections for you (introspection for example).
In many ways Qt brings the benefits of higher level languages like C#/Java to C++.

Signals and slots are also safer/easier than Connect, based on the last comment on that blog: "It should be noted that ... you should always remember to disconnect the event handler in the event handler object's destructor, otherwise your application may crash if/when the handler is called after your event handler object is destroyed."
That can never happen in Qt. If you delete an object it is automatically disconnected from any signals it may be connected to.

Re:Wow, great news

[dancpsu]

If Connect() is so great, then why does the wxwidgets events doc hide it and practically discourage its use by stating that everything happens at run time with Connect()? Why do introductory tutorials rely on event tables rather than Connect()? In short, why does wxwidgets force developers to slog through event tables if you have Connect()?

Re:Wow, great news

[Ilgaz]

If GIMP people really listened and acted on user feedback, they wouldn't wait until 3.x to ship a native widget using GIMP (not native in Qt sense) or they would already add that CMYK thing which some DTP guys whining (!) about. :)

Re:Wow, great news

[losinggeneration]

You could start with making a Qt version of The GIMP.

A lot of people don't know this, but GTK stands for 'The GIMP Toolkit', and Gnome used this toolkit. Not the other way around! :-)

I think that's what would make it funny. GIMP switching toolkits... Genius!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Why?

[WindBourne]

Did Netcraft confirm it? Or is it MS that is trying to do that?

NetCraft Confirms It, GNOME is Dead!

[Anonymous Coward]

n/t

Die Gnome

[kenp2002]

Perhaps now we can finally get enough momentum to end this Gnome\KDE battle and get KDE to win so we can settle on ONE desktop environment so we can get back to writing 40 different window managers.

QT + KDE = 1 Desktop Standard Linux (hell even Windows) folk can get behind.

Gnome + KDE = Goblin Desktop (You can thank me for coming up with that name

Merge the teams, move forward with KDE and lets get Linux on the desktop in earnest.

Re:Die Gnome

[Cthefuture]

I don't think so. GNOME is more that a GUI toolkit and as a developer I much prefer many of the GNOME API's over KDE. I have always hated Gtk+ though. Switching GNOME to use Qt would make more sense than ditching all the other excellent GNOME stuff.

Re:Die Gnome

[LWATCDR]

I really like Gnome better than KDE. You can run QT applications under Gnome just fine.
What I wonder is if we could see OpenOffice or Mozilla move to QT for the widgets :)

Re:Die Gnome

[Snodgrass]

Yeah, which would be great if everybody liked KDE. Which clearly isn't the case, since a whole lot of people still use GNOME.

Personally, I can't think of anything that would get me to use KDE.

Re:Die Gnome

[qbast]

Really? Which parts? Was it Bonobo that got you so enamored? CORBA, GNOME-VFS ? Or maybe GObject pseudo objects (which are quite cute in grotesque sort of way) ? Please share, because after several minutes of trying to come up with any API that is better in GNOME I still draw blank.

Re:Die Gnome

[Anonymous Coward]

Perhaps now we can finally get enough momentum to end this Gnome\KDE battle and get KDE to win so we can settle on ONE desktop environment

That you care which one wins demonstrates why this will *never* happen.

Re:Die Gnome

[characterZer0]

You realize that there are a lot of people that use neither KDE nor Gnome, right?

I've been using Enlightenment for years, and have no intent to switch.

Re:Die Gnome

[kenp2002]

Last I checked (about 3 years ago) enlightment was still more a window manager then a complete desktop environment. Boy do times change. Too bad 99.9% of people out there have no clue about black\fluxbox, enlightment, and can't tell the difference between Gnome and Sawfish. That's why we need one desktop environment platform to go forward with.

It never ceases to amaze me with the linxu could how they'll complain about 2 open document standards (ODF and MS XML based one) and how bad it is for there to be two standards but by God they'll defend a plethora of desktop standards with their lives it seems.

Curious I'd say. We need A standard. DBUS isn't cutting it. 1 platform = better more focused development.

Re:Die Gnome

[alexme]

Look here. There's port of firefox with qt4 done by Mozilla and Nokia Mobile Browser teams.

Re:Die Gnome

[digitalunity]

Good luck with that. I would like the same thing, but it just isn't going to happen.

Re:Die Gnome

[LWATCDR]

Nice on Mozilla but makes me wonder about one other thing. How about Swing ported to us QT for widgets or QT for Java.
Now that it is GPL maybe we could fold QT into Java for GUI applications.

Re:Die Gnome

[characterZer0]

Ideally, different destktops would be different implementation of the same standard. Unfortunately, ICCCM, NetWM, and freedesktop all seem to be insufficient.

Re:Die Gnome

[Anonymous Coward]

But without proper config, it looks just plain ugly due to problem with font hinting, theme etc, now that qt is LGPLed, I would like to switch to KDE/Qt apps, only if KDE 4 doesn't suck so much.

Re:Die Gnome

[t_ban]

Perhaps now we can finally get enough momentum to end this Gnome\KDE battle and get KDE to win so we can settle on ONE desktop environment so we can get back to writing 40 different window managers.

Many people on this thread seem to desire Gnome's death. I myself was one of them till KDE4 came out. Unfortunately, I haven't been able to go from 3 to 4 like I went from 1 to 2, or 2 to 3. Maybe I'm in a minority, but I find KDE4 unusable. OpenSuSE 11.1 gives me the option to remain with KDE3, and I have chosen to do that on my desktop box. But for how long? In a version or two, they will not include KDE3 any more, and what option will I have then? On my laptop, I have already shifted to Gnome, because Intrepid doesn't offer any easy way to retain KDE3.

If Gnome dies, I lose the only GUI I find usable at this point. I sure hope it doesn't.

- t.

I'm not a copyright lawyer

[windsurfer619]

Could someone summarise the difference between the LGPL and the GPL? Thanks.

Re:I'm not a copyright lawyer

[Anonymous Coward]

Could someone summarise the difference between the LGPL and the GPL? Thanks.

LGPL allows closed-source programs to link with the library in question.

Re:I'm not a copyright lawyer

[Anonymous Coward]

GPL: Not as in Free Beer
LGPL: Free Beer, but you can't change the recipe.

Re:I'm not a copyright lawyer

[Constantine XVI]

If you have a piece of GPL code in your program, all of the program must be GPL. LGPL only applies to the LGPL code and any changes you make to it (your original code can be under any license)

Re:I'm not a copyright lawyer

[JohnFluxx]

A proprietary (closed-sourced) program cannot use a GPL'ed library. So previously you couldn't write a closed-sourced program with the GPL'ed version of Qt.

But now you can.

Re:I'm not a copyright lawyer

[torstenvl]

A BSD-licensed program cannot use a GPL'd library, either. GPL is license-incompatible with everything else, not just closed-source.

Re:I'm not a copyright lawyer

[Anonymous Coward]

From Wikipedia

The main difference between the GPL and the LGPL is that the latter can be linked to (in the case of a library, 'used by') a non-(L)GPLed program, which may be free software or proprietary software.[1] This non-(L)GPLed program can then be distributed under any chosen terms if it is not a derivative work.

Re:I'm not a copyright lawyer

[Nick Ives]

Totally wrong. The current BSD license is completely compatible with the GPL. The FSF has a page detailing the many licenses that are GPL compatible.

Re:I'm not a copyright lawyer

[torstenvl]

Totally wrong. You didn't read the link.

What the FSF means by "compatible" is that you can include BSD code in GPL projects. However, you CANNOT include GPL code in BSD-licensed projects. My comment stands.

Re:I'm not a copyright lawyer

[Nick Ives]

Doh, what I missed was your first sentence!
 

Re:I'm not a copyright lawyer

[maxwell demon]

If you have a piece of GPL code in your program, all of the program must be GPL. LGPL only applies to the LGPL code and any changes you make to it (your original code can be under any license)

Not any license. For example, if the license specifically says that the code may not be linked with LGPLed code, you certainly cannot link it (legally) with LGPLed code. More likely, if the license is a GPL-like "you must license the whole code under this", but contains any clause incompatible with the LGPL, then you cannot link to LGPLed code, because then both licenses would conflict.

Re:I'm not a copyright lawyer

[torstenvl]

No worries. I am a bit disappointed in the FSF's misleading and one-sided definition of "compatible" though.

Re:I'm not a copyright lawyer

[Nick Ives]

What's one sided about it? One of the terms of the GPL is that any combination of GPL and non-GPL parts must, absent any other agreement, be distributed under the GPL. Only licenses that permit relicensing in such a manner are GPL compatible.

Re:I'm not a copyright lawyer

[djcapelis]

In the case of Qt however there are many many special license exceptions which make this not true at all: http://doc.trolltech.com/4.4/license-gpl-exceptions.html

The only thing the LGPL'ing maintains is allowing licenses outside that list and since most of the open-source ones are on that list (including the BSD-style licenses) this generally is just applicable for proprietary programs.

Re:I'm not a copyright lawyer

[Kjella]

What the FSF means by "compatible" is that you can include BSD code in GPL projects. However, you CANNOT include GPL code in BSD-licensed projects. My comment stands.

Huh? There is no difference, legally. In both cases you'd have to comply with both licenses. "Compatible" means it's possible to comply with both licenses. It just so happens that if you comply with the GPL, you also comply with the BSD license while complying with the BSD license does not automatically mean complying with the GPL.

Re:I'm not a copyright lawyer

[spitzak]

Nonsense. "Compatible" means "they can be made to work together". Yes the result is GPL.

They would only be "incompatible" if it was impossible to combine the code. That is obviously false.

Re:I'm not a copyright lawyer

[swilver]

Not only those, but also open source programs using a different license than GPL, like Eclipse. Eclipse was forced to use GTK even though QT would have been a far better choice.

Re:I'm not a copyright lawyer

[mabinogi]

....and distribute it with your binary.

Merely linking to a library at runtime is not creating a derivative work.

Re:I'm not a copyright lawyer

[Twinbee]

How big is the library to include with a potential program? Is it just a single DLL file or similar (how big?)

Re:I'm not a copyright lawyer

[Anonymous Coward]

LGPL is a totally free license, except that if you distribute software using LGPL software, you have to write it in your software documentation: "I'm using (insert the name of the LGPL software here)"

Re:I'm not a copyright lawyer

[JohnFluxx]

I think what you are complaining about is that you cannot use GPLed code in a BSD project and then treat the whole thing as BSD licensed code.

You can, however, use GPL code in a BSD project, and then treat the GPL code as GPL code and the BSD code as BSD code...

Re:I'm not a copyright lawyer

[Anonymous Coward]

No, you cannot.

Re:I'm not a copyright lawyer

[Anonymous Coward]

You are right, but its not complete. Closed source applications require the entire stack to allow closed source. Almost all programs finally required to link with C library of the OS at last, Linux's C library (glibc) is GPL covered, therefore, on Linux you cannot run a closed source app without breaking GPL. Qt now LGPL is only useful for developers who intend to develop closed source applications for Windows, Mac OS X and BSDs, not for Linux.

Excellent news!

[apodyopsis]

Excellent news!

And a sensible move - the best way for any technology to become a standard (defacto or otherwise) is for it to be freely available and demonstrably good.

Now this is both we can predict swift adoption of it. Some firms may view Linux as a hobby, but even that is changing - my new job I started last week has two Ubuntu PCs in this very room I am typing from.

Re:Excellent news!

[urbanRealist]

Some firms may view Linux as a hobby

I am working on a Qt application right now. Previously, we planned to release only for Windows since each additional platform cost extra in licensing fees. Now, we can support Linux and OS X as well.

Re:Excellent news!

[Anonymous Coward]

my new job I started last week has two Ubuntu PCs in this very room I am typing from.

Second week on the job and already screwing off on Slashdot? Boy, are we proud of you...

Strategy fail

[betterunixthanunix]

Open source desktops fail really hard from a strategic point of view because of the split between GTK and Qt. They store l10n and i18n settings in separate places, they look different, the dialogs have different configurations, etc. It creates a desktop that feels less unified, more like a bunch of random applications than a single system.

Of course, porting GNOME would take so long that people would forget that GNOME even exists. The unfortunate reality is that this split will only be resolved when either GNOME and all of the associated GTK applications die, or KDE and its associated applications die (unfortunately, that would mean a loss of K3B, one of the applications that made open source desktops usable for non-technical users).

Re:Strategy fail

[siride]

What? Within a desktop, everything is more or less consistent. Yes, there is some inconsistency *between* desktops, but if you avoid using programs from another desktop, it's not a problem. Also, there are themes that make the apps look the same, and the copy/paste problems were solved years ago. Honestly, I have no trouble using mixed apps on the same desktop.

Re:Strategy fail

[Anonymous Coward]

try netbeans under kde.

Re:Strategy fail

[betterunixthanunix]

"if you avoid using programs from another desktop"

Which is just not possible. Where is the CD burning program in GNOME that beats K3B? Where is the music player that beats Amarok? In the other direction, where is the office suite that beats OpenOffice.org? You cannot avoid mixing GTK and Qt apps on a desktop without hurting yourself.

"Honestly, I have no trouble using mixed apps on the same desktop."

Just three days ago at FUDCon, I saw someone try to use KGPG on their GNOME desktop. He had localized GNOME in Dutch, and when KGPG pops up...everything was in English. The localization settings are stored in different places, which is a problem that goes beyond "installing themes to make it look the same." There is also the failure to have OLE across Qt and GTK, which has so far only been solved by disparate hacks in specific applications, and only works for certain cases. The copy and paste problems being solved was a good thing, but that is only one of many issues that arise from mixing GTK and Qt apps on a single system.

Re:Strategy fail

[WindBourne]

Configuration usage is a different issue from libraries. The libraries are SLOWLY coming together. It will take time to get both groups to agree which tech to share.

Re:Strategy fail

[jbolden]

The widget kits born in the mid 80s died out just recently. I can't see the ones from the late 90s being gone anytime soon. So you are talking something like 2020.

I think Gnome vs. KDE is going to be an example of what Linux brings: choice and "have it your way" type computing.

Re:Strategy fail

[jbolden]

People who are picky enough to care about which text editor and which IRC client can handle the notion of different apps using different structures where integration is important. For example on a Mac I use TextEdit when I want integration and VI when I want features.

Re:Strategy fail

[jbolden]

OpenOffice isn't QT or GTK. That problem ain't going away.

Re:Strategy fail

[aliquis]

Because people really want to use Kopete under KDE instead of Pidgin (bahahahaha)

Yes?

Re:Strategy fail

[FishWithAHammer]

Bzzt, wrong. I don't want to be using different apps when "integration is important". I want it to work. That's one of (many) reasons I don't use a Linux desktop.

Re:Strategy fail

[buchner.johannes]

That is the chance and duty of freedesktop.org. Combining the parts that are common and the platforms can agree upon. Defining the standards (like trash, cache, drag+drop, etc.).
It is getting better and better (e.g. I think KDE+GNOME both use DBUS now? ), some services/libs (NetworkManager) are already commonly used.
What I'd really like to see is a common password storage.

Re:Strategy fail

[Anonymous Coward]

Oh, he's just generalizing his personal preferences to mankind.

Re:Strategy fail

[Anonymous Coward]

Because people really want to use Kopete under KDE instead of Pidgin
And why not? They both have the same functionality. In fact, Kopete has several features I like that Pidgin doesn't, like webcam support.

Re:Strategy fail

[je ne sais quoi]

The unfortunate reality is that this split will only be resolved when either GNOME and all of the associated GTK applications die, or KDE and its associated applications die

I think that's a little extreme. There is room for more than one desktop environment. Just like there is room for both Windows and OS X, or Vista and XP for that matter.

I think that Nokia trying to open up Qt is absolutely great. The reason is that I think that the kde apps are great like amarok, gwenview, konqueror and k3b, but what I dislike is kde itself. kde isn't bad, but I prefer to use e17 as my WM because I wrote my own theme for it that doesn't look like anything else you've ever seen in a WM. What I'd very much like to see is to be able to run kde apps without having to load all the kde overhead. It's annoying like hell, that if I want to load gwenview or konqueror I have to load the dcopserver and all the other kde Krap and there's no way to shut it off (yes I know what the dcopserver does, but I'd still like to turn it off). Ergo, if Qt is more widely used outside of kde, perhaps we'll see some of my favorite applications able to run without loading all the kde libraries and helper apps.

Re:Strategy fail

[C0vardeAn0nim0]

What I'd like to see is a decoupling of basic stuff like dialogs from the toolkit.

the idea is that filechoosers, print dialogs and other stuff like that should be separate applications, that comunicates with the calling app using a standard way, adopted by all.

this way GTK, QT, GNUStep, etc. apps. all would have _AT LEAST_ those items in common. that'll make the user able to use muscular memory to use those elements no matter wich toolkit was used to build the app, something that we don't have right now.

Re:Strategy fail

[FishWithAHammer]

Because Kopete is an ugly Mac-ish mess? I've seriously never seen anybody use it. Among the folks I know, grabbing Pidgin from APT or YUM seems to be one of the first steps on a new box.

Webcam support might make me change my mind on that, when I actually need a webcam (though if Kopete has it, it's rather stupid that Pidgin doesn't). Or I can go back to my normal Windows desktop. :P

Re:Strategy fail

[betterunixthanunix]

OpenOffice.org, at least version 2.x, is GTK+...

Re:Strategy fail

[should_be_linear]

There is possibility that major GUI appications will move gradually towards managed code (Java) so QT + GTK would become only sort of low-level windowing library sitting between X and Java apps. Major IDEs (Eclipse, Netbeans) are proof-of-a-concept, except startup times issue, which certainly should be addressed by Sun VM. I would welcome such transision but it will not happen in next 5 years, thats for sure. There are just too many C/C++ apps in Linux to rewrite and some of them (Office, Browser) are really complex.

Re:Strategy fail

[vdboor]

Just three days ago at FUDCon, I saw someone try to use KGPG on their GNOME desktop. He had localized GNOME in Dutch, and when KGPG pops up...everything was in English

And that's something this distribution could have addressed already. The package manager knows the language setting too.

Re:Strategy fail

[Per Wigren]

AFAIK it's only using GTK to graphically draw the widgets, not to do layout or things like that.

Re:Strategy fail

[simcop2387]

a properly configured distro using gtk-qt (or qgtkstyle if you use gnome) doesn't have the problem of things looking different, as far as different configurations i agree completely. As for the l10n and i18n i don't believe that matters at all as there isn't a standard for any other platform as far as i know (i could be wrong about OSX)

Re:Strategy fail

[SanityInAnarchy]

In what way?

Last I checked, Kopete has more features (think webcams) than Pidgin. The biggest downside has been segfaults (I've gotten one today after at least two months with no problems), and disconnects (annoying, but if it automatically reconnects five seconds later, is that really a problem?)

Re:Strategy fail

[betterunixthanunix]

It has nothing to do with packaging. He had the Dutch i18n packages installed, but the package manager does not (and should not) go into a user's home directory and start messing with their settings. The problem was that after setting his l10n in GNOME, the change is not reflected for KDE/Qt; the original system install was in the US-en locale, he made the change afterward, which is not uncommon.

Re:Strategy fail

[Cthefuture]

Where is the music player that beats Amarok?

I agree with your other stuff but I just wanted to point out that I think Songbird thoroughly beats any other music player. It's still in its infancy and has some warts but it has been one of my favorite apps for a long time now. I'm also a heavy Firefox and Thunderbird user so it fits right in.

The thing about Songbird is that it's already set for the whole multimedia-web-blah-blah experience. As far as I know nothing other than Songbird and iTunes does all that very well. I know some will say "but I just want a music player" and that's fine too but some of us enjoy a rich experience.

Re:Strategy fail

[Tubal-Cain]

What I'd really like to see is a common password storage.

It's called a .txt file. In the ~/.secretstuff/ directory.

Re:Strategy fail

[jbolden]

I believe openoffice has some sort of GUI abstraction layer and then binds to a variety of different widget sets. This is for example how it binds to the Windows widgets and Cocoa.

Re:Strategy fail

[jbolden]

I didn't see didn't want I said could handle.

If you want that kind of monolithic Windows is the right choice for you.

Re:Strategy fail

[pieleric]

Which is just not possible. Where is the CD burning program in GNOME that beats K3B?

Brasero, it's there now. I was honestly a fan of K3B, but version 0.9 of Brasero is great. It looks like it has as many features as K3B, but everything is damn simple and clear.

Where is the music player that beats Amarok?

Unfortunately neither Banshee nor Rhythmbox can beat this one. Hopefully, competition will push them to become better!

Re:Strategy fail

[fuzzyfuzzyfungus]

Wider use of Qt will almost certainly increase the number of Qt applications that can run without KDE stuff; but I'd be shocked if KDE apps are going to start working without KDE stuff. On the other hand, given what happened to phonon(developed for KDE, now part of Qt) you might end up running the same stuff; but as part of Qt instead of KDE.

Re:Strategy fail

[jedidiah]

Of course the obvious answer is to pre-empt the GNOME configuration
and have one that's global. This goes a bit farther than just GNOME
versus KDE. This is still a packaging and configuration issue at the
distribution level.

Re:Strategy fail

[Bob54321]

Where is the music player that beats Amarok?

Unfortunately neither Banshee nor Rhythmbox can beat this one. Hopefully, competition will push them to become better!

Exaile? Maybe not now Amarok2 is out.

Re:Strategy fail

[FishWithAHammer]

I agree. Hence why it is my primary desktop, even though I really would like a Linux desktop that didn't suck.

(I'm amused that the post you replied to was modded troll. Do people really think that Linux integration doesn't suck?)

Re:Strategy fail

[FishWithAHammer]

The user interface makes me cringe, and the disconnects are considerably more than annoying because I set alerts on certain users and, the last time I used Kopete, it treated all logins by me as logins by those users and fired those alerts--to be fair, Pidgin does this as well, but Pidgin doesn't randomly drop out on me.

Re:Strategy fail

[domatic]

This is really the sort of thing freedesktop.org is supposed to be smoothing out.

Re:Strategy fail

[Hatta]

Have you tried Amarok? I've tried Songbird, and Banshee, and Rhythmbox, etc. and none of them come close. The problem with those players is that the main playlist and collection browser are the same window. In Songbird, IIRC you have 3 small windows for Genre-Artist-Album, and you can select a specific genre, artist, or album, and it will filter your entire collection, leaving only matching entries in the main playlist.

Ok, so suppose I play an album, and halfway through I decide to queue another album. To do that, I have to select a different album in the album window. But since my playlist is the collection browser, when I select a different album, it wipes the album I'm listening to from the playslit, and adds the new album. Not what I want at all.

Unless things have changed since I last used Songbird, there's no easy way to do this. This is obviously a serious usability issue. Not only is this inferior to Amarok, but it's a major step backwards from the XMMS days, when you could independently browse your collection and edit your playlist. In fact, it's such a bad idea, I can't imagine what would possibly possess someone to design such an interface.

Re:Strategy fail

[Hatta]

If you're just going to consolidate everything, what's the point of having two desktops to choose from?

Re:Strategy fail

[Hatta]

I should also point out that Amarok is the only music player, as far as I can tell, that supports an external database. If you have more than a few thousand tracks, you need a real database server, not SQLite. That alone puts Amarok head and shoulders above the competition.

Re:Strategy fail

[Anonymous Coward]

Despite those who have an axe to grind with the notion of choice (such as yourself), the open source desktop has made incredible advancements over the past decade. And it is obvious that it is only going to get better. So why must you (among others) continually fling your poo on the notion of choice which is nothing less than the foundation of all open source software development?

If you still don't get it, I'll try to spell it out for you. Open source works because people choose for themselves what to work on, when, and how -- NOT because they are controlled by some committee (such as yourself) who directs them to collaborate on a unified project they may not even be interested in.

So keep on persuading, by all means, but don't for a second think that open source (even the desktop) won't succeed without the ideals of top-down control. It already has, and it's only going to get better.

I for one hope there is NEVER a "one size fits all" desktop without competition -- or any application for that matter.

Re:Strategy fail

[g2devi]

> Which is just not possible. Where is the CD burning program in GNOME that beats K3B? Where is the music player that beats Amarok? In the
> other direction, where is the office suite that beats OpenOffice.org? You cannot avoid mixing GTK and Qt apps on a desktop without hurting
> yourself.

This is the key difference for the desktop split. Why do you mean by "beat"?
If you want a no-nonsense desktop and desktop apps that allows you to do your work without getting in your way, then GNOME and GNOME apps beat KDE and KDE apps. Personally, I can't stand either K3B and Amarok.
If you want a pimped up desktop and desktop apps that allow you to do anything you want, then KDE and KDE apps beat GNOME and GNOME apps.

If one or another need dominates, except for one area, then you have a mix.

I personally have a pure desktop...not out of ideology, but simply because GNOME and GNOME apps works better for me. I'm sure plenty of KDE lovers have a pure KDE desktop for the same reason.

If, for some reason, GNOME decided to migrate to Qt (theoretically, it is possible if GNOME 3.0 moves to be more IDL driven and Qt components could be modified to support any missing feature that GNOME needed), GNOME and GNOME apps would still exist separate from KDE and KDE apps simply because GNOME users and KDE users are different.

Re:Strategy fail

[LateArthurDent]

Which is just not possible.

It's possible, it's just not desirable. I don't see the issue with mixing apps from different frameworks anyway.

Where is the music player that beats Amarok?

Ugh. Just any single one? I'd rather use windows media player through wine...luckily I don't have to because of rhythmbox.

Believe it or not, my point here isn't that Amarok sucks. You obviously like it a lot, which means they've done something right. My point is that people have different tastes and want to use different stuff. I hate Amarok, but I don't think everybody else should quit using it. You like it, a lot of other people like it, yay for you. I don't like it, I shall use rhythmbox and stay away from amarok. Choice is good. What I think sucks is the exact same software you think is the best one available. I'm sure we could find examples that go in the other direction if we tried.

He had localized GNOME in Dutch, and when KGPG pops up...everything was in English. The localization settings are stored in different places...

Don't see a problem with that either, I've configured my desktop both under gnome and kde to get things the way I like them for all apps I use. If that type of stuff bothers you, then I guess you should try to avoid using programs from another desktop. If it bothers enough people that there's no gtk amarok, somebody should make an amarok-like player in gtk. Apparently they are doing that with Exaile. Might not be good enough yet (or it might be. I haven't tried it because I have no desire for amarok-like programs), but it'll get there, I'm sure.

Not that I wouldn't encourage both teams to collaborate where possible in order to increase compatibility between frameworks, that would be great. However, I certainly wouldn't want either KDE or gnome to disappear (or for qt or gtk to disappear) for the same reasons I outlined above. I like the ability to pick and choose what I prefer and the choices I make won't necessarily be the same choices you'd make. Somebody is going to be unhappy.

Re:Strategy fail

[Anonymous Coward]

Anyone who uses phrases like "rich experience" needs to drown in their own shit.

Re:Strategy fail

[aztracker1]

I think this is probably a good idea for abstraction... Common dialogs (print/file) should probably use whatever the OS is based on. The toolbar icon interfaces are now pretty much standard across desktops, would be nice to see common dialogs do the same, though file is probably much easier than print in this case. To be honest, I don't so much mind having different apps a little different. Years of switching windows versions, mac os 6-X, and various flavors of Linux over the years have numbed me a bit to it.

Where's the preferences... Tools, Edit, File or in the App Menu(mac)... You just get used to it after a while. One good thing about windows, is people are far less expecting of a consistent UI, as they don't get it in Windows between applications. I don't think that KDE/Gnome (Actually QT/GTK) is the problem... it's GTK/Qt/SDL/Tk/wx and then trying to write portable apps to different platforms (Win COM, WinForms, Win WPF, Mac Aqua Carbon, Mac Aqua Cocoa, Java, etc.). That becomes the problem. Yeah MVC/MVP can resolve the issue, supporting multiple C/P layers... but having a common library available helps a literal ton in supporting cross platform, even if less than perfect.

Not to mention that wrapper libraries for Qt haven't received as much support, probably because it has been GPL, and people like libraries to be at least LGPL. This makes that possible. I'm hoping this spurs some SharpQT support (Mono/MS.Net), since pushing GTK+ onto windows and mac isn't so nice/easy. Also, people forget there are other licenses besides commercial which are incompatible with GPL libraries. I can't write a BSD/MIT program that uses GPL either. But I can write MIT/BSD apps that use LGPL.

Re:Strategy fail

[gbjbaanb]

no, consolidate the commonality - places to store stuff, configuration files that are shared between apps, etc. The point of having multiple desktops is to provide different "user experiences" for different users. In much the same way as a lot of people turn off Vista aero and revert to the Windows 2000 look, a linux user should be able to switch between Desktop1 and Desktop2 while having one place to decide which mouse button is click and which is menu.

As an analogy - imagine if debian decided that all config files were to be placed in /user/local/config, redhat in /etc, and suse in ~/appdata. It'd be chaos... just like with the 2 desktops we have today.

Obviously, it would be best if all common functionality was in a 'desktop framework' that user desktops work on top of - much like apps use the kernel. Then we'd see more applications being written, and they'd be more consistent across the board.

Perhaps the time is right for a new opengl-based 3d desktop :)

Re:Strategy fail

[Narishma]

So just because you don't know anybody that uses it you assume nobody does? That's pretty short-sighted. I can as well say nobody is using Windows since everyone I know has either Linux or a mac but that doesn't make it true.

Re:Strategy fail

[Anonymous Coward]

Do people really think that Linux integration doesn't suck?

Sure. Linux integration works great for me and millions of other Linux users. The fact that you were incapable of figuring it out just means that you're not ready for Linux. Linux isn't suited for everyone, that's why some people (such as yourself) should just stick with Windows, since it works well for them.

Re:Strategy fail

[mweather]

That's why I originally installed an Ampache server. It's Cross-platform, uses mysql, and has most of the features I want. Now that Amarok itself is cross-platform, I just hooked my Ampache to it (only works on the newest version), and now I have the best of both worlds. I could just move my data off the Ampache server, but I have become accustomed to being able to play music on my friends' Ampache servers as well. Now my music is portable AND I can use Amarok. Best of both worlds.

Re:Strategy fail

[drsquare]

What? Within a desktop, everything is more or less consistent. Yes, there is some inconsistency *between* desktops, but if you avoid using programs from another desktop, it's not a problem.

Yes, because I choose my apps based on the toolkit they use...

But in all seriousness, even if they were consistent, you've still got Firefox, Open Office, iTunes etc. screwing everything up.

Re:Strategy fail

[FishWithAHammer]

Not being "ready" for Linux is like not being "ready" to take a driving test in a car where the brake lines are frayed and the steering wheel jams when you try to make a left turn.

Re:Strategy fail

[richlv]

oo.org has qt/kde widget support. that wasn't the best example :)
thinking about gtk apps i use - thunderbird and gimp. while i think about migrating to kmail now and then, simple differences always put me off =)
gimp, i'm too used to, at least for now. these two apps have taught me one thing - i passionately hate many, many aspects of gtk file dialogs... having gimp use qt/kde would be a blessing in that regard :)

Re:Strategy fail

[Ant P.]

There is also the failure to have OLE across Qt and GTK, which has so far only been solved by disparate hacks in specific applications, and only works for certain cases.

Um, what? I've got a Qt4 music player running right now that uses Gnome's notification-daemon to display popups. Things have moved on a lot since the days of whatever you're referring to. We even have this nifty "LC_ALL" thing to set the language across all apps...

Re:Strategy fail

[jbolden]

Yes. /. users in general don't tend to make as much use of drag and drop / OLE as most users. They don't use application extensions (like the commercial addons to Word or Excel). So they don't see integration on Windows as being a huge plus.

Many of them don't even need the level of integration from Mac.

With this crowd you need to give specific examples of types of integration that aren't provided. And even then it is going to be unconvincing.

Let me give an example in another way. One of my biggest with windows is not having simple raw to hardware writes:

i.e.

echo "...." > /dev/eth0

I would expect to have to explain to people why I want to be able to write to hardware that directly.

Re:Strategy fail

[Anonymous Coward]

Where is the CD burning program in GNOME that beats K3B?
Nautilus.
Where is the music player that beats Amarok?
Rhythmbox.

Seriously. Since I switched from KDE like a month ago, I've been amazed with how good those are.

Re:Strategy fail

[Anonymous Coward]

The localization setting is an environment variable, inherited from the parent process. How the fuck does a desktop environment manage to break basic unix functionality like that?

Re:Strategy fail

[Randle_Revar]

Open source desktops fail really hard from a strategic point of view because of the split between GTK and Qt. They store l10n and i18n settings in separate places, they look different, the dialogs have different configurations, etc. It creates a desktop that feels less unified, more like a bunch of random applications than a single system.

Yes, and Windows is a paragon of consistency, which explains why it does so well.

Re:Strategy fail

[Randle_Revar]

I prefer a CLI Jabber client, failing that I would take Psi, failing that I would take Kopete. Pidgin is the awful one.

Re:Strategy fail

[FishWithAHammer]

At least somebody gets it.

Although, at least between KDE and GNOME, I can just say "clipboard clipboard clipboard" as enough of a reason. Granted, it's gotten better, but not that much better (and why, exactly, do I have an X clipboard as well as the WM clipboard...?).

Re:Strategy fail

[Anonymous Coward]

LOL if you think SQLite can't handle a couple thousand rows in a table. I seriously doubt you have a music collection of a couple million songs which is what you would need to make it necessary to go to a different database system.

People seem to be confused because of all the crappy slow software out there. A modern computer can shuffle around a couple hundred thousand pieces of information without breaking a sweat.

Re:Strategy fail

[Randle_Revar]

There is possibility that major GUI appications will move gradually towards managed code (Java) so QT + GTK would become only sort of low-level windowing library sitting between X and Java apps.

That doesn't even make sense.

And I think the chances of the majority of the FOSS community moving towards Java is about 0%

Re:Strategy fail

[Hatta]

Amarok with roughly 40,000 tracks in a MySQL database is significantly faster than SQLite. Try it and see.

Re:Strategy fail

[sholsinger]

Technically? Yes, it is a problem. You should not be receiving segfaults from a stable release-ready application. Especially one that has been around the block like Kopete. That is unfortunate.

I like Pidgin because it is lightweight. If I want to do video chat, I launch Skype which ironically uses QT4.

Then again, I use Gnome. I've had difficulty with KDE + Dual Head in the past. Gnome seems to handle it better.

Re:Strategy fail

[ivucica]

...and it has everything with KDE not honoring the LANG variable.

Seriously. LANG is used universally by command line tools and Gnome alike. Anything that uses libintl (gettext) reads the setting from LANG.

Re:Strategy fail

[Anonymous Coward]

Basing the specifications on existing implementations makes it less likely that it becomes a design by committee clusterfuck, and cooperation to create clear documentation and protocols that everyone can follow works a lot better in the long term than de facto standards arising from ad hoc implementations that happen to become ubiquitous. It helps innovation too, by making it easier to replace small parts of a system with another standards compliant implementation.
So you don't consolidate everything, only the parts that turn out not to be shit.

Re:Strategy fail

[msaavedra]

"if you avoid using programs from another desktop"

Which is just not possible. Where is the CD burning program in GNOME that beats K3B? Where is the music player that beats Amarok? In the other direction, where is the office suite that beats OpenOffice.org? You cannot avoid mixing GTK and Qt apps on a desktop without hurting yourself.

Personally, I don't really like K3B. I use Gnome Baker and am perfectly happy with it. Amarok seems decent enough, but I prefer Quod Libet, a player that uses gtk, gstreamer, and python.

I don't mean any disrespect to the hackers who have put a lot of hard work into KDE/QT apps, but I don't even have QT installed on my system any more and don't feel like I'm missing anything. Likewise, I'm sure someone so inclined could do without gnome and gtk. It may be hard, though, to find an adequate substitute for OpenOffice, if one needs that sort of app.

Re:Strategy fail

[legirons]

where is the office suite that beats OpenOffice.org?

Ironically, it's the office software in GNOME (AbiWord, Gnumeric, GNUCash, etc)

Re:Strategy fail

[Brandybuck]

Nitpick: OpenOffice is not a GNOME application. It may use GTK+ in spots, but it is not a part of "another desktop".

Re:Strategy fail

[betterunixthanunix]

1. libintl is part of GNU. KDE is not part of GNU and never claimed to be. Qt has its own method of handling l10n/i18n.
2. LANG is not standardized, just common. Blaming a project for not respecting a vaguely defined part of the standard does not solve anything.
3. Locales do not provide translations. An application can set a different locale without being translated. Locales specify date, time, and money formats a few details about how capitalized letters work. Locale names are not part of any standard.

This is a problem with freedesktop.org not specifying how l10n and i18n should be handled on Linux systems, not the fault of KDE. There is no more reason to blame KDE than to blame GNOME for not respecting language settings from KDE.

Re:Strategy fail

[an unsound mind]

Exaile has a fixed layout and wants everything to be in a gigantic resolution.

Frankly, I don't think Amarok nor Exaile really match up to fb2k in Wine.

Re:Strategy fail

[Tamran]

Ergo, if Qt is more widely used outside of kde, perhaps we'll see some of my favorite applications able to run without loading all the kde libraries and helper apps.

This is a statement I also agree with. I personally think KDE is ugly and too windows like.

Re:Strategy fail

[pbhj]

They've made KDE4 in pretty short time, it's a from the bottom rewrite, can't imagine porting Gnome to QT4 would take longer than porting KDE^w^w rewriting KDE to^w for QT4, especially with Canonical on the case.

I'm not a dev, I'm sure you'll let me know why and how I'm so wrong ...

Re:Strategy fail

[Anonymous Coward]

"if you avoid using programs from another desktop"

Which is just not possible. Where is the CD burning program in GNOME that beats K3B? Where is the music player that beats Amarok? In the other direction, where is the office suite that beats OpenOffice.org? You cannot avoid mixing GTK and Qt apps on a desktop without hurting yourself.

Are you implying that Openoffice is a GTK app?
Because it'snot it uses its own GUItoolkit.

Also take a look at this http://dot.kde.org/1082652256/ It's from OpenOffice 1.1.1 era, I don't know if there's something similar for OpenOffice3.

As for gtk and qt apps there's that theme for gtk apps to use the QT theming functions and/or vice versa.

Re:Strategy fail

[segedunum]

In the other direction, where is the office suite that beats OpenOffice.org?

Open Office is not a GTK or a Gnome application, and it shows. It can superficially look like a GTK application, as well as a Qt/KDE one though.

Re:Strategy fail

[Mystra_x64]

I don't see how 'OS-in-OS' concept is desirable on desktop.

Re:Strategy fail

[Anonymous Coward]

Database usage is a tricky thing and using it the wrong way often leads to poor performance. My guess is Amarok is doing something wrong. I run SQLite databases with tens of millions of rows and it's no slower that MySQL running on the same dataset (although they are both annoyingly slow at times).

Looking at the source it looks like Amarok is turning off synchronous disk writes which is good but it doesn't look like they are doing anything else to tune for performance at all. For one thing, increasing the memory cache size can give a huge boost in performance because by default SQLite is tuned to run on tiny systems (we're talking a mere 3 MB of RAM for cache by default). I imagine there are many other things that should be done. I'm guessing they may also be using transactions improperly. It's not a direct fault of the database though, just different default tunings and developer knowledge.

An Amarok database with 40000 tracks seems to have less than a million rows related to the tracks (actually the track data is only about 80000 rows, it's the image table that is stupidly huge). That is a ridiculously small database. If you're having performance problems then either the developers are clueless or your computer is broken. I actually just tried it and did not notice any performance difference between SQLite and MySQL. Although fast because my computer is fast, they both seem suboptimal. Even at 100000 tracks this is a minuscule amount of data and the computer shouldn't even blink yet Amarok is really chunking on the data hard. I think unskilled developers are more to blame for your performance issues.

I doubt Songbird will be much better. Probably not worse though. For some reason developing these types of applications attracts the most unskilled of developers. Having to choose between the two I would pick Songbird for its much cleaner interface and huge Firefox-like community with all sorts of add-ons available. Amarok reminds of 90's-era Microsoft applications, blech.

Re:Strategy fail

[NoobixCube]

I don't know how different the feature sets are, but Brasero is just find for me when it comes to burning CDs. It's a light weight GTK CD burning application. It seems to have all of the functions of Nero on Windows (at least, the last version I used, a few years back), and I just can't see what more a CD burning application would need. As for Amarok, I'd definitely love to see a GTK version of it, but that's not going to happen. Exaile is similar, but not quite there. Until the final release of KDE 4.2, I'm sticking to Gnome and using Rhythmbox for my music. I'd like to see more office suites out there, and maybe KOffice will improve some day.

Re:Strategy fail

[ivucica]

Does everything need to be standardized, or should some things make common sense because they're widely used?

Yes, KDE is not part of GNU, but it could respect the OS it runs on*. GIMP, for example, respects Windows standards although it's not a typical Windows application.

In fact GIMP surprises me by applying Croatian language to normally English OS just because "regional settings" (locales) are set to Croatian.

However, if LANG was not specified by fdo, then I don't have a serious problem with it. But I still find it easier and more logical for KDE to set and respect LANG variable since many command line programs would also use the specified language.

By the way, "LANGuage", not "LC_NUMERIC" or whatever. Who mentioned locales? Maybe my post's parent, but not me :)

I don't blame KDE for not respecting LANG (that makes it sound so ... mean), and I understand the difference in language handling; I for one find setting priorities fantastic, and quite nice for Balkans where languages are similar, but amount of translation not the same. However remember, it's easy to detect if KDE session is running or not, and if not, use LANG instead of settings from kcontrol.

* No matter what you think about name GNU/Linux, you can't say GNU isn't "typically there" with Linux. And that KDE is not typically used with Linux kernel.

Re:Strategy fail

[maxume]

On XP, on a modest laptop (2 years old), foobar 2000 will build a full playlist of 14,000 tracks in about 20 seconds, with full metadata.

A decent music player shouldn't need any database.

Re:Strategy fail

[Anonymous Coward]

OLE? What are you talking about? Windows 3.1?

Re:Strategy fail

[Vexorian]

I still like K3b much better, however, this does not matter from a desktop consistency perspective because:
a) Users don't notice the difference.
b) Projects like GTKQT and using QT as GTK engine, will allow both things to look mostly the same anyway. I for one use ubuntu gnome, and a lot of QT apps and really can't say it caused me any issues.

Re:Strategy fail

[EsbenMoseHansen]

I use it, and I switched from Pidgin. I don't know, Pidgin just seemed clunky for me.

I only use Jabber though --- I had a lot of accounts, but in the end, Jabber was the only one with more than 1 contact/connection.

Re:Strategy fail

[Katalyst23]

I know this is going to sound weird, but I like Rhythmbox best out of the three. It's been a while since I used Amarok though, maybe I should go back and check it out again.

Re:Strategy fail

[Yosho]

Exaile? Maybe not now Amarok2 is out.

Nah, I'm still a fan of Exaile. Amarok2 has WAY too much junk that I don't need, and, at least in my experience, it's UI and startup/shutdown times are much slower than Exaile; that's pretty impressive considering that Exaile is written in Python.

Then again, I don't expect (or want) much from a music player other than a decent UI for playlist management and the ability to integrate with my iPod.

Re:Strategy fail

[supervillainsf]

...I still have clipboard issues with crossing between applications to this day

That's one of (many) reasons I don't use a Linux desktop.

If you don't use a Linux desktop then I fail to see how you have clipboard issues between applications on Linux. I guess you could be an admin, but then there aren't any real circumstances where you would be copy/pasting between applications since you aren't running X on your servers.

Re:Strategy fail

[Ciaran Power]

Hmm, don't know about this.

This page claims it only needs GTK for the optional 'crash reporter'.

On my system (Debian Etch) if I do the following:

find /usr/lib/openoffice -type f -perm +ugo+x -exec bash -c 'file {} | grep -q 64-bit && echo {}' \; | xargs ldd | less

I can't see anything that looks very Gnome-y, except for 'ooqstart', which uses glib (and nothing else Gnome-y).

So, without downloading the source, I guess it's either doing it all itself in Xlib or Xt, or those java libraries that it's linking are doing the drawing. Hmm.

Re:Strategy fail

[Phroggy]

Interesting. It occurs to me that Linux having Qt and Gtk+ apps is vaguely similar to Mac OS X having Cocoa and Carbon apps, although because a single entity completely controls both Cocoa and Carbon, they've managed to make things like localization settings work across both. Still, there are minor details like the Services menu, standard text-input features like inline spellcheck and emacs-style key bindings, and other Cocoa features that aren't available in Carbon applications.

Re:Strategy fail

[Requiem18th]

Are you the nutcrack that insists on calling KParts OLE a while ago? Please don't, OLE is a Microsoft centric term.

  While you are right that the divide between KDE and GTK makes everybody a little less comfortable your suggestion to kill thousands of projects based on their GUI toolkit, is sure to generate enough heat to melt to boil the oceans.

  It's overkill.

  And I laugh at your suggestion that K3B made desktop linux usable for the first time (that merit goes to either firefox or openoffice), and for your information, not everybody loves KDE apps.

  I've never needed more from a media burner than what Brasero or GnomeBaker have to offer. Amarok is a bloated cow, etc, etc.

  Different desktops for different people.

  Honestly I also hope for desktop unification one day, but that can't be accomplished with such negative attitude.

the ice caps is problematic, it is only a problem for freedesktop.org and the likes.

  It is not a problem of KDE or Gnome respectively, since your suggestion to bite the dust will only you don't need to wait for all apps in a platform to die, you just hace to wait until

Re:Strategy fail

[JohnFluxx]

For example? What copy-paste doesn't work between KDE and Gnome?

Re:Strategy fail

[pherthyl]

No, it is not. It uses its own toolkit, and you can optionally make it use one of several platform-specific frontends to render the widgets. One of those frontends uses GTK and tango icons, one of them uses Qt and crystal icons.. Openoffice does not require or depend on GTK or Qt though.

Re:Strategy fail

[sagematt]

Where is the music player that beats Amarok?

gmusicbrowser
foobar2000 on WINE

Re:Strategy fail

[troubbble]

I've been running Exaile for a while now. It feels a lot like Amarok but looks great in Gnome. Plus it's written in Python, which in my mind makes it sexy.

Re:Strategy fail

[Anonymous Coward]

This is totally wrong. You can make a GNOME dialog using Qt, and viceversa. The reason the GNOME dialog looks different from the KDE one, is because the developers and usability persons of each team had different points of view when doing their work.

That said, I think that you are not critical enough with Windows, for example. Not only Microsoft applications differ a lot from each other (e.g. Messenger vs everything else), but also you have to add later 3rd party applications that just suck. The user interface of popular 3rd party programs is completely different from the one of the native apps.

Of course, there is a lot of room to the improvement, but the problem is perfectly acknowleged by FreeDesktop, and they are fixing it.

Re:Strategy fail

[Daengbo]

You were modded "troll" because you were trolling. This post farther down insults various aspects of the Linux desktop but gets modded +5 Interesting. Compare it to your own and learn something.

Re:Strategy fail

[Daengbo]

There was a conversation about this last month on the FD.o mailing list

> Mark Seaborn wrote:
> > I have written a hack for Gtk which replaces Gtk's usual file chooser
> > with a file chooser implemented in a separate process.
>
> Nice, this could be useful. I'm not sure yet if there is a concise
> in-process solution. If not, I'll have a closer look on your code.

The current version is an LD_PRELOAD library that replaces some Gtk
API calls. It works with a lot of applications, but not with Firefox,
which dlopen()s libgtk. The successor is a work-in-progress; it's a
patch to Gtk, which you can find here:
http://repo.or.cz/w/gtk-with-powerbox.git (code)
http://plash.beasts.org/wiki/Story20 (notes)

The intention is that the Gtk code will be separate from the RPC
mechanism used, which is implemented in libpowerbox, of which there
can be different implementations.
For example, there is a DBus implementation:
http://svn.gna.org/viewcvs/plash/scratch/powerbox-dbus/
and the intention is that there will also be a version using Plash's
object-capability comms protocol.

Maybe I should rename libpowerbox to something more descriptive such
as libtrustedpathfilechooser (that's a bit long-winded though).

> Is there a chance that you'll give me permission to "reuse" your
> code under the terms of the MIT-License?

I'm open to the idea of relaxing the licence, but which bits of code
do you have in mind? The Gtk hooks are quite Gtk-specific.

Mark

I hope that it happens, too.

Re:Strategy fail

[Narishma]

OpenOffice isn't a gnome application, nor is Firefox. Also, there's KOffice in KDE.

Re:Strategy fail

[Narishma]

That's not true though. They have only rewriten some parts of KDE, most notably the desktop. Most of the rest was either new libraries or just a straight port to Qt4 with some cleaning up of the cruft that has accumulated over the years.

Re:Strategy fail

[kojot350]

Than go back to Windows or whatever, just stop bitching about things you don't understand. We _really_ don't need your ignorance, just go away.

Re:Strategy fail

[Anonymous Coward]

The better burning program is right clicking and selecting to burn to disc. More usable approach than the K3B that seems like a shuttle cockpit solution for a simple everyday solution. Also, Banshee is far more usable than Amarok.

Way to go, Nokia!

[Dexter77]

I love to see when a company understands that giving something away they will get ten times more in return. And nowadays that happens too rarely.

For a while it seemed that Nokia is about to lose to its competitors, because of Symbian and bad software. This will totally remedy it. I've also heard from Nokia insiders that they're actively dumping everything related to Symbian. It won't take more than couple of years and all their phones use Qt.

Seeing how well Apple has been selling iPhone applications, I can only imagine the potential Qt phones have in future. With Symbian that just wasn't possible, it was a total nightmare for the developers.

Re:Way to go, Nokia!

[hweimer]

I love to see when a company understands that giving something away they will get ten times more in return. And nowadays that happens too rarely.

Aren't you confusing something here? This move is nothing but a reward for companies choosing not to give anything to others.

Re:Way to go, Nokia!

[FishWithAHammer]

Nokia doesn't give a shit about the Free Software bullshit (and neither does anyone else of relevance). Nokia is LGPLing the libraries to encourage development on their platforms.

They have more important things to do than suck up to Stallman.

Re:Way to go, Nokia!

[Directrix1]

Well, that's not entirely true. With the extra usage the companies will want to keep their libs working well without having to maintain a large patch set. So they will more than likely contribute what they would have contributed had they purchased the commercial license, and they will also have more incentive to use the software in the first place because there is no longer a price for commercial deployment. More users = more patches. This is a major win.

Re:Way to go, Nokia!

[Yahma]

Don't believe for one second that Nokia is being altruistic in its motives for changing the license of Qt to LGPL. They have said that the monetary reward to their business would be greater by LGPL'ing Qt than selling licenses. Remember, this is the same company that closed down a profitable production plant laying off thousands of workers, some of whom have has 20+ years with the company, after receiving millions in subsidies from the EU. Only to move production East, where they could pay workers less.

While I am pleased with this move, as Qt is generally technically superior to Gtk. It is, nonetheless important to keep in mind that Nokia does not, and probably will never, have the best interests of the Open Source society in mind.

Re:Way to go, Nokia!

[JoeMerchant]

keep in mind that Nokia does not, and probably will never, have the best interests of the Open Source society in mind.

I concur - though this (LGPL) is far from the worst thing that Nokia could have done with the Trollware.

Re:Way to go, Nokia!

[spitzak]

Since the LGPL requires those companies to publish their "patch set", they have absolutely no reason not to try to contribute it back to Nokia, since they can't keep it secret anyway. And as you said, it is a pain to maintain a patch set so they also have that incentive to get their changes into the main version.

Re:Way to go, Nokia!

[Directrix1]

Yeah, thats pretty much what I meant. Technically, any in house changes they don't have to contribute back, though. But they have to submit their changes back for any derived work that is distributed. What's wrong with the phrase "patch set"?

Re:Way to go, Nokia!

[impaledsunset]

Nokia doesn't give a shit about the Free Software bullshit (and neither does anyone else of relevance). [...] They have more important things to do than suck up to Stallman.

Apart from being a corporate patron of the FSF, perhaps?

QT/GTK

[StuffMaster]

I actually like GTK Windows apps better than native ones! Smaller dialogs are usually resizable, which is something Windows (at least XP and earlier) does horribly wrong. Options dialogs also often don't disable the main window, another thing Windows sucks at.

Hopefully QT will bring more windowing goodness to Windows (if it hasn't already).

Re:QT/GTK

[Enderandrew]

The KDE team has been working on dialogs and user interface to make KDE 4 scale better, and work even on small netbook screens.

Kills any idea of using Qt in our products

[Anonymous Coward]

A couple years ago, we were discussing using Qt for our desktop applications (at a well known scientific software house) as we needed a cross-platform framework and I have a couple years experience writing cross-platform (Mac+Windows) applications in Qt. We didn't, but it was a viable option, perhaps one we should have taken.

However, the company has a strict policy of no LGPL or GPL software. Nothing more restrictive than BSD or Apache when it comes to using free software. So, any talk of using Qt would have been a non-starter.

Re:Kills any idea of using Qt in our products

[vurian]

I'm curious: what did your company choose? Homegrown?

Re:Kills any idea of using Qt in our products

[oever]

So buy a commercial Qt license. These are still available have no GPL/LGPL in them.

Re:Kills any idea of using Qt in our products

[Anonymous Coward]

Well there is still some question about the future, but we just kept with our in house "framework" till we can start migrating to non-C++ based options.

Re:Kills any idea of using Qt in our products

[shutdown -p now]

However, the company has a strict policy of no LGPL or GPL software. Nothing more restrictive than BSD or Apache when it comes to using free software.

Your company has a very silly policy. I've worked in quite a few places that did commercial closed-source development, and none of them had any problems with LGPL; after all, it was written precisely so that closed-source apps can use it! Why waste time re-writing the code somebody has already written before, and allowed you to use?

Re:Kills any idea of using Qt in our products

[Anonymous Coward]

Perhaps I don't understand the LGPL....

Doesn't the LGPL allow you to link to the DLLs(.so)? IE: the same licensing used for Windows dlls, except that with LGPL, you can actually view and modify the source if you need to, as long as you return the new code back to the library. If you don't need to change the library, then you don't have to contribute your proprietary code back. And you code that is separate from the library never has to be contributed (unless you just want to be a good person)

Can someone clarify this for me?

Re:Kills any idea of using Qt in our products

[ceoyoyo]

Why no LGPL? I'm curious... I don't really see why using an LGPL library would have any negative effect at all, unless you have to statically link all your libraries for some reason.

Re:Kills any idea of using Qt in our products

[Kidbro]

However, the company has a strict policy of no LGPL or GPL software. Nothing more restrictive than BSD or Apache when it comes to using free software.

Thank you. That made me smile.
When I hear about extremely stupid people making extremely stupid decisions that result in extreme costs for themselves, my day becomes a little bit brighter :-)

Re:Kills any idea of using Qt in our products

[Gregory Arenius]

According to the Ars Technica article not only is QT opening up their source they're opening up their development process as well with an open GIT repository. The article claims they will not be requiring copyright assignment. If that is the case future versions of QT are unlikely to be available under a commercial license at all because no one entity will have the right to do that.

Cheers,
Greg

Re:Kills any idea of using Qt in our products

[oever]

Qt requires people that contribute to give them a permissive license. That is good enough for inclusion of the code in the commercial version.

Re:Kills any idea of using Qt in our products

[Anonymous Brave Guy]

Your company has a very silly policy.

At first glance, it sounds that way, but we have to be careful because we don't know all the details. I've seen companies rejecting all sorts of external software based on apparently permissive licence agreements. One example is companies that produce libraries rather than end-user products, who can't necessarily impose any changes on their entire customer base without rewriting every contract they ever signed; this can be triggered by something as simple as a required attribution clause in the licence of a sub-library.

Re:Kills any idea of using Qt in our products

[Tetsujin]

However, the company has a strict policy of no LGPL or GPL software. Nothing more restrictive than BSD or Apache when it comes to using free software.

Your company has a very silly policy. I've worked in quite a few places that did commercial closed-source development, and none of them had any problems with LGPL; after all, it was written precisely so that closed-source apps can use it! Why waste time re-writing the code somebody has already written before, and allowed you to use?

They may have been feeling very cautious about the possible issue of developers not only "linking with" but actually "deriving from" LGPL code...

Basically when code is open-source, but with a license restrictive enough to make the lawyers uncomfortable, there's a bit of a liability there - the developers, of course, have total freedom to read and learn from that code. But not all of them will be disciplined enough, when reading a piece of code which does exactly what they need a closed part of their app to do, to not reuse that information inappropriately.

Some would be careless enough to misinterpret the LGPL and either link it improperly or reuse it within closed portions of the code. Aggressively warning employees to avoid GPL/LGPL code is easier that teaching the proper discipline in handling it - and even if a violation didn't wind up costing them a lot of money, it does tend to raise a bit of a stink when it's discovered...

Re:Kills any idea of using Qt in our products

[Brandybuck]

Why the heck is this modded down as a troll? Yet more evidence that the Slashdot moderation system is seriously broken.

It's good news, but is it too late?

[tjstork]

I mean, the need for GUI toolkits that are portable was a void that Qt was early to fill, but now, there's a lot of choices out there, and I think those choices might have undermined Trolltech's business post Nokia purchase. Like, 5k was a good thing to pay when there were no portable frameworks, but, there are plenty of them out there.

First off, there's Java. As the old saying goes, if you want an application framework that does everything, maybe C++ isn't your language. Java is portable, has several very good IDEs for it, from NetBeans 6.5 is nice and I think JBuilder is actually good as well.

For C++, wxWidgets is actually pretty impressive and it increasingly has GUI designers that you can use. Then, there is the C++ GTK toolkit, which is out there. And then, there's any other number of frameworks that are a bit less tried and true. And, honestly, C++0x is going to have so many changes to it, that, you almost have to wonder how much a good legacy C++ codebase is actually worth. Qt was born in an era when even templates didn't work right, and now, C++ is fairly mature, C++0x builds on that, and, you almost have to wonder, if the U/I toolkits don't need to be rethought in terms of modern things like STL under C++0x, new closure features coming, and so forth.

Re:It's good news, but is it too late?

[ardor]

Qt beats wxWidgets by a wide margin. The API is much cleaner, documentation is a lot better, and wxWidgets has nothing like QGraphicsView (actually, *no* toolkit out there has anything like this).

You are right that Qt uses very umm... baroque C++, but the fact is that it is a very good toolkit, the best opensource one out there. Using new features don't guarantee a top result, and vice versa.

Re:It's good news, but is it too late?

[VZ]

Qt beats wxWidgets by a wide margin. The API is much cleaner, documentation is a lot better, and wxWidgets has nothing like QGraphicsView

Being a wx developer, I don't know Qt well but wxArt2d seems to be similar to QGraphicsView, doesn't it?

Re:It's good news, but is it too late?

[shutdown -p now]

You are right that Qt uses very umm... baroque C++, but the fact is that it is a very good toolkit, the best opensource one out there

I dare say it's the best UI (and general multipurpose) C++ toolkit out there, period. It's the only thing that gives you the look and feel and productivity very close to Java/C#-like RAD with all the power and speed of native C++. Even if you aren't doing cross-platform development, but, say, sticking to Windows, Qt is still the best choice; though commercial Windows developers might still want to pay to get VS integration.

Re:It's good news, but is it too late?

[metamatic]

First off, there's Java. As the old saying goes, if you want an application framework that does everything, maybe C++ isn't your language. Java is portable, has several very good IDEs for it, from NetBeans 6.5 is nice and I think JBuilder is actually good as well.

Yes, but have you tried making a good-looking UI with Swing? It's like teaching a dog to walk on its hind legs--you feel accomplished when you get something that looks even passable.

Re:It's good news, but is it too late?

[scorp1us]

Don't forget:

• Qt has Jambi (Java version)
• Qt has the bindings generator (ECMAScript (JavaScript))
• Qt has various bindings to other languages like Qyoto(C#) and Python

Re:It's good news, but is it too late?

[mzs]

All true, plus for about the last two years Qt has seemed much less buggy than wxWidgets. The whole Qt on Windows quagmire is what got me onto wxWidgets in the first place, I may do a lot less wxWidgets in the future now.

Re:It's good news, but is it too late?

[Snoboo]

You are right that Qt uses very umm... baroque C++, but the fact is that it is a very good toolkit,...

What is worse: A C++ toolkit which tries to emulate C via a meta object compiler (we called it the precompiler in the good old days) or a C toolkit, which tries to emulate object oriented programming? Qt might be a good toolkit, but from the C++ point of view GTKMM is far better.

Re:It's good news, but is it too late?

[mzs]

I had problem after problem trying to use wxArt2d on a Mac, it was so bad that in the end I just did what I had to with my with DCs myself.

Re:It's good news, but is it too late?

[JoeMerchant]

I'd say Qt was the first, and they currently are the best at cross platform.

Unless you don't mind Java's performance.

Re:It's good news, but is it too late?

[ardor]

In sum, moc is a minor nuisance, not more. Good documentation, RAD and API are *far* more important.

Re:It's good news, but is it too late?

[JoeMerchant]

You are right that Qt uses very umm... baroque C++, but the fact is that it is a very good toolkit, the best opensource one out there

I dare say it's the best UI (and general multipurpose) C++ toolkit out there, period. ... Even if you aren't doing cross-platform development, but, say, sticking to Windows, Qt is still the best choice; though commercial Windows developers might still want to pay to get VS integration.

I totally agree, and paying to get access to the Visual Studio debugger is also a net-gain.

Re:It's good news, but is it too late?

[Snoboo]

It sure has a good documentation and good RAD capabilities, but it still feels like C + Classes. I can understand why they did this back when they started with the toolkit: The capabilities of the C++ compilers were not what they are now. They should have updated the toolkit long ago to be a real C++ toolkit - every major version number is such an opportunity. I do programm C++ a lot and this baroque C++ is no fun. And MOC is a major nuisance to me.

Re:It's good news, but is it too late?

[stilborne]

similar in that they are both canvases, but not similar in functionality or scope at all. check out this blog post:

http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third-dimension-wolfenqt/

it's pretty insane. =)

Re:It's good news, but is it too late?

[petermgreen]

Java is portable
If you define portable as wintel, lintel and solaris then definately othewise not so much.

Mac is somewhat supported but it's at apples whim and typically they delay for ages then force you to upgrade your OS to get an up to date version of java.

Other linux plaforms are supported but only barely. The openjdk version of hotspot can currently only do JIT on i386, amd64 and possiblly sparc (someone is working on this but how long it will take is anyones guess). I belive there is an attempt to use the openjdk libs with the cacao VM but I dunno how well they work.

The other problem with java is it doesn't play well with other languages. Calling other languages from java is pretty annoying (though made better by the third party JNA). Calling java from other languages is even worse.

Re:It's good news, but is it too late?

[JohnFluxx]

Specifically, what about MOC causes a major nuisance to you?

Re:It's good news, but is it too late?

[Snoboo]

Because it forces me to program C++ in a way that is very unlike C++. If you read the comments on the QT homepage concerning templates you get the impression, that they wish C++ to be way more like Objective C or Java. There is lots you can do with C++ without the need for a metaobject compiler: class properties, signals, slots, ... - just have a look at www.boost.org and see what is has to offer. Memory consumption is nowadays not really the issue anymore. (If you use KDE, you also use lots of the KDE libraries, which add a lot to the memory consumption.)

Re:It's good news, but is it too late?

[JohnFluxx]

> Because it forces me to program C++ in a way that is very unlike C++.

Wow, that's your whole argument for why it's a major nuisance? Really? It takes about 10 minutes to learn.

Re:It's good news, but is it too late?

[Snoboo]

Wow, it might even take me less than 10 min to learn and I actually learned it, but I don't really see the point in using a language, when you don't actually use pretty much anything of this language. C++ has evolved, the basics of QT havn't. Perhaps nuissance is not the right word, perhaps annoyance is better, but Moc is imho simply a hack for something the language can deliver itself by now. Yeah, perhaps I am a C++ purist, but I seem to be not the only one who thinks that C-Macros should have very little place in a C++ program - especially when they pollute the main namespace. E.g. see http://lists.trolltech.com/qt-interest/2002-08/thread00000-1.html

Re:It's good news, but is it too late?

[JohnFluxx]

> I don't really see the point in using a language, when you don't actually use pretty much anything of this language.

Templates are hardly the only feature of c++. Can't you make your point without completely over exaggerating everything?

> especially when they pollute the main namespace.

You're linking to a post that is 7 years old? Qt lets you choose between using 'signals' or using Q_SIGNALS. KDE uses latter, specifically to avoid namespace problems.

> Moc is imho simply a hack for something the language can deliver itself by now.

Not at all. Read:
http://doc.trolltech.com/4.4/templates.html

Another big advantage that that link doesn't mention is scripting support. Qt binds very nicely to javascript, python, etc. C++ templates don't allow for introspection and calling functions based purely on a string name. (At least, afaik. Correct me if I'm wrong)

Re:It's good news, but is it too late?

[Snoboo]

> I don't really see the point in using a language, when you don't actually use pretty much anything of this language.

Templates are hardly the only feature of c++. Can't you make your point without completely over exaggerating everything?

Point taken, sorry, my fault, but I am not exaggerating everything. A few examples: .) Does it use templates - no. .) Does it use standard collections & iterators - no. .) The standard C++ string? no, you cannot even construct a QString from a std::string without using c-strings. .) Qt hardly uses any exceptions (apart from exceptions thrown by "new" and those are not QT exceptions). No templates, no exceptions? So I think I am not that far from the truth. Nevertheless sorry for the exaggeration.

> especially when they pollute the main namespace.

You're linking to a post that is 7 years old? Qt lets you choose between using 'signals' or using Q_SIGNALS. KDE uses latter, specifically to avoid namespace problems.

It is still featured in the wikipedia entry about QT, and therefore still seems to be valid. Please correct the (german) wikipedia entry if you feel that this is not valid anymore. The english wikipedia entry boils basically down to the same conclusion. Q_SIGNALS is a new name for the same old concept: C-macros. The advantage is of course, that it won't pollute the namespace anymore. And it seems to have appeared in QT 4.4 (please correct me if I am wrong), that means somewhere in Mai 2008. So that development is pretty recent and therefore not really something to be proud of.

> Moc is imho simply a hack for something the language can deliver itself by now.

Not at all. Read: http://doc.trolltech.com/4.4/templates.html

I have read it all. And some things on this page are plain wrong: example: "Our approach goes far beyond anything you can do with templates. For example, we can have object properties. And we can have overloaded signals and slots, which feels natural when programming in a language where overloads are a key concept." It basically a marketing page.

Another big advantage that that link doesn't mention is scripting support. Qt binds very nicely to javascript, python, etc.

So does Gtk. You can wrap C++ templates with SWIG, but this is not the way templates are meant to be used and therefore more complicated. But it is possible.

C++ templates don't allow for introspection and calling functions based purely on a string name. (At least, afaik. Correct me if I'm wrong)

You are right, that is a shortcoming of C++. Meanwhile lots of compilers support "typeof". The library Boost.Typeof should also be able to help under certain circumstances. The question for me is: Do I really want to call a function based on a string name? I never came across a situation where I needed to do that. There were always more robust ways so solve the problem.

Re:It's good news, but is it too late?

[pherthyl]

>> Qt might be a good toolkit, but from the C++ point of view GTKMM is far better.

You're absolutely right. So if you are programming to write high quality programs in the least possible time for real world applications, chose Qt. If you are a language purist who values that more than productivity, chose GTKMM.

Re:It's good news, but is it too late?

[Snoboo]

Have you ever used GTKMM? Why is it so "unproductive"? Are they http://www.gtkmm.org/commercial_support.shtml all wrong?

Re:It's good news, but is it too late?

[pherthyl]

>> Does it use templates - no

Sure it does, all the collection classes are templated.

>> Does it use standard collections & iterators - no

True, although I like the api of the Qt collections much better than the std ones.

>> The standard C++ string?

The standard C++ string class is horrible for GUI applications. It just sucks. No convenience functions, no unicode. Blah. Thank god for QString.

>> you cannot even construct a QString from a std::string without using c-strings

Sure you can:
QString QString::fromStdString ( const std::string & str )

>> Qt hardly uses any exceptions

This one is true. I agree that in certain situations Qt should definitely add some exception support.

>>It is still featured in the wikipedia entry about QT, and therefore still seems to be valid.

Haha. Wikipedia says it so it must be true :)

>> And it seems to have appeared in QT 4.4 (please correct me if I am wrong)

Actually it was first an option in Qt 4.1. Not sure of the exact date, probably early 2006.

>> It basically a marketing page.

So.. what about the rest of the points on that page? Introspection and all that good stuff comes from moc. I sure appreciate it a lot more than that warm fuzzy feeling of being more pure to the C++ language.

Re:It's good news, but is it too late?

[pherthyl]

Yes I have.
I'll tell you why it was so "unproductive" using my current project as an example. It's a small visio-like diagramming tool for a niche application that I sell. It comes in at a scant 7000loc, but does flowchart editing with various shapes, images in vector and raster formats and automatic connectors, manipulates SQL databases, autoupdates from the net, the canvas is zoomable, movable, undoable. Printing, spellchecking, exporting to PDFs and images, etc.
All this with 7 delete statements and no memory leaks (since Qt manages most of the memory).
All this with two dependencies (Qt and aspell).
All this works on 3 platforms, with the only platform specific code related to handling aspell differences.
Native look and feel on windows. And I mean really native, not "skin that looks like native".
Build steps on each platform are "qmake make"

You just can't do that with GTK (mm or # or what have you). You will end up depending on many different little libraries, each one with a different build system and various levels of quality, documentation, maturity, and cross-platform issues. I do this as a side business, but I also do it for fun, and dealing with those kinds of hassles is not fun.

Re:It's good news, but is it too late?

[Snoboo]

>> Does it use templates - no

Sure it does, all the collection classes are templated.

Sorry, my fault, I was not precise enough. Having only templated collection classes is hardly something to be proud of.

>> Does it use standard collections & iterators - no

True, although I like the api of the Qt collections much better than the std ones.

ok, personal choice.

>> The standard C++ string?

The standard C++ string class is horrible for GUI applications. It just sucks. No convenience functions, no unicode. Blah. Thank god for QString.

>> you cannot even construct a QString from a std::string without using c-strings

Sure you can: QString QString::fromStdString ( const std::string & str )

Ok, my bad, I only check the Constructors. What you say about UTF-8,.. is also true, since also GTKmm uses a different string class.

>> Qt hardly uses any exceptions

This one is true. I agree that in certain situations Qt should definitely add some exception support.

>>It is still featured in the wikipedia entry about QT, and therefore still seems to be valid.

Haha. Wikipedia says it so it must be true :)

You are really fun. It is true (at the end of the following page - and - hurray - its from trolltech): http://doc.trolltech.com/4.4/signalsandslots.html

>> And it seems to have appeared in QT 4.4 (please correct me if I am wrong)

Actually it was first an option in Qt 4.1. Not sure of the exact date, probably early 2006.

Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.

>> It basically a marketing page.

So.. what about the rest of the points on that page? Introspection and all that good stuff comes from moc.

I don't know what you exactly need, but this might be an option for you if you want Introspection: http://en.wikipedia.org/wiki/Typeid The other major point on the page is creating connections to UI produced from XML files ("GUI is dynamic") I imho frankly don't see much point in doing this. The translations are not in the UI anyway, so why bother to construct the UI from an XML file during runtime? Never missed this feature and its no problem doing something like this with templates during compiletime.

I sure appreciate it a lot more than that warm fuzzy feeling of being more pure to the C++ language.

Please be more specific what other good stuff comes from moc and gives you a warm and fuzzy feeeling? I cannot get a warm and fuzzy feeling from programming C in C++.

Re:It's good news, but is it too late?

[Snoboo]

Sure, Qt gives you an "All in One" toolkit. And I never said, that it does not have lots of features in the library. But if GTKMM is really as bad as you describe it, I wonder how e.g. Ardour (http://ardour.org/) or k-3d (http://www.k-3d.org/wiki/Main_Page) came into being (ok, Ardour does not support Windows, only Linux and Mac OS X). Sure, GTKMM might not offer you what you are looking for, but it still does for other people, who also develop professional software.

If you are a language purist who values that more than productivity, chose GTKMM.

Is therefore something of a slight exaggeration.

Re:It's good news, but is it too late?

[pherthyl]

Sorry, my original comment was meant to be somewhat tongue in cheek. Of course you can write great applications with GTKMM. You can write great applications with any combination of language and toolkit. Great applications were written in assembly, even though we can now agree that using it for a new desktop application would be insanity. GTKMM is a decent choice, but it is my firm belief that it is not the best choice. And for me, I have only very limited time to devote to my side business, and Qt enables me to make a viable, successful product with those very limited resources. To me that is critical, to others it is not. Anyway, those projects you point out were written before this announcement. I can fully understand the attraction of using an LGPL/BSD toolkit instead of a GPL one, and how it can outweigh many other factors.

Re:It's good news, but is it too late?

[pherthyl]

>> You are really fun. It is true (at the end of the following page - and - hurray - its from trolltech): http://doc.trolltech.com/4.4/signalsandslots.html [trolltech.com]

Wrong. Just because it's mentioned on that page for the first time in 4.4 doesn't mean it was added in that version. It was added in 4.1 as shown in the release notes from Trolltech themselves:

http://www.qtsoftware.com/developer/changes/changes-4.1.0

>> Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.

Why are you so obsessed with timing? Who cares whether it was a problem in the past? You complained about namespace pollution, it's no longer an issue. Period.

>> Never missed this feature

Ah yes,the old "I don't use this feature therefore it's useless".

Re:It's good news, but is it too late?

[Snoboo]

>> You are really fun. It is true (at the end of the following page - and - hurray - its from trolltech): http://doc.trolltech.com/4.4/signalsandslots.html [trolltech.com]

Wrong. Just because it's mentioned on that page for the first time in 4.4 doesn't mean it was added in that version. It was added in 4.1 as shown in the release notes from Trolltech themselves:

Wrong in what way? Forgive me, if my comment was not as clear as it should have been, but I am not wrong in this case. The point was, that this problem is still there, as detailed in the mailing list posting, if you don't use Q_SIGNAL, because you doubted the correctness of the mailing list posting. The point was not that it was added in 4.4 and not previously. You said that it was added in 4.1 and I am in no position to doubt that.

http://www.qtsoftware.com/developer/changes/changes-4.1.0

>> Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.

Why are you so obsessed with timing? Who cares whether it was a problem in the past? You complained about namespace pollution, it's no longer an issue. Period.

I never said, that the problem is not solved. You told me so in your previous post and I don't doubt it. I don't care about the timing either. I just pointed out, that 4 years is a heck of long time to fix such a problem.

>> Never missed this feature

Ah yes,the old "I don't use this feature therefore it's useless".

Yeah, a really good answer. It there any better reason to use this? I won't use it just because it is there. I am sorry, but I will not continue this discussion. This is slowly degenerating into a flamewar and I do not see any benefit for either of us if this continues. Have a nice evening.

Re:It's good news, but is it too late?

[Snoboo]

Anyway, those projects you point out were written before this announcement. I can fully understand the attraction of using an LGPL/BSD toolkit instead of a GPL one, and how it can outweigh many other factors.

True. Their choice might have been otherwise after the announcement. I have no idea why they chose GTKmm instead of Qt.

And for me, I have only very limited time to devote to my side business, and Qt enables me to make a viable, successful product with those very limited resources. To me that is critical, to others it is not.

If Qt offers basically everything you need and reduces both the development time and the dependencies to the absolutly necessary minimum, then every other solution is the worse choice. One has to earn money for a living. Good night

Re:It's good news, but is it too late?

[JohnFluxx]

> The point was, that this problem is still there, as detailed in the mailing list posting, if you don't use Q_SIGNAL

You're complaining that the problem is there if the programmer chooses it to be there? How that a problem? Even if Qt removed the option to enable 'signal', a programmer could still "#define signal Q_SIGNAL" if they wanted, and thus 'polute' the namespace.

> why bother to construct the UI from an XML file during runtime?

Some programs allow the user to construct their own GUIs. Kontact does it, for example, as part of their exchange support. If you're not convinced - how about DBUS support?
DBus communication is an example of when you want to convert a string to an actual function.
Or scripting support - if you want to use a Qt object via javascript?

(Btw, you realise that you're talking to two different people?)

Re:It's good news, but is it too late?

[Snoboo]

> The point was, that this problem is still there, as detailed in the mailing list posting, if you don't use Q_SIGNAL

You're complaining that the problem is there if the programmer chooses it to be there? How that a problem? Even if Qt removed the option to enable 'signal', a programmer could still "#define signal Q_SIGNAL" if they wanted, and thus 'polute' the namespace.

Ok, I tool my point probably too far. You are right, this solves the problem. But "signal:" is still the default mode and the better alternative is mentioned in the very last section of the very last version of the documentation on signals/slots and not really advertised as the solution one should use. Of course, this is only a problem of the documentation.

> why bother to construct the UI from an XML file during runtime?

Some programs allow the user to construct their own GUIs. Kontact does it, for example, as part of their exchange support. If you're not convinced - how about DBUS support? DBus communication is an example of when you want to convert a string to an actual function. Or scripting support - if you want to use a Qt object via javascript?

Its not really a question of being convinced or not. As I wrote: I never missed the feature. Ok, you provide me now with several examples why this is useful. ok. Btw.: Even in this case templates can be used for the signal mechanism (-> libglademm)

Ah yes,the old "I don't use this feature therefore it's useless".

Not really using a new feature is not really something I am guilty of. Blame me for not looking far enough into the software world, blame me for anything, but I am not guilty of that. Sorry, I probably was a bit upset about this statement. My fault.

(Btw, you realise that you're talking to two different people?)

no, sorry, it was late yesterday evening. - guilty

Re:It's good news, but is it too late?

[Reality Master 201]

Oh my fucking god! How do you eat such giant cocks?!?

Penis munch!

PyQt?

[robot_love]

I wonder what will happen to PyQt? They have traditionally offered the same licensing as Trolltech, but at a much cheaper rate. I'm curious to know what Qt's change to the LGPL will mean to them.

Re:PyQt?

[Anonymous Coward]

Maybe nothing? They can stay GPL/Commercial just fine.

Re:PyQt?

[pembo13]

I hadn't thought of that. Will be interesting to hear. I'm on the list, and nothing has been mentioned officially yet.

Re:PyQt?

[Simon]

...and now without needing a Qt license, I imagine PyQt becomes a much cheaper proposition for most closed source developers.

--
Simon

Re:PyQt?

[FunkyELF]

Lets just hope that Riverbank will allow their Commercial PyQT to be used with the LGPL QT and not restrict it to the Commercial QT version.

Re:PyQt?

[robot_love]

Yes. It would seem silly to turn away clients who want to do PyQt projects and could afford Riverbank's 350 GBP license, but couldn't afford Qt's $1000 license on top (for small business).

I've done some personal projects with the GPL version of PyQt, and I've often thought of buying a license for PyQt to do commercial work. If I only need a PyQt license and not a Qt license, I'll almost certainly do so in the next year. The price seems a little steep, but still a good deal.

Finally!

[Aladrin]

I considered QT when I was looking for a good GUI for an open source project I was considering, but ended up rejecting it on licensing agreements. It has actually gotten better licensing twice since then, and now I would actually choose it.

That project, sadly, never happened because I never found a GUI toolkit I thought would do what I needed. How many other projects were similarly stalled like this?

This is indeed good news.

Re:A GUI for MySQL?

[hobbit]

At last! Qt has gone LGPL! The final obstacle to our creating a front-end for MySQL has been removed!

What on earth are you talking about?

KDE is a perfect cross-platform environment

[oever]

One year after Nokia bought Trolltech, they've released Qt as LGPL. This positions Qt and KDE in an excellent position for cross-platform application development for FOSS *and* commercial projects. KDE libraries were already licensed under LGPL. This means the entire stack is now LGPL.

In the mean-time, Qt Creator, an IDE for developing Qt applications, has been announced. This will be all you need to write cross-platform applications with Qt.

Qt Jambi (java bindings for Qt) will also available under LGPL. Qyoto (mono bindings) and the other bindings (Perl, Python, Ruby) will be able to make releases under LGPL now.

These are exciting times!

Re:KDE is a perfect cross-platform environment

[FishWithAHammer]

The Mono crew will be able to release their stuff under LGPL too. which is great, because Winforms->QT# is a really easy port.

Re:KDE is a perfect cross-platform environment

[Enderandrew]

Yet when Nokia purchased the Trolls people insisted they would try to close up Qt and fight FOSS. Nokia did oppose open formats in HTML 5 for some crazy reason, but maybe Nokia isn't so evil after all.

Re:KDE is a perfect cross-platform environment

[Shimmer]

The Qyoto project doesn't seem to exist anymore. Or at least Google can't find it. Anyone got a working link?

Re:KDE is a perfect cross-platform environment

[oever]

See the package qyoto-examples in ubuntu or check out the code here.

Re:KDE is a perfect cross-platform environment

[Simon]

http://websvn.kde.org/trunk/KDE/kdebindings/csharp/

The C# support has been steadily worked on for the last few years and should be quite mature by now.

--
Simon

Re:KDE is a perfect cross-platform environment

[Anonymous Coward]

Commercial projects means Closed source projects. Closed source applications require the entire stack to allow closed source. Almost all programs finally required to link with C library of the OS at last, Linux's C library (glibc) is GPL covered, therefore, on Linux you cannot run a closed source app without breaking GPL means without breaking law. Qt now LGPL is only useful for developers who intend to develop closed source applications for Windows, Mac OS X and BSDs, not for Linux. RMS must be very unhappy now because this move paves way for closed applications for people to earn money. RMS says all software must be free. So don't get caught breaking GPL.

Re:KDE is a perfect cross-platform environment

[oever]

Nonsense, libc is LGPL. You should read a bit more before you talk rubbish.
You are aware that there are currently closed source applications running on Linux, right? Are all of these breaking the GPL or do they magically avoid libc?

Re:A GUI for MySQL?

[vurian]

I don't either, but he might take a look at kexi http://www.kexi-project.org/...

That would be a disaster

[WindBourne]

Think about Xfree. it was basically a closed monopoly. Then X11 grabbed it and opened it up further. Has it improved things? Absolutely. Basically, we NEED competition. GNOME is good competition, vs. say MS's form of competition (involving lots of dirty tricks and legal maneuvers).

Re:That would be a disaster

[siride]

There's no competition between XFree86 and X.org because XFree86 is effectively dead. There still is a monopoly on X, but they have a more open development process, which is why things are proceeding at a faster pace now.

Re:That would be a disaster

[Anonymous Coward]

>say MS's form of competition (involving lots of >dirty tricks and legal maneuvers).

You forgot Mono.

Re:That would be a disaster

[Kjella]

Think about Xfree. it was basically a closed monopoly. Then X11 grabbed it and opened it up further. Has it improved things? Absolutely. Basically, we NEED competition. GNOME is good competition(...).

Linux? OpenOffice? Firefox? Don't tell me BSD, KOffice and Konqueror have any serious marketshare to compete. If you mean closed source competition, we got it. The desktop should absolutely be configurable to the point where it could look like either GNOME or KDE. But that there's any big inherent bonus in having two different codebases that don't talk and can't share easily because they're built in different languages is just bullshit. We're talking about a generic framework here where you plug stuff into.

Re:That would be a disaster

[Eil]

I agree 100%. I used to think the KDE/GNOME divide was bad for the Linux desktop. Then KDE4 came out and as much as I'm no big fan of GNOME, I was glad it was there because KDE4 sucked too hard to be my daily desktop. Hopefully 4.2 will bring back the stability and flexibility of 3.5.x, but we'll see.

Re:That would be a disaster

[stilborne]

"The desktop should absolutely be configurable to the point where it could look like either GNOME or KDE"

that desktop is called "plasma". we'll be introducing layout switching for plasma in kde 4.3 letting you change between (or add to existing) layouts with the click of a button. you can already swap things about by hand, since the support for this was built into the design from the start, but making that part of the machine user accessible is kde 4.3 material.

plasma itself has no assumptions (or, really, knowledge) about what "must" be there. you can have 0, 1, 2, or N panels; any number of desktop activity layouts; even per-virtual-desktop layouts (experimental feature in 4.2; we hope to iron out the wrinkles and then expose it in the UI for 4.3) ..

so .. yes. we're going there. =)

Re:That would be a disaster

[kojot350]

...we'll be introducing layout switching for plasma in kde 4.3 letting you change between (or add to existing) layouts with the click of a button. you can already swap things about by hand, since the support for this was built into the design from the start, but making that part of the machine user accessible is kde 4.3 material.

so .. yes. we're going there. =)

wow, now I'm happier KDE4 user :)

No copyright assignent

[dfdashh]

From arstechnica:

To further reduce the barrier to participation, Nokia plans to accept code from contributors without requiring copyright assignment.

If they do what this article suggests they will, this is a big step towards better code and community involvement. Go Qt, go!

Re:No copyright assignent

[mrchaotica]

It also means that they'll never be able to change the license again in the future -- no worries about future versions going to a proprietary license (or even back to regular GPL).

Jump onboard Firefox and Adobe!

[bogaboga]

With this development, I hope Firefox and Adobe developers will jump on board...fast. I would also like to see the folks at OpenOffice.org on board the QT bandwagon as well. The interfaces I see on Openoffice and Adobe's PDF reader would look better with QT in my opinion.

Re:Jump onboard Firefox and Adobe!

[pak9rabid]

XMAS comes early, my friend.

Re:Jump onboard Firefox and Adobe!

[bjkinney]

I was thinking the same thing. While Konqueror is a nice browser I could never replace Firefox with it.

There is a QT port of Firefox but when I tried it it was still in the very early development stages and was unusable.

Re:Jump onboard Firefox and Adobe!

[piquadratCH]

Did anything come out of this? I compiled and tried it back in August, but it (unsurprisingly) crashed all the time and had some major rendering bugs. I never heard anything about the project after the initial announcment.

Re:Jump onboard Firefox and Adobe!

[Anonymous Coward]

well, i'm still waiting for my qt-firefox, and the last time i saw movement on its development was late '07...

anyone knows if there's been any progress on this?

Re:Jump onboard Firefox and Adobe!

[Anonymous Coward]

The interfaces I see on Openoffice and Adobe's PDF reader would look better with QT in my opinion.

You actually use Adobe's PDF Reader? O_O

Very nice! It's death of RIA!

[codedj]

Very nice move!

This also means serious damage to RIA aproach too. Without QT, it was very difficult to create cross-platform apps (running on OSX, Linux and Windows).

Java was an option, but too few people used it for small apps like shareware utilities.

RIA was an option, but their are immature and do not allow to implement a lot of things.

Gtk was another ugly option.

Also running web server locally (e.g. with web server for CD and USB drives ) was elegant option for some cases when UI is rendered by web browser and backend is implemented using server-side programming language like php or python running locally.

Now it seems a lot of shareware authors will start using QT even for developing Windows-only apps. This means a lot of new apps that are stable and cheaper to develop will enter the market soon. Hopefully most of those apps will probably be ported to OSX (and even Linux) by their authors afterwards.

Re:Very nice! It's death of RIA!

[vurian]

And don't forget that Qt+QtWebkit is a very good choice for a cross-platform RIA application -- it's what we're doing at work and it's giving us a chance to get the best of two rolds.

Re:Very nice! It's death of RIA!

[Yosho]

Um, wxWidgets has been around for many years, and it can be used to write decent-looking GUIs for OS X, Windows, Linux, and many more operating systems.

While I think Qt's API is a bit nicer, it was already pretty easy to make cross-platform GUIs.

Re:Very nice! It's death of RIA!

[codedj]

Unfortunately WxWidgets are too buggy on every platform, and bugs are different accross platforms.

I have several friends trying Wx for their commercial apps, all of them abandoned it due to bugs and lack of features.

Re:Very nice! It's death of RIA!

[qbast]

wxWidgets is an option as long as you don't mind spending weeks debugging lots of small cross-platform inconsistencies.

Re:Very nice! It's death of RIA!

[Vexorian]

wxwidgets is a great option if you don't mind :

a) That your windows users need 9 MB more for DLLs in their packages.

b) That Linux users will have difficulty getting the wxwidgets version you are using

c)c) Dunno about other OSes, maybe they work completely fine on them, (That's aright, all of the non-windows, non-Linux OSes!)

Re:Very nice! It's death of RIA!

[Anonymous Coward]

a) That your windows users need 9 MB more for DLLs in their packages.

Oh, boo-hoo, not 9 MB of space! Please, that's a pitiful amount of space on a modern hard drive, and it's not like you don't have to distribute Qt DLLs along with your program, too.

b) That Linux users will have difficulty getting the wxwidgets version you are using

Only if they're not using a decent package manager that can install whatever version you request. Or you could just statically link your program; problem solved.

Your presented issues are only problems if you're specifically looking for nits to pick. wxWidgets has problems... but those are not two of them.

ARGH! Just migrated to CMake + added Wx support :(

[QX-Mat]

ARGH.

I have spent the last few days migrating from QMake to CMake and adding a WxWidgets GUI to my project.

ARGH!

The CMake stuff is useful (qmake needs some test scripting a la autoconf) because i can use it for library discovery, but the Wx GUI is now pointless.

ARGH!

Implications of LGPL for Qt Developers

[Jeff Tranter]

ICS, Qt Software's largest consulting partner, has a whitepaper on their web site at http://www.ics.com/ that talks about the implications of Qt being available under the LGPL. This helps make sense of what it will mean to developers.

Re:Yeah but KDE doesn't work.

[Anonymous Coward]

screwed up my kernel

How did KDE screwed up your kernel?

Great news

[squoozer]

While competition is generally a good thing I think the fight between Gnome and KDE has seriously hampered the adoption of Linux on the desktop (even if there hadn't been a fight I don't think we would see widespread Linux use on the Desktop but it would be greater than it is). The problem was that they were both good, for different reasons, and both had a good developer base the end result of which was a battle neither side could really win and we all lost from.

While I would hate to see Gnome consigned to the dustbin I think it's about time they gave up and admitted that KDE has won (flame away). I admit that KDE isn't perfect, far from it, but KDE4+ is streets ahead of Gnome now and the big hurdle to widespread use by companies has now vanished.

Re:Great news

[Anonymous Coward]

Isn't KDE4 the advanced desktop that just recently implemented the revolutionary feature of hiding panels?

Perhaps you could make the argument KDE 3.5 was ahead of Gnome, but I think KDE4 has a ways to go. Though, I will admit KDE4 is winning the eye candy battle.

Re:Great news

[Hairy Heron]

I admit that KDE isn't perfect, far from it, but KDE4+ is streets ahead of Gnome now and the big hurdle to widespread use by companies has now vanished.

Hahahahaha KDE4+ is total disaster. That was a good joke.

Re:Great news

[Anonymous Coward]

How has KDE won? Almost all the mainline distros use GNOME as the default environment. Don't drink the kool-aid fanboi!

Re:Great news

[wikinerd]

I don't think the concept of fight exists in free and open source software. Free software is free speech, and different projects exist because different people have different things to say. Nobody is fighting.

Re:Great news

[bendodge]

I'm not a coder, but I am an avid KDE4 user. I'm sure it's technically possible to port all of GNOME's good stuff to use KDE's libs, but are the people involved willing to work together? I don't know enough background and history in the long GNOME vs KDE thing to know if the emotional people behind them could be merged. Is there any possibility of that happening?

Re:Great news

[Hairy Heron]

Exactly. If we are going by true stats like that KDE is the one to be dumped not Gnome.

Re:Great news

[hunteke]

[KDE and Gnome both good for different reasons]

While I would hate to see Gnome consigned to the dustbin I think it's about time they gave up and admitted that KDE has won (flame away). I admit that KDE isn't perfect, far from it, but KDE4+ is streets ahead of Gnome now and the big hurdle to widespread use by companies has now vanished.

I will give you that KDE4 has a ton more features than Gnome, as well as a couple of programs that are better. However, as an outside observer (read: end-user), Gnome and affiliated programs fit my bill because they are generally more stable, and have smaller memory-footprints to boot.

Anecdotally, let me give some examples:

• At work, I have two identical machines, circa 1 year ago hardware-wise. I'm running Kubuntu 8.10 and Ubuntu 8.10 on them. The KDE one regularly "loses" the mouse or keyboard. They just plain stop responding. I used to have to CTRL-ALT-F1, and restart kdm to get back responsiveness. The Gnome version has yet to show me this behavior.
• The KDE desktop will entirely freeze from time to time. I'm not running much, just doing something simple, like switching between desktops, or alt-tabbing through windows. And bam. I have to resort to CTRL-ALT-F1. Sometimes that won't even work, and I have to hard-reboot. Doing similar in Gnome has yet to show me similar behavior. (I use them both in similar ways, for the same things - it's a test environment.)
• Programs will randomly quit. An example is KMail. If I get a new IMAP mail, it sometimes decides to quit. Evolution does this too, but much less frequently.
• Off the top of my head, some KDE programs with different, but annoying problems: Kate, KOffice, Konqueror, Kopete, Konversation, Kirc. In contrast, I find that their GTK counterparts "just work," are faster, and use less memory to boot. Gedit/jEdit? OpenOffice? Firefox? Pidgin? Yeah, very successful on the Gnome desktop.

On that note, I find that KDE and QT apps are just ... slower than Gnome and GTK apps. Clicking on a menu shouldn't take 4 or 5 seconds to pop up. It should be pert-near instantaneous. Switching desktops should take milliseconds, not seconds, nor should it matter to which virtual desktop I'm switching.

I'm not dissing KDE, but rather pointing out that it's not as complete as folks say it is. I'll concede KDE's successes. I have only small gripes against Amarok, and indeed use it as my default music client. I believe Konsole to be superior to Gnome's terminal in terms of usability. Okular is a decent program although I prefer Evince for it's simplicity.

But for the majority of my KDE4 experience ... Crashing randomly, even if it's only in my particular use case, is hardly successful, especially when the counterpart doesn't crash for my use case. Using excess memory is another no-no. I have 4 Gigs on both of these machines, and the KDE one consistently has problems, starting to swap, etc. Unacceptable.

I believe that Gnome is far from dead, and as long as KDE has these problems, it is not nearly as far ahead of Gnome as one might think. In fact, in my mind, stability and resource usage are far more important.

But what do I know? I'm just an end-user.

Re:Great news

[stilborne]

"Isn't KDE4 the advanced desktop that just recently implemented the revolutionary feature of hiding panels?"

ha. ha.

yes, panel hiding was recently implemented (and with a neat hover-on-approach feature if you have a compositing window manager), but it also had a dashboard (where's that in anything not-MacOS?), multiple widget layouts on desktop, zooming and various other features you won't find most other places, or in some cases, anywhere else right now. take the whole picture in and it's a different story.

add in google gadgets, enlightenment 17 edje content support, ruby/python/javascript bindings, the krunner search plugins, the wallpaper plugins, the beautiful artwork, the general flexibility and the large number of widgets that come with it .. it's pretty compelling in 4.2 indeed.

and we have plans for much, much, much more.

as for kwin, it too has comes leaps and bounds. the number of effects have risen dramatically and the quality of the effects is quite high. the focus is on usefulness and beauty combined for kwin's effects, so you won't find the more silly effects you can in compiz, but you will find high quality, fast, functional ones. that includes the cube, cylinder and sphere as well as wobbling windows, if you're into that. =)

"but I think KDE4 has a ways to go"

check out 4.2. i don't think we have a ways to go at all, and currently about to start lapping both kde3 and the other desktop environments out there as we move on to yet further adventures =)

Re:Great news

[sricetx]

find that KDE and QT apps are just ... slower than Gnome and GTK apps. Clicking on a menu shouldn't take 4 or 5 seconds to pop up. It should be pert-near instantaneous. Switching desktops should take milliseconds, not seconds, nor should it matter to which virtual desktop I'm switching.

What graphic card and driver are you using? I've read that KDE4 has issues with nvidia binary driver versions earlier than 177.80 due to bugs in the driver.
I've had problems with it using the amd fglrx driver with integrated graphics too (740G chipset, Radeon HD2100 integrated graphics).
When I bought a cheap nvidia 7200GS card and switched to using the current version of the nvidia binary driver available for Kubuntu 8.10 (177.82 I believe) performance improved markedly.

Re:Great news

[hunteke]

What graphic card and driver are you using? I've read that KDE4 has issues with nvidia binary driver versions earlier than 177.80 due to bugs in the driver.

That's exactly the point. KDE4 "has problems" that Gnome doesn't. Thus, for what I (and I'd guess many others as well) do, KDE4 is almost unusable. Or put simply, Gnome works, KDE4 doesn't.

I'll give you that sometimes you have to fix hardware issues. (At least one does in the Windows world.) On the other hand, I've experienced similar slow differentials on similar hardware with and without binary drivers from nVidia, with integrated graphics systems, and with ATI cards.

The slow issue is one of a few problems, that for me, are show-stoppers.

Re:Great news

[sricetx]

I see your point, and I agree that KDE4 has been a big regression from the very stable, very usable KDE 3.5.x. I've never used Gnome, so switching to it would be a learning curve, so I've been trying to have patience with KDE4. I've tamed KDE 4.1 in Kubuntu 8.10 to the degree that it is reasonably usable (my wife still hates it compared to 3.5). Customizing Dolphin to have an "Up" button was a big help -- what were they thinking in leaving that out by default?? I still think KDE 3.5 was a hell of a lot more stable and usable. The KDE folks are promising big things for version 4.2, which is supposed to be the release for regular folks (I've read that 4.1 was targeted to "early adopters"). It should be released later this month.

Re:Great news

[Anonymous Coward]

The KDE folks are promising big things for version 4.2, which is supposed to be the release for regular folks (I've read that 4.1 was targeted to "early adopters").

Eh, we'll see. I think it may be more marketing hype than anything else. I tried both 4.0, and 4.1 with Kubuntu, Fedora and an LFS system I built. All three were ... lacking and buggy in just the right areas. I must agree with hunteke on the gripe of bugginess and memory usage. There is just no reason that they need to be such memory hogs.

4.0 was supposed to be the "zero" release, which I hadn't heard of before the KDE project. But fine, they said that well in advance. However, this is the first I've heard of the 4.1 being for early adopters, and, to be honest, I'm wondering if it's more because it wasn't quite where they wanted it at release time. 4.2 ... well, we'll see, we'll see.

Re:Yeah but KDE doesn't work.

[Sir_Lewk]

Have you tried anything more recent than 4.0? Things have improved A LOT since then. Hell, we are almost at 4.2 already, 4.1 is nearly just as featureful as the 3.5.x line ever was.

Also, I really cannot see any way that KDE could ever "screw up your kernel". Firstly, your kernel image should never be writable to anyone but root (and if you are running KDE as root we need to have a talk...). Secondly, even if the kernel image was writable, KDE shouldn't touch it unless you explicitly tell it to do something. My guess is your system was already messed up to begin with.

There are GPL GUIs for MySQL available now...

[maxfresh]

Such as HeidiSQL. It's a pretty good GPL graphical front end for MySQL written in Delphi. It's got a couple of bugs, but nothing show stopping that I've come across.

Re:Yeah but KDE doesn't work.

[Bwian_of_Nazareth]

Try comparing KDE 3.5 to KDE 4.2... no, seriously, if you liked KDE, give it another try. KDE has come a long way from 4.0 to 4.2. Many things are much more polished and the whole experience is now very nice (obviously, YMMV). The only thing I am still missing is the printing infrastructure of KDE 3.5.

GTK is not the target...

[Saint Fnordius]

I have a hunch Nokia is looking at XCode and Apple instead. After all, the main battle for them is in the mobile market, and Apple made a big deal about the iPhone being based on OS X. So this is a bid to win over the talented developers.

QT is available on more platforms, true, and it always has been. Still, XCode was free for anyone with a Mac, and the developer kits for the iPhone only required that you own a Mac and that you registered as a developer.

Re:GTK is not the target...

[ceoyoyo]

If only you were right, and if only Apple responded with cross platform Cocoa.

2009 on teh desktop

[Anonymous Coward]

1991-2008 "on teh desktop".

Linux. Failing for 17 years. Windows XPSEVEN2000VISTANTSP9001 Millenium Edition for the win.

Go on mod me down bury brigade. -1, butthurt (google takeittux.jpg).

congratulations to Nokia

[speedtux]

With this, Nokia has removed a major problem for KDE, Qt, and the open source community. The decision by the KDE developers to adopt Qt under its original license was stupid and has done a lot of damage to desktop Linux. Thanks to Nokia for finally solving this problem.

However, not all is well. Personally, I don't like either KDE or Qt particularly from a technical point of view. Qt programming in C++ is a lot nicer than Gnome programming in C. But Gnome bindings to Python and C# are excellent and have good tools support, and that's probably what matters more these days. And if you are silly enough to want to do GUI programming in C++, you can use Gtkmm.

All things considered, I'll stick with Gnome anyway.

Re:congratulations to Nokia

[vurian]

Well, the Python, Ruby, C# and Java bindings to Qt are also excellent and have excellent tools support.

Re:congratulations to Nokia

[darkvizier]

I'm assuming we're talking about development for Linux, or cross platform here, since this is QT. Two questions:

1) Why would you program in C# on Linux? Mono support is years behind the feature sets that MS is rolling out. There are a variety of languages/frameworks that are better supported than .NET.

2) What's wrong with GUI programming in C++? QT tools seem pretty nice to me, and objects are much easier to work with than a mountain of procedural code. C++ should also be plenty efficient for application space.

So, what advantages are there in using C/Gnome?

Re:congratulations to Nokia

[jbolden]

At the time there are options were:

1) Use a good toolkit available only commercially (including redistribution of libraries) like Win32 or OpenStep

2) Use a bad toolkit available free

3) Jump on the GNUStep project bandwagon and tie themselves to Objective-C.

4) Use a sorta kinda free one, with libraries that were clearly free that was excellent and tied to the language the wanted to use.

5) Write their own toolkit.

Smart people picked all sorts of options from this list. I don't know that #4 was really a mistake. Mozilla foundation has been devastated by the work for XUL. OpenOffice ended up picking up the disadvantages of #5 and #2 with none of the advantages of either. Gnome burned through a lot of their very heavy resources on #5.

I was a big fan of option #3 at the time, but look how that would have turned out.

Re:congratulations to Nokia

[ultrabot]

But Gnome bindings to Python and C# are excellent and have good tools support, and that's probably what matters more these days.

PyQt is pretty great as well, and tool support is there (Qt Designer can be used just as for C++).

I don't know about C#, but who cares when you have Python and C++? C++ programming with Qt is not your grandfather's C++ programming (c.f. MFC, Symbian) - it's actually quite tolerable. And PyQt exposes all of Qt.

Re:congratulations to Nokia

[mzs]

You need to buy the commercial version of PyQt if you want to target Windows. All other platforms are GPL or commercial. I wonder if this action by Nokia will have any effect on Riverbank Computing? Most likely not in the short term.

Re:congratulations to Nokia

[Anonymous Coward]

What? You can't say "The GPL applies only to these platforms.". Either it is available under GPL for everything or it isn't for anything.

Re:congratulations to Nokia

[mzs]

Well this shows how dated I am. You are absolutely right. PyQt for Qt 4 is available under GPL, I just checked. Qt used to be that there was a different codebase for Windows and that was not released under the GPL. In Qt 4 that all changed. I never learned until just now that PyQt had made the Windows version available under the GPL as well when you use Qt 4. I should have realized that it would have had to. Thanks for letting me know. I made a bunch of decisions back in '98 that lead me to (the then named) wxWindows. I may have to reevaluate now in light of LGPL Qt and GPL PyQt.

Re:congratulations to Nokia

[MobyDisk]

Why would you program in C# on Linux?

C# and the .NET Framework are just frikkin great.

Mono support is years behind the feature sets that MS

Yeah, but the recent MS stuff is not important. WPF and Linq are just bad, and I don't want them anyway.

What's wrong with GUI programming in C++?

Yeah, GUI programming in C is just awful. C/Gnome programmers: Welcome to 1990.

Until today, I would never have considered QT. So that left me with Java, C++/WxWidgets, C++/GTK+, C#/WinForms, C#/GTK+. I tried C#/GTK+ years ago and it seemed very incomplete. I think that Mono's Winforms implementation is very good now (third time is a charm!) and since I have existing C#/WinForms apps that is the way for me to go.

I might try C++/QT again for larger or higher-performing apps where C# is not an option.

Re:congratulations to Nokia

[ultrabot]

I may have to reevaluate now in light of LGPL Qt and GPL PyQt.

Expect PyQt to go LGPL soon (it's mostly autogenerated stuff anyway) for ultimate goodness.

Re:congratulations to Nokia

[Anonymous Coward]

I was a big fan of option #3 at the time, but look how that would have turned out.

But if more people had gone for option #3 then GNUstep would be in much better shape now. I still prefer GNUstep, and it's what I use everyday (with Window Maker). While it doesn't have anywhere near as many apps as Qt and GTK+, it does have some useful ones that I use all the time.

Re:congratulations to Nokia

[jbolden]

No question. If KDE had gone with #3 and #3 had been successful the Linux world might have been a lot different. For one thing there would have been very strong Mac KDE sharing. Linux would be getting all the cool mac apps because KDE could have had GNUStep keep up.

Well if GNUStep every picks up again I'll be thrilled. With the new LVVM compiler (part of GCC) this would be a great time to make GNUStep an LVVM app and have GNUStep be the home of desktop apps for linux that take advantage of multiple cores.

Re:congratulations to Nokia

[Vexorian]

winforms

So long for your cross platform development intentions.

Re:congratulations to Nokia

[MobyDisk]

Winforms for Mono

Re:congratulations to Nokia

[mrchaotica]

Why would you program in C# on Linux? Mono support is years behind the feature sets that MS is rolling out. There are a variety of languages/frameworks that are better supported than .NET.

Because C# is nice, and you don't have to use .NET with it.

Re:congratulations to Nokia

[speedtux]

1) Why would you program in C# on Linux? Mono support is years behind the feature sets that MS is rolling out. There are a variety of languages/frameworks that are better supported than .NET.

Who cares what Microsoft is doing? Who cares about .NET? Mono with Gtk# is a pretty good platform.

2) What's wrong with GUI programming in C++? QT tools seem pretty nice to me, and objects are much easier to work with than a mountain of procedural code. C++ should also be plenty efficient for application space.

What's wrong with programming GUI apps in C or C++? Then end up bloated, slow, and hard to extend. That's true for both Gnome and KDE (and Windows). They also tend to crash, and you can't safely extend them with plugins. Most people working on those platforms have never seen anything better, so they don't know any better, but the state of GUI and application programming is really abysmal, in part due to the use of C/C++.

So, what advantages are there in using C/Gnome?

There is no advantage in using "C/Gnome". There is an advantage in using Gtk# or PyGnome or any of a number of other HLLs. For that purpose, Gnome is a better choice than Qt, since the use of C++ in Qt only adds unnecessary complexity when binding to other languages.

Re:congratulations to Nokia

[Anonymous Coward]

>> They also tend to crash, and you can't safely extend them with plugins.

Haha.. Wow. You really don't know anything about C++/C do you?

Re:congratulations to Nokia

[speedtux]

Haha.. Wow. You really don't know anything about C++/C do you?

I do, but you obviously don't. Ignorance like yours is why software sucks.

Re:Yeah but KDE doesn't work.

[Enderandrew]

I'm curious how KDE screwed up your kernel.

BTW, what distro are you running, and what version of KDE 4.x did you run?

I've long been seen as a critic of the KDE 4.x branch, but there has been some massive progress moving towards 4.2, which comes out this month.

I highly recommend the openSUSE packages specifically.

Some distros had no clue how to build and package KDE 4 properly.

SWT and Eclipse

[Anonymous Coward]

Great news, perhaps this means we get to see SWT integration with Qt/KDE?

An idea!

[Anonymous Coward]

We should help Nokia buy other companies like Adobe, Microsoft and Apple too.

Do they accept donations?

Re:Yeah but KDE doesn't work.

[betterunixthanunix]

"4.1 is nearly just as featureful as the 3.5.x line ever was."

It is? Funny, I am using it right now, and really, it is not. ArK4 is not even close to ArK3, Konqueror4 is nowhere near Konqueror3 (unless you count functionality that doesn't even work), there is no global configuration for adding SSL certificates and the only configuration that has anything to do with that is broken and hidden in Konqueror, and half the KParts components that were embeddable in KDE3 are either nonexistent or not embeddable in KDE4.

Don't get me wrong, I like KDE a lot, I think it beats GNOME in terms of usefulness. But KDE 4.1 has a LONG way to go before catching up with the 3.5 branch.

Constrained by the LGPL?

[Anonymous Coward]

The article at ars states:

"The commercial licenses will still be available, however, for developers who don't wish to be constrained by the terms of the LGPL."

So, for the uninitiated, how does the LGPL contrain someone? I thought the GPL was responsible for contraint?

Re:Constrained by the LGPL?

[otis wildflower]

Presumably, if folks want to make changes to the libraries themselves, they'd need to make those changes public when redistributing the binaries.. Sort of defeats the purpose if you ask me, but I'm sure there's potential customers who would demand commercial licenses for dopey legal reasons, and perhaps they'll only offer support on the non-LGPL?

Re:Constrained by the LGPL?

[spitzak]

The main constraint is that the LGPL requires that the Qt library be distributed as a shared library (that is not really what the LGPL says, but it is the only practical way to do it). I think it is likely Nokia will add an exception to allow static linking very soon, as they already had a big list of exceptions to their GPL license that allowed that (though not for commercial products).

The other constraint which is very unlikely to change is that if you modify the library itself, you have to include the source code for the modifications. Thus you cannot make some secret change to Qt. However in reality there is really no reason to do that. It is extremely unlikely you have some tricky piece of code you want secret and you are unable to arrange things so that it is not part of Qt itself.

Re:Yeah but KDE doesn't work.

[bmcage]

Over my dead body. I can't stand KDE 4.0.

Can you send us your address?

I wonder if you ever had to develop new widgets based on GTK ... This post should get developers quite excited.

Zaurus

[TypoNAM]

Well its about damn time! It is my opinion that the reason why the Sharp Zaurus (specifically SL-5500 and onward) never had much of a following is because in order to do GUI applications on the platform you either write GPL software or you must buy a QT license from TrollTech. So, I couldn't legally write a freeware app that wasn't GPL/open sourced without a QT license even though I wasn't doing anything commercial with QT. You might ask then why didn't you use a different GUI toolkit on the Zaurus? Well because there was no such thing as an alternative cause all Linux distributions for the Zaurus used QT (Qtopia) for the GUI, all of them. Even the X server running on the Zaurus was GPL'd and written by TrollTech that had no exceptions clause.

Ever since I looked up all the license material and realized what was going on I have hated TrollTech ever since for being so damn monopolistic on the Zaurus PDAs. Either you do GPL software or you pay a license, there is no option three basically.

Now that TrollTech has been bought by Nokia and for seeing the light of day we can now add QT to the list of WxWidgets and GTK+ of GUI toolkits that are acceptable to be used by any licensed software. And hopefully we can now finally end the license bullshit TrollTech caused on mobile platforms.

Re:Zaurus

[SpammersAreScum]

As a (mostly) happy owner of a 5500 and a C3200, I wonder whether this is too late to do the product line and users any good. Is it too much to hope for a movie player for the SL-C3200 that handles MPEG4, for example?

Windows 7

[Anonymous Coward]

In other news Windows 7 is going to be based on Qt4 as well.

Let's hope both GNOME and KDE lives on...

[jopsen]

It's great that Qt becomes LGPL, but it doesn't mean that we should stop developing GNOME and GTK...
Seriously there's lots of business that depends on GNOME and/or GTK, and lots of reasons to keep them alive...
Competition among desktop environments is good and having two large desktop environments if probably a good idea... As it drives competition and innovation.

Re:Let's hope both GNOME and KDE lives on...

[MemoryDragon]

It would be neat if gnome and gimp would drop gtk, but I doubt it, first of all Qt is C++ while it uses basic enough structures that it easily can be bound to any oo language binding it to plain C however is a big issue (well it was a stupid decision by the gnome people to opt for C as base language anyway, but that is entirely different)

That's cool...

[crazycheetah]

I guess that's cool.

But I have to admit. I'm not a big fan of Qt. I kind of see it as an oversized, bloated library. I suppose someone could probably argue reasons for every class and functionality that's present in the library, but some of the things in Qt I look at and get turned off. When there's good cross-platform libraries present for things, I don't really get the reasoning behind rewriting those things.

I know most people look at Qt as a GUI library, but I look over everything, and it's so much more than that. And yet, a lot of those other pieces, I've spent a lot of my programming experience learning things that are just as good and at times, in my personal opinion, better than what Qt offers for the same. Even pieces of the C++ standard that I'm sure Qt added on extra functionality in their equivalent, but it gets really hard for me to reason not using the standard libraries that are nearly (nearly because it does depend on what the implementation of the standard libraries on the system supports--not a problem if each platform goes for compliance with the standard, which I believe most go at least pretty damn close) guaranteed to work anywhere the standard libraries are present.

Just for example, I read they now have a whole parallel/multi-threading library going. But I sit here and ask myself with that over and over, what's wrong with boost::thread (which is going to be included in the C++0x standard anyway)? Even more, there's OpenMP for even further niceness. And having plenty of experience to the point that boost::thread comes naturally to me and OpenMP is getting more and more natural, why the hell would I want to go through learning a whole new set of libraries to do the same thing? But at the same time, why would I want to link against 2-3 libraries that do the same thing?

I guess someone could also argue the niceness of having it all in one place, as well. But I find multiple libraries each focused on their specific task much easier to sift through for documentation and examples than the crap of a library that tries to be everything. The flip-side being when you use one thing and another library you want to use uses something different (which I don't run into often enough for it to be a serious problem, honestly).

I wrote a library in C++ that any time I find something (other than GUI, as that's a whole mess of it's own in my opinion) that is difficult to implement for cross-platform purposes due to the different platforms, I write a little class which I can just take out and put in any of my apps. Of course, it also has a few other things like a couple classes such as a multiple-read, single-write access interface (using boost::mutex, the const volatile keywords, and some const_cast action), but it has maybe 4 other things, which mostly compose of other cross-platform libraries that left just a few capabilities I ended up needing out (like Sleep, though I can't say I'm aware of a good Windows equivalent to nanosleep yet, and it kinda makes my code on Windows not as nice when I'm sleeping in milliseconds but meaning to sleep in microseconds or nanoseconds, meaning dividing by 1000 or 1000000).

That's one thing I do like about GTK, though I am annoyed by so many other pieces of it. At least, a lot of what is implemented in GTK and glib isn't really there a million times over already. Partly just because they're using C, which doesn't have some of the nice stuff in the standard already, and doesn't have Boost ;). But I don't feel like I'm having to justify to myself either learning a whole new thing I've already learned multiple other alternatives to or linking to a whole 'nother library to do something that's already present in another library I'm linking against.

That's my only gripe about "Hopefully we can get rid of GTK now!" Otherwise, I'm actually happy about this. I do like the GPL, but for libraries and such things, I always felt the LGPL was the better choice (in some cases, I even prefer BSD or MIT type licenses over that, but whatever). So, despite my gripes about Qt, I view this as a good thing.

Re:That's cool...

[ultrabot]

I'm not a big fan of Qt. I kind of see it as an oversized, bloated library.

Now that it's LGPL, at least community has a chance to unbloat it :-).

Even pieces of the C++ standard that I'm sure Qt added on extra functionality in their equivalent, but it gets really hard for me to reason not using the standard libraries that are nearly (nearly because it does depend on what the implementation of the standard libraries on the system supports--not a problem if each platform goes for compliance with the standard, which I believe most go at least pretty damn close) guaranteed to work anywhere the standard libraries are present.

You can still use stdlib. Perhaps implement your app "model" with boost + stdlib, ans use Qt for GUI. Of course you will still be using stuff like QString to interface with the APIs.

Also, stuff like QString are actually better than C++ stdlib equivalents - providing reference counting, copy-on-write and unicode support. C++ stdlib is a compromise - it's intentionally "not a platform", which sort of holds it down. Being restricted by standards process doesn't help; even glib (which is a pure C lib) is better.

Re:A GUI for MySQL?

[xtracto]

Moreover, now that QT has gone LPGL maybe we will at last have white chocolate Ferrero versions!

Re:Wait, what?

[thedonger]

More interestingly, a company in this day and age of name-sensitivity actually called themselves Trolltech. Maybe they were trying to be ironic. You know, like ray-eee-ain on your wedding day.

We all know why GNOME is ill

[Improv]

It caught Mono through an ill-considered tryst with Miguel ;)

fight?

[massysett]

fight between Gnome and KDE

Why is it a fight, or a battle? Both projects benefit from a great deal of volunteer labor, and they're not doing it primarily to beat someone else. Others use Gnome and KDE for commercial purposes but they, too, don't come at this from a zero-sum "fight" or "battle" perspective. Companies building stuff for gtk+ or Qt (or for GNOME or KDE) are doing it so that they can release useful applications, not so that they can beat the other GUI toolkit.

GNOME and KDE both existed because they both served different purposes. Just because people have different objectives doesn't make them people who "fight" or are in a "battle." If the two desktops still need to exist, then they will; if not, they will merge or one will fold, or one (or both) will change and adapt. Any change will be to the betterment of all, not because someone "fought" and "won".

Free software is about cooperation and practicality, and I just don't think this "fight" language that people like to employ when discussing free software really fits.

Should all GPL projects switch to LGPL eventually?

[IAmAI]

I think once a GPLed application has become well development and stable, it's good that it lowers its restrictions. Perhaps free software developers should eventually feel free obliged to release the software under the LGPL or some other weaker copyleft license. In the early stages of a project, a need for contributions from the community and corporations is strong, but as the project develops that need diminishes. As this need diminishes, perhaps it is fair that in return the project reduces its restrictions.

Re:Yeah but KDE doesn't work.

[tjstork]

I wonder if you ever had to develop new widgets based on GTK ... This post should get developers quite excited.

You know, I forgot all about that. I looked at building a grid control for GTK and it was, well just aweful. Even Windows SDK was easier to make widgets for and GTK managed to screw that up completely.

Wow, I'm totally wrong. Thank you for reminding me of that.

Re:Yeah but KDE doesn't work.

[tjstork]

Screwed up kernel... BTW, what distro are you running, and what version of KDE 4.x did you run?

I am running Ubuntu Hardy Heron with nVidia drivers. The problem was the KDE, and I think it was 4.0, went and updated my kernel. This in turn hosed my nVidia drivers for some god aweful reason and brought down my whole desktop.

I used to use OpenSuse before Ubuntu and that was where I really liked KDE the best. It was nice because under OpenSuse you could switch between KDE and Gnome quite effortlessly and this has never really worked under Ubuntu. However, there's a lot that I do like about Ubuntu, in particular, the whole package management system is out of this world good compared to OpenSUSE when I used it, and honestly, I think Gnome desktop just looks a lot more polished even though KDE has a lot of features to it.

Nokia did not purchasee Trolltech for reselling Qt

[Khopesh]

Nokia never insisted anything of the sort.

While they may have opposed the HTML 5 standard, their opposition is based upon their relationship with Webkit (recall that Nokia is one of the big players backing Webkit ... in addition to the fact that Qt now bundles a derivative of it).

When Nokia purchased Trolltech, they promised not to change much. That's the opposite of what you just claimed. Those of us heavily entrenched in the Qt world knew that there was likely to be a shift in priorities ... the profitability of Trolltech was measured in digits that were not significant to a massive company like Nokia.

They bought Trolltech for the IP rights on the phone operating system Qtopia (now Qt Extended) because it enabled them to get back into the smartphone game (which they've been losing to Apple, RIM, and soon Google). The purchase was not for direct Qt profitability.

Disclaimer: I work for the biggest Qt shop in North America, www.ics.com (and we're already under heavy load, so that link is cached).

Re:ARGH! Just migrated to CMake + added Wx support

[pherthyl]

Don't feel so bad, I just paid $1100 to renew my Qt commercial license :) That's ok though, it was worth it before, and they deserve the money for the kick ass product.

Re:Nokia did not purchasee Trolltech for reselling

[Enderandrew]

http://en.wikipedia.org/wiki/HTML_5#Ogg_controversy

I realize that Nokia bought Trolltech for Qtopia. Nokia is now trying to push a mobile GTK platform while owning the Qt platform. I did think it was a really smart move to give Nokia n810 tablets to KDE devs. Then the KDE devs worked on getting KDE 4 to work on the n810. Nokia could easily ship a full KDE 4 based desktop on future smart phones and tablets.

Re:Yeah but KDE doesn't work.

[Enderandrew]

The Ubuntu devs screwed up their KDE 4 packages in a bad way. That isn't KDE's fault.

Furthermore, KDE doesn't depend on video drivers. If the Ubuntu devs made a certain Nvidia driver a dependency, then they screwed up big time. KDE does not change your kernel or video driver in any way.

I'm not calling you a liar or saying you didn't have problems. I'm sure your box got hosed somehow, but it is more likely the problem was with Ubuntu's packaging.

It should also be noted that the QT 4/Nvidia problems have largely been remedies. Qt 4 used Xrender heavily, and Nvidia's driver had a piss-poor Xrender implementation. The forthcoming Qt 4.5 is supposed to move away from using Xrender all over the place, and the latest Nvidia driver has much better Xrender support to boot. openSUSE even provides a repo with weekly snapshots of the KDE 4.2 branch compiled against the weekly snapshots of Qt 4.5. In theory it is unstable, but I've had good luck with it so far.

I know I'll get modded Troll for this, but I don't care. Ubuntu has got some serious problems, and is very overrated. openSUSE puts out quality KDE 3, KDE 4 and Gnome desktops. They support all 3 currently (though KDE 3 is being dropped in the future).

Novell hires a large staff of developers that make quality packages, fix upstream bugs, backport features, etc. As much as I hated Novell for the MS deal, Novell is one of the best contributors to several upstream projects, and openSUSE is a fantastic distro.

I can't recommend it enough.

I'll take your recommendation then.

[tjstork]

I don't think you should be modded troll at all. I think you've made a well thought out recommendation based on some good working knowlege of the issues at hand, and I'll give old OpenSUSE a try again down the road.

XFree86 died BECAUSE of X.org

[Anonymous Coward]

and then ONLY because the XFree86 group didn't want to respond to opening the process up.

So you had the XFree86 developers working on XFree86 vs Anyone who could get it working on X.org.

And the choice of which was better was only available when X.org was in competition. XFree86 ignored what the market was telling them and so died.

Not competition's fault, the fault of not listening to what the market is telling you via competition.

multi-touch

[Anonymous Coward]

A bit OT, but since we're talking about QT, I'd like to put in a request for multi-touch support. This will obviously be necessary for phone apps, but also for tablets.

Effect on Qt Solutions (e.g. SOAP)

[LittleBigPile]

Does this mean LGPL opens up availability (as in free) of these components as well?

Re:Effect on Qt Solutions (e.g. SOAP)

[Ren Hoak]

It's a fair assumption that it might open QT Solutions up.

Related... I've got a Qt developer's license and I never purchased Qt Solutions. I recently discovered that Nokia has decided to retroactively give Qt Solutions to anyone with a developer license.

Re:Effect on Qt Solutions (e.g. SOAP)

[LittleBigPile]

According to Alexandra from this blog post, it does include Qt Solutions code. This is also good news!

SWT/Qt ?

[characterZer0]

Does this mean SWT/Qt can be released?

http://dot.kde.org/1078257737/1078263532/

Re:SWT/Qt ?

[swilver]

Let's hope so... one of the things keeping me on Windows is the crappy GTK interface Eclipse is using on Linux. For some reason, GTK manages to take up almost twice the space in displaying a simple tree control than the Windows equivalent.. spacing all around is way too large and no way to change it.

Re:SWT/Qt ?

[try_anything]

Seconded. The GTK+ implementation of SWT is sloooooooow, and it's especially apparent when using Eclipse itself. Plus my Eclipse RCP app looks crappy (especially under KDE) compared to the Windows version. Eclipse RCP is practical and usable as a cross-platform GUI toolkit, but it bothers me to produce apps that look and behave better on Windows.

There is a lot of talk that IBM has been intentionally keeping SWT/Qt for themselves and using licensing as an excuse for not releasing it, but I hope IBM is invested enough in Linux that they see the necessity of improving user perception of Eclipse-based applications under Linux.

meanwhile

[Lord Ender]

Rich Internet Application platforms, like Adobe Flex, are making it easier to get rid of client-side GUI libraries entirely.

Have a browser? Most apps can be done in AJAX, the remaining apps can be done in Flex. Why use GTK or QT?

Re:meanwhile

[Microlith]

Whoops, your server just died.

There's plenty of reasons to use GTK and QT, including pretty much every app that has no need for internet access (and some that are using it, but really shouldn't be.)

Never mind the hefty CPU load that AJAX apps can put on a system. Needlessly inefficient, even if we do have dual- and quad-core machines.

Re:meanwhile

[crazycheetah]

Because using a browser for my every app means I have to hope I have a browser that not only meets my needs, but also doesn't suck at speed, memory, and other such factors. That's all improving of course. But Firefox get blown off of the list of acceptable to me, as I have to restart firefox regularly because it leaks memory all over the place until it's using over half of my 1GB memory all by itself and begins running slow as all hell and makes everything else I'm doing run slow as all hell along with it, because everything is starting to use swap space instead of RAM.

Opera is about the only other (current) browser I look at as a possibility, but it's far from problem-less itself.

Chrome could have the potential to theoretically change that. But IE, safari... neither are cross-platform to the extent of Qt. Chrome isn't currently either. And those have their own problems as well. Konqueror doesn't display everything properly at the moment (along with--though I haven't paid attention in long enough, it might have changed--not being as cross platform). I'm honestly not happy from a developing regularly used applications standpoint with any browser at the moment. Nevermind if I need critical speed that the browsers, even with JIT compiling the javascript, can't match C (or exceptional Assembly...) for.

There's always going to be a need for native code, and there's always going to be a need for a GUI toolkit that the native code can use. GTK or Qt happen to be on the top of the list for Linux at the moment, and both offer some level of cross-platform (more-so with Qt).

The space for browser-based applications does seem to be growing, but it's never going to push the native code out all together. Just like Java and other languages have never been able to do.

Re:meanwhile

[Lord Ender]

The number of apps I use which are useful without an internet connection is very small--Word, Excel, and Scite (source code editor). Nearly everything else connects to a server in some way.

If your app requires a server, anyway, just make it a RIA and forget about QT/GTK/Motif/Whatever thick client app. RIAs also save you from worrying about distributing the software, updates and patches, or licensing/piracy.

Re:meanwhile

[swilver]

You lost me at Adobe...

Re:meanwhile

[Brandybuck]

...because Flex/Flash doesn't work on every operating system and browser.

Re:meanwhile

[Flammon]

You obviously never wrote an AJAX app. AJAX does not increase the load on a server. In fact, using AJAX properly will normally reduce the load and save you a crap load of bandwidth. Trust me, I know. I write AJAX apps for a living and have been before the term AJAX was coined.

Re:meanwhile

[Lord Ender]

The same is true for QT.

Re:meanwhile

[Brandybuck]

True, but Flash supports only three, count them, three operating systems. I'm magnanimously ignoring variations of these operating systems that are not supported (ei. 64-bit versions).

Qt supports Windows, Mac OSX, Linux, FreeBSD, NetBSD, OpenBSD, OpenSolaris, AIX, HP-UX, IRIX, S60, Hurd and LynxOS. There are a few other platforms it will also run on, but they aren't supported, so for the interest of fairness I'm leaving them out, even though the Open Source nature of Qt allows it to be ported everywhere

Qt supports four times the platforms that Flex/Flash does!

Comparison to WPF or other non stone-age tools?

[sundarvenkata]

Can somebody tell me how this can compete with free Visual C# express editions that allow developers to develop great desktop applications in C# and WPF (XAML)? Also why would one be so masochistic as to torture themselves with C++/QT and cross-platformity when they can go with .NET 3.0 and do a much better job faster and with better tool support? If cross-platformity was such a big deal, Swing should have shot to prominence 5 years ago.

Re:Comparison to WPF or other non stone-age tools?

[scorp1us]

• You don't need to know C#
• You can use the Kyoto bindings if you want C#
• You can use the Binding Generator so you can use Qt in ECMA (Java)Script.
• WPF doesn't exist... Designer can make a XML file that is used on all platforms, but I don't know what you're getting at. CSS steps in to provide theming.

I wouldn't say "'torture' with crossplatformity" You never really think about it. It just works. The details are hidden, so you never think about it.

Swing was coupled to Java. A slow, unknown language with wonky GUI elements. Qt draws everythign as natiivce controls and supports skinning via CSS.

Re:Comparison to WPF or other non stone-age tools?

[gbjbaanb]

lol. So your question is really: "why should I bother with this Linux thing when Mr Ballmer gives me all the nice feel-good, happy development tools I need to do Windows-only GUIs"?

Here is a question from a quite pro-C# site concerning WPF.

Swing was a "failure" because it was slow, and required Java. Not enough people wanted to move to Java to get that cross platform feature, to be honest x-platform hasn't been too much of an issue until relatively recently, just shows how far Linux has come in the last few years.

Re:Comparison to WPF or other non stone-age tools?

[JoeMerchant]

Depends on your target market - we have some potential OS-X customers, and we also will be porting from the desktop to an embedded device. Yes, 90% of our 1st year revenue will be from Windows, but that other 10% is worth having, and down the line having a single code base that ports onto an embedded Linux platform becomes a BIG deal.

As others have said, cross platform "just works" if you stay inside the Qt API - since about Qt 4.0, I wouldn't consider the Qt API restrictive, and since the addition of Phonon in 4.4, it's downright bitchin'

Re:Comparison to WPF or other non stone-age tools?

[SpinyNorman]

Using C++/Qt isn't torture - it's a genuine pleasure. The cross-platformity doesn't cost you anything in terms of inconveniece or even a moments thought - it comes for free with everything (including threads, SQL, XML, etc) in the Qt API. If you download the free version of Qt for Windows you even have the convenient option of downloading it togther with MinGW (basically GNU g++, tools and bash shell for Windows) so you can install it all in one go, for free Windows software development.

Re:Comparison to WPF or other non stone-age tools?

[Ilgaz]

Don't forget Nokia bought Trolltech for a reason, mainly for their own smart phones (micro laptops). So, the Symbian market which is truly gigantic and even Windows Mobile market will be possible for your application.

Just to say you made the right choice.

Re:Comparison to WPF or other non stone-age tools?

[Anonymous Coward]

Also why would one be so masochistic as to torture themselves with C++/QT

Huh? C++/Qt torture? C++/MFC was torture. C#/.NET is torture. Coding for Windows is in general torture. I've never (I repeat: NEVER) seen Windows code that was well laid out, had sensible variable names, and sanely commented.

Coding for Windows is torture! Period!

re desktop adoption - nonsense

[cinnamon colbert]

I'm a typical middle adopter used to wintel; i recnetly put ubuntu via wubi on my laptop.
Sure it worked - but so what
I don't care about the stallmann stuff; viruses are not a big deal, so
*why would i care about ubuntu ?*
to repeat basic 101 of computer biz yet again:
people adopt new software cause it does something
so far as i can see linux doesn't do anything i care about, and yelling at me that i should care about open source or virus or whatever is counter productive
when there is a linux app that does osmething tht windows can't linux will conquer the desktop with ease
(PS that app ain't open office and it ain't the gimp)

Re:re desktop adoption - nonsense

[dancpsu]

*why would i care about ubuntu ?*

Because it's free? And runs well on older hardware?

When netbooks are $200, things like this start to matter, especially to manufacturers. It doesn't have to be better or unique, it just has to be a good enough substitute and substantially enough cheaper.

Re:re desktop adoption - nonsense

[Anonymous Coward]

u raise an interesting point
1) netbooks aren't really a substitute
2) it is not clear what the cost to make a copy of xp for MS is - maybe it only costs MS ~ 1 dollar to keep xp up to date, which means the can make a healthy profit selling it for 3 bucks
3) even if there is a "ms tax" there is also a "linux tax": if any of my peripherals, say a printer, don't work, then I have to get a new printer (remember, we are talking about people who don't know how to write drivers, or even modify existing ones)
4) there is also a linux loneliness problem: if most other people have ms, you have problems getting help, compatibility of programs, etc
5) gaming - my son uses his computer to game; i have heard that linux is not good for gaming; that means that I , the household sysadmin, would have to maintain two OS if i switched to linux, which is a pain; i suppose in a few years he can be his own sysadmin...

Vala makes the creating widgets argument moot

[caseih]

Fortunately Vala makes this very easy to do. Defining a new widget is just a matter of creating a class and inheriting from some other widget and then adding in your code in a nice, C#-style syntax. And it compiles down to C code so the resulting gobject class can be used by normal C programs and libraries, and easily be wrapped in a language binding. I hope that in the near future most if not all GTK and Gnome programming, particularly when it comes to the GUI and defining widgets, will be done in Vala. Vala isn't really a new language per se. It's nice syntactic sugar that allows things to stay in C where they belong so they can be interfaced with and bound by programs in *any* language. Going forward, it's possible to develop GTK in Vala, all without ruining the purity of having a good C library that anyone can access.

Really Vala is proof that the GTK devs, when they defined the gobject model in pure C, where very forward-thinking. This isn't the kind of thing that could be easily done had GTK been based in C++. C++-based libraries are hell to work with, especially on Windows.

So very soon (within the year), I believe people will be comparing Vala-based GTK code with Qt in terms of ease of use, the API cleanliness, etc. Any arguments about the clumsiness of using C (and it is clumsy to define a new gobject class in C!) and GTK will be put to rest.

Re:Vala makes the creating widgets argument moot

[Cyberax]

Yeah, sure.

Vala is a massive pile of failure on the scale of VB6. It doesn't contain a garbage collector _or_ a cycle detector. So it's VERY easy to leak memory by creating cycles of objects.

It's OK for small applets that don't allocate much objects anyway. However in large applications it'll soon become a BIG problem.

Re:Vala makes the creating widgets argument moot

[stilborne]

i think it goes a bit deeper than the language choice, and the post you are replying to is probably talking about completely custom widgets vs customizing existing ones. that customizing existing ones is already not streamlined is a bit shocking, but ok, as you say, they are working on Vala.

the problem with Vala is the same problem with any niche language: nobody knows it. yes, i know, it's C#-ish. but it's not C#, and people will have to be taught that it is "like C#" first. creating and then supporting an entire language and its runtime just to make a toolkit easy to use is, to be frank, insane.

i completely understand why people make new languages, but the reason for Vala is one of the most absurd things i have ever come across. really, GNOME should just have picked something that already existed and leveraged the developer base already familiar with it.

instead they are creating a separate silo of code called Vala that will only raise the barrier to entry due to the solution applied in an attempt to lower it.

the gnome-shell team's adoption of javascript is much more sane and well thought out. GNOME users and developers really ought to hope that the rest of project takes a cue from gnome-shell and does something similarly pragmatic on the language choice front.

Re:Vala makes the creating widgets argument moot

[caseih]

I guess I should have been more clear. I wasn't necessarily saying Vala was an app development language (although it could be). Actually the reason Vala exists is exactly to prevent creating a silo of code when it comes to developing and promoting GTK. If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components? They simply couldn't. Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code.

Sorry but I'm very confused by some of your other comments. How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach? Javascript is fine as a glue language, or even as a language to develop an extensible app in. Hence bindings to GTK are awesome for Javascript. But how does it address core GTK development issues? This is what Vala is really for. Sure apps could be and are written in Vala. But if core GTK development uses Vala extensively going forth, it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding.

So in short, Vala is going to prove the salvation of GTK itself for these reasons. I guess my original post wasn't clear enough. I never said Vala should be used to write applications necessarily. Just that it can be used to easily create new widgets or extend existing widgets. So if you're going to work with GTK development itself, or build libraries of GTK code (widgets, etc) that you can use anywhere, then Vala is the way to go.

Re:Vala makes the creating widgets argument moot

[caseih]

Vala is hardly a failure if you examine why it exists and what is used for (and how it relates to the post I was originally answering). Well Vala is really syntactic sugar over C and the existing gobject facilities. So yes, memory management isn't going to be like C#, and it's not like C++ either, alhough C++ doesn't have a garbage detector or a cycle detector... nothing big ever gets written in C++ for those reasons. Like Qt Apps. Right. Big applications can and have been written in straight C with GTK and have done fine. Worst case, Vala just makes writing such applications easier, though you do have to manage memory yourself.

But I should have been more clear when I was promoting Vala. Vala could be used to write big apps I'm sure, but like you say with real nice languages like Python, there's really no point. However I was addressing the concern expressed that creating new widgets in GTK or even extending widgets is very painful in C. Vala is intended to address this and make it easier to develop GTK libraries and extend GTK. That's the point.

Sure if you want to compare GTK to Qt you'd be better off to compare GTKmm to Qt. But of course if you were to write widgets in GTKmm you're locked to C++ and can never offer them to other languages without a port.

Re:Vala makes the creating widgets argument moot

[stilborne]

"I wasn't necessarily saying Vala was an app development language (although it could be)."

GNOME devs are already writing full apps with it, so it is being used as such.

"If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components?"

yes, i understand that is what has driven Vala's design and implementation. i just don't agree with the "we'll wedge another home grown language in between the C and the other languages" approach. i think it's overly complicated and limits the number of people who can (and will) hack on it.

time will tell if i'm smoking crack or not, of course .. =)

"Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code."

that is produces C is both a feature and a bug. it makes debugging much more awkward (and for a while wasn't even possible at all! how do you go from your generated C to your Vala code in gdb? there's a plugin now for gdb, but really .. oy vey!) and you lose all the interesting security possibilities of managed code.

"How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach?"

it's simply a language that is well known. pick a different well known language if you wish. make your own runtime if you wish. certainly add your own sugar on top (see QScript for a really nice example of how that can all be done with JavaScript). there's nothing particularly magical about the Vala syntax, except that it's a new language specific to one toolkit.

which is precisely my point.

"it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding."

let's do this then: let's come back to this in 2-3 years (it takes time to get these things going, i know) and see if that theory works out.

my theory is that it will just be one more baroque tool that people working with Gtk will have to get their head around (and people complained about moc with Qt; they ain't seen nothing yet ;) thereby limiting the pool of candidate developers. as a non-transferable skill it won't gain much in the way of value that might cause people to learn it "just because", and yet people will write applications with it. i expect to see more and more vala usage in Gtk+/GNOME (because, well, that's already happening =) and it will cause the project to become more insular rather than less.

i do expect that those using it will get more done with vala than with plain C, but not to an extent that will make up for the number of people lost by not choosing a language syntax that is already widely known or a language that avoids compile cycles, dealing with the intricacies of C debuging, etc.

given that it's homegrown, it will also soak up resources maintaining and extending vala itself that could be put elsewhere.

combined, i expect individual efficiency of existing contributors to increase due to vala, but the overall effect on the project to be a net negative. i predict that in a few years vala will get quietly binned. bonobo 2.0 if you will: a cool idea that "just has to work, it's so well designed and advanced!" but which just didn't pan out in reality.

again, i could be wrong. and i certainly don't want to see the GNOME team falter. but vala gives me the heebie-jeebies.

Re:Vala makes the creating widgets argument moot

[Cyberax]

However, Vala itself is deliberately C#-like. And that's going to cause problems.

C++ has a lot of nice memory handling features: automatic objects, various smart pointers, etc. Also, C++ makes memory management very explicit while Vala tries to hide it.

And it's even WORSE if Vala is used for widgets. Because a memory leak in a nice Vala widget can bring down a large well-written application which uses this widget.

(it's also possible to write portable widgets using GTKmm, but I digress)

Re:Vala makes the creating widgets argument moot

[petermgreen]

Disclaimer i've only used the gtk/gnome very briefly

Fact is most OOP languages are specific to one object system. GTK already has it's own custom object system and the system will be pretty bewildering to anyone without a low level knowlage of structure layouts.

If people want to work with it without doing the OOP stuff by hand they need a language designed for that object system. Indeed vala is fairly unusual among native code languages in being designed arround an existing object system rather than introducing a new one.

To me vala looks a lot easier to understand than manual OOP with gobject. Especially for people who have some familiarity with languages that use similar syntax (C++, java, C#).

Re:Vala makes the creating widgets argument moot

[elysiuan]

You make many good points, but there are a few things going for Vala that I feel you aren't taking into account.

• Vala's impetus is to lower the barrier to entry by making gobject easier to work with.
• Vala is largely a response to Mono. It is trying to provide a C#-style experience without having all the cruft mono brings to the table. (Not all Gnome devs are huge Mono fans, I'm certainly not.)
• Any previous C# experience will easily transfer to Vala.

As for resources, Vala is worked on by a pretty small team of people. It's not a huge developer sink that's pulling all Gnome devs to it's titantic-like edifice.

Maybe it's just from my own perspective but compared to some of the other efforts to make gobject an unodious experience (like say, GOB *shudder*) Vala is by far the best and least baroque!

Largely due to the OO architecture of the GTK ecosystem there's lots of quality bindings for this stuff also. People always bring up the few Gnome apps that make use of Mono and ignore all the Python Gnome apps for example.

Time will tell and see which of us is correct. I am more hopeful than you on this though!

I felt...

[conares]

...a disturbance in the FOSS, as if milloins of voices cried out in terror and then were LGPL'd...

And MS in schools?

[Mathinker]

Your analogy doesn't seem to fit reality.

Or did you just manage to totally obscure your meaning by being cute?

How would *you* know?

[Mathinker]

> You'd be the first I've seen. Kopete is terrible.

How would you know?

You should put a bit more effort into making your trolling consistent, no?

Re:How would *you* know?

[FishWithAHammer]

How is it trolling to say I don't use a Linux desktop? I've tried it. It's not good. I wish it were; I don't like Windows any better (Windows currently wins based on applications more than anything) and the OS X user interface makes me cringe. But it's bad. It's not usable.

"Troll" is not a synonym for "disagrees with me and therefore is bad".

Re:How would *you* know?

[Vexorian]

You didn't get modded down because you said Linux is not good, you got modded down because of saying "Kopete is terrible" and no extra explanations, not to mention the insistent spam on the rest of the thread about your stupid attempt to call the GPL immoral mostly because you don't understand it. So, perhaps the sentiment from the guy who modded you down was not an "I disagree" but a "I hope this is a troll, else my faith of humanity would be gone"

Re:How would *you* know?

[lgw]

"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."

You do realize that there's no difference between pointer arithmetic and array indexes, beyond syntax sugar, right? Any array that doesn't bounds-check on every reference has all the same problems as pointer arithmetic. A compiler that enforces array bounds-checking on every pointer derefernce would be just as safe as bounds-checked arrays. There's nothing stopping a C compiler from doing that, and it's becoming common in C++ libraries for iterators (in debug mode, anyway).

What you want is bounds-checking, not the absence of pointer arithmetic.

Re:How would *you* know?

[Mathinker]

> "Troll" is not a synonym for "disagrees with me and therefore is bad".

I totally agree with that. "Troll" like everything else is a judgment call. You came across like a troll. See Vexorian's post for more explanation.

Personally, I didn't judge you a troll for the "I don't use Linux" post; in fact, I have no problem with people for whom Linux doesn't cut it and I am very aware of some of the reasons which might cause that.

The "Kopete is terrible" post by itself also didn't bring you over my threshold, but the combination of the two passed the threshold.

One of the big differences between the FOSS world and Windows / MacOS is the rate at which applications can evolve feature-wise and interface-wise. For some, this is great, for others, a catastrophe. This makes me doubt that anyone who uses Windows (and I assumed Windows without FOSS, given the complaint of your post: "integration") as their primary computing platform would be able to properly pass judgment on any particular FOSS application.

Next time, qualify with "Last time I tried Linux, in Monthname Yearnumber, Kopete was terrible. " and you will be much less likely to be judged a troll.

Signals? Slots?

[gatkinso]

I'll stick with ANSI C++ thank you very much.

Re:Should all GPL projects switch to LGPL eventual

[fuzzyfuzzyfungus]

Why? If a project is using the GPL, that is presumably because it doesn't want to be included in a proprietary or otherwise GPL-incompatible application. Why would that change according to the project maturity?

KDE 4 has major UI issues

[metamatic]

Fact is, KDE 4, even 4.2, still has some horrendous UI issues that the developers just dismiss. I switched from GNOME to KDE to avoid Mono/.NET, but with KDE 4 I feel like they're heading even further in the wrong direction as far as UI design is concerned. KDE 3 had too many settings but behaved more or less as you'd expect from other UIs; KDE 4 has hardly any settings and behaves in weird and freaky ways unlike any other desktop environment.

Re:KDE 4 has major UI issues

[Enderandrew]

I think with 4.2's release, most distos won't have the folder view containment as a plasmoid, but rather will use it as the desktop containment. It will operate like a classic desktop, and no one will notice the difference.

As for a lack of settings, it takes time to rewrite the entire KDE project. At the 4.0 launch, there weren't dialogs to alter the taskbar, even though that functionality existed. It took them time just to add the configuration dialogs. Every month I see more and more functionality and features in the KDE 4 branch.

I still use a KDE 3 desktop session, but given time, I think KDE 4 will offer most of the KDE 3 features, and then some.

Re:KDE 4 has major UI issues

[stilborne]

"rather will use it as the desktop containment"

having actually seen packages of 4.2, i can tell you that this is incorrect. i do expect *some* distros out there to do this, however. that's sort of why we have the feature there, of course. =)

"it takes time to rewrite the entire KDE project. "

just to put this into perspective, the only full rewrite is of the desktop shell. we added a lot of new library frameworks (Phonon, Solid, ThreadWeaver, Nepomuk, etc, etc.) did a massive amount of work on the existing libraries (particularly so that libkdecore doesn't require a GUI, sorted the functionality out properly so that they aren't massive globs of semi-random class collections, etc), introduced a number of new apps (akonadi, dolphin, the new printer configuration tool, numerous games, some edu apps ..) and obviously ported everything to Qt4. massive, massive effort, but it wasn't technically a rewrite, with the exception of the desktop shell.

Re:KDE 4 has major UI issues

[Randle_Revar]

>Fact is, KDE 4, even 4.2, still has some horrendous UI issues [kde.org] that the developers just dismiss.

I am not seeing a real problem in that bug report...

I also don't see why you would move from Gnome to KDE to avoid Mono. There are only about 3 or 4 well known Gnome apps that use Mono, and all have alternatives. It is easy to run a full Gnome desktop without having any Mono installed.

>behaves in weird and freaky ways unlike any other desktop environment.

I would say different, rather than weird and freaky, and really that is the point of Plasma et al - to be different, and try new ideas.

Re:KDE 4 has major UI issues

[Enderandrew]

Evolution is the latest app to require Mono, and given that Icaza has been pushing for Mono hooks in every app he can, I expect that list of apps to grow. There are already Mono hooks for Nautilus, Gvfs, etc.

Are those hooks going to stay optional forever?

Re:KDE 4 has major UI issues

[Randle_Revar]

Oh Noes! There are *optional* *hooks* for Mono in many apps! The horror!

Re:KDE 4 has major UI issues

[Enderandrew]

Evolution's hook isn't optional. Neither is Tomboy's, nor F-Spot's, nor Beagle's, etc. Mono is more embedded in Gnome with every passing month and I've yet to see any evidence whatsoever that the trend will reverse.

All Miguel Icaza talks about is how Mono is the future of Gnome. As a major Gnome developer, I'll take his word over yours.

Re:KDE 4 has major UI issues

[metamatic]

I am not seeing a real problem in that bug report...

If you don't think it's a problem that two identical-looking icons on the desktop behave in a completely different way, or that an object dropped on top of something falls underneath it and becomes non-selectable, then you shouldn't be designing GUIs.

There are only about 3 or 4 well known Gnome apps that use Mono, and all have alternatives. It is easy to run a full Gnome desktop without having any Mono installed.

By definition, a full Gnome desktop includes the full set of standard Gnome desktop applications, as shipped by the Gnome project. You can't run a full Gnome desktop as shipped by the Gnome project unless you have Mono installed.

To put it another way: to get rid of Mono you have to rip out applications which are a standard part of Gnome as shipped by the Gnome project. I opted to rip out the whole of Gnome and replace it with KDE.

Re:KDE 4 has major UI issues

[metamatic]

So is there some easy way to get rid of the useless new KDE 4 desktop and replace it with a folder view that works like every other GUI? Like you can rip off the useless new launcher and replace it with a hierarchical one?

Re:KDE 4 has major UI issues

[Enderandrew]

KDE 4.2 will allow you to use the folder view applet as your desktop containment. It will fill your entire desktop, will allow a wallpaper, and will basically operate like a classic desktop, but with added functionality as well. You can get it to display any folder you want, home just $HOME and it will allow you to filter results, even recognizing Nepomuk meta-data.

The new 4.2 RC which just came out today should work.

Re:KDE 4 has major UI issues

[Randle_Revar]

Evolution's hook isn't optional.

from the Evo bug report:
--enable-mono=no

The other do not have Mono hooks, they are written in Mono.

Mono is more embedded in Gnome with every passing month and I've yet to see any evidence whatsoever that the trend will reverse.

I have yet to see any evidence that "Mono is more embedded in Gnome with every passing month"

All Miguel Icaza talks about is how Mono is the future of Gnome. As a major Gnome developer, I'll take his word over yours.

He is one of very few who think that. If you read Planet Gnome and some of the mailing lists, you will quickly see that Gnome is not going to depend on Mono anytime soon, and probably not ever.

Re:KDE 4 has major UI issues

[Randle_Revar]

The "gnome" (2.24) package in Debian Sid/Experimental does not depend on anything that uses Mono. The closest it comes is a "recommends" for Tomboy.

I don't feel that lacking a feature-stuffed note application makes it not a full Gnome Desktop.

Re:KDE 4 has major UI issues

[Enderandrew]

There is a patch that removes Mono dependency, but that patch isn't utilized by Novell, the company that is pushing Mono.

I just double checked, and Mono is still a dependency of Evolution.

As for proof, the number of projects with Mono as a dependency continues to grow. We're talking about easily verifiable facts, of which Evolution itself is proof.

And despite you claims that Gnome will never depend on Mono (you're not the first to say that) people are actively writing Mono hooks for very core portions of Gnome like GVFS, Nautilus, etc. And while many have suggested these will always be optional, several core apps already depend of Mono.

Should I listen to verifiable facts, or your opinions?

Furthermore, Icaza is a major player in the Gnome community whose prognostications of Mono have so far been accurate. Clearly, your expertise on this matter is more valid than his.

Re:KDE 4 has major UI issues

[metamatic]

I believe I was clear that what makes something part of the full Gnome desktop is whether it's part of the full Gnome desktop as distributed by the Gnome project--not what Debian decides to do.

(Similarly, irb and RubyGems aren't part of Ruby according to Debian, but they most definitely are according to Matz.)

Re:KDE 4 has major UI issues

[metamatic]

Uh, yeah, how exactly do I set it to do that? That was the question I was asking.

Others are irrelevant

[Anonymous Coward]

People write applications for Gnome because of usability. Not because of toolkits.

Re:Yeah but KDE doesn't work.

[neuro88]

It should also be noted that the QT 4/Nvidia problems have largely been remedies. Qt 4 used Xrender heavily, and Nvidia's driver had a piss-poor Xrender implementation. The forthcoming Qt 4.5 is supposed to move away from using Xrender all over the place, and the latest Nvidia driver has much better Xrender support to boot. openSUSE even provides a repo with weekly snapshots of the KDE 4.2 branch compiled against the weekly snapshots of Qt 4.5. In theory it is unstable, but I've had good luck with it so far.

I'll second this. I recently switched from an nvidia card (using nvidia's drivers) to a radeon (using the fglrx drivers). Certain things that were unusably slow with nvidia (such as scrolling folder views on the desktop) became snappy using the radeon!

Sorry to disapoint you

[marcosdumay]

Lots of people fail to understand that, but competition doesn't happen between products, it happens between people (or companies). Since everybody can change it anyway they want, Free Software doesn't need alternatives to maintain competition, only one product is enough. Everybody then can fork it if they want.

LGPL'ing Qt is Awesome!

[Anonymous Coward]

I hope this invigorates more widespread use from both open source organizations as well as commercial organizations.

The LGPL license is the next best thing to BSD license. I mean, is the best of both worlds. Qt remains open, yet you can still write closed sourced applications.

Pfft.

[warrax_666]

On any modern system, the only real difference between a process and a thread is that threads share memory. Threads can be marginally faster because of this, but usually not enough to matter. (Yes, if you abuse the implicit memory sharing you'll end up with lots of heisenbugs, but that'll also happen if you abuse shared memory, mmaps, etc. in an n-process model. In either case there's no substitute for properly designed communication channels.)

You might argue that processes are theoretically more crash-safe since either can monitor the other, but that's only if you use low-level languages which allow you to crash a process (C and C++ come to mind) -- Erlang, for example, doesn't suffer from this. The only area where I've actually ever seen this crash-resistance exploited is in networked applications (mail daemon) and high-availability apps where I have a little commercial experience.

Re:Pfft.

[agbinfo]

The problem with sharing memory is that one thread can corrupt the other. You then crash all threads.

I don't know Erlang so I can't comment on how good Erlang is at preventing applications from crashing but garbage-in-garbage-out therefore corrupted data by one thread corrupts data in all threads.

Another difference is that all threads run with the same uid:gid. With processes, I can lower the ability of one process to do harm.

When I kill a process, the system will usually do a good job of freeing its resources. When I kill a thread, I have to manually free its resources.

Re:Pfft.

[Anonymous Coward]

Another difference is that all threads run with the same uid:gid. With processes, I can lower the ability of one process to do harm.

Windows threads can run under a different security context, including both a different user account, and reducing the privs of the process's context. Just an FYI since Qt is multi-platform.

- T

You're right.

[warrax_666]

KDE 4.1 was also lacking severely in comparison with 3.5. I'm running 4.1.96 aka 4.2rc1 and it looks far more complete though I must admit that I don't really run all that many KDE applications regularly.

Funny.

[Futurepower(R)]

"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."

That made me laugh.

Karlan Mitchell

[Anonymous Coward]

I don't like C++, I don't like Win32's API, so I picked up GTK up a while back. Its crazy easy to
use, and I know the code isn't as bulky/slow as its
C++ cousins. A nice look is achieved through GTK skins.

Re:Wait, what?

[gbjbaanb]

Maybe they were trying to be ironic. You know, like ray-eee-ain on your wedding day.

its like meeting the toolkit of your dreams, then meeting its beautiful kdesktop.

Now, that's ironic!

Weird license restriction:

[Futurepower(R)]

Interesting point.

Nokia DOES presume to tell you what you can do with your LGPL code. Read this quote:

"Can I switch from using Qt under the LGPL to commercial afterwards?

"Users of the LGPL versions of Qt need to comply with the LGPL licensing terms and conditions. Qt's commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL licensed version of Qt and then transitioning to a commercial version of Qt."

Wow! How do they know how you "initially" began development?

It seems as though some lawyer or marketing guy with no technical understanding got involved.

How does this affect the open source cross-platform GUI toolkit WxWidgets?

Re:Weird license restriction:

[ncc74656]

How does this affect the open source cross-platform GUI toolkit WxWidgets?

Since wxWidgets uses Gtk+ on Linux and platform-native widgets on Windows and Mac OS X, I'd think that LGPLing Qt wouldn't have much (if any) effect on you if you're already using wxWidgets. If you're looking at cross-platform toolkits for your next project and want something with relatively permissive licensing, Qt is now a more viable alternative to wxWidgets than it had been previously (the GPL is a showstopper for commercial development).

Re:Weird license restriction:

[scorp1us]

I think maybe someone did a search-and-replace on GPL with LGPL.

Because what people would do is use the GPL version and develop until they had a sellable product. That is a violation of the GPL license.

It doesn't make any sense as LGPL though.

Re:Weird license restriction:

[Raenex]

Because what people would do is use the GPL version and develop until they had a sellable product. That is a violation of the GPL license.

How so? As long as you don't distribute, then there's no violation.

Re:Weird license restriction:

[Anonymous Coward]

Nokia DOES presume to tell you what you can do with your LGPL code.

The restriction lies in their commercial licence, not the LGPL. It also restricts you from starting with the GPL version and moving over to commercial. They can't stop you from transitioning from Qt LGPL to something like GTK, for example. I don't see anything inherently wrong with that clause in the commercial licence, except maybe for the challenge of policing it.

Wow! How do they know how you "initially" began development?

They normally don't, unless they somehow find out by someone leaking the information, or a large profile customer releases a product on the same day they purchase the commercial licence.

Re:Weird license restriction:

[Anonymous Coward]

No. The quote you cited only says that Nokia tells you what you can do with THEIR commercially licensed code.

Re:Weird license restriction:

[Anonymous Coward]

If you release it as LGPL, they'll know. Otherwise they can only guess, but if they have a strong suspicion that you did so or are trying to do so they might be able to use a subpoena to get the information out of you or they could just refuse to sell you the commercial licence if they haven't already sold it to you. But it isn't adding any further restrictions to the LGPL.

I do fail to see what benefit the commercial license gives you now since you should be able to write an application with any license you want linked to a an LGPL library, though maybe some people might want to modify the library directly and not release that code back.

Re:Weird license restriction:

[scorp1us]

By saying "violation", I did not mean a GPL violation, it is a commercial license violation.

Re:Weird license restriction:

[RichiH]

> Wow! How do they know how you "initially" began development?

Wow! It seems you did not read what they actually say in that FAQ. They _can_ tell you if you are able to _relicence_ to their other licence.

How they can enforce it is another question, but they can make things hard for others.

Re:Weird license restriction:

[Raenex]

That doesn't make any sense. First, you explicitly said "GPL violation". Also, you were referring to the GPL vs the LGPL. Why does the clause make sense in one but not the other?

QT vs iPhone SDK vs Android SDK

[EmperorOfCanada]

This all boils down to Nokia having to compete with the other key smartphone SDKs basically being free and popular. If lots of people learn to love QT for the various computer OSs then they will then have the skills ready for Nokia development. But corporate development just doesn't sit well with GPL so the LGPL is the only real option. If anything this might be a huge win. The iPhone makes you use at least some Objective C and Android gets all Java on your ass. But for really cool killer apps you might want to use C++ to do something really cool on the tiny processors found in most handsets. What would be really cool and daring for Nokia would be to make QT for iPhone. Then people might port their apps to both iPhone and Nokia.

Re:More.. STAT!

[Tetsujin]

Umm... what does it abbreviate?

"Statistical Analysis!"

Admittedly, it's sort of a knee-jerk reaction to be suggesting statistical analysis as the solution to every problem - particularly when it's not even assured that the currently-available sample size will be adequate to provide useful data - but it is nevertheless a popular reaction.

Re:Yeah but KDE doesn't work.

[Anonymous Coward]

Yes, it annoys me that Kubuntu isn't as well supported as Ubuntu. But I wouldn't move back to Suse either. Suse was great in the 9.x releases, but I abandoned it for Kubuntu after they switched package managers from YOU to SMART in 10.0 -- steaming pile of dung. I blame the downfall of Suse as a good KDE distro on their hiring of that Gnome guy... I think his name was Miguel.

QT 4 bindings for Ruby

[chrysalis]

Here: https://rubyforge.org/frs/?group_id=181&release_id=23283

No need to stick with C++ and Java, the QT bindings for Ruby work like a charm.

Re:Signals? Slots?

[Anonymous Coward]

Yes, because ANSI C++ is such an awesome graphical toolkit.

Re:Yeah but KDE doesn't work.

[Enderandrew]

First off, openSUSE uses Zypper for package management, but you can optionally use Smart if you want.

Package management was greatly improved in 11.0 and 11.1.

Secondly, Miguel Icaza is not a guy I agree with on any level, but hiring him to work on Mono and Gnome has nothing to do with the quality of KDE packages as he has nothing to do with them.

Gnome and KDE

[Tetsujin]

Yeah, which would be great if everybody liked KDE. Which clearly isn't the case, since a whole lot of people still use GNOME.

Personally, I can't think of anything that would get me to use KDE.

I want to start by saying that I have no interest in bashing one package or the other...

But I have to say that I have always preferred KDE. Getting Debian packages has been an issue sometimes (due to licensing, or just Debian not keeping up with releases) but it's always just seemed like it's had its act together much better than GNOME. It's got a pretty good selection of applications, too. GNOME doesn't seem to have kept up with application development - I guess probably it's just assumed everyone uses OpenOffice these days...

Qt vs Swing?

[Cow_woC]

How does Qt compare with Java Swing? If you're using Java anyway what are the advantages of using one versus the other?

Re:Yeah but KDE doesn't work.

[stilborne]

which is why we didn't stop at 4.0 or 4.1. 4.2 brings ark back to usefulness, SSL cert config is there, etc.. i'm pretty sure i've even told you this previously on a different web board. *raises eyebrows* so let's not beat dead horses. =)

of course, we're not stopping with 4.2 either. stopping isn't in our plan at all, in fact. just better and better releases ...

Other side of the fence

[G3ckoG33k]

"There have been too many times I where I couldn't find a good Gnome/GTK+ based app but found it with a KDE based app. However, that one app pulls in a lot of KDE based bloat that I don't want/need."

OTOH, as a KDE user I would rephrase that as - There have some times I where I couldn't find a good KDE based app but found it with a Gnome/GTK+ based app. However, that one app pulls in a lot of Gnome/GTK+ based bloat that I don't want/need. ;)

Re:Other side of the fence

[Jim4Prez]

Why do you think I also reversed it? I stated:

So I would try to switch to KDE from Gnome for a while, but found the same issue where I would have to pull in/use a Gnome/GTK+ based app.

;)

That's the People's Front of Judea!

[Giant Electronic Bra]

You collaborationist you!

Re:Wait, what?

[stilborne]

afaik, in Norway trolls are traditionally lucky creatures that live in the forests. so culturally it makes more sense. ;)

Why not LGPL?

[gknoy]

Forgive my lack of knowledge, but why does your company say no to LGPL? What restrictions does it place on you that you're not willing to work with?

QString

[spitzak]

Also, stuff like QString are actually better than C++ stdlib equivalents - providing reference counting, copy-on-write and unicode support.

std::string was certainly designed to support reference counting and copy on write. It is true that the G++ and Windows versions do not do this, but I believe they ran timing tests and determined that it was slower. Reference counting on modern machines dirties the memory that the source string was in, which can cause considerable slowness on modern multiprocessors as it requires a sync between all the processor caches.

More importantly std::string supports Unicode just fine, due to UTF-8. If you don't believe me then you have not tried programming with true UTF-8 without any api's that require conversion.

In fact QString and all the other UTF-16 things are a huge hindrance to Unicode, because of the simple fact that you cannot easily put a UTF-8 string (such as is stored in every file and Internet api used everywhere) into one, because it will be lossy (which can lead to security bugs) or throw an exception (which leads to DOS bugs) if there are invalid encodings in there. Storage as bytes allows the invalid encodings to be preserved and deferred until the last moment, when it is much easier to manage errors.

UTF-16 makes most programmers give up and pretty much resort to only supporting ISO-8859-1 (or worse, only ASCII) when reading bytes. Don't believe me? Just yesterday, a quite smart programmer where I work, in response to encountering an invalid UTF-8 string, "fixed" it by running every string through a filter that replaced every byte with the high bit set with "\xNN" (where NN is the byte in Hex). That was considered good enough, as English still printed. They do not give a damn about Unicode, and all those politically-correct idiots pushing UTF-16 need to learn that they are causing far more damage to Unicode than they are helping!

Re:Yeah but KDE doesn't work.

[digitalunity]

As an avid Ubuntu user, I can attest to that. The package manager is nice, the dist. is easy to use, but it's not very fault tolerant and there are some wigged out packages.

For instance, I can't uninstall Ubuntu's package for proprietary Nvidia drivers because it says it needs to remove the kernel to remove Nvidia(wtf indeed). Their fundamental policies regarding proprietary drivers is wonky, considering there are really not a lot of people against proprietary hardware drivers on linux.

The distribution has a lot going for it, but really needs some polish.

Good and Bad

[nurb432]

Its good that its not free to use, and will spur short term projects that were held back due to licensing.

But is it good long term? Now that its not a money maker, where is the true incentive to keep development happening. Is there enough momentum in the OSS world to keep it alive?

i see it starting to stagnate then eventually get moldy.

Re:Yeah but KDE doesn't work.

[Brandybuck]

Furthermore, KDE doesn't depend on video drivers.

Actually it does. Even with desktop effects turned off, you can get flashies, dropouts and sluggishness if you don't have a good video driver (or correctly massaged xorg.conf settings). Much of this is actually Qt's fault, but should be fixed in Qt 4.5 with the new raster backend.

Re:Yeah but KDE doesn't work.

[Enderandrew]

KDE depends on X11, but there are no package dependencies for specific video drivers.

I just installed openSUSE 11.1 on an old, beat-up Dell notebook with a GeForce 440 with only 32 MB of RAM. It actually manages to run KDE 4 with Desktop Effects turned on.

Good to hear

[sentientbrendan]

The main reason I've avoided QT in the past is the licensing... I can understand releasing an application under GPL, but it's very obnoxious when it is used for a library.

Even among open source developers, not everyone wants to release under GPL. People like myself like apache, BSD, MIT, etc, but using a GPL library forces us in practice to release under GPL terms as well.

Re:Good to hear

[Vexorian]

My sentiments as well. I for one think GPL is vital for core programs/stuff like the kernel , but other small projects , can really do great without the protections from the GPL. Just saying , in the case of a small game/app, hijack from proprietary companies is not a big threat anyway to justify the complications from the GPL, and it is great QT just got friendlier to this sort of apps.

Re:Signals? Slots?

[Brandybuck]

I'll stick with ISO C++! And since Qt uses 100% ISO Standard C++, I'll have no problems!

Typos..

[nurb432]

Damned typos. i meant is NOW free to use..

Blah.

Re:Yeah but KDE doesn't work.

[Brandybuck]

Yes, it will build and install. That's not what I was talking about. Performance and rendering can suffer if the correct driver/config are not used.

Re:Yeah but KDE doesn't work.

[pbhj]

Qt 4 used Xrender heavily, and Nvidia's driver had a piss-poor Xrender implementation. The forthcoming Qt 4.5 is supposed to move away from using Xrender all over the place, and the latest Nvidia driver has much better Xrender support to boot. openSUSE even provides a repo with weekly snapshots of the KDE 4.2 branch compiled against the weekly snapshots of Qt 4.5.

Kubuntu does seem particularly bad with KDE4 compared with OpenSUSE as far as slickness of presentation goes, I'm using suppurating edge however.

But, Xrender is an option in the Kwin settings .. so I've always used OpenGL (think that was default). Can't see that would mean Xrender was used too?!?

Re:Yeah but KDE doesn't work.

[Enderandrew]

It isn't fast, but it runs as well as XP did on that box.

Regardless, if you don't configure Xorg properly, you aren't going to get great performance in Xorg, period.

tjstork said that installing KDE 4 automatically changed his video driver and kernel. The KDE 4 packages don't depend on video driver packages. Installing KDE 4 should not alter the kernel, or install different Xorg packages.

Qt Becomes LGPL: Game changer!

[spongebob232323]

Winners:
-- Software engineers.
-- KDE/Qt.
-- C++.

Losers:
-- GNOME (is dead).
-- Wackjob "Why you shouldn't use the Lesser (Library) GPL for your next library" Stallman & FSF.
-- Any other computer languages that are not C++.

I sure hope so!

[Giant Electronic Bra]

It would be a VAST improvement if I could distribute RCP based applications with a single underlying UI toolkit. SWT is great, but whoever thinks their SWT based app will work cross platform without a LOT of tweaking, is insane ;).

Re:Signals? Slots?

[gatkinso]

Really? I guess someone should tell that to trolltech as they refer to these and other constructs as "C++ extensions"

http://doc.trolltech.com/4.0/moc.html

Additionally, the list of what you can and cant do in a signal/slot block is quite extensive. Even MFC, abortion that it is, is not nearly so screwed up.

I especially like the quote, "Less importantly, the following constructs are illegal. All of them have alternatives which we think are usually better, so removing these limitations is not a high priority for us."

Translation: we are not up to the task of fixing our crap, so screw it.

Like I said, I'll stick with ANSI C++ and let you ankle biters muck about with the moc.

Re:Should all GPL projects switch to LGPL eventual

[Vexorian]

Hell no? LGPL is a superior option for libraries, but for normal apps GPL is even necessary, unless of course you agree to proprietary forks and stupid things like that, but then I doubt people that chose GPL for their projects would like that.

Ppl miss this point

[WindBourne]

There are some ideas which ARE easier to code in GNOME and others easier in KDE. More importantly, ppl PREFER a different platform. I did GTK back in the mid 90's. Did not care for it. I am sure that it is different, but still. When I am coding in C, I want it at the OS. When doing an App, I prefer C++, Perl or Java. They are both taking different paths. Yeah, they have to come together on core things, but still, that is a different matter.

this isn't enough

[Anonymous Coward]

if you ship your product with the plugin you are still creating a derivative work under the GPL even after all that. Even if you use standard APIs (e.g. ODBC/JDBC) that are not GPLed to access GPLed software you could find yourself in court.

Re:Yeah but KDE doesn't work.

[Brandybuck]

My xorg.conf on one platform works fine for KDE3, GNOME, Beryl, Enlightenment, etc, etc. But for KDE4 I have to change it. Which sucks, because then it's crap for KDE3, GNOME, Beryl, Enlightenment, etc. Not every driver will have this problem, but enough do that KDE lists are forums are littered with driver related complaints.

Pretending this problem does not exist does not make it go away. I'm crossing my fingers very tightly that 4.5 will fix this.

tjstork said that installing KDE 4 automatically changed his video driver and kernel.

That is the **distribution** doing that, not KDE4. But it sort of proves my point, even the pre-packaged iso-wrapped distros that automatically replace your kernel know that the standard xorg.conf settings will not work with KDE4.

Re:Signals? Slots?

[Brandybuck]

Just because some parts of the documentation refer to certain names as "keywords" does not make it so. As powerful as Nokia is, they still cannot change the compiler. There are no new keywords or G++/VC++ could not parse them!!! Really now, stop regurgitating trolls and think for a moment. If these are C++ extensions, how the hell can you compile Qt applications on standard C++ compilers? The answer is that they are not extensions. "signals", "slots" and "emit" are macros. Furthermore, they are macros that expand to nothing. The only thing Qt is doing is giving you a preprocesser called MOC that writes some object introspection code for you.

And please upgrade from "ANSI C++". Only ankle-biters user it any more. The rest of the world has upgrade to ISO Standard C++.

Re:Yeah but KDE doesn't work.

[Enderandrew]

What distro are you running? Which version of KDE 4? What video card do you have?

You know what? Send me an email with all that pertinent info, along with your xorg.conf to enderandrew AT gmail dot com and I can probably get you taken care of.

Again, I just installed a KDE 4.2 snapshot on an old laptop with a Geforce 440, and it is running KDE 4 reasonably well.

rewrite Qt in C++ templates?

[NuShrike]

Would Qt be better written now using C++ templates and the latest template meta-programming instead of the meta-language Qt is currently using?

We're at the point where most main-stream platform compilers can handle template code properly and efficiently, so Qt's non forward thinking objections are beside the point now.

Re:rewrite Qt in C++ templates?

[jbolden]

I don't know the answer, sorry.

Present state of development: WxWidgets vs. Qt?

[Futurepower(R)]

On Windows, how does WxWidgets compare in ease of programming and quality with Qt?

Re:Present state of development: WxWidgets vs. Qt?

[ncc74656]

On Windows, how does WxWidgets compare in ease of programming and quality with Qt?

I've not used Qt on Windows yet (or on Linux, for that matter).

For the one cross-platform project I did, wxWidgets turned out to be fairly easy to pick up; as I recall, most of the calls aren't too different from how Windows does things. I even had a Linux-based toolchain set up within KDevelop that would build both Linux and Windows binaries. Whether Qt would be easier or more difficult, though, isn't something I can answer.

NOT OFFICIAL

[Anonymous Coward]

Not a word of this on Netcraft.

15 years too late

[the-matt-mobile]

It seems like this is 15 years too late. The damage of having the GTK / QT rift has been done, and its impact on the desktop Linux world seems irreparable. Personally, while I prefer QT's architecture, I and many other developers have favored GTK because of its license. It kind of makes me sad that after all this time of posturing and zealotry and bravado and division, that the end result is that now there are 2 LGPLed GUI toolkits for Linux. Forgive me for not being as excited today as this news would have made me years ago.

Re:15 years too late

[pherthyl]

That's stupid. If Qt was LGPL'd 15 years ago, Trolltech would have gone out of business 14 years ago, and Qt wouldn't exist.

Re:15 years too late

[the-matt-mobile]

Are you saying that the GPL is the only way they stayed in business?

Re:15 years too late

[pherthyl]

Dual licensing GPL/Commercial is how they stayed in business. Licensing revenue was their primary income (you can check their financial statements) Having the GPL as the open source license forced commercial companies to pay them if they wanted to develop closed source programs using Qt. With LGPL licensing, that incentive is gone, so licensing revenue will likely drop hugely (I know that I probably won't bother renewing my commercial license after this announcement).

Re:15 years too late

[kojot350]

What's wrong with you, it's all about choice remember? Now we have more choice ;D

Re:Yeah but KDE doesn't work.

[betterunixthanunix]

Yes I know, but 4.2 is still not officially released. Also, the GP said that 4.1 was almost feature complete compared with 3.5.x, so there was no reason to bring up 4.2. Anyway, I am looking forward to 4.2, hopefully the Fedora guys package it quickly when it is released.

patch set

[spitzak]

I think the LGPL actually says you have to provide the full modified source code, not a patch set, so that is why I put it in quotes.

In reality, however, any company that wants to do this would instead send their patches to Nokia and try to convince them to put them into the official version. So their output really would be patches.

Re:patch set

[Directrix1]

I see.

Exception safety

[Pseudonym]

Of course, some C++ "purists" hate it for that reason.

Well I'm a C++ language paralegal, and I don't hate Qt for that reason. I used to hate it because it didn't play nice with the standard library or third-party applications which did do things like throw exceptions.

Qt used to be full of this sort of thing:

QThingy *thingy = new QThingy();

You can safely assume that anyone who writes that today doesn't know C++.

So... how exception-safe is Qt these days? Can I safely use the STL or Boost and Qt in the same program?

I do realise that most Linux distros ship Qt with exception handling turned off, which is wrong on multiple levels, so obviously I'd have to compile it myself. And I'm aware that throwing non-fatal exceptions from a slot or event handler isn't what you want. Apart from that, is everything fine?

Re:Exception safety

[pherthyl]

>> You can safely assume that anyone who writes that today doesn't know C++.

Since I write C++ for a living, I have to ask, what's wrong with that line? Of course if possible I'd put it on the stack, but sometimes it can't be avoided..

>> So... how exception-safe is Qt these days? Can I safely use the STL or Boost and Qt in the same program?

Of course. We do.

>> I do realise that most Linux distros ship Qt with exception handling turned off, which is wrong on multiple levels, so obviously I'd have to compile it myself.

I don't think this is the case on newer distros. I think before GCC 4.0 exception support imposed a pretty big overhead so people left it out. I've never had a problem with exceptions in Qt-using code on any platform.

Re:Exception safety

[Pseudonym]

Since I write C++ for a living, I have to ask, what's wrong with that line?

Consider the following code sequence:

QThingy *thingy = new QThingy();
justAboutAnything();

Just about anything can throw an exception in C++. When that happens, thingy will never get deleted, causing a memory leak and, if thingy owns a resource, a resource leak. The fix is to use a managed pointer, such as std::auto_ptr, boost::shared_ptr or QSharedDataPointer. This also applies to class members.

You might like to read Exceptional C++ by Herb Sutter. It goes into these issues in some depth.

Of course if possible I'd put it on the stack, but sometimes it can't be avoided..

Of course, thanks to multi-threading, stacks are smaller than they used to be. If you want to put a large object in stack scope, boost::scoped_ptr might be appropriate.

I've never had a problem with exceptions in Qt-using code on any platform.

That's good to know, thanks.

Re:Exception safety

[Brandybuck]

QThingy *thingy = new QThingy();
You can safely assume that anyone who writes that today doesn't know C++.

Then I guess not very many people know C++!!! I'm a contractor who has worked with dozens of companies in a wide range of fields, including medical, space and security. I have seen new statements wrapped in try blocks exactly once in that time.

Re:Exception safety

[Pseudonym]

I've never seen a new statement wrapped in a try block. That sounds excessive.

Tricky, and not strictly LGPL

[Futurepower(R)]

It's LGPL, except it's not. The "commercial license" modifies the meaning of LGPL.

Re:Tricky, and not strictly LGPL

[Perky_Goth]

No, it doesn't. You can use the LGPL one as long as you want. But if you want a closed one, they want to make an extra buck off of you, so that you don't buy it only when you release. Nothing unusual. I'm sure that companies could come to an understanding with them.

Good News for Linux, Windows And Developers

[ZuBsPaCe]

This is really exciting! IMO, QT is one of the cleanest C++ API's I've ever seen. The interface is easy to use and the documentation is simply excellent. As a windows developer I've been hesitant of porting C++ Apps to Linux, simply because of the terrible GUI Toolkits available. QT going LGPL makes this a no brainer. It's superior to WinAPI, MFC and even the combination of .NET/C#/C++, if you're just in need of a proper GUI. Maybe the Year of Linux Desktop is finally coming, thanks to QT??!

Re: Sig

[Anonymous Coward]

Patriotism and nationalism are different things; your objection applies to the latter, though it calls itself the former. Please learn the difference.

Crazy: You must make decisions about the future.

[Futurepower(R)]

You said, "You can use the LGPL one as long as you want."

No you can't. According to the commercial license restriction, you must know in advance that you plan to make your software commercial. If you didn't know that in advance, and you use the LGPL, you must abandon any idea of making your software commercial.

That's simply crazy. If an employee makes a test version of something to use inside the company, the company cannot later build on that and make a commercial project.

Non-sequitor

[Anonymous Coward]

To paraphrase the meme: I don't think you replied to who you think you replied to...

Consistency would be nice, but ...

[drx]

I don't know what is the problem with "the two" desktops and "the two" libraries ... on Windows, i seem to enjoy 1024 different libraries, file selector dialogues and ways to display fonts, let alone user interface rules. And this system is, for some reason, very successful.

Only Mac users are used to a more or less consistent user experience. But that is more of a culture than a technical effect.

Re:Crazy: You must make decisions about the future

[Perky_Goth]

Sure you can, you can even sell something that is closed source with an open LGPL module. What you want is to use someone else's work without paying anything in return, and only BSD-type licenses lets you do that. Again, you can probably reach an agreement.

Re:Yeah but KDE doesn't work.

[kojot350]

I totally agree, I've used both GNOME and KDE4 on Ubuntu for couple of months, but I was very disappointed, it just sucked big time, especially Kubuntu's KDE4. Now I use openSUSE 11.1 with KDE4.2 RC1 and I have to say it's the best KDE I've seen. I've also tested recently openSolaris and it have better polished and tweaked GNOME than Ubuntu.

Re:Signals? Slots?

[kojot350]

I'll stick with ANSI C++ thank you very much.

You don't have to use them if you don't need them and if you don't use them you also don't need MOC, just don't put QOBJECT macro into your class declaration, that's all...