Swing was initially much slower than AWT. However, as optimizations were made, it became almost as fast as AWT. If you have used a modern java, you'd know this:)
> Gtk is more commonly used then any other brand. Sure it sucks, but it sucks less.
And gtk-- is barely used at all.
Re:QT forces non standard c++ use
on
GTK-- vs. QT
·
· Score: 2
> I don't think that is really in the remit of a gui toolkit at all.
It's an application framework.
> QT has reimplemented all those things as a rather dodgy set of proprietry classes.
Dodgy? How do you figure? They are very high quality, and are actually more cross platform than many std:: classes are. Ever try to compile large non=Qt C++ code in HP/UX with quite broken compilers? I have, it's not pretty.
Besides, if you knew anything about Qt, you'd see that Qt3 has stl support.
Re:If internationalisation matters...
on
GTK-- vs. QT
·
· Score: 2
> It looks like Gtk2 will use Unicode and Pango, thus potentially blowing away the competition, but as long as there's no stable version of Gtk2.
However, Gtk2's win32 port will likely remain a very unsupported port. While qt's win32 port is as important if not more important (because of commercial licenses), than their X11 port.
No, in fact, quite the opposite is true. It'd be faster than solutions that simply wrap around native API calls.
It is like in the Java world between AWT (Java 1.0.x) and Swing (Java 1.2.x). AWT tried to simply wrap around the native toolkits. As a result, it was quite slow. Swing does it like Qt, and provided an API for drawing widgets, much like Qt does with QStyle.
> eat up memory space and disk access time.
I think they alleviated this by using QPixmapCache. It should be only a tad bit slower, if not the same speed as regular OSX apps. Either way, an user would not know the difference in speed.
Re:A third alternative... :)
on
GTK-- vs. QT
·
· Score: 2
> good choice for a large commercial project.
Nah, Qt itself is probably the best choice for a commercial project. I'd use wxWindows for free software that targets many platforms tho, and Qt for X11-only free software.
> wxPython
Yeah, wxPython's really nice.
Re:Qt has better documentation
on
GTK-- vs. QT
·
· Score: 2
> QT on the other hand has a very good abstraction of windowing system details.
Yup, this is because Qt is not a gui-toolkit but rather an application framework. It provides classes that work equally on all platforms that Qt supports, saving the user from writing a bunch of #ifdefs for particular platforms. It works really well:)
Re:wxWindows (slightly OT)
on
GTK-- vs. QT
·
· Score: 2
> Note that your apps will look totally windowsy on win32, so your users will not be confused by their look.
Which Qt does as well. I find wxWindows too MFC-y too use tho, although it is quite a viable alternative to Qt, especially for open software on Windows.
However, If you want a high quality professional toolkit, stick with Qt. gtk--? no way, it's not in any good shape.
> And the KDE guys can't? They have the source to everything, it should be even easier!
I think ideally they should. However, I don't think that'd go over too well with the 'oh wait, that's not UNIX-y" group.;-)
> Except that Win95 was slower because it had tons of new features. Win2K matches KDE feature for feature, but KDE is slower, even though it is running on a better kernel/display layer (yes, XFree86 is faster than GDI these days, with good drivers). Are you telling me that there's nothing wrong with that?
And a better display layer is not all that counts. KDE is currently hampered in various things that are not KDE's fault. First, and most major, is probably g++.
> If my 3D modeler is faster, I can work on more complex models before the system becomes too slow to be comfortably usable. If my display layer is faster, I can make more complex graphics at an acceptable frame-rate. If my desktop is faster, I can have more windows open and switch between them quicker. Even if I upgrade to new hardware, the faster system will STILL be better.
Ok, that IS true. However one has to consider that most things that provide great amounts of features slows down performance. There are, of course ways to get around this problem, like Microsoft does with integration.
> Under the Micro$haft regime. I thought OSS was supposed to be new and different! I honestly don't mind spending the cycles when I get features in return. But when I switched from Windows to Linux (which I did because I couldn't stand Windows anymore, even though it is a higher-quality OS)
Under any regime, this is true. It has always been true. This has nothing to do whatsoever with OSS. Computers get defunct. Deal with it.
> I lost features *and* speed.
Modern KDE versions are quite comparable with Windows in terms of speed on modern machines.
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
> How you explain the fact that ROX is as fast as Explorer?
Because it does much less than Explorer does, and can do. Remember that the internal infrastructure can slow down things, at the expense of getting more stuff done (or being extensible, which ROX isn't).
> XFree 4.x is *not* slower than Windows/GDI. In fact, for many things, like image blitting, its as fast as DirectX.
Yes, that's true. Then again, I never said it wasn't.
>Also, the integration thing is overblown. Most Windows apps run quickly, and you can't tell me that they all have tight integration with the core OS!
Ah, yes, but the underlying libs that "most Windows apps" depend on do. Much of the win32 api is kept in kernel space rather than user space. This is similiar to classic MacOS as well, with all Mac toolbox functions kept in the core OS. In the case of winXX, this includes GDI, parts of COM,
> Its just that Linux desktops have too many performance sapping paradigms. Take, for example, XUL.
Mozilla is quite a bit faster on Windows than Linux. It's as fast as explorer in turbo mode, for example.
> Parsing a text file to display a GUI? Are you insane!
This is done in a variety of environments. It's nothing new. KDE does it with XML-GUI. Gnome does it with libglade. Windows does it with.rc files. I beleive MacOSX also does it in special files in bundles.
> Then the use of CORBA instead of something nice and fast like COM.
Again, power versus speed.
> There are lots of KDE/GNOME features that make computer nerds cream, but do nothing except sap the performance of users' machines.
Both run quite zippy enough here.
> I don't think so. Most of the reviews I've seen that say XP is slower are pased on the Release Candidates. XP sped up a *lot* between the those and the gold release.
Out of personal information, I can tell you that XP in fact, IS much slower than win2k on the same machine. It is certainly in mine!
> But KDE 2.2.x is *faster* than KDE 2.0.x! That's the KDE develoment model. Big features, then incremental quality improvements.
Yes, but that is minor versions. If you take major versions into account, you see that this is not the case. For example, KDE 2.x's speed Its really not like that all the time. There are tons of programs that don't keep getting slower. Photoshop, for example, has been pretty much the same since 4.x.
Almost everyone I know that uses Photoshop can tell you that Photoshop was much faster in certain tasks than Photoshop 5.x and 6.x. That's why there are still many Photoshop 4.x users left.
> 3D Studio keeps getting faster. KDE 2.2.x keeps getting faster. It does slow down over time, but the stuff you see in the Linux world is *much* more dramatic than the same in the Windows world.
Yes, but say a new version of 3d studio came out with 25% new features. It'd be certainly slower. However, people would move on to faster comps.
> But then Windows (which has just as many features BTW) will be faster too, so KDE will STILL be slow (comparatively).
Yes, but that's because Microsoft can do optimizations in the core OS.
>The "buy a faster system" arguement is total bullshit.
In fact, this is a pretty sane argument. Don't bother to say something is slow unless you have modern hardware. It just makes people laugh at you. It's like all of the 386 users who bitched at win95 being slow on their boxes. comeon, it's the natural evolution of software.
>If the applications are faster, you can do more complex things, no matter what kind of system you have.
That logic is total bullshit. There is absolutely no coorelation between faster applications being able to do more complex things.
>I buy a faster system to do more of the things I want to do, not feed some stupid desktop environment.
Heh, people have been getting faster computers in order to run the "newest versions of software" forever.
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
> Actually, KDE 3.x will be faster than 2.x, according to the developers anyway.
That was said between KDE 1.x and KDE 2.x too. It may have been true initially, but probably will not be true later on. I don't think KDE 3.3 will be faster than KDE 2.3.
> Also, its not GNOME vs KDE here. I am talking GTK+ vs KDE. If you don't run an actual GNOME desktop, GNOME apps whip KDE apps speedwise. Just go download Sylpheed and compare it to KMail. If you can't tell the difference, then you have infinate amounts of patience.
I've used both, they seem pretty similiar in speed. However, KDE apps do seem to start slower when not in the KDE environment. However, I notice no speed difference in the actually performance of the programs.
> There should be no corrolation between age and CPU usage, only between features and CPU usage. Win2K might be older, but it has just as many features while being faster.
Yes, because it has tighter integration with the core of the OS. You really can't beat that easily.
> That implies that the free software community cannot outcode Microsoft (which, I think, I something that they would rather not imply). Also, WinXP, while having more features than Win2K, is *faster* [cnet.com] than Win2K.
WinXP has *some* things that are faster than Win2k, but there are plenty of reviews out there that say that WinXP is actually slower than Win2k. I've noticed this myself. To be fair to WinXP, it adds things like being skinnable, which makes it naturally slower than Win2k.
> Why is it that the "evolution" of Microsoft software includes increases in speed while the "evolution" of GNOME and KDE don't?
Nope.. evolution of all software almost always goes down in speed. this is offset by faster computers. win3.1 > win95 > win98 > win2k > winXP in speed. Whatever Microsoft has in store for the future will be slower than winXP.
Re:my favorite new feature (Quicktime??)
on
KDE 2.2.2
·
· Score: 2
Some plugins do work in 2.2.1, but it was just not officially supported.
I've done it before, more than a year ago, and it felt snappy. And it was a 48mb machine (PowerComputing PowerTower Pro 200, which was a PowerPC 603e Macintosh clone). Note that it was KDE 1.9.x, which was KDE 2.0-alpha and beta. Not only that, but the computer had slow ram, and a pretty slow hd. Also, X wasn't accelerated. Even so, KDE felt more snappy than GNOME with Enlightenment.
It took forever to compile (about 2 days), but it worked. Unfortunatly, it broke within a few days:/, and so I used Blackbox for about a year, until I got a new box.
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
I think optimizations and such matter on old CPUs, but not on modern ones.
I'm using Debian GNU/Linux, which is optimizated for absolutly nothing (other than using objprelink in their KDE packages). Also, I am using a drive and chipset that is really buggy with DMA, so I leave it off (IBM DeskStar with a VIA KT133A). Both KDE and GNOME run pretty zippy on my box (1.2ghz athlon).
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
I've not noticed any of this on my computer, Qt and GTK seem to be the same speed, and GNOME and KDE compare pretty much in speed (except that Nautilus is slower than Konqi).
But then again, I have a modern computer (1.2ghz Athlon-C).
Realistically, KDE 3 and GNOME 2 will be slower than KDE 2.x and GNOME 1.x. Sorry, but this is simply evolution as CPU speed ramps up. However, I have noticed that Win2k is speedier on my box than either GNOME or KDE. However, Win2k is old. WinXP is not noticebly faster than either of the current versions of KDE or GNOME.
Uhh, the new Icon server has nothing to do with Konqueror's thumbnail slave, which, as of 2.2.x IS as fast as Xv's, and handles many more graphics file types, as well as other file formats such as text.
try using linux > 2.4.10
I had probs with konq and leaks before that
Re:This is turning into a VI or Emacs topic
on
KDE 3.0 Screenshots
·
· Score: 2
The main reason I switched from GNOME to KDE (back in KDE 2.1 and just when GNOME 1.4 came out), was that KDE has a much better architecture and API (and I've done both GNOME and KDE programming). Now, GNOME 2.0 may catchup quite a bit, but KDE is not standing still. It is a good to see two desktop environments competeting.
> WindowBlinds? Isn't that illegal? I think all their themes say you can't use them without WindowBlinds in their license agreements.
Possibly for those themes included with the base package, but I'm not sure since I've never used WindowBlinds or even downloaded their package. However, with third party themes, using that logic is shakey at best. Most of the third party themes don't even have any:
1). kind of license
2). disclaimers
I've encountered a few WindowBlinds themes which say "For use with WindowBlinds 2.x". This isn't much of a legal disclaimer tho.
Anyways, the format of windowblinds themes themselves, is much less complicated than they say in their website (they claim that they "invented" uis1, uis2, uis3, as languages). In fact, they are simply.ini files (rfc 822-like).
And I doubt that they would approach anything legally anyways. This doesn't really compete with WindowBlinds. If they wanted to make a closed source WindowBlinds for X11 for pay, I'm sure people wouldn't pay for shit like that.
> Not that we care about such things (:-) but the KDE project itself has to.
I understand the possible legal concerns, and that's why it's not in the base KDE distributions. Maybe the blackbox portions will eventually be, but probably not in KDE 3.0 (with the freeze and all).
Re:Bad screenshots for showing anti-aliasing
on
KDE 3.0 Screenshots
·
· Score: 2
i'd be something like:
match
any family == "mono"
edit
antialias = false;
I'm not sure if this works yet in Xft. The reason why you cannot use antialiased text and non-AA text at the same time is because with the current implementations, the calls to the conventional X11 non-AA text drawing functions and the Xft versions are different.
From what I heard about a year ago, the E developers decided to make E17 self-sufficient. That said, E17 developement has/seemed/ to slow down a lot, so I'm not sure what they said a year ago is still pertinant now.
> KDE, on the other hand, is always slow. Widgets just feel like they're moving through tar. Almost everything rubber-bands when resized. I think this might have a lot to do with Qt on Linux. While Qt on Windows performs well, it doesn't seem to on Linux. Most GTK+ apps can almost touch Windows in speed, but even simple KDE apps are far behind even complex Windows apps (ie. kmail is slower at most UI stuff than Word.
That's weird. The only complaint I could have with KDE with speed is that launching apps the first time is a bit slower (although this alleivaited with using objprelink and using the native KDE envionment). I'd say that speed of widgets in Qt and GTK+ are about the same.
Windows, however, I've had differing results. On some windows boxes (particlarily one win98 box I had), it is much faster than any toolkit on X. However, other Win98 installations are about the same speed. From my experience, win2k is about the same speed as win98 (if you turn the eye candy off), and winXP is a tad slower (but not noticebly).
Re:Bad screenshots for showing anti-aliasing
on
KDE 3.0 Screenshots
·
· Score: 2
Sure, if you want to run the terminal without AA'd fonts, just type in QT_XFT=0 konsole
I beleive, in KDE 3, there is a switch in konsole that you can use to turn AA off.
Slashdot Mirror
Swing was initially much slower than AWT. However, as optimizations were made, it became almost as fast as AWT. If you have used a modern java, you'd know this :)
> Gtk is more commonly used then any other brand. Sure it sucks, but it sucks less.
And gtk-- is barely used at all.
> I don't think that is really in the remit of a gui toolkit at all.
It's an application framework.
> QT has reimplemented all those things as a rather dodgy set of proprietry classes.
Dodgy? How do you figure? They are very high quality, and are actually more cross platform than many std:: classes are. Ever try to compile large non=Qt C++ code in HP/UX with quite broken compilers? I have, it's not pretty.
Besides, if you knew anything about Qt, you'd see that Qt3 has stl support.
> It looks like Gtk2 will use Unicode and Pango, thus potentially blowing away the competition, but as long as there's no stable version of Gtk2.
However, Gtk2's win32 port will likely remain a very unsupported port. While qt's win32 port is as important if not more important (because of commercial licenses), than their X11 port.
> The downside is that QT is slow,
No, in fact, quite the opposite is true. It'd be faster than solutions that simply wrap around native API calls.
It is like in the Java world between AWT (Java 1.0.x) and Swing (Java 1.2.x). AWT tried to simply wrap around the native toolkits. As a result, it was quite slow. Swing does it like Qt, and provided an API for drawing widgets, much like Qt does with QStyle.
> eat up memory space and disk access time.
I think they alleviated this by using QPixmapCache. It should be only a tad bit slower, if not the same speed as regular OSX apps. Either way, an user would not know the difference in speed.
> good choice for a large commercial project.
Nah, Qt itself is probably the best choice for a commercial project. I'd use wxWindows for free software that targets many platforms tho, and Qt for X11-only free software.
> wxPython
Yeah, wxPython's really nice.
> QT on the other hand has a very good abstraction of windowing system details.
:)
Yup, this is because Qt is not a gui-toolkit but rather an application framework. It provides classes that work equally on all platforms that Qt supports, saving the user from writing a bunch of #ifdefs for particular platforms. It works really well
> Note that your apps will look totally windowsy on win32, so your users will not be confused by their look.
Which Qt does as well. I find wxWindows too MFC-y too use tho, although it is quite a viable alternative to Qt, especially for open software on Windows.
However, If you want a high quality professional toolkit, stick with Qt. gtk--? no way, it's not in any good shape.
> And the KDE guys can't? They have the source to everything, it should be even easier!
;-)
I think ideally they should. However, I don't think that'd go over too well with the 'oh wait, that's not UNIX-y" group.
> Except that Win95 was slower because it had tons of new features. Win2K matches KDE feature for feature, but KDE is slower, even though it is running on a better kernel/display layer (yes, XFree86 is faster than GDI these days, with good drivers). Are you telling me that there's nothing wrong with that?
And a better display layer is not all that counts. KDE is currently hampered in various things that are not KDE's fault. First, and most major, is probably g++.
> If my 3D modeler is faster, I can work on more complex models before the system becomes too slow to be comfortably usable. If my display layer is faster, I can make more complex graphics at an acceptable frame-rate. If my desktop is faster, I can have more windows open and switch between them quicker. Even if I upgrade to new hardware, the faster system will STILL be better.
Ok, that IS true. However one has to consider that most things that provide great amounts of features slows down performance. There are, of course ways to get around this problem, like Microsoft does with integration.
> Under the Micro$haft regime. I thought OSS was supposed to be new and different! I honestly don't mind spending the cycles when I get features in return. But when I switched from Windows to Linux (which I did because I couldn't stand Windows anymore, even though it is a higher-quality OS)
Under any regime, this is true. It has always been true. This has nothing to do whatsoever with OSS. Computers get defunct. Deal with it.
> I lost features *and* speed.
Modern KDE versions are quite comparable with Windows in terms of speed on modern machines.
> How you explain the fact that ROX is as fast as Explorer?
.rc files. I beleive MacOSX also does it in special files in bundles.
Because it does much less than Explorer does, and can do. Remember that the internal infrastructure can slow down things, at the expense of getting more stuff done (or being extensible, which ROX isn't).
> XFree 4.x is *not* slower than Windows/GDI. In fact, for many things, like image blitting, its as fast as DirectX.
Yes, that's true. Then again, I never said it wasn't.
>Also, the integration thing is overblown. Most Windows apps run quickly, and you can't tell me that they all have tight integration with the core OS!
Ah, yes, but the underlying libs that "most Windows apps" depend on do. Much of the win32 api is kept in kernel space rather than user space. This is similiar to classic MacOS as well, with all Mac toolbox functions kept in the core OS. In the case of winXX, this includes GDI, parts of COM,
> Its just that Linux desktops have too many performance sapping paradigms. Take, for example, XUL.
Mozilla is quite a bit faster on Windows than Linux. It's as fast as explorer in turbo mode, for example.
> Parsing a text file to display a GUI? Are you insane!
This is done in a variety of environments. It's nothing new. KDE does it with XML-GUI. Gnome does it with libglade. Windows does it with
> Then the use of CORBA instead of something nice and fast like COM.
Again, power versus speed.
> There are lots of KDE/GNOME features that make computer nerds cream, but do nothing except sap the performance of users' machines.
Both run quite zippy enough here.
> I don't think so. Most of the reviews I've seen that say XP is slower are pased on the Release Candidates. XP sped up a *lot* between the those and the gold release.
Out of personal information, I can tell you that XP in fact, IS much slower than win2k on the same machine. It is certainly in mine!
> But KDE 2.2.x is *faster* than KDE 2.0.x! That's the KDE develoment model. Big features, then incremental quality improvements.
Yes, but that is minor versions. If you take major versions into account, you see that this is not the case. For example, KDE 2.x's speed Its really not like that all the time. There are tons of programs that don't keep getting slower. Photoshop, for example, has been pretty much the same since 4.x.
Almost everyone I know that uses Photoshop can tell you that Photoshop was much faster in certain tasks than Photoshop 5.x and 6.x. That's why there are still many Photoshop 4.x users left.
> 3D Studio keeps getting faster. KDE 2.2.x keeps getting faster. It does slow down over time, but the stuff you see in the Linux world is *much* more dramatic than the same in the Windows world.
Yes, but say a new version of 3d studio came out with 25% new features. It'd be certainly slower. However, people would move on to faster comps.
> But then Windows (which has just as many features BTW) will be faster too, so KDE will STILL be slow (comparatively).
Yes, but that's because Microsoft can do optimizations in the core OS.
>The "buy a faster system" arguement is total bullshit.
In fact, this is a pretty sane argument. Don't bother to say something is slow unless you have modern hardware. It just makes people laugh at you. It's like all of the 386 users who bitched at win95 being slow on their boxes. comeon, it's the natural evolution of software.
>If the applications are faster, you can do more complex things, no matter what kind of system you have.
That logic is total bullshit. There is absolutely no coorelation between faster applications being able to do more complex things.
>I buy a faster system to do more of the things I want to do, not feed some stupid desktop environment.
Heh, people have been getting faster computers in order to run the "newest versions of software" forever.
> Actually, KDE 3.x will be faster than 2.x, according to the developers anyway.
That was said between KDE 1.x and KDE 2.x too. It may have been true initially, but probably will not be true later on. I don't think KDE 3.3 will be faster than KDE 2.3.
> Also, its not GNOME vs KDE here. I am talking GTK+ vs KDE. If you don't run an actual GNOME desktop, GNOME apps whip KDE apps speedwise. Just go download Sylpheed and compare it to KMail. If you can't tell the difference, then you have infinate amounts of patience.
I've used both, they seem pretty similiar in speed. However, KDE apps do seem to start slower when not in the KDE environment. However, I notice no speed difference in the actually performance of the programs.
> There should be no corrolation between age and CPU usage, only between features and CPU usage. Win2K might be older, but it has just as many features while being faster.
Yes, because it has tighter integration with the core of the OS. You really can't beat that easily.
> That implies that the free software community cannot outcode Microsoft (which, I think, I something that they would rather not imply). Also, WinXP, while having more features than Win2K, is *faster* [cnet.com] than Win2K.
WinXP has *some* things that are faster than Win2k, but there are plenty of reviews out there that say that WinXP is actually slower than Win2k. I've noticed this myself. To be fair to WinXP, it adds things like being skinnable, which makes it naturally slower than Win2k.
> Why is it that the "evolution" of Microsoft software includes increases in speed while the "evolution" of GNOME and KDE don't?
Nope.. evolution of all software almost always goes down in speed. this is offset by faster computers. win3.1 > win95 > win98 > win2k > winXP in speed. Whatever Microsoft has in store for the future will be slower than winXP.
Some plugins do work in 2.2.1, but it was just not officially supported.
I've done it before, more than a year ago, and it felt snappy. And it was a 48mb machine (PowerComputing PowerTower Pro 200, which was a PowerPC 603e Macintosh clone). Note that it was KDE 1.9.x, which was KDE 2.0-alpha and beta. Not only that, but the computer had slow ram, and a pretty slow hd. Also, X wasn't accelerated. Even so, KDE felt more snappy than GNOME with Enlightenment.
:/, and so I used Blackbox for about a year, until I got a new box.
It took forever to compile (about 2 days), but it worked. Unfortunatly, it broke within a few days
I think optimizations and such matter on old CPUs, but not on modern ones.
I'm using Debian GNU/Linux, which is optimizated for absolutly nothing (other than using objprelink in their KDE packages). Also, I am using a drive and chipset that is really buggy with DMA, so I leave it off (IBM DeskStar with a VIA KT133A). Both KDE and GNOME run pretty zippy on my box (1.2ghz athlon).
I've not noticed any of this on my computer, Qt and GTK seem to be the same speed, and GNOME and KDE compare pretty much in speed (except that Nautilus is slower than Konqi).
But then again, I have a modern computer (1.2ghz Athlon-C).
Realistically, KDE 3 and GNOME 2 will be slower than KDE 2.x and GNOME 1.x. Sorry, but this is simply evolution as CPU speed ramps up. However, I have noticed that Win2k is speedier on my box than either GNOME or KDE. However, Win2k is old. WinXP is not noticebly faster than either of the current versions of KDE or GNOME.
Uhh, the new Icon server has nothing to do with Konqueror's thumbnail slave, which, as of 2.2.x IS as fast as Xv's, and handles many more graphics file types, as well as other file formats such as text.
try using linux > 2.4.10
I had probs with konq and leaks before that
The main reason I switched from GNOME to KDE (back in KDE 2.1 and just when GNOME 1.4 came out), was that KDE has a much better architecture and API (and I've done both GNOME and KDE programming). Now, GNOME 2.0 may catchup quite a bit, but KDE is not standing still. It is a good to see two desktop environments competeting.
Follow the anon coward's advice. It works.
Take a look at this for an example.
> WindowBlinds? Isn't that illegal? I think all their themes say you can't use them without WindowBlinds in their license agreements.
.ini files (rfc 822-like).
:-) but the KDE project itself has to.
Possibly for those themes included with the base package, but I'm not sure since I've never used WindowBlinds or even downloaded their package. However, with third party themes, using that logic is shakey at best. Most of the third party themes don't even have any:
1). kind of license
2). disclaimers
I've encountered a few WindowBlinds themes which say "For use with WindowBlinds 2.x". This isn't much of a legal disclaimer tho.
Anyways, the format of windowblinds themes themselves, is much less complicated than they say in their website (they claim that they "invented" uis1, uis2, uis3, as languages). In fact, they are simply
And I doubt that they would approach anything legally anyways. This doesn't really compete with WindowBlinds. If they wanted to make a closed source WindowBlinds for X11 for pay, I'm sure people wouldn't pay for shit like that.
> Not that we care about such things (
I understand the possible legal concerns, and that's why it's not in the base KDE distributions. Maybe the blackbox portions will eventually be, but probably not in KDE 3.0 (with the freeze and all).
i'd be something like:
match
any family == "mono"
edit
antialias = false;
I'm not sure if this works yet in Xft. The reason why you cannot use antialiased text and non-AA text at the same time is because with the current implementations, the calls to the conventional X11 non-AA text drawing functions and the Xft versions are different.
From what I heard about a year ago, the E developers decided to make E17 self-sufficient. That said, E17 developement has /seemed/ to slow down a lot, so I'm not sure what they said a year ago is still pertinant now.
> KDE, on the other hand, is always slow. Widgets just feel like they're moving through tar. Almost everything rubber-bands when resized. I think this might have a lot to do with Qt on Linux. While Qt on Windows performs well, it doesn't seem to on Linux. Most GTK+ apps can almost touch Windows in speed, but even simple KDE apps are far behind even complex Windows apps (ie. kmail is slower at most UI stuff than Word.
That's weird. The only complaint I could have with KDE with speed is that launching apps the first time is a bit slower (although this alleivaited with using objprelink and using the native KDE envionment). I'd say that speed of widgets in Qt and GTK+ are about the same.
Windows, however, I've had differing results. On some windows boxes (particlarily one win98 box I had), it is much faster than any toolkit on X. However, other Win98 installations are about the same speed. From my experience, win2k is about the same speed as win98 (if you turn the eye candy off), and winXP is a tad slower (but not noticebly).
Sure, if you want to run the terminal without AA'd fonts, just type in QT_XFT=0 konsole
I beleive, in KDE 3, there is a switch in konsole that you can use to turn AA off.