The KDE Project yesterday
announced the release
of KDE 3.1 RC 1. This release, while important, will have but a short lifespan (RC 2 is scheduled for next Monday), and so binary packages are not planned.
A couple of points to consider: First,
if you are wed to the hicolor icons, please note that they have been moved
to the kdeartwork package; the other packages ship only with the new modern
and attractive Crystal-SVG icon theme.
Second, Klipper users who experience slowness or possible crashes in Konsole
or KMail with this release should try disabling the Klipper syncing options,
and then check
the KDE 3.1 Info Page
about reporting results. Please give this release a thorough testing
so KDE 3.1 will be good and ready on schedule! A short but informative
preview of
the much-improved KDE 3.1 is available on the KDE Promo site.
KDE 3.1 RC1: Ready for a Short Test Drive
Dot Categories:
Comments
You might also want to consider longlines-mode (in Emacs 22 or http://www.emacswiki.org/cgi-bin/emacs/download/longlines.el)
I am still studying Emacs, but they say that "C-s RET C-w" is able to find phrases even if they are separated by newlines.
KDE's text editors all have word wrapping IIRC, so does GNOME 2.0's gedit. And just about any formatted text editor for Unix - KWord, StarOffice, OpenOffice, Mozilla Composer, etc. - has word wrapping.
The talk is about *soft* word wrapping.
Well, I have been informed that the GNOMEs have fixed their soft word wrapping in their 2.x versions. (I don't really like the direction they've taken in the 2.x versions so I don't use it that much, if at all; too MacOS < 10 for me.)
I still haven't had any RC1 users tell me if KDE editors will have this feature yet.
Will there be Debian packages of the RC? I'd like to test them, but I don't fancy uninstalling all my Debian stuff and compiling all the new stuff.
http://shakti.ath.cx/debian
But I don't think they are official...
is there any place to find a list of fix being apply to 3.0.9 from 3.0.8 ?
just curious....
thanks
I got an errror message when I compiled the QT3.1.
is there something I missed?
/usr/bin/ld: cannot find -lXft
collect2: ld returned 1 exit status
make[1]: *** [../lib/libqt-mt.so.3.1.0] Error 1
make[1]: Leaving directory `/usr/local/qt-3.1/src'
make: *** [sub-src] Error 2
Try installing Xft-devel.
That doesn't work either. I am having the same problem and I have Xft-devel installed. I get this same error in Redhat 7.3 :-(. Any help on this?
ln -s /usr/X11R6/lib/libXft.so.1.2 /usr/X11R6/lib/libXft.so
and then, in your qt-copy directory, after you make -f and configure, run:
find . -name Makefile | xargs perl -pi -e 's,-lXft,-lXft -lXft2,'
The linking might be optional, but I'm not about to rebuild qt to find out...
...guys for testing this non final version. i wait for debians official packages, but because of you, they will be rock stable!!!
...guys for testing this non final version. i wait for debians official packages, but because of you, they will be rock stable!!!
what i forgot: kde is really cool, but i hate one thing: this thousands of little arrows in panel. they are ugly and useless. i got rid of most of them in kcontrol, but this ones where you get this "Move,Remove,Preferences,Panel"-menu are still there. can i comment out some lines in sourcecode to remove them??? please, help ;-)
I absolutely agree with you there. Those little arrows all over the place don't look good.
I know that they are useful in terms of users being able to see that they can move stuff about but they look silly.
There should be a control panel option -> Hide All Arrows.
This is a trend with the usability people. They seem to think more clutter is a good thing. Same thing applies to repeating the same instructions and text all over the place.
It's *not* a good thing. It's a careful balance.
actually, our real goal is to piss off people who post anonymously to web boards.
Apple, the usability gods, avoid clutter too.
Once you learn something you don't need to read instructions over and over again.
It eventually becomes counter-productive.
find, ignore my joke.
second, Apple has shown with OS X that they are no longer "usability gods". they have some good ideas still (and occassionally great ones) but they are far more fallible than they ever have been.
in any case, your "once you learn something" argument falls down at one particular point" you have to learn it first. and that was the entire problem with removing panel applets: people never learned how to do it. they needed help learning (and remembering). they got that help. problem went away.
now we just get to put up with the occasional whine of "i don't like how it looks"
I wouldn't ignore those whines. I am sure there is some fundamental UI rule that says clutter and redundancy is bad. The whines are just one symptom of violating that rule.
Retard! Opening his stupid mouth and fear posting with his real name.
this has been taken care of for a while...here's how to make them fade away.
click on one of those little arrows, choose "Panel Menu > Configure Panel..."
click on the "Advanced Options" button at the bottom.
check the "Fade out applet handles" box and then click OK a couple of times.
easy, huh?
KDE 3.1 has an GUI option to fade out the applet handles. In KDE 3.0 you had to change kickerrc.
as others already mentioned, you can fade out the applets via the panel config dialog. hopefully that is satisfactory.
as to why those arrows are there: there were endless reports of problems with removing applets from the panel. people just didn't clue in that you could right click on the applet handle! when the arrows were added, the number of such reports dropped practically to zero. they may annoy a few people, but they can be turned off and that is far better than a good % of users not being able to figure out how to remove applets.
Ok, but check out bug #49969.
Andras
i just assigned it to myself. it's a bug in the control panel, not inherent to kicker. now the question is whether it will get fixed for 3.1, or 3.1.1 ... =)
it is possible to hide the applet-handles, yes, but, why do they still leave a space ?! that's really unfinished.. that should be simple accessed and work similar to WindowsXP's "Fix Taskbar", that is easy accessible by right-klick on the taskbar !!! in KDE you need to open "Kontrolcenter", that's so heavy! really Big Work. hope things like that will be finally equal to "MS Windows", since, there is no copyright on that feature! and it is just logical to change that.
thx
the patch for this logical change is available where?
Do it yourself, it's opensource afterall. >:-p
you've got it backwards: mononoke wants the feature, s/he should provide the patch. it isn't something high on my priority list (lots of other things are, though). the things that bother(ed) me the most about kicker have mostly been fixed, hopefully we'll get to the remaining annoyances for 3.2.
With KDE 3.0.4 I can rightclick the panel and choose 'preferences'. Just make sure you click an empty region of the panel.
i don't know something about the XP way, but in my opinion. i like the applet-handles (especially with keramik), but not the arrows. so this fade out thing should only fade out the arrow, not the hole applet-handle. the empty area is better then a.-h. with arrow, but not perfect. and hey, to discuss about such stupid things shows the high quality of kde 3.x!!!
ok, thank you for all this informations!
In ~/.kde/share/config/kickerrc
in the [General] section
put the following:
FadeOutAppletHandles=true
and the little vertical bars w/ the arrows will be faded in and out, so they're not visible unless you hover over them.
-steve
Is there some explaination of why a tarball that won't compile was released?
Is this GCC or Qt issue?
I am using GCC 3.2 and Qt 3.1 Beta 2 and I consistently get this error:
khtmlview.cpp: In member function `virtual void KHTMLToolTip::maybeTip(const QPoint&)':
khtmlview.cpp:247: no matching function for call to `KHTMLToolTip::tip(QRect&, QString&, QRect&)'
????
--
JRT
You need a newer Qt than beta2 - i.e. Qt-copy or a recent rsync snapshot for that function...
This doesn't appear to be a very good idea to me -- releasing a release candidate that requires an Alpha version of Qt.
In any case, I see nothing here:
http://www.kde.org/info/3.1.html
to indicate this problem.
Perhaps at least a snapshot known to work would be a good idea.
--
JRT
> releasing a release candidate that requires an Alpha version of Qt
Alpha? Qt 3.1 already had a Beta2 release and its current state is RC1.
> Perhaps at least a snapshot known to work would be a good idea.
Like ftp://ftp.kde.org/pub/kde/unstable/kde-3.1-rc1/src/qt-copy-3.1_20021024....?
>> releasing a release candidate that requires an Alpha version of Qt
> Alpha? Qt 3.1 already had a Beta2 release and its current state is RC1.
We would all like to think that the development process results in software improving monotonically, but I think that we all know that this is not the case -- regressions DO occur. There can be no assurance that the current snapshot is as stable as the last Beta.
I checked the TrollTec web site about 10 minutes ago and couldn't find that RC1 to download.
>> Perhaps at least a snapshot known to work would be a good idea.
> Like:
>ftp://ftp.kde.org/pub/kde/unstable/kde-3.1-rc1/src/qt-copy-3.1_20021024....?
Yes, too bad that that link isn't posted on the 3.1 info page with the 3.0.9 tarballs.
--
JRT
Uhm ? Sorry, you like to try out KDE 3.1 RC1 (which is also more or less something to test) but you refuse to get and compile QT 3.1 RC1 ? What's wrong with you ?
> I checked the TrollTec web site about 10 minutes ago and couldn't find that RC1 to download.
TrollTech doesn't offer release candidates to the public, but makes them available to their friends at KDE. Get current qt-copy and you have Qt Free Edition 3.1 RC2.
> Yes, too bad that that link isn't posted on the 3.1 info page with the 3.0.9 tarballs.
Yes, that could be improved. But this is no normal release, I was even surprised to see the 1 week living release candidate announced so public on the dot.
Well, latest RC2 seems to have stabilized my combination of KDE-3.1pre, Qt-3.1pre,Xfree, Freetype. Compilation on a gcc3.2+glibc2.3.1 system was without problems. Now it looks better. Hey, I can even launch kcalc again! :-))
Bye
Thorsten
Actually, that's a pretty good idea, since Qt 3.1 beta 2 had some serious bugs for KDE. I don't think you would be able to do any meaningful testing for the RC since there are some more visible bugs in that Qt version. As for this method the error was about: IIRC, that was added by request of KHTML hackers, so fix some bugs with tooltips in webpages.
And, BTW, qt-copy is generally what is known to work with KDE well -- since if anyting is broken, patches are typically applied to fix it. And this is why, in fact, Qt snapshots are used like this -- so Qt bugs affecting KDE, if any, can be found and fixed before a Qt release happens.
After compiling and installing: kdeartwork, I found that I still had icon trouble.
Did anyone consider backward compatibility??
It seems that: "hicolor" is now called: "kdeclasic" and "lowcolor" is now called "Lowcolor".
So KDE can't find my icons. :-(
So, I know, just rename the directories. I already did that.
BUT, applications that install icons in a directory other than the application's are going to be looking for: "hicolor" & "locolor". So, links are necessary. But, not only for the global directory, but for all of the user: $HOME/.kde/share/icons/" directories as well.
My suggestion is to change it back immediately before the problem spreads.
--
JRT
Some icon problems have been addressed after RC1, for rest http://devel-home.kde.org/~larrosa/iconthemes.html may help understanding.
OK. So, the global icons are not a problem.
HOWEVER, there is a serious bug here.
The icon loader did NOT find: "#HOME/.kde/share/icons/hicolor/" which is were OpenOffice (for one) installs its icons, and I presume that any locally installed application should install its icons.
Has this been fixed?
--
JRT
OpenOffice icons display fine here with CVS and either Crystal or KDE Classic themes.
most annoying bug of kde is fixed! now you can wheelscroll in konquer without having to worry about comboboxes on pages!! It was really annoying on sites like slashdot.
I liked this *feature*. Agreed, implementation was bad. It should have better be changed to work only when one presses e.g. Ctrl instead of turning it off completely.