tde-devels

devels@trinitydesktop.org

3 participants
3808 discussions

kwrite Crash - Now Down To 3/29 -> 4/1 (this may not be good -- gcc to blame?)
by David C. Rankin 03 May '12

03 May '12

Tim, Darrell, All: I rebuilt TDE from 4/1 sources with full debug in attempt to further look into the kwrite crash that Darrell and I have experienced with TDE built on gcc 4.7. With this build, if it is a source/bad patch/tde issue, then with my 3/29 build giving no crash and my 4/1 build crashing, that would point to some problem in between those two dates. However, I am coming around to the thought that -- this isn't a TDE problem and is more likely a problem introduced by the gcc 4.7 interpretation of the TDE code. I will still have to build the 3/29 sources with gcc 4.7 to confirm that to be the case. I have 3/29 binaries that work fine (which I'm fairly sure were built on gcc 4.7, but I can't remember). If I rebuild with gcc47 on the 3/29 sources and get the same failure -- that, in my mind, conclusively points to the problem being gcc47. If that is the case -- how in the heck do you debug something like that? I don't even know where to begin. (well, I do, but that's by asking). So with full debug packages built, on the 4/1 sources, I get the following backtrace. If this doesn't point to anything specific, then all we can do is wait on the 3/29 build to finish. Let me know if you see anything in this backtrace: 0x00007f1723b65947 in KateLineRange (this=0x7ffffcad3100) at /build/src/tdelibs/kate/part/katelinerange.h:25 25 /build/src/tdelibs/kate/part/katelinerange.h: No such file or directory. (gdb) bt #0 0x00007f1723b65947 in KateLineRange (this=0x7ffffcad3100) at /build/src/tdelibs/kate/part/katelinerange.h:25 #1 KateViewInternal::range (this=this@entry=0x152c5d0, realLine=realLine@entry=4, previous=previous@entry=0x0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1308 #2 0x00007f1723b66b32 in KateViewInternal::range (this=this@entry=0x152c5d0, realLine=4, viewLine=viewLine@entry=1) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418 #3 0x00007f1723b66fd3 in KateViewInternal::nextRange (this=this@entry=0x152c5d0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1391 #4 0x00007f1723b6ec7f in KateViewInternal::cursorDown (this=0x152c5d0, sel=false) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1772 #5 0x00007f1723b4bc9c in KateView::tqt_invoke (this=0x173dac0, _id=172, _o=0x7ffffcad3370) at /build/src/build/kate/part/kateview.moc:772 #6 0x00007f17299d0d35 in TQObject::activate_signal (this=0x16805c0, clist=0x14729f0, o=0x7ffffcad3370) at kernel/qobject.cpp:2383 #7 0x00007f17299d0bbb in TQObject::activate_signal (this=0x16805c0, signal=2) at kernel/qobject.cpp:2352 #8 0x00007f172ba21a24 in KAction::tqt_invoke (this=0x16805c0, _id=15, _o=0x7ffffcad3480) at /build/src/build/tdeui/kaction.moc:216 #9 0x00007f17299d0d35 in TQObject::activate_signal (this=0x172ae50, clist=0x16d2780, o=0x7ffffcad3480) at kernel/qobject.cpp:2383 #10 0x00007f17299d0bbb in TQObject::activate_signal (this=0x172ae50, signal=2) at kernel/qobject.cpp:2352 #11 0x00007f172a9bacc5 in KAccelPrivate::emitActivatedSignal ( this=this@entry=0x172ae50, pAction=0x14b2fa0) at /build/src/tdelibs/tdecore/kaccel.cpp:403 #12 0x00007f172a9bc8db in KAccelPrivate::eventFilter (this=0x172ae50, pEvent= 0x7ffffcad3ab0) at /build/src/tdelibs/tdecore/kaccel.cpp:373 #13 0x00007f17299ce4cc in TQObject::activate_filters (this=0x152c5d0, e=0x7ffffcad3ab0) at kernel/qobject.cpp:930 #14 0x00007f17299ce326 in TQObject::event (this=0x152c5d0, e=0x7ffffcad3ab0) at kernel/qobject.cpp:762 #15 0x00007f1729a06237 in TQWidget::event (this=0x152c5d0, e=0x7ffffcad3ab0) at kernel/qwidget.cpp:4701 #16 0x00007f1729970559 in TQApplication::internalNotify (this=0x7ffffcad4170, receiver=0x152c5d0, e=0x7ffffcad3ab0) at kernel/qapplication.cpp:2638 #17 0x00007f172996f9eb in TQApplication::notify (this=0x7ffffcad4170, receiver=0x152c5d0, e=0x7ffffcad3ab0) at kernel/qapplication.cpp:2395 ---Type <return> to continue, or q <return> to quit--- #18 0x00007f172a92a844 in KApplication::notify (this=0x7ffffcad4170, receiver=0x152c5d0, event=0x7ffffcad3ab0) at /build/src/tdelibs/tdecore/kapplication.cpp:583 #19 0x00007f172a9b8f88 in sendEvent (event=0x7ffffcad3ab0, receiver=<optimized out>) at /opt/tqt3/include/ntqapplication.h:523 #20 KAccelEventHandler::x11Event (this=<optimized out>, pEvent=<optimized out>) at /build/src/tdelibs/tdecore/kaccel.cpp:147 #21 0x00007f172a92c5a8 in publicx11Event (e=0x7ffffcad3e20, this=<optimized out>) at /build/src/tdelibs/tdecore/kapplication.cpp:1782 #22 KApplication::x11EventFilter (this=0x7ffffcad4170, _event=0x7ffffcad3e20) at /build/src/tdelibs/tdecore/kapplication.cpp:2094 #23 0x00007f17298ef48f in qt_x11EventFilter (ev=0x7ffffcad3e20) at kernel/qapplication_x11.cpp:422 #24 0x00007f17298f929a in TQApplication::x11ProcessEvent (this=0x7ffffcad4170, event=0x7ffffcad3e20) at kernel/qapplication_x11.cpp:3422 #25 0x00007f1729914c44 in TQEventLoop::processEvents (this=0x1378ec0, flags=4) at kernel/qeventloop_x11.cpp:195 #26 0x00007f1729983818 in TQEventLoop::enterLoop (this=0x1378ec0) at kernel/qeventloop.cpp:201 #27 0x00007f17299836e9 in TQEventLoop::exec (this=0x1378ec0) at kernel/qeventloop.cpp:148 #28 0x00007f1729970689 in TQApplication::exec (this=0x7ffffcad4170) at kernel/qapplication.cpp:2761 #29 0x00007f172dc5f3a8 in kdemain (argc=1, argv=0x7ffffcad4748) at /build/src/tdebase/kate/app/kwritemain.cpp:692 #30 0x000000000040082c in main (argc=1, argv=0x7ffffcad4748) at /build/src/build/kate/app/kwrite_tdeinit_executable.cpp:2 (gdb) -- David C. Rankin, J.D.,P.E.

3 6

Odd FTBFS in kdepim 3.5.13
by Francois Andriot 03 May '12

03 May '12

Hello, I'm trying to rebuild kdepim 3.5.13 on redhat-based distributions, and on some variants, I get an FTBFS, not on other. It used to work before, so I'm disappointed. The FTBFS is: (taken from RHEL 5 x86) ---------- [ 1%] Building CXX object ktnef/gui/CMakeFiles/ktnef.dir/attachpropertydialogbase.cpp.o cd /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui && /usr/lib/ccache/c++ -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=generic -fasynchronous-unwind-tables -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui -I/home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/ktnef -I/home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/libkdepim -I/opt/trinity/include -I/usr/lib/qt-3.3/include -I/opt/trinity/include/tqt -o CMakeFiles/ktnef.dir/attachpropertydialogbase.cpp.o -c /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp: In constructor 'AttachPropertyDialogBase::AttachPropertyDialogBase(QWidget*, const char*, bool, uint)': /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:101: error: invalid use of undefined type 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.h:21: error: forward declaration of 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:102: error: invalid use of undefined type 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.h:21: error: forward declaration of 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:103: error: invalid use of undefined type 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.h:21: error: forward declaration of 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:104: error: invalid use of undefined type 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.h:21: error: forward declaration of 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:105: error: invalid use of undefined type 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.h:21: error: forward declaration of 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:105: error: incomplete type 'KListView' used in nested name specifier /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:107: error: no matching function for call to 'QGridLayout::addMultiCellWidget(KListView*&, int, int, int, int)' /usr/lib/qt-3.3/include/qlayout.h:336: note: candidates are: void QGridLayout::addMultiCellWidget(QWidget*, int, int, int, int, int) /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp: In member function 'virtual void AttachPropertyDialogBase::languageChange()': /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:149: error: invalid use of undefined type 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.h:21: error: forward declaration of 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.cpp:150: error: invalid use of undefined type 'struct KListView' /home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build/ktnef/gui/attachpropertydialogbase.h:21: error: forward declaration of 'struct KListView' make[2]: *** [ktnef/gui/CMakeFiles/ktnef.dir/attachpropertydialogbase.cpp.o] Error 1 make[2]: Leaving directory `/home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build' make[1]: *** [ktnef/gui/CMakeFiles/ktnef.dir/all] Error 2 make[1]: Leaving directory `/home/albator/rpmbuild/BUILD/BUILD.el5.i386/kdepim/build' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.53807 (%build) ---------- When looking in "attachpropertydialogbase.cpp", I see that it lacks the line: "#include <klistview.h> . That's why it fails. In a working build environment, the same file contains the include, and it compiles correctly. It looks like the "attachpropertydialogbase.cpp" and "attachpropertydialogbase.h" are both autogenerated with "uic". I tried running "uic" manually in both build environment, and I confirm that in one case, I get the "#include <klistview.h>", and in another case, i do not get it, and then it FTBFS. What could cause a different behaviour in the uic utility ? (Note: both build environment have same QT, kdelibs, etc ... versions) Thanks François

1 0

nm-applet kwallet problem
by Jay 02 May '12

02 May '12

While using nm-applet from network manager i have a problem. I am not sure if kwallet is to blame or NM is not calling gnome-keyring. Perhaps NM does not recognize TDE as a desktop due to some environment variable not exported or something? After restarting the nm-applet and trying to connect it spews out this: root@porteus:~# nm-applet ** Message: applet now removed from the notification area ** Message: applet now embedded in the notification area ** (nm-applet:2383): WARNING **: Failed to register as an agent: (32) No session found for uid 0 ** Message: Starting applet secret agent because GNOME Shell disappeared ** (nm-applet:2383): WARNING **: Failed to register as an agent: (32) No session found for uid 0 ** (nm-applet:2383): WARNING **: Could not initialize NMActiveConnection /org/freedesktop/NetworkManager/ActiveConnection/0: Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist ** (nm-applet:2383): CRITICAL **: applet_get_connection_for_active: assertion `path != NULL' failed ** (nm-applet:2383): WARNING **: Could not create object for /org/freedesktop/NetworkManager/ActiveConnection/0: Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist So while it senses all networks when i try to connect i do not get the popup asking for passphrase. If i edit the config file for NM with a plain text password it connects without issue. Any ideas? Jay

1 0

sftp-kio - still fails in R14 - Any progress? (log captured - may help?)
by David C. Rankin 02 May '12

02 May '12

All, Another critical issue that should be a priority for the R14 release is to finally have a working sftp. I just check and it is still broken: http://www.3111skyline.com/dl/dt/trinity/ss/sftp-kio-err.jpg However, I did capture a log from the command line that might help. It looks like there is a blank field '' that might be the culprit. http://www.3111skyline.com/dl/dt/tde/err/sftp-kio/sftp-output.txt Can someone give me a functional flow as to how the sftp-kio gets called? I doubt I'll be able to do anything, but at least I can look.... -- David C. Rankin, J.D.,P.E.

10 64

BSD moves from kde4 -> kde3 in latest releases (on Qt4)
by David C. Rankin 02 May '12

02 May '12

All, I found this a very interesting tidbit posted by Felix Miata on the opensuse kde3 list this morning. According to distrowatch, BSD has gone from kde4 back to kde3 for both its release 9 and 10 due out this month. It has also gone back to FF 3.6: <quote> I was looking over distrowatch, opened the BSD page, and noticed some interesting data points: Version 8.1 8.2 9.0 9 10 Released 2010/07 2011/02 2012/01 2012/05 2012/05 Firefox 3.6.4 3.6.13 9.0.1 3.6.28 3.6.28 K3B 1.0.5 2.0.2 2.0.2 1.0.5 1.0.5 KDE 4.4.5 4.5.5 4.7.3 3.5.10 3.5.10 QT 4.6.3 4.7.1 4.7.4 4.7.4 4.7.4 Samba 3.4.8 3.5.6 3.6.1 3.6.4 3.6.4 T Bird 3.0.5 3.1.7 9.0 3.1.20 3.1.20 </quote> This caught my eye for a number of reasons. First, it is a major distro shifting back to kde3. This bodes well for TDE for a number of reasons (a) additional patch collaboration, (b) Qt3 -> Qt4 development experience. I do not know what the details are, but if BSD has ported the kde3 kwin widget set/styles/etc.. that should make it much easier for someone to build a prototype of TDE on the current kwin as Martin discussed. Next, the Mozilla downgrades were of interest as well. The current releases seem to take quite a bit of CPU and require manual maintenance to vacuum and reindex the sqlite databases to prevent them from growing wildly. (if you haven't checked your firefox and tbird profiles lately, then cd into you .mozilla/firefox/<blah349.default> and .thunderbird/<blah349.default> directories and then 'ls -al *.sqlite'). You will be surprised what you find. You can repair them with: for i in *.sqlite; do sqlite3 $i vacuum; sqlite3 $i reindex; done But I digress. The point being, between BSD, opensuse and others either returning to, or presently maintaining, kde3, the opportunities for advancing TDE become better and better each day. It might be a good idea to open up channels of communication between the developers so that everyone can benefit from the good work done by the kde/tde community as a whole. -- David C. Rankin, J.D.,P.E.

3 3

TIME Frame 3/29 -> 4/10 kwrite crash introduced
by David C. Rankin 01 May '12

01 May '12

Tim, All, I have completed downgrading through the sets of binaries I have and from that I can summize that this bug was introduced sometime between 3/29 and 4/10. In my 3/29 build, kwrite is fine. In my 4/10 build, this bug effects kwrite, kate, all editors EXCEPT kedit. In kedit, I can continue to paste away without any crash (I'm sure it makes no use of katepart...) So that is the best I can do in narrowing it down rapidly from existing binaries I have. Darrell, do you have any binaries between 3/29 and 4/10 that could help narrow? There were a ton of changes that went into the GIT tree for tdelibs and tdebase during that two week period. It would be great if we could further narrow it by simply loading binaries rather going through all the commits... I've updated 979 with the info. -- David C. Rankin, J.D.,P.E.

4 19

Narrowed Time Frame 3/29->4/3 kwrite crash -> Looks like Qt3 bug
by David C. Rankin 01 May '12

01 May '12

Tim, Darrell, All, I rebuilt all packages this morning with sources from 4/3 to help narrow down the kwrite crash issue. The files were built with full debug information. I don't know if this new backtrace is useful, but it is different from the prior backtraces in that it points straight at tqt3. (at least to me) I can't interpret exactly what it is saying, but I'll let the experts decide: Loaded symbols for /lib/libnss_files.so.2 0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 (gdb) bt #0 0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 #1 0xb6a12d77 in category (c=...) at ../include/private/qunicodetables_p.h:99 #2 0xb6d89361 in isSpace (ch=...) at tools/qunicodetables_p.h:218 #3 0xb6d7e96f in TQChar::isSpace (this=0x8d8d810) at tools/qstring.cpp:475 #4 0xb5270346 in KateRenderer::textWidth (this=0x8b4e400, textLine=..., startcol=0, maxwidth=751, needWrap=0xbfae53d8, endX=0xbfae53cc) at /build/src/tdelibs/kate/part/katerenderer.cpp:806 #5 0xb524dd97 in KateViewInternal::range (this=0x8bc5e20, realLine=0, previous=0x0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331 #6 0xb524f1ae in KateViewInternal::range (this=0x8bc5e20, realLine=0, viewLine=1) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418 #7 0x08bc5e20 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) A strace was also run and I've attached that to bug 979. http://bugs.pearsoncomputing.net/attachment.cgi?id=576 I also get a lot of undefined symbol messages when strace is running. I don't know if this will help, but maybe it provides a clue. IIRC, there was a name mangling patch that went it at some time around here. This is what gets dumped to konsole: 13:52 tdepv:~> strace -o vbh/tde/err/kwrite/strace0403.txt kwrite /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent <snip> (see attached file for remainder) I also tested kate - same crash! I don't know what Darrell is doing, he must be living right! I just pasted 'undefined symbol ' into line one until it would make it wrap and then on the next paste - wham! > crashed. This backtrace is a bit different, the qt3 error I saw in kwrite appears masked for some reason?? Here is the kate crash backtrace: Loaded symbols for /opt/tqt3/plugins/inputmethods/libqimsw-none.so 0xb620dd36 in TQChar::row (this=0x9f4c300) at ../include/ntqstring.h:221 221 ../include/ntqstring.h: No such file or directory. (gdb) bt #0 0xb620dd36 in TQChar::row (this=0x9f4c300) at ../include/ntqstring.h:221 #1 0xb620dd88 in category (c=...) at ../include/private/qunicodetables_p.h:104 #2 0xb6584361 in isSpace (ch=...) at tools/qunicodetables_p.h:218 #3 0xb657996f in TQChar::isSpace (this=0x9f4c300) at tools/qstring.cpp:475 #4 0xb5503346 in KateRenderer::textWidth (this=0x9fc6260, textLine=..., startcol=0, maxwidth=555, needWrap=0xbf887a08, endX=0xbf8879fc) at /build/src/tdelibs/kate/part/katerenderer.cpp:806 #5 0xb54e0d97 in KateViewInternal::range (this=0xa08e128, realLine=0, previous=0x0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331 #6 0xb54e21ae in KateViewInternal::range (this=0xa08e128, realLine=0, viewLine=1) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418 #7 0x0a08e128 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) What say the experts? Anything look like it points to anything specific? Worth running a strace on kate? I also found another bug in the setup wizard when choosing keramik style -- you get no window decorations. (this may be fixed since this was the 4/3 code). Plastik works fine. I had deleted ksycoca and my ~/.trinity profile for this test, so I was starting over from scratch. I thought I would pass that along as well. -- David C. Rankin, J.D.,P.E.

3 4

TDE spring fundraiser success!
by Timothy Pearson 01 May '12

01 May '12

I know many of you are not subscribed to the trinity-announce list, so here is a link to the 2012 fundraiser completion announcement: http://trinity-announce.pearsoncomputing.net/?0::22 Tim

3 2

/etc/ld.so.cache
by Darrell Anderson 30 Apr '12

30 Apr '12

If I understand correctly, any library directory outside of the standard /lib and /usr/lib locations need to be identified in /etc/ld.so.cache. Is this correct? During my Trinity build and packaging process, I have been inserting /opt/trinity/lib into /etc/ld.so.cache. Do I need to add /opt/trinity/lib/trinity too or are subdirectories of /opt/trinity/lib automatically found by ldconfig? Are there any other library locations from Trinity that belong in /etc/ld.so.cache? When I build Trinity packages, because I am installing to a non standard location, I explicitly declare $LD_LIBRARY_PATH=/opt/trinity/lib in my build environment. I do not declare this variable in during run time. To my understanding, this variable causes the build process to use that location before using library files in the standard locations or /etc/ld.so.cache. Is this correct? Thanks. Darrell

4 11

Resolving the TWin/KWin Fork Issue
by Martin Gräßlin 30 Apr '12

30 Apr '12

Hi all, I had to see that there is still development going on in your fork of KWin and I am very unhappy about that. This is something I really want to see resolved, any development to KWin should happen in KWin, it's such a waste to work on the same project without coordination. Let's first recapture the state of TWin: = Why does TWin exist? = Because KWin got forked together with everything else from KDE 3.5 to form the Trinity Desktop Environment (TDE). = Why has the TDE fork happened? = The TDE fork existist because of a combination of the following reasons: * Parts of KDE had to be rewritten in order to be ported to Qt 4 * Early versions of KDE 4.x were lacking functionality compared to KDE 3.5 * Early versions of KDE 4.x had quality and stability issues compared to KDE 3.5 * A general disagreement with some project decisions * KDE 4.x introduced new technologies unliked by some (e.g. Nepomuk or Akonadi) = Do these reasons hold for KWin? = No! None of the reasons stated above has ever been true for KWin. KWin is a direct continuation of the KDE 3 version. The codebase did not get rewritten, the quality of the window manager did not suffer, new functionality got added as optional addons. = Is there any other reason justifying the TWin fork? = Maybe the fact that KWin depends on Qt4/kdelibs4 which is not liked by TDE. = Is that a reason for a hostile fork as it is at the moment? = No, the fact that TWin requires Qt 3 is no reason to have the current state with the hostile fork. Best would be a solution of no fork, but a collaborative friendly fork should be possible, given that KWin and TWin share a large code base. = What can KDE do about the fork? = Actually pretty much nothing. The license allows TDE to fork KWin - whether we like it or not. All we can do is force you to change the name and urge you to work together with us. = Why do I actually care? = The KWin development team is rather small. I would like to see more involvment inside KWin than to see duplicated work in a fork. Furthermore KWin 3.5 has a very good reputation and is known as rock solid. I see this reputation questioned if the TWin fork is continued without the quality checks performed in the KWin development. Lets have a look at the recent patch for TWin called "Mac Like Switching Panel". This introduces a new feature to switch through applications and references an implementation in window maker. To be clear: this functionality has been present in KWin since version 4.4 (I added it). A little bit of coordination here would have prevented the duplication of development. But is there a problem when Trinity adds code, should I care? Well the code is wrong (review based on patch2.patch on mailing list). In an attempt to copy everything from window maker code got added to KWin (particular readClass) which already existed. Lack of knowledge about the KWin source code are probably the reason that it is unknown that KWin::Client::resourceName()/resourceClass() provide the window class attribute. Another problem is that the code is crashy. For me as an experienced KWin developer I only need to look at the code and see immediately were it is likely that the code will crash. Consider that start is NULL and the following line of code: start->readClass(). How likely is it that a non KWin developer would have spotted this crashy code? How likely is it that you know how to create such a situation? (I know it exactly). It is not surprising that you are not able to add code to KWin which is correct - hardly anybody not knowing the code base is able to do so. That's why we perform code review and help new developers to get the code into a state that it works correctly. We are happy to accept patches from the Trinity team to KWin as well (of course we only accept patches for current master). The important difference is that in KWin there is a quality assurance through the code review by *experienced* KWin developers. This is impossible in TDE as there are no experienced developers for KWin. Now I'm not writing this mail to blame you for writing wrong code. If I would be "evil" I would sit back, relax and wait to see TDE hit the wall which is approaching faster and faster when crashy code gets added. Remember: one of the reasons for Trinity is the (no longer) bad quality of KDE 4 code. And you even use that in your external communication - such crashy changes might backfire and then you cannot blame KDE. I'm here now to resolve this issue about TWin together with you. I want to see the hostile fork go away. From all we see TDE is unable to maintain or even develop TWin. Please accept this fact as it is. It is nothing bad, I needed three years of strong involvment in KWin developer before becoming maintainer and there are still large areas of code blocks where I have no clue about. Based on that fact we have to look for a solution. In my opinion the best would be to just use our KWin. And we have some quite useful things about that in our current development version: * no longer depends on anything else from kde-workspace * build options to disable "KDE 4" features (see http://techbase.kde.org/Projects/KWin/Build_Options) * mostly runtime dependencies to libplasma * desktop integration possible through custom QML additions like e.g. Alt+Tab * currently integrates with three desktop shells * (under review) build option to change the name of the binary, which would allow you to generate a kwin_tde or twin binary (automatic adjustment of all configuration files, etc.) (see https://git.reviewboard.kde.org/r/104299/) * after feature freeze: branch to build kwin standalone without the need to run cmake in kde-workspace. As you can see this is a rather impress list of features which would allow TDE to use KWin instead of their fork. Of course KWin depends on Qt 4 and kdelibs 4. We have no interest to support anything below Qt 4.7 and are currently preparing the transition to Qt 5 and KDE Frameworks 5. I think that this is only a minor issue to Trinity as to my understanding TDE can also use Qt 4. We are open to discuss any concerns regarding integration a Qt4/kdelibs4 based application into TDE. I am very sure that most of your possible concerns are rather non-issues and that they can all be easily resolved. I hope that you consider dropping your hostile fork of KWin and start to collaborate with your upstream pears at KDE more closely. Thanks for your time Martin Gräßlin KWin maintainer

17 74

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels