Yup, a native port to OSX acheives one half of this.. in terms of removing all X11 dependencies from KDE. The other half is of course, to to finish Qt/Win32-Free (port of a GPL'd Qt/FreeX11 to Win32), which is about 80% there.. See here for some screenshots
Qt/Win32-Free would eventually allow a KDE not hampered by X11 or Cygwin dependencies on Windows.
The Loki Games installer is actually open source. The reason gtk was selected over Qt is that the toolkit needed to be shared linked, and the fact that gtk 1.2 is much smaller than qt 2.x.
Who knows which one would have been used today; Qt/embedded is smaller than GTK 2.x is.
> What is becoming apparent is that a smallish, vocal fanboy group is prepared to tear any project apart if they do not include their favorite project.
Indeed.. I think Bruce Perens could have avoided a lot of trouble by saying that from the onset that no GUI based on GPL tools like Qt could be used. That would have ruled out KDE from the onset.
Instead, he announced it and he wanted people's opinions on a GUI for it. I guess now it's pretty obvious what he wanted.:)
GNOME also has full accessibility support. What's exicting is that KDE and GNOME's accessibility is fully compatable with each other. Great step in the advancement of the UNIX desktop.
> A commercial license of QT gives you no more freedom than the LGPL does.
Nope.. with a commercial Qt license, you can link to modified copies of Qt without having to rerelease the source of said modified copy, which you would be required to release with the LGPL.
I think that kcontrol most has an appearance of being unusable. KDE 3.2 has "settings:/", which has the same content as kcontrol, but presents it in a much better way (akin to GNOME, Windows, MacOS before OSX).. and to me, it feels a lot more usable.
> GTK+ is ported natively to a particular immensely popular proprietary operating system
Erm, the gtk+ windows port is still _very_ raw.
> whereas Qt Free needs the heavyweight Cygwin layer.
Qt-win32, which is the port of Qt/free from X11 to win32, _barely_ requires Cygwin at this point. Over the past few six months or so, it has matured to a point where all X11 classes have been ported to GDI. The next step is to port the three or four remaining classes that require Cygwin to native windows. If you chose not to compile in Qt's networking classes (actually, only the DNS classes aren't ported right now), you can likely build Qt/free on Visual C++.
> LGPL is good if you like giving other people the freedom to use proprietary software if it better suits their needs. No one forces you to use proprietary software just because a library is LGPL'd.
Using that argument, Qt would indeed be a better solution, since a commercial license of Qt gives you pretty much ALL freedoms.:-)
That really has to do with interpretation of whether a company is internally one entity or many entities. This differs between localities, states, and countries. It coinicidently is one of the more fuzzy areas of both the GPL and LGPL.
Yup, but what's weird is that UserLinux will include other toolkits _anyways_ besides just GTK. It'll include at least, XUL, used in Mozilla, VCL, used in OpenOffice, and probably wxWindows as well.
It's fine using GNOME as a default desktop. That's Bruce's decision I guess. But including Qt and KDE _libraries_ and some apps is probably a mistake. You don't need to include the KDE desktop, but don't ignore KDE apps, unless you're willing to ignore non-GTK apps like OpenOffice as well.
> First of all, Moz had a great product long before AOL bought them.
uhhhm, really? AOL bought Netscape in late 1998. Mozilla, at that time, was at Milestone 3. I *clearly* remember Milestone 3, both on my Mac on Linux. It consisted of a app called ViewerApp and a large amount of shared libraries. ViewerApp, which barely had http support, took about three mins to launch on my PowerMac 604e.
RH 5.2 included M3, but NS 4.5 was default, which itself was *much worse* than IE 5.0 was. I don' t think anybody in their right mind would use Mozilla at that point. It took nearly AOL millions of dollars and a seventy person strong Netscape Division to bring Mozilla where it is today.
Ehm, it has been off since KDE 3.0, mostly because people considered it annoying. If it's on by default, it's probably the fault of your distro, as another user said.
Yup folks, I've been trying it out the last few days, and the port of Qt/X11 to Qt/Windows (and is thus GPL'd) is almost done, and has progressed a lot over the past few months. Most of the graphical parts are done (replacing the x11 dependant parts of Qt with win32/GDI equivalents.)
What's not done yet is replacing the non-GUI parts- e.g, moving from the "_unix" files and writing win32 equivalents. Thus it currently requires cygwin (but no X11).
> You are extrapolating in a linear fashion based on the highest growth rate recorded this century.
No, as I started, there was a large amount of economic and social reforms put in place after 1991 (when the Rao government took power, and instituted massive reforms in not only education, but the economy-- moving from post-Gandhist "lets leave most Indians as farmers", to a different post Cold War reality. Much like China did in 1978, but in a perhaps more accelerated manner)
> Western Europe and the US have literacy rates circa 95%
Of course, that's why I said "western standards". It's unlikely India will ever reach 99% literacy.
Assuming another 13% Jump in literacy, India will be at western standards in less than twenty years. It might even be faster than that, because between 1991 and 2001, there was greater change in India as a whole in terms of economic reforms than the whole fifty years since Indian independence before that. In any case, there is already more literate people in India than in the US.
Yup, I didn't mean to say that. I mean that LD_PRELOAD'd libraries that allow non-KDE/GNOME applications to transparently use kio and gnome-vfs are kludges. It's been done various times with both. Although I admit "ls -la ftp://ftp.foo.com" sounds cool.
> I still can't understand why this hasn't made it into a mainline kernel hook
theoretically possible, but very non-portable, would break frequently. Gennerally isn't a good idea to bring something like that into kernel space.
> or at least a shared library kludge.
It's been done with with kio and gnome-vfs. But again, it's a kludge. Things are prone to frequent breakage, and LD_PRELOAD isn't terribly portable either.
Well, I suppose so. However, nearly all gtk development (perhaps 90%+?) development is done in C, and nearly all Qt development (perhaps 90%+?) is done in C++. It would be interesting to do a comparison between Qt and gtkmm however, or hell even between gtk and QtC (that would be writing managed C++ in.NET =).. I'd bet that Qt would come out over gtkmm, and gtk would come out over QtC, mostly because those respective API's have been optimized over a long period.
> As to Mozilla/Gecko, I'm not sure but I know there is a GtkMozEmbed and I doubt the API is significantly different to GtkHtml.
Erm, there is quite a large difference between just embedding a widget and having a web browser. gtkhtml and gtkmozembed provide a quick API to embed a html widget into an app, but last time I checked, the app had to do a lot of logic to make everything work together. This would be the equivalent of khtmlwidget then, not khtmlpart, which is actually used by applications.
I think the LOC argument is best supported from people who've actually ported code between gtk and Qt, and vice versa. The kvim authors wrote a piece about this a while ago, and I found the same thing to be true, when I ported xchat's xtext text widget to Qt (see here compared to here).. they are nearly functionally equivalent, but one is less than one half the size of the other =)
It's rather odd, but I think it's actually becoming increasingly more viable for people to retain a non-gtk system (e.g, KDE+OOo).
I would have agreed with you in KDE 3.0 and 3.1. For example, there was really not any good KDE media players, Konq was just not as good as Mozilla was, and there wasn't any real equivalent of Gaim. But I completely disagree with you in terms of things like KDE 3.2b1, due to the inclusion of juk (a great media player, finally got rid of xmms && gtk1.2 ), kopete (got rid of gaim, one of the last few gtk2 apps I was using), and the improvements to Konqueror are definatly very nice.
Slashdot Mirror
Yup, a native port to OSX acheives one half of this.. in terms of removing all X11 dependencies from KDE. The other half is of course, to to finish Qt/Win32-Free (port of a GPL'd Qt/FreeX11 to Win32), which is about 80% there.. See here for some screenshots
Qt/Win32-Free would eventually allow a KDE not hampered by X11 or Cygwin dependencies on Windows.
> Loki Games installer.
The Loki Games installer is actually open source. The reason gtk was selected over Qt is that the toolkit needed to be shared linked, and the fact that gtk 1.2 is much smaller than qt 2.x.
Who knows which one would have been used today; Qt/embedded is smaller than GTK 2.x is.
> What is becoming apparent is that a smallish, vocal fanboy group is prepared to tear any project apart if they do not include their favorite project.
:)
Indeed.. I think Bruce Perens could have avoided a lot of trouble by saying that from the onset that no GUI based on GPL tools like Qt could be used. That would have ruled out KDE from the onset.
Instead, he announced it and he wanted people's opinions on a GUI for it. I guess now it's pretty obvious what he wanted.
GNOME also has full accessibility support. What's exicting is that KDE and GNOME's accessibility is fully compatable with each other. Great step in the advancement of the UNIX desktop.
> A commercial license of QT gives you no more freedom than the LGPL does.
Nope.. with a commercial Qt license, you can link to modified copies of Qt without having to rerelease the source of said modified copy, which you would be required to release with the LGPL.
I think that kcontrol most has an appearance of being unusable. KDE 3.2 has "settings:/", which has the same content as kcontrol, but presents it in a much better way (akin to GNOME, Windows, MacOS before OSX).. and to me, it feels a lot more usable.
> GTK+ is ported natively to a particular immensely popular proprietary operating system
Erm, the gtk+ windows port is still _very_ raw.
> whereas Qt Free needs the heavyweight Cygwin layer.
Qt-win32, which is the port of Qt/free from X11 to win32, _barely_ requires Cygwin at this point. Over the past few six months or so, it has matured to a point where all X11 classes have been ported to GDI. The next step is to port the three or four remaining classes that require Cygwin to native windows. If you chose not to compile in Qt's networking classes (actually, only the DNS classes aren't ported right now), you can likely build Qt/free on Visual C++.
> LGPL is good if you like giving other people the freedom to use proprietary software if it better suits their needs. No one forces you to use proprietary software just because a library is LGPL'd.
:-)
Using that argument, Qt would indeed be a better solution, since a commercial license of Qt gives you pretty much ALL freedoms.
> to write a GPL application for internal use -
That really has to do with interpretation of whether a company is internally one entity or many entities. This differs between localities, states, and countries. It coinicidently is one of the more fuzzy areas of both the GPL and LGPL.
Yup, but what's weird is that UserLinux will include other toolkits _anyways_ besides just GTK. It'll include at least, XUL, used in Mozilla, VCL, used in OpenOffice, and probably wxWindows as well.
It's fine using GNOME as a default desktop. That's Bruce's decision I guess. But including Qt and KDE _libraries_ and some apps is probably a mistake. You don't need to include the KDE desktop, but don't ignore KDE apps, unless you're willing to ignore non-GTK apps like OpenOffice as well.
> If TrollTech chose to make Qt non-free, then all previous revisions will still be available under the GPL.
Additionally, the last free version of Qt would become BSD licensed. As per KDE FreeQt foundation guidelines.
> The biggest secret: if you want a field that you can type a url into, you have to use the Location toolbar, and leave the "location" widget on it.
:)
This buglet was fixed in 3.2, I beleive. It was quite annoying before
> Make them context sensitive.
Uhm Konq's context menus, *are* _mostly_ context sensitive in KDE 3.2.
More things will be changed in 3.3 however. The current plan is to move things like Security to the status bar.
Oh well, it's *good enough* for a large amount of users, and that's really what's important.
> First of all, Moz had a great product long before AOL bought them.
uhhhm, really? AOL bought Netscape in late 1998. Mozilla, at that time, was at Milestone 3. I *clearly* remember Milestone 3, both on my Mac on Linux. It consisted of a app called ViewerApp and a large amount of shared libraries. ViewerApp, which barely had http support, took about three mins to launch on my PowerMac 604e.
RH 5.2 included M3, but NS 4.5 was default, which itself was *much worse* than IE 5.0 was. I don' t think anybody in their right mind would use Mozilla at that point. It took nearly AOL millions of dollars and a seventy person strong Netscape Division to bring Mozilla where it is today.
That post is in extremely bad taste. Desktop wars are one thing, but largly inconsequental in comparison to human life!
Ehm, it has been off since KDE 3.0, mostly because people considered it annoying. If it's on by default, it's probably the fault of your distro, as another user said.
Yup folks, I've been trying it out the last few days, and the port of Qt/X11 to Qt/Windows (and is thus GPL'd) is almost done, and has progressed a lot over the past few months. Most of the graphical parts are done (replacing the x11 dependant parts of Qt with win32/GDI equivalents.)
What's not done yet is replacing the non-GUI parts- e.g, moving from the "_unix" files and writing win32 equivalents. Thus it currently requires cygwin (but no X11).
There are some screenshots here. Source is available there too.
> You are extrapolating in a linear fashion based on the highest growth rate recorded this century.
No, as I started, there was a large amount of economic and social reforms put in place after 1991 (when the Rao government took power, and instituted massive reforms in not only education, but the economy-- moving from post-Gandhist "lets leave most Indians as farmers", to a different post Cold War reality. Much like China did in 1978, but in a perhaps more accelerated manner)
> Western Europe and the US have literacy rates circa 95%
Of course, that's why I said "western standards". It's unlikely India will ever reach 99% literacy.
> India has an illiteracy rate about 70%.
Erm, that hasn't been true since around 1970.
Indian Literacy Rates:
1951 - 18.33%
1961 - 28.31%
1971 - 34.45%
1981 - 43.56%
1991 - 52.21%
2001 - 65.38%
Assuming another 13% Jump in literacy, India will be at western standards in less than twenty years. It might even be faster than that, because between 1991 and 2001, there was greater change in India as a whole in terms of economic reforms than the whole fifty years since Indian independence before that. In any case, there is already more literate people in India than in the US.
> kio and gnome-vfs are *not* kludges
Yup, I didn't mean to say that. I mean that LD_PRELOAD'd libraries that allow non-KDE/GNOME applications to transparently use kio and gnome-vfs are kludges. It's been done various times with both. Although I admit "ls -la ftp://ftp.foo.com" sounds cool.
> Where would be the right place for the implantation for this? freedesktop? XFree86? As gnome feature?
i st
Probably as an XDG spec/standard that both KDE and GNOME follow (as well as gtk and qt)
See https://listman.redhat.com/mailman/listinfo/xdg-l
> I still can't understand why this hasn't made it into a mainline kernel hook
theoretically possible, but very non-portable, would break frequently. Gennerally isn't a good idea to bring something like that into kernel space.
> or at least a shared library kludge.
It's been done with with kio and gnome-vfs. But again, it's a kludge. Things are prone to frequent breakage, and LD_PRELOAD isn't terribly portable either.
Well, I suppose so. However, nearly all gtk development (perhaps 90%+?) development is done in C, and nearly all Qt development (perhaps 90%+?) is done in C++. It would be interesting to do a comparison between Qt and gtkmm however, or hell even between gtk and QtC (that would be writing managed C++ in .NET =).. I'd bet that Qt would come out over gtkmm, and gtk would come out over QtC, mostly because those respective API's have been optimized over a long period.
> As to Mozilla/Gecko, I'm not sure but I know there is a GtkMozEmbed and I doubt the API is significantly different to GtkHtml.
Erm, there is quite a large difference between just embedding a widget and having a web browser. gtkhtml and gtkmozembed provide a quick API to embed a html widget into an app, but last time I checked, the app had to do a lot of logic to make everything work together. This would be the equivalent of khtmlwidget then, not khtmlpart, which is actually used by applications.
I think the LOC argument is best supported from people who've actually ported code between gtk and Qt, and vice versa. The kvim authors wrote a piece about this a while ago, and I found the same thing to be true, when I ported xchat's xtext text widget to Qt (see here compared to here).. they are nearly functionally equivalent, but one is less than one half the size of the other =)
It's rather odd, but I think it's actually becoming increasingly more viable for people to retain a non-gtk system (e.g, KDE+OOo).
I would have agreed with you in KDE 3.0 and 3.1. For example, there was really not any good KDE media players, Konq was just not as good as Mozilla was, and there wasn't any real equivalent of Gaim. But I completely disagree with you in terms of things like KDE 3.2b1, due to the inclusion of juk (a great media player, finally got rid of xmms && gtk1.2 ), kopete (got rid of gaim, one of the last few gtk2 apps I was using), and the improvements to Konqueror are definatly very nice.