tde-devels June 2012

devels@trinitydesktop.org

18 participants
114 discussions

Bug 979 - NOT fixed - kwrite/kate still locks up tight when built on gcc 4.7 (todays sources and gcc 4.7.0-6)

by David C. Rankin

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.

11 years, 10 months

Keyboard handling, compose key broken in Trinity nightlies

by Julius Schwartzenberg

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

11 years, 10 months

Speaking of component version numbers

by Marvin L Jones

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

11 years, 10 months

Anyone building tde on box with systemd init?

by David C. Rankin

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.

11 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels June 2012