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
It shouldn't be there at all by default. Please file a bug for its removal and have it run by demand in some config panel.
50% slowdown is *serious*.
Don't file it to KDE, it's afaik a Mandrake messing of startkde.
Here is the fastest setup I ever had :
-gcc3.2 + new binutils (compiled together)
-recompile new glibc
-recompile your c++ libs, png, jpeg, etc,
-recompile X
-recompile qt with --no-g++-exceptions (and -qt-gif,-thread, etc)
-recompile all kde with --disable-debug and --enable-final
your system will be really faster.
(but ok it's time consumming and not so easy to do)
Hope this helps
I'm compiling now! Since I've just installed Redhat 8.0, I thought I'd
just skip their KDE alltogether :>
It's been ages since I last compiled KDE from source, it's really grown ;)
kdelibs took some 4-5 hours on my rusty old celeron433mhz. But it'll be
worth it, 3.1 looks sweet.
Also, thanks to the nice people on #kde-users at irc.kde.org for their patient
support :)
They are simple and fir in with all linux apps. Crystal isn't even 1/4 done, there are so many apps that need to be crystalized!
Leave Hi-Color in there for those who want a complet desktop. Please!
Latest KDE-CVS needs a Qt-3.1pre (qt-copy). And it is soo unstable compared to the lastest possible KDE-CVS+Qt-3.0.5. Qt 3.1 seems to have problems with e.g. font-handling. Using a current qt-copy e.g. Konqi crash too often with stuff like this:
[New Thread 1024 (LWP 1469)]
0x41015569 in wait4 () from /lib/libc.so.6
#0 0x41015569 in wait4 () from /lib/libc.so.6
#1 0x410913f8 in __DTOR_END__ () from /lib/libc.so.6
#2 0x40ece402 in waitpid () from /lib/libpthread.so.0
#3 0x406720c0 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:235
#4 0x40ecc134 in pthread_sighandler () from /lib/libpthread.so.0
#5
#6 0x40dfca2d in XGetFontProperty () from /usr/X11R6/lib/libX11.so.6
#7 0x409aab9e in QFontPrivate::fillFontDef () from /usr/qt/3/lib/libqt-mt.so.3
#8 0x409b09ed in QFontPrivate::initFontInfo ()
from /usr/qt/3/lib/libqt-mt.so.3
#9 0x409b245a in QFontPrivate::load () from /usr/qt/3/lib/libqt-mt.so.3
#10 0x409b148c in QFontPrivate::loadUnicode () from /usr/qt/3/lib/libqt-mt.so.3
#11 0x409b179d in QFontPrivate::load () from /usr/qt/3/lib/libqt-mt.so.3
#12 0x409a8e37 in QFontMetrics::QFontMetrics ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0x41bcfdcc in khtml::Font::update (this=0x84d0f20, devMetrics=0x80657a8)
at font.cpp:194
#14 0x41be1780 in khtml::CSSStyleSelector::styleForElement (this=0x831c348,
e=0x84d0a98, state=0) at cssstyleselector.cpp:362
#15 0x41b5c5ac in DOM::ElementImpl::attach (this=0x84d0a98)
at dom_elementimpl.cpp:318
#16 0x41b6b8f9 in KHTMLParser::insertNode (this=0x8474310, n=0x84d0a98,
flat=false) at htmlparser.cpp:308
#17 0x41b6b7cd in KHTMLParser::parseToken (this=0x8474310, t=0x8474214)
at htmlparser.cpp:267
#18 0x41b748a9 in HTMLTokenizer::processToken (this=0x84741e0)
at htmltokenizer.cpp:1561
#19 0x41b72f9d in HTMLTokenizer::parseTag (this=0x84741e0, src=@0x84742ec)
at htmltokenizer.cpp:1094
#20 0x41b73ab9 in HTMLTokenizer::write (this=0x84741e0, str=@0xbfffe91c,
appendData=true) at htmltokenizer.cpp:1348
#21 0x41b284b2 in KHTMLPart::write (this=0x83ddf48,
str=0x84c1078 "\n\n \n\nSear"..., len=203) at khtml_part.cpp:1399
#22 0x41b261bf in KHTMLPart::slotData (this=0x83ddf48, kio_job=0x82f9be0,
data=@0xbfffed54) at khtml_part.cpp:1109
#23 0x41b3d00a in KHTMLPart::qt_invoke (this=0x83ddf48, _id=9, _o=0xbfffeab0)
at khtml_part.moc:344
#24 0x409e01d4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#25 0x40183c21 in KIO::TransferJob::data (this=0x82f9be0, t0=0x82f9be0,
t1=@0xbfffed54) at jobclasses.moc:728
#26 0x40174090 in KIO::TransferJob::slotData (this=0x82f9be0,
_data=@0xbfffed54) at job.cpp:737
#27 0x40184487 in KIO::TransferJob::qt_invoke (this=0x82f9be0, _id=18,
_o=0xbfffebd4) at jobclasses.moc:807
#28 0x409e01d4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#29 0x40168d73 in KIO::SlaveInterface::data (this=0x8404448, t0=@0xbfffed54)
at slaveinterface.moc:195
#30 0x401674ed in KIO::SlaveInterface::dispatch (this=0x8404448, _cmd=100,
rawdata=@0xbfffed54) at slaveinterface.cpp:246
#31 0x40166ed8 in KIO::SlaveInterface::dispatch (this=0x8404448)
at slaveinterface.cpp:191
#32 0x40164c2d in KIO::Slave::gotInput (this=0x8404448) at slave.cpp:221
#33 0x401665f9 in KIO::Slave::qt_invoke (this=0x8404448, _id=4, _o=0xbfffee68)
at slave.moc:114
#34 0x409e01d4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#35 0x409e0365 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#36 0x40c31904 in QSocketNotifier::activated ()
from /usr/qt/3/lib/libqt-mt.so.3
#37 0x409f678d in QSocketNotifier::event () from /usr/qt/3/lib/libqt-mt.so.3
#38 0x40996256 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#39 0x40996054 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#40 0x40611290 in KApplication::notify (this=0xbffff378, receiver=0x8319718,
event=0xbffff0b0) at kapplication.cpp:441
#41 0x4097b157 in QEventLoop::activateSocketNotifiers ()
from /usr/qt/3/lib/libqt-mt.so.3
#42 0x4095dcd2 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#43 0x409a621e in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#44 0x409a6186 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#45 0x409963d9 in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#46 0x416ab774 in main (argc=2, argv=0x805e500) at konq_main.cc:130
#47 0x0804dbd7 in launch (argc=2, _name=0x805e77c "konqueror",
args=0x805e78f "\001", cwd=0x0, envc=1, envs=0x805e7a0 "",
reset_env=false, tty=0x0, avoid_loops=false,
startup_id_str=0x805e7a4 "susi;1035933340;324242;23568") at kinit.cpp:547
#48 0x0804ecd7 in handle_launcher_request (sock=7) at kinit.cpp:1023
#49 0x0804f491 in handle_requests (waitForPid=0) at kinit.cpp:1189
#50 0x080506b0 in main (argc=3, argv=0xbffff934, envp=0xbffff944)
at kinit.cpp:1534
#51 0x40f88671 in __libc_start_main () from /lib/libc.so.6
Bye
Thorsten
I have a similar problem with KDECVS.. I get this everytime I close konqueror:
0x40fde739 in wait4 () from /lib/i686/libc.so.6
#0 0x40fde739 in wait4 () from /lib/i686/libc.so.6
#1 0x4105b340 in sys_sigabbrev () from /lib/i686/libc.so.6
#2 0x40e2fa73 in waitpid () from /lib/i686/libpthread.so.0
#3 0x405eaeb0 in KCrash::defaultCrashHandler(int) ()
from /opt/kdecvs/lib/libkdecore.so.4
I dunno if this is my fault, but I didn't have this problem a couple of months back..
Don't confuse dot.kde.org with bugs.kde.org.
These are known bugs AFAIK. OK, a posting a complete backtrace is maybe a little bit too long ;-) but the question in the title is valid.
Bye
Thorsten
You answered your question yourself with the first sentence. :-)
Oh, so only praise, and not problems, are welcome here?
*beep* *beep* *beep*
The sensitivity on our new detector is a little high. It's supposed to only go off for trolls, but sometimes it goes off for grumpy gnomes. Any way we can recalibrate it?
But...the beep message IS pretty funny!
it's about putting such reports where they will actually do some good, e.g. bugs.kde.org. they aren't nearly as effective or useful when posted as a comment to dot.kde.org.
...and a month later, the original question was never answered. Ah well.
Who can read has an advantage: http://dot.kde.org/1035902091/1035933509/1035950008/1035958915/1035964613/
Hi. Is it only me? or does anyone had experience artsd being a little
bit buggy (kde-3.1rc1). It plays well for about 10 secs,then makes a noise, continues to play well, then makes a noise, and so goes on.
I compiled it with gcc 3.2
Thanks
Nope, been working just fine for me. Sounds like a hardware-specific issue.
Hmm, sounds like you are listening to the Rolling Stones ...
Your description fits perfectly ):-
Try mozart instead ))::--
:-D
+5, Funny!
I've noticed the same yesterday on my Mandrake 9.0/KDE 3.0.3 desktop. I don't know the reason for sure but the only thing i've done since the sound worked fine was installation of HSF soft modem drivers (My modem device is Pentagram Hex 2 based on Conexant chipset). So I can suppose that my problem is caused by buggy modem drivers.
Marcin
I hope it's only you, because don't count on getting many aRts bugs fixed. It's largely a "one man project" and such projects are badly hurt if that "one man" loses interest. That _seems_ to be happening to aRts. Check the kde-multimedia archives for the last month and judge for yourself. I could be wrong, actually I hope I am.
Do you expect the one man to have conversations with himself on the mailing-list? :-)
Check kdenonbeta/arts for recent additions to arts.
But I get a little worried when messages like
http://lists.kde.org/?l=kde-multimedia&m=103588908821958&w=2
go unanswered.
Matthias Welwarsky has taken care of that issue already.
I don't think artsd has changed since KDE 3.0... at least, the version # has been the same for the last few KDE updates...
I have exactly the same problem using arts 1.1.49/KDE 3.1 on SuSE Linux 8.1. I use a Intel 82801. Playing MP3 files using noatun or xmms (arts plugin) results in noise with increasing volume after 1-2 minutes (or even 10-15 minutes) Noise will not stop until I terminate the player or restart artsd. Also when streaming sound or video using realplay, noise occurs after several minutes.
Using xmms with stopped artsd and OSS output plugin works well.
I have the same problem and even turning off artsd and playing mp3's on xmms through OSS does not help :(
I've been hearing that the RC1 release is supposed to have soft word wrap which supposedly will even respect indentation. Can anyone tell me if this is true since I don't have the pipe or the time to get RC1 up and running?
It has been absolutely ridiculous that line-wrapping in Un*x has been so rudimentary that we haven't been able to do this. Only the August HTML editor has word wrapping so far as I know but even its wrapping plays tricks w/the keyboard like Emacs's and GNOMEs crappy character wrapping does.
I couldn't believe it when I found out that UNIX had no soft wrapping editors. Please tell me that this is no longer true! As it is now, I have to fire up Windoze programs under Wine to edit my HTML and keep my sanity :(
Kate in HEAD/RC1 does support soft wrap -- View-> Dynamic Word Wrap ( not to be confused with the static word wrap stuff in the settings dialog); I am not sure what you mean by respecting indentation with that, though. However, I'd be *really* surprised if EMACS didn't support softwrap, seeing how it has just about everything imaginable in there. IIRC, Vim has a softwrap mode on by default (although it's handling of arrows confused me somewhat when I tried it, I think)
I am not sure what you mean by respecting indentation with that, though. However, I'd be *really* surprised if EMACS didn't support softwrap, seeing how it has just about everything imaginable in there. IIRC, Vim has a softwrap mode on by default (although it's handling of arrows confused me somewhat when I tried it, I think)
When I say respecting line indentation, I am referring to that if a line is indented 4 tabs, when it is soft-wrapped, the wrapped portion of the line will be in alignment with the indentation of the first.
Emacs does have _line_ wrapping but it is rather primitive (like vim and GNOME's) in that it is character based and not word based. Thus your words will be broken up if they're at the end of a line. Also, both have irritating keyboard motions, i.e. if you want to move down to a virtual line, you cannot do so by pressing a keystroke but must use the mouse (or some other irritating variation).
Sorry,
I've been using vi for ages, and it has always had word wrap
:se wm=5 to WORD wrap at 5 characters from the right border
Autoindent has been part of VI sine (at least) the mid 80s
:se ai
Vim has improved this a bit with it's smart indent option.
Emacs has had what you want for ages as well (at least xemacs, I've never tried gnu emacs)
"Emacs does have _line_ wrapping but it is rather primitive (like vim and GNOME's) in that it is character based and not word based."
Mm, nope. I use XEmacs on a regular basis, and it's line-wrap mode never breaks up a word. I don't think that it respects indentation (at least, not with the Fundamental major-mode), but I'm sure there's a way to make it do what you want.
But you want to start out with:
M-x auto-fill-mode
I think the emacs M-x auto fill mode you are talking about inserts a soft return which then becomes part of the text stream. So, if you narrow margins or lengthen them, for instance, the text does not re-wrap. What the person way up stream on this thread was looking for really does not exist.
One way to implement the desired feature may be found at this web site:
http://penguinpetes.com/b2evo/index.php?title=howto_make_emacs_use_soft_...
I have not tried this so I cannot attest to it. It is important to me. If I can get it to work, I can use emax/xemax, otherwise, not really...\
No Unix editor with soft word-wrap?
The _best_ editor available --> EMACS <-- is a typical unix app!
I never found an editor with comparable auto-indent-capabilities,
so this is still my preferred choice for all kind of programming jobs (C/C++, HTML,
TeX and so on)
How do you enable soft word-wrapping in EMACS? The default is hard wrapping (not even word wrapping in programming modes).
Those who have recommended emacs to me have not read my original post in which I said that emacs (and xemacs and vi and GNOME) feature a primitive CHARACTER-based wrapping which breaks up words in the middle and puts them onto the next line. This is irritating and very confusing trying to explain to a person who knows about computers but has never used Un*x why such a basic thing cannot be done right.
There is absolutely no reason why the wrapping should be based on characters rather than on words. I'm hoping that KDE doesn't follow in this bad precedent.
I know that both vi(m) and (x)emacs both have ways to automatically format a section of text into 80 columns. I'm sure it's customizable, too. And I wouldn't be surprised if there's a way in each of the editors to have it do that automatically - it's just a matter of learning how to use the program properly.
'linebreak' 'lbr' boolean (default off)
local to window
{not in Vi}
{not available when compiled without the |+linebreak|
feature}
If on Vim will wrap long lines at a character in 'breakat' rather
than at the last character that fits on the screen. Unlike
'wrapmargin' and 'textwidth', this does not insert s in the file,
it only affects the way the file is displayed, not its contents. The
value of 'showbreak' is used to put in front of wrapped lines. This
option is not used when the 'wrap' option is off or 'list' is on.
Note that characters after an are mostly not displayed
with the right amount of white space.
I have a file called updown.vim that makes vim behave almost like notepad.
Some features are still missing, like indentation after wrap and the status bar (it will then show the paragraph number instead of line number...)
" Up, Down, Home and End keys in normal and insert mode
map gk
imap gk
map gj
imap gj
map g
imap g
map g
imap g
" Don't break words in middle
set linebreak
" Show incomplete paragraphs even when they don'f fit on screen (avoid @'s)
set display+=lastline
THANK YOU SO MUCH
I have been trying to figure out how to get it to move the cursor by visual lines rather than stored-in-the-file lines. And the fucking hiding of paragraphs was driving me insane. I tried some other keybindings recommended to fix the visual lines thing, but they did not work half the time. Your method is flawless.
Thank you, thank you, thank you !
- raven morris
That is a fantastic tip - you just (well, in 2002) solved the very last thing that was really annoying me about vim! :-) Thanks very much!
Ditto. Thanks a million.
It works great, you rock
Youre really cute...i KNOW that emacs is a very good editor and bla blah..
simply say how to enable the word wrap and howto set the margins !
like : M-x auto-fill-mode , left margin via (options-> advanced-> emacs -> editing ->fill -> left margin)(under xemacs)
Word wrap in editors like editplus / context and so on is fortunately different to the word wrap in emacs. emacs (via auto-fill or M-q) adds a kind of line-break that unfortunately prevents built in incermental search (STRG-F), search-replace, regexp search, 3rd party search (e.g. grep) etc from finding the string "xxx (linebreak) yyy" when you are searching for "xxx yyy". To me, that really is a pain in the ass. To me, that is THE reason for changing the tool, as a non-destructive (!) word wrap is essential (for me) when working with normal text.
I have been searching the net for a workaround or even for ANY way to make the search / replace / grep oversee the added linebreak and haven't found it yet. Help is greatly appreciated but I am not expecting any.
Ralph
Don't suppose you could just write your own? Its real easy, instead of counting '\n' as a character, ignore it. For that matter, you could ignore anything that you don't want to be a break. I, for one, rewrote word count so that it didn't count hyphens as seperate words.
Use word-search-backward and word-search-forward. It would be great if this were the default in text-modes or when auto-fill is enabled.