Tim,
The kwrite crash detailed in bug 979 is NOT fixed. I rebuilt everything today
with updates on both Arch and TDE current through today. The behavior is exactly
the same as before. I don't know what Fedora did to get around the crash, but it
is still there. It may be gcc, but I'd bet it is non-standard compliant code in
TDE that was exposed by the stricter interpretation by gcc 4.7. I'll reopen 979,
but I'm at a loss at what else to do. Backtrace from tonight:
Loaded symbols for /lib/libnss_files.so.2
0x00007f3934e3fe7a in TQChar::unicode (this=0x218ac2e) at ../include/ntqstring.h:198
198 ../include/ntqstring.h: No such file or directory.
(gdb) backtrace
#0 0x00007f3934e3fe7a in TQChar::unicode (this=0x218ac2e) at
../include/ntqstring.h:198
#1 0x00007f3934e3fa7f in TQFontMetrics::charWidth (this=0x2071930, str=..., pos=47)
at kernel/qfont_x11.cpp:704
#2 0x00007f392e3724da in width (tabWidth=<optimized out>, italic=<optimized out>,
bold=<optimized out>, col=47, text=..., this=0x2071910)
at /build/src/tdelibs/kate/part/katefont.h:76
#3 width (tabWidth=<optimized out>, col=47, text=..., fs=..., this=<optimized out>)
at /build/src/tdelibs/kate/part/kateattribute.h:55
#4 KateRenderer::textWidth (this=0x2144930, textLine=..., startcol=0, maxwidth=753,
needWrap=0x7fff40b10b78, endX=0x7fff40b10b6c) at
/build/src/tdelibs/kate/part/katerenderer.cpp:797
#5 0x00007f392e353994 in KateViewInternal::range (this=this@entry=0x2195c00,
realLine=realLine@entry=0, previous=previous@entry=0x0)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331
#6 0x00007f392e354e52 in KateViewInternal::range (this=this@entry=0x2195c00,
realLine=0,
viewLine=viewLine@entry=1) at
/build/src/tdelibs/kate/part/kateviewinternal.cpp:1418
#7 0x00007f392e3567e9 in KateViewInternal::viewLineOffset
(this=this@entry=0x2195c00,
virtualCursor=..., offset=0, keepX=keepX@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1578
#8 0x00007f392e35a045 in KateViewInternal::makeVisible
(this=this@entry=0x2195c00, c=...,
endCol=118, force=force@entry=false, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:781
#9 0x00007f392e35a672 in KateViewInternal::updateCursor
(this=this@entry=0x2195c00, newCursor=...,
force=force@entry=true, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2204
#10 0x00007f392e35e7e0 in KateViewInternal::editEnd (this=0x2195c00,
editTagLineStart=0,
editTagLineEnd=<optimized out>, tagFrom=<optimized out>)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:3385
#11 0x00007f392e2fb208 in KateDocument::editEnd (this=0x20906f0)
at /build/src/tdelibs/kate/part/katedocument.cpp:1032
#12 0x00007f392e2f523b in KateDocument::paste (this=0x20906f0, view=0x2068bc0)
at /build/src/tdelibs/kate/part/katedocument.cpp:3249
#13 0x00007f392e32cd73 in KateView::paste (this=0x2068bc0)
at /build/src/tdelibs/kate/part/kateview.cpp:1597
#14 0x00007f392e35c422 in KateViewInternal::mouseReleaseEvent (this=0x2195c00,
e=0x7fff40b11480)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2965
#15 0x00007f3934f2e343 in TQWidget::event (this=0x2195c00, e=0x7fff40b11480)
at kernel/qwidget.cpp:4725
#16 0x00007f3934e98559 in TQApplication::internalNotify (this=0x7fff40b11ce0,
receiver=0x2195c00,
e=0x7fff40b11480) at kernel/qapplication.cpp:2638
#17 0x00007f3934e97be3 in TQApplication::notify (this=0x7fff40b11ce0,
receiver=0x2195c00,
e=0x7fff40b11480) at kernel/qapplication.cpp:2424
#18 0x00007f3935e618d4 in KApplication::notify (this=0x7fff40b11ce0,
receiver=0x2195c00,
event=0x7fff40b11480) at /build/src/tdelibs/tdecore/kapplication.cpp:583
#19 0x00007f3934e2a6b3 in TQApplication::sendSpontaneousEvent (receiver=0x2195c00,
event=0x7fff40b11480) at kernel/ntqapplication.h:526
#20 0x00007f3934e23f53 in TQETWidget::translateMouseEvent (this=0x2195c00,
event=0x7fff40b11990)
at kernel/qapplication_x11.cpp:4381
#21 0x00007f3934e21871 in TQApplication::x11ProcessEvent (this=0x7fff40b11ce0,
event=0x7fff40b11990)
at kernel/qapplication_x11.cpp:3558
#22 0x00007f3934e3cc44 in TQEventLoop::processEvents (this=0x1fd3f80, flags=4)
at kernel/qeventloop_x11.cpp:195
#23 0x00007f3934eab818 in TQEventLoop::enterLoop (this=0x1fd3f80) at
kernel/qeventloop.cpp:201
#24 0x00007f3934eab6e9 in TQEventLoop::exec (this=0x1fd3f80) at
kernel/qeventloop.cpp:148
#25 0x00007f3934e98689 in TQApplication::exec (this=0x7fff40b11ce0) at
kernel/qapplication.cpp:2761
#26 0x00007f39391d43a8 in kdemain (argc=1, argv=0x7fff40b122b8)
at /build/src/tdebase/kate/app/kwritemain.cpp:692
#27 0x000000000040082c in main (argc=1, argv=0x7fff40b122b8)
at /build/src/build/kate/app/kwrite_tdeinit_executable.cpp:2
--
David C. Rankin, J.D.,P.E.
Hi Tim and others,
Is there significant development going on regarding keyboard handling or
maybe character handling?
I'm a bit surprised, because I didn't know this depended on the toolkit,
but with the current nightlies, I'm unable to use my compose key to
compose characters in any Trinity application. In Qt4 and GTK
applications (within Trinity), the compose key works correctly. In the
past, this worked without issues in Trinity as well.
I can imagine this is not noticed by everybody quickly, I myself need to
use compose a lot to type in foreign languages. Let me know if I can
help with reproducing/solving this.
Best regards,
Julius
Ubuntu 10.04 LTS - Trinity 3.5.13
I have seen several konqueror updates recently (via Slavek's PPA.)
But, konqueror's Help > About konqueror reports:
"Konqueror 3.5.10 (using Trinity 3.5.13.1)"
Is it truly still konqueror 3.5.10 from back in the 2009-2010 days?
Has it just been bug fixes until now?
Or, has the Help > About konqueror text never been updated.
Thanks,
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
Pueblo, Colorado | @ | Jonesy | OS/2 __
38.238N 104.547W | config.com | DM78rf | SK
All,
Arch is switching to systemd init. I don't know if this will have any impact
on TDE, but older versions have dependency conflicts due to the packages that
have been removed (heimdal from krb5, etc...) Not all systemd related, but I
wonder what other init or sysv dependent packages will need to be fixed for
systemd -- hopefully none at all, but I don't know enough to knnow.
So what do the TDE gurus say? Is there anyone building/running on a systemd
box currently? If not, what problems has anyone heard of caused by systemd (more
importantly -- and known tde specific impacts related to systemd.
Issue/No Issue? Gurus?
--
David C. Rankin, J.D.,P.E.