Well, with each major version QT has been given more and more ability to theme itself. So, given that the QT styling system has changed for QT 3, the KDE styling system is going to have to change as well -- but hopefully for the better! Their main aim is to have a coherent way to theme all the different aspects of the desktop (at the moment you have to insert things in random directories to theme the startup splash screen, for example).
The ideal would be to have a theming system that, as far as possible, was compatible between Gnome and KDE (plus anything else that wanted to join in) -- this would certainly be possible for pixmap window/widget themes, colour schemes, background pictures, and non-SVG icons.
It's a pity, because there are some very nice things in GNOME development.
One is Glade: because it's so mind-numbingly boring to hard code the UI, most people use GLADE, and as a result the UI is abstracted into XML files, which can be altered to change the UI without recompiling... which is nice.
Another is Nautilus. For all the critics (THIS took $30 million?!), and the bad experiences running the bloated hippo that was Nautilus 1.0.0, it's now quite a nice file manager, although still very lacking in depth (do they still not have a.tar.gz reading component?).
Another is the attempt to actually use CORBA. Of course, this is also a problem: I don't know of any system which has actually used CORBA successfully that hasn't come in over time and over budget.
I need GNOME to do well, because I use KDE, and the two environments feed off each other very well: KDE developers are more concerned with features than prettiness, so they pick up some graphical ideas from GNOME. Of course, this could also be solved by some of the GNOME graphical artists moving over and helping KDE (there's a good opportunity in the KDE 2 to KDE 3 transition to completely rework the KDE theming system).
Re:i'm going to suffer for this but...
on
KDE Wins 3 awards
·
· Score: 2
Yes, he is telling you that they couldn't put it in the same place as the rest of the desktop settings --- because it isn't a desktop setting.
The resolution is not under control of KDE, but under the control of the particular X server you are using. They could perhaps write a configuration module for XFree86, as this is just about the only one used on free operating systems... but until now KDE have resisted writing modules for distro specific components: they consider it the job of the distribution to sort that out.
If it isn't, you should easily be able to get XFCE to compile on your machine, as long as you can get GTK+ to compile. It's not a complete CDE replacement, but it's good enough.
GCP has created a tuned version of the RC2 encoder that includes a competitor to the LAME archival quality settings (to use it, set the bitrate to 999 in his special version), as well as tuned 128k and 350k versions. This tuned setting is nominally 160k, tends to average 170k or so on the music I encode... and I've not been able to find a single piece of music that isn't transparent (ignoring samples such as 'fatboy' which *all* encoders screw up).
The level of insight offered in this speech is outstanding
I agree -- the speech is extraordinary -- one of the best pieces of political argument I have read for a long time (however, do I only think it so good because I agree with all his arguments?). But don't think that it was an unmitigated age of enlightenment: I promise you that there was a fair amount of posturing, rhetoric and lying even back then:)
Some nice themes on your site. Why don't you add them to
KDE-Look
(the replacement for the sadly defunct kde.themes.org)? If you don't have the time I can add them for you this weekend...
Or try the QNiX theme -- for those of us that like our desktop to be usable, rather than a weird graphic designers wet dream:)
On a seperate point, I'd really like it if Gnome 2 and KDE 3 could use a common standard for *pixmap* window and widget styles... (code styles couldn't be interoperable, of course).
I think you need to take some more of the pills the kind doctor gave you.
I know you're not really interested, but to answer some points you raise:
1) KDE compiles and works on Solaris fine (I've done it myself)
2) KDE isn't Windows like... it's more like OS/2 with bits of Windows, Mac and RISC/OS
To agree with you:
1) Starting KDE applications is too slow. This isn't KDE's fault, it's C++ & the library system -- people are looking into object prelinking to improve the startup times dramatically.
2) Both KDE and Gnome are great projects. I'm looking forward to Gnome 2 eagerly (I'm also looking forward to Enlightenment 17... if it ever gets released).
Yes, it's strange that wxWindows has been ignored by the wider Unix community... from what little I've seen of it (mainly in relation to wxPython, the Python bindings for it) I've been very impressed -- particularly compared with Tcl/TK (or tkinter, the 'standard' Python GUI system).
There is some nice software like Audacity and Roxfiler using it, but nothing like the amount that *should* be.
I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.
Although you are stupid and misinformed (no closed source software anywhere in KDE), with your attitute, you should prefer KDE to Gnome. QT is GPLed, which means that if you want to write commercial applications using it, you have to pay Trolltech for an alternative license. In contrast, the whole of Gnome is no better than LGPLed, which means there is nothing stopping commercial software.
KDE is therefore the better choice for those like Richard Stallman that believe that all software should be free.
for about 35% compression, which just isn't quite enough for it to be worthwhile for me.
Yes, depending on the type of music you listen to, you'll get compression rates from about 50-25%. The difference between the best and the average lossless compressors is only about 2.5%... so if you were expecting a magic bullet for archiving your CDs, lossless compression isn't it:).
Stupid question, but how much do the vorbis encoder and the lame encoder have in common?
Very little. It's possible that some of the perceptual models developed by the LAME people can be used by the Vorbis coders (such as the new ATH models), but the actual algorithms are fairly different (mainly because MP3 splits the input into many seperate bands, and Vorbis doesn't).
This is interesting -- I really wish you knew what version of Vorbis you were testing, though. Given that you did the test recently, it'll either be beta4 or RC2.
We already know that RC2 can be improved -- RC3 will be out soon and it would be wonderful to re-run this test with it...
On your other point, I believe there are already MP3 decoders such as the MAD decoder that dither to 16 bits rather than truncating.
Of course, the Macintosh is a whole seperate world...
64k *is* low bitrate (you can't get that low with MP3 without either resampling the input or having the output sound truly terrible). The lowest that beta4 would go was 112k.
To go lower with Vorbis you'll have to resample the input (it's not currently tuned for sample rates other than 44.1/48KHz, but it will work). In Linux this is easily done with something like (from memory)
The '-b 64' specifies the bitrate you would get if you were giving it CD quality (44KHz) input. In reality, it just specifies a set of noise masking, channel coupling, and low passing switches... you'll probably get around 40k with it.
Sadly, this often isn't valid for quite a few reasons.
Quite often, encoders will use very different procedures to encode a low bitrates than they would use to encode at high bitrates. They will probably use a hearing model (which models the ATH - absolute threshold of hearing) which is less demanding, for example. They may even automatically low pass the music, or resample it to a lower bitrate.
For example, Ogg Vorbis has different methods of channel coupling. At very high bitrates, no stereo information is lost. At medium bitrates, no stereo information is lost for the sounds we are most sensitive to, but for others the phasing is quantisised. The degree of compression determines the range of lossless coupling, and also the amount of quantisisation -- and each may have its own distinctive artifacts.
MP3 can't encode stereo 44kHz (CD quality) sound at 48kp/s without sounding truely terrible. If you try with LAME, you will find that it automatically resamples, and uses one of the 'extensions' to the official MP3 specification which encode better at low bitrates by resampling the sound.
Like the sound of cymbals, acoustic guitar, very low frequency instruments don't get reproduced correctly on MP3s compared to Vorbis... I used Bladenc
Well, there's your problem. If you're going to test MP3 vs Vorbis, at least use a decent MP3 encoder (LAME is the benchmark free encoder). You might want to use the most recent version of the Vorbis libraries, as well.
If you like RC2 Ogg, then you'll like RC3 even better. In particular, you might have noticed that at lower bitrates Ogg doesn't do quite the right thing with high pitched transients -- RC3 has much improved noise masking & a higher lowpass.
The benchmark for Ogg currently is LAME -- it has been tuned so much in the last few years that, once Ogg can beat or equal it at *all* bitrates, you'll start seeing a lot more of the militant archival-quality encoding people using it. At the moment most of the concentration is going into improving performance at the low end... but this improves performance at the high end as well as a by-product.
Slashdot Mirror
QT's file dialog is a Windows copy, but KDEs isn't -- in fact it's the most usable file dialog I've ever used.
Well, with each major version QT has been given more and more ability to theme itself. So, given that the QT styling system has changed for QT 3, the KDE styling system is going to have to change as well -- but hopefully for the better! Their main aim is to have a coherent way to theme all the different aspects of the desktop (at the moment you have to insert things in random directories to theme the startup splash screen, for example).
The ideal would be to have a theming system that, as far as possible, was compatible between Gnome and KDE (plus anything else that wanted to join in) -- this would certainly be possible for pixmap window/widget themes, colour schemes, background pictures, and non-SVG icons.
yes... like GNOME 2's new file open dialog, which is an exact copy of the Windows 2000 one... or their object model, which is an exact copy of DCOM...
(if you want something not like Windows, then ignore both KDE and Gnome, and use Windowmaker, or XFCE, or Ion, or FVWM)
It's a pity, because there are some very nice things in GNOME development.
.tar.gz reading component?).
One is Glade: because it's so mind-numbingly boring to hard code the UI, most people use GLADE, and as a result the UI is abstracted into XML files, which can be altered to change the UI without recompiling... which is nice.
Another is Nautilus. For all the critics (THIS took $30 million?!), and the bad experiences running the bloated hippo that was Nautilus 1.0.0, it's now quite a nice file manager, although still very lacking in depth (do they still not have a
Another is the attempt to actually use CORBA. Of course, this is also a problem: I don't know of any system which has actually used CORBA successfully that hasn't come in over time and over budget.
I need GNOME to do well, because I use KDE, and the two environments feed off each other very well: KDE developers are more concerned with features than prettiness, so they pick up some graphical ideas from GNOME. Of course, this could also be solved by some of the GNOME graphical artists moving over and helping KDE (there's a good opportunity in the KDE 2 to KDE 3 transition to completely rework the KDE theming system).
Yes, he is telling you that they couldn't put it in the same place as the rest of the desktop settings --- because it isn't a desktop setting.
The resolution is not under control of KDE, but under the control of the particular X server you are using. They could perhaps write a configuration module for XFree86, as this is just about the only one used on free operating systems... but until now KDE have resisted writing modules for distro specific components: they consider it the job of the distribution to sort that out.
but you can't use it to share files
Not quite true -- it will share whatever is in the download directory.
Get MPlayer... it plays DivX movies very well (on x86 machines).
If it isn't, you should easily be able to get XFCE to compile on your machine, as long as you can get GTK+ to compile. It's not a complete CDE replacement, but it's good enough.
GCP has created a tuned version of the RC2 encoder that includes a competitor to the LAME archival quality settings (to use it, set the bitrate to 999 in his special version), as well as tuned 128k and 350k versions. This tuned setting is nominally 160k, tends to average 170k or so on the music I encode... and I've not been able to find a single piece of music that isn't transparent (ignoring samples such as 'fatboy' which *all* encoders screw up).
True, but initally Miguel was working on KDE, and only agitated to create GNOME once he realised that they were going to stick with QT.
The level of insight offered in this speech is outstanding
:)
I agree -- the speech is extraordinary -- one of the best pieces of political argument I have read for a long time (however, do I only think it so good because I agree with all his arguments?). But don't think that it was an unmitigated age of enlightenment: I promise you that there was a fair amount of posturing, rhetoric and lying even back then
Some nice themes on your site. Why don't you add them to KDE-Look (the replacement for the sadly defunct kde.themes.org)? If you don't have the time I can add them for you this weekend...
Yes, I noticed that about 10 minutes after posting... but what can you do? :)
Or try the QNiX theme -- for those of us that like our desktop to be usable, rather than a weird graphic designers wet dream :)
On a seperate point, I'd really like it if Gnome 2 and KDE 3 could use a common standard for *pixmap* window and widget styles... (code styles couldn't be interoperable, of course).
I think you need to take some more of the pills the kind doctor gave you.
I know you're not really interested, but to answer some points you raise:
1) KDE compiles and works on Solaris fine (I've done it myself)
2) KDE isn't Windows like... it's more like OS/2 with bits of Windows, Mac and RISC/OS
To agree with you:
1) Starting KDE applications is too slow. This isn't KDE's fault, it's C++ & the library system -- people are looking into object prelinking to improve the startup times dramatically.
2) Both KDE and Gnome are great projects. I'm looking forward to Gnome 2 eagerly (I'm also looking forward to Enlightenment 17... if it ever gets released).
Yes, it's strange that wxWindows has been ignored by the wider Unix community... from what little I've seen of it (mainly in relation to wxPython, the Python bindings for it) I've been very impressed -- particularly compared with Tcl/TK (or tkinter, the 'standard' Python GUI system).
There is some nice software like Audacity and Roxfiler using it, but nothing like the amount that *should* be.
I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.
Although you are stupid and misinformed (no closed source software anywhere in KDE), with your attitute, you should prefer KDE to Gnome. QT is GPLed, which means that if you want to write commercial applications using it, you have to pay Trolltech for an alternative license. In contrast, the whole of Gnome is no better than LGPLed, which means there is nothing stopping commercial software.
KDE is therefore the better choice for those like Richard Stallman that believe that all software should be free.
for about 35% compression, which just isn't quite enough for it to be worthwhile for me.
:).
Yes, depending on the type of music you listen to, you'll get compression rates from about 50-25%. The difference between the best and the average lossless compressors is only about 2.5%... so if you were expecting a magic bullet for archiving your CDs, lossless compression isn't it
Stupid question, but how much do the vorbis encoder and the lame encoder have in common?
Very little. It's possible that some of the perceptual models developed by the LAME people can be used by the Vorbis coders (such as the new ATH models), but the actual algorithms are fairly different (mainly because MP3 splits the input into many seperate bands, and Vorbis doesn't).
This is interesting -- I really wish you knew what version of Vorbis you were testing, though. Given that you did the test recently, it'll either be beta4 or RC2.
We already know that RC2 can be improved -- RC3 will be out soon and it would be wonderful to re-run this test with it...
On your other point, I believe there are already MP3 decoders such as the MAD decoder that dither to 16 bits rather than truncating.
Of course, the Macintosh is a whole seperate world...
64k *is* low bitrate (you can't get that low with MP3 without either resampling the input or having the output sound truly terrible). The lowest that beta4 would go was 112k.
To go lower with Vorbis you'll have to resample the input (it's not currently tuned for sample rates other than 44.1/48KHz, but it will work). In Linux this is easily done with something like (from memory)
sox input.wav -r 22050 -t wav - | oggenc -b 64 -o output.ogg -
The '-b 64' specifies the bitrate you would get if you were giving it CD quality (44KHz) input. In reality, it just specifies a set of noise masking, channel coupling, and low passing switches... you'll probably get around 40k with it.
Sadly, this often isn't valid for quite a few reasons.
Quite often, encoders will use very different procedures to encode a low bitrates than they would use to encode at high bitrates. They will probably use a hearing model (which models the ATH - absolute threshold of hearing) which is less demanding, for example. They may even automatically low pass the music, or resample it to a lower bitrate.
For example, Ogg Vorbis has different methods of channel coupling. At very high bitrates, no stereo information is lost. At medium bitrates, no stereo information is lost for the sounds we are most sensitive to, but for others the phasing is quantisised. The degree of compression determines the range of lossless coupling, and also the amount of quantisisation -- and each may have its own distinctive artifacts.
MP3 can't encode stereo 44kHz (CD quality) sound at 48kp/s without sounding truely terrible. If you try with LAME, you will find that it automatically resamples, and uses one of the 'extensions' to the official MP3 specification which encode better at low bitrates by resampling the sound.
Like the sound of cymbals, acoustic guitar, very low frequency instruments don't get reproduced correctly on MP3s compared to Vorbis ... I used Bladenc
Well, there's your problem. If you're going to test MP3 vs Vorbis, at least use a decent MP3 encoder (LAME is the benchmark free encoder). You might want to use the most recent version of the Vorbis libraries, as well.
If you like RC2 Ogg, then you'll like RC3 even better. In particular, you might have noticed that at lower bitrates Ogg doesn't do quite the right thing with high pitched transients -- RC3 has much improved noise masking & a higher lowpass.
The benchmark for Ogg currently is LAME -- it has been tuned so much in the last few years that, once Ogg can beat or equal it at *all* bitrates, you'll start seeing a lot more of the militant archival-quality encoding people using it. At the moment most of the concentration is going into improving performance at the low end... but this improves performance at the high end as well as a by-product.
Shorten has licensing problems, as well as problems with certain types of usage such as streaming.
Stop using Shorten, and switch to FLAC instead.