OSNews.com: I'm Hammering
Tuesday, 12 November 2002 | Numanee
Corey Taylor has written an article for OSNews.com called "KDE 3.1 RC2: I'm Hammering". He has some font and icon issues with Red Hat 8.0, but overall seems happy. It's good to see people actually appreciating the new eyecandy and all the hard work by the artist team and developers. A wider range of opinions can be seen from their readers -- one even provides some nice screenshots of Liquid and Keramik. Sit tight for KDE 3.1, which has been delayed in favour of more RCs.
Are you hammering on KDE 3.1 RC2 as well? Use the reply button below and let the KDE developers know what you think of it!
Comments:
I'm hammering... - Luke-Jr - 2002-11-12
See, I'm hammering too :)<p> <a href="http://bugs.kde.org/buglist.cgi?emailreporter1=1&emailtype1=exact&email1=Luke7Jr%40yahoo.com">bug list</a>
Crystal icons look bad without Render extension - kesha - 2002-11-12
The author of the article complained about the aliased fonts and jagged edges around his icons. He was unable to build the Qt library with support for Xft, which I believe to be the root of the aliased/jagged appearence of fonts/icons that he was seeing. <p> Don't you see the problem here? All that fancy alpha transparency just does not work without the Render extension on the X server. This means that KDE 3.* + icons with alpha will look like crap on Linux boxes still running the old XFree86 3.x.y X server, as well as the commercial X servers on Solaris and Irix which will likely not support the Render extension in the near future. <p> I think KDE would do itself a better service by shipping with less eye-candy by default (the old hicolor icons were fine without the Render extension). <p> Paul. <p> PS. I am running KDE 3.0.1 on Solaris 2.6, and icons utilising the alpha channel do look like crap.
Re: Crystal icons look bad without Render extension - W.K. Havinga - 2002-11-12
On first startup, you can choose from different themes/styles (one of which is the Keramik theme) - at least last time I checked, this was the case. So I think it's still perfectly possible to select the 'default highcolor' scheme if you find the 'eye-candy galore' themes to look like total crap on your display. Now about what Red Hat 8.0 installs for a default...well yes...let's not go there shall we? If you rm -rf ~/.kde I'm pretty sure you'll get a 'setup wizard' the first time you start KDE again, which will ask you which style you want to use, and how many CPU-cycle-consuming-but-nice-looking features you want or don't want.
Re: Crystal icons look bad without Render extension - kesha - 2002-11-12
I am sorry about the "crap" comment. I know I am perfectly capable of installing the hicolor icons myself. That really is not solving the underlying problem in the long term. Eventually the hicolor icons will become obsolete as more features are added to KDE. There will be a discrepancy between the number of icons used in the default icon theme, and the number of icons in the hicolor theme, which means I will see "question-mark" or "kde-gear" default icons for things which do not have a corresponding icon in the hicolor theme. A better solution is to implement a software fallback rendering engine that could perform the same functions that Render performs, but on X servers that do not support the Render extension. However, this is probably too-much work for too-little benefit to the wider audience (the Linux + XFree86 4.x.y). After all, how many KDE Solaris users are there? Maybe I should stop being so selfish and let you enjoy the Crystal/Keramik eye-candy by default (provided you have the Render extension ;) Paul.
Re: Crystal icons look bad without Render extension - meikee - 2002-11-12
Well, there was a software fallback on KDE 2.2.2 (kalphapainter.cpp). But as far as I know it was removed after Qt started to support XRender. There is a thread about this on kde-devel or kde-core-devel. I tried to port kalphapainter to KDE 3 but I'm no graphics expert. It just didn't work. And some words to the hicolor theme: Of course I can (must) switch to it, but it doesn't look good either, without alpha blending. Hicolor on KDE 3 looks worse than on KDE 2.2.2. I wrote some mails about this to kde-devel and kde-solaris, but got no response. So it seems that there are indeed not very many non-Xfree users of KDE.
Re: Crystal icons look bad without Render extension - AC - 2002-11-12
I believe that Keith Packard's plan for newer versions of the render library includes just what you wanted... a fallback for servers without the extension. So everyone will be able to benefit, not just KDE users.
Re: Crystal icons look bad without Render extension - kesha - 2002-11-12
As far as I know, Keith Packards newer Render library is still for XFree86 4.x.y only. All it will do is provide software Render fallback for cards which do not have hardware acceleration for Render. Render will not be a stand-alone software-rendering library (to my knowledge), because in order to provide accelerated Render functionality it will have to be a part of the XFree86 X server (an X server extension). Which means that this will benefit users with older/weaker graphics cards, who are running XFree86 4.x.y, but it will do nothing for people running XFree86 3.x.y, nor for commercial X servers on SUN and SGI. Paul.
Why on earth would KDE wait for Sun and SGI? - Moritz Moeller-Herrmann - 2002-11-12
People like you can always choose the high color icons if you insit on using commercial closed source software with less abilities than XFree86. Also, I don't think Sun can be called a friend of KDE.
Re: Why on earth would KDE wait for Sun and SGI? - Rodolfo Conde Mtz. - 2002-11-12
Yeah !!! they are a friend....but of GNOME....not KDE.....
Re: Why on earth would KDE wait for Sun and SGI? - asf - 2002-11-12
.. And the fact that XFree86 is the dominant implementation of X11 now, especially in the open source world (read: the world that encomposses KDE)
Re: Crystal icons look bad without Render extension - thefrog - 2002-11-12
Hmm, does something changed to Solaris 2.8? I'm running it with the actual kde31-rc2 and have now problems with alphablending. It was ugly with the kde 3.0.x series, but it seems to be gone now. I switched back to the classic icons because crystal looks to me a bit, hmm let's say "psychedelic" -:)) One things I'm still working on is that qt-copy-3.1.0-rc3 does not compile completely. The libs are fine, but qtdesigner, especially libeditor.so, is breaking -:((
Re: Crystal icons look bad without Render extension - Peter - 2002-11-12
Did you try a 'make clean'?
Re: Crystal icons look bad without Render extensio - mefesto78 - 2002-11-13
but he also said that he is running RedHat 8.0, which comes with Xfree86 4.2.
Yep - Moo - 2002-11-12
RC2 is great! Its just a sin that Liquid isn't the default theme. That screenshot you link to doesnt show the stipples, though, which really fill out the plain windows. Other than that, I looooove my KDE :)
Re: Yep - socialEcologist - 2002-11-12
kde is great. That's right, it the best of the best kde release I have ever compiled. KDE is really a stable, rich, nice environment for the linux desktop. kde team did a great job! socialEcologist PS 1: yes, I think stripples are better than flat frame backgrounds PS 2: don't forget your --disable-debug --enable-final flag to compile a fast kde (with gcc3.2)
I'm definitly HAMMERING !!! :) - Rodolfo Conde Mtz. - 2002-11-12
KDE 3.1 really rocks.....tons of new features and many improvements.....its not just eyecandy...its really a GOOD software worth it......and BTW congratulations to the KOffice team....i couldnt even install OOo 1.0.1 in linux, and with KOffice aside from some crashes and some weird things in KWord and the interaction with KFormula, with some playing im been able to write really professional documents, matematical reports and all without me knowing a single LaTeX command, with the AA fonts, freetype and all my fonts....really COOL :)....and the UI of KFormula is more user friendly that the formula component of OOo (tested on Windowz) i hope soon the KOffice team has working filters for all the OOo formats... Great job to everyone !!! Keep it up !!!!! And remember everyone...Linus uses KDE...uses KWord...uses KPresenter :)...... Cheers....
Noatun on RedHat 8.0 - Ahmed - 2002-11-12
where is my mp3???noatun says that it supports mp3 but redhat says that they removed this support... :(.i have xmms now palying mp3 after installing a library but i want noatun.i really like noatun and its full integration with KDE.is there any way to play mp3 some how on noatun???if yes,mail me
I have the same prolem - Rimmer - 2002-11-13
Of course, with the number of complaints I've read about noatun maybe this is a good thing.
Re: I have the same prolem - ac - 2002-11-13
Red Hat is to blame...
Re: I have the same prolem - ROBBY - 2003-03-31
i cant send aan IM
Re: I have the same prolem - ROBBY - 2003-03-31
i cant send aan IM
Re: I have the same prolem - bharat - 2004-12-11
i have a problem with attachment and i have formated my pc 4 time but the problem is same pls solve this problem and one thing net is ok every sites is open but no file attache so i dont send any document ok thx
Re: Noatun on RedHat 8.0 - Neil Stevens - 2002-11-13
Well, Red Hat, having applied for its own software patents, is honoring other peoples' software patents. If you want mp3, then you need to stop using Red Hat, and tell others to do the same.
Re: Noatun on RedHat 8.0 - Ward Schmit - 2003-04-28
Same problem. But there must me a solution for it, isn't it? I tried to install a newer Noatun from KDE.org but it doesn't work neither.
Re: Noatun on RedHat 8.0 - padreTony - 2003-10-14
i believe in open-source and i'm not agree with the redhat software patents question. software isn't of redhat, so they coudn't invite us to use our linux box as they think we should. everyone likes play his favourites mp3s so why shoudn't? well, redhat encourage not more mp3 but "unfortunatelly" xmms isn't of redhat, and that's the solution: there's an xmms plug-in for mp3 and it name is xmms-mpg123-1.2.7.21.i386.rpm. you could find it on google very fast, i use redhat9 and works fine. why should we use redhat and xmms and not redhat and xmms with plug-in?
Why so many RC's ? - NewMandrakeUser - 2002-11-12
Dear friends, Let me respectfully suggest something. Why not kill all the obvious bugs during the betas, make just one release candidate, give time to the interested distros to package it (as they do with the betas), check for showstoppers, fix them if any, and then either rename RC as final or make the final release. It occurs to me that this way: 1) Less effort would go in release related stuff (as opposed to the effort of releasing / coordinating several RC's) 2) More people would test the RC After all, a release candidate is exactly this: a version that looks finished, and that will in principle become the final release. If the idea is not to release binaries of the RC to avoid mixing up packaging errors with code bugs, the RC can be released src only. Either way KDE is fantastic, and the developers/translators/etc., the whole team is making a damn great job. I just though I should post just one more opinion at the hectic bazaar, in case it helps :-)
Re: Why so many RC's ? - thefrog - 2002-11-12
For this release I have really the impression that the turnaround times are really short. I finished compilation for rc2 on sunday, monday rc3 comes out ... So what now? Testing rc2 or compiling rc3? Can't we slow down kde speed a little bit?
Re: Why so many RC's ? - Anonymous - 2002-11-12
> Can't we slow down kde speed a little bit? No, these are RCs and not several weeks living Betas with announcements and binary packages distribution.
Re: Why so many RC's ? - Marc Mutz - 2002-11-12
> After all, a release candidate is exactly this: a version that looks finished, and that will in > principle become the final release. If the idea is not to release binaries of the RC to avoid > mixing up packaging errors with code bugs, the RC can be released src only. Well, that's what KDE 3.1 RC's all were. It's just that there is a major showstopper left: No Qt 3.1-final ;-) Marc
Re: Why so many RC's ? - NewMandrakeUser - 2002-11-13
> > principle become the final release. If the idea is not to release binaries of the RC to avoid > > mixing up packaging errors with code bugs, the RC can be released src only. > > Well, that's what KDE 3.1 RC's all were. It's just that there is a major showstopper left: No Qt > 3.1-final ;-) Ha !, true :-), but really, while the last RC was not planned, several quick RCs were planned ahead in the release schedule for 3.1 - I guess my point is, if you plan them ahead, they are not really RC's. They are betas. And I don't see the use of short lived betas. By definition, the RC should be one (except if sh*t happens, but that you can't plan :-). So, my suggestion in the end is: why not plan just 1 RC, give people time to use it and see if it turns into final with no changes. As I said before, just an idea ... Cheers :-)
splash screen - ac - 2002-11-12
The new KDE 3.1 splash is hella sharp!
Toolbars - Julien Olivier - 2002-11-12
Hi I noticed something in the screenshots: On those screenshots, you can see that konqueror has very few icons (back, forward, up, home, reload and stop). IMO that should be the default configuration for two reasons. 1) It make konqueror easier to use because only the most useful items are on the toolbar. 2) It makes it nicer because you can have only one toolbar instead of 2 or 3. And as keramik isn't very nice with lots of toolbars, it's better. I think this could be applied to lots of apps (kword for example). The less toolbar icons you have the easiest it is for the user to find what he looks for and the nicest it looks. Look at GNOME apps. I haven't seen any GNOME apps having more than one toolbar (in fact, I haven't seen any non-KDE app having more than 1 toolbar). And the most important part is that with 2 or 3 toolbars, you reduce vertical area for the app, which can result in usuability problem at low resolutions. Cheers.
Real Hammering !!! But Red Hat 8 - Muthu.V - 2002-11-12
KDE 3.1 is real cool .... but having some font problems with redhat 8.0 Red Hat 8.0 is confusing .......with their own standards :( Good Work KDE Team
Re: Real Hammering !!! But Red Hat 8 - Joe - 2002-11-12
Learn it, because the way Red Hat 8 handles fonts is the way every distro will handle fonts in the future.
Re: Real Hammering !!! But Red Hat 8 - jimjamjo - 2002-11-12
Yes, but not simply becuase it is Red Hat,but becuase as usual they are implementing something that isn't quite finished yet ( close, tho) Keith Packard's excellent xft2, which does look like it will be the definitive solution to font handling in Linux. Now if only they had used this "best of breed" approach to package management we would all be using debs and apt. God Speed , KDE 3.1
Expanding keramik title bar? - Andy - 2002-11-12
Hey, what happened to the expanding frame around the title in the title bar? In older versions, the frame around the title would grow for the active window, to be a little higher than the top of the title bar. I thought that was a really nice effect, but it seems to be gone from the keramik screen shot in the article.
Re: Expanding keramik title bar? - Julien Olivier - 2002-11-12
In fact, it's an option. I don't know what the default is in this release though.
Re: Expanding keramik title bar? - Rayiner Hashem - 2002-11-12
The default is still on.
Re: Expanding keramik title bar? - ac - 2002-11-12
I hope it's back with a more contrast default colour scheme.
easy customization is the answer to clutter. - jimjamjo - 2002-11-12
Next to being slow for those with older hardware, KDE being a little too busy seems to be the most common criticism of it. It is a difficult job to square frequency of use, comprehensiveness,and proper categorisation. The answer may lie in easy customisation , so that those who like a cleaner simpler interface can cull away. Of course, KDE has this now but perhaps it needs to be emphasized more. That or perhaps some kind of "level" toggle that could reaveal an extra layer with more detail. At most 3 layers in total, but probably just 2 would be best. This could do wonders for the Menu List.