tde-devels

devels@trinitydesktop.org

2 participants
3855 discussions

Start a nNew thread

Finding a running process
by Darrell Anderson 02 Mar '12

02 Mar '12

What is an appropriate way in TDE/Qt to query the process list to determine whether an app is running? Darrell

3 3

Missing includes after uic (was Re: tdelibs v3.5.13 doesn't build!)
by Aleksey Midenkov 02 Mar '12

02 Mar '12

Continuing to shed light on my issue. The same appeared on second host. Both have Ubuntu 'Precise' on it. GCC version is different: 4.6.2 vs 4.5.3. cmake version: 2.8.5 vs 2.8.7. Looks like these two are not the cause of the problem. I should really look at uic sources. Will remind what's going on: [ 18%] Building CXX object kdeui/CMakeFiles/kdeui-shared.dir/kshortcutdialog_simple.cpp.o /home/midenok/src/kde/tdelibs/build.debug/kdeui/kshortcutdialog_simple.cpp: In constructor ‘KShortcutDialogSimple::KShortcutDialogSimple(QWidget*, const char*)’: /home/midenok/src/kde/tdelibs/build.debug/kdeui/kshortcutdialog_simple.cpp:31:50: error: invalid use of incomplete type ‘struct QLabel’ Adding '#include <qlabel.h>' to kshortcutdialog_simple.cpp fixes it. But moves straight to similar error: [ 10%] Building CXX object tdeui/CMakeFiles/tdeui-shared.dir/kshortcutdialog_advanced.cpp.o /home/midenok/src/kde/tdelibs/build.debug/tdeui/kshortcutdialog_advanced.cpp: In constructor ‘KShortcutDialogAdvanced::KShortcutDialogAdvanced(QWidget*, const char*)’: /home/midenok/src/kde/tdelibs/build.debug/tdeui/kshortcutdialog_advanced.cpp:33:58: error: invalid use of incomplete type ‘struct QButtonGroup’ Looking at kshortcutdialog_simple.ui shows: <widget class="TQLabel" row="0" column="0"> I suppose uic must add any q*.h include to any TQ* class it finds in .ui?

2 4

Preparing update kdebase for the 3.5.13
by Slávek Banko 02 Mar '12

02 Mar '12

Hello I'm going to finish the next update to 3.5.13 kdebase. I added the following: Fix kdm_greet high CPU usage in SAK dialog and without SAK - perhaps the final solution of 100% CPU load in KDM. Upon recommendation by David Hare, I update the startkde script (based on commit 39fcb49a). Based on commit d409abdb from KDE 4.6, I rewrote the patch to hostname not displayed in the window title if it is the FQDN of localhost. (It does LibreOffice for example.) Does anyone have more ideas before they will go to compile the package in the PPA? Slávek --

2 1

TQLayout: Adding TQLabel/unnamed (child of TQButtonGroup/unnamed) to layout for KFocusConfig/kcmkwm
by Darrell Anderson 01 Mar '12

01 Mar '12

Different system. I'm seeing this message in my xsession log. The message occurs after I see messages about autostart apps and in the messages where kcompmgr seems to be starting. Messages immediately following: No composite extension trying '/root/.xcompmgrrc' as configfile finished parsing the config file Which probably indicates the error is associated with kcompmgr. The message itself is from tqt3 qlayout.cpp:1227: qWarning( "TQLayout: Adding %s/%s (child of %s/%s) to layout for " Any ideas how to resolve? Darrell

1 0

[tdmctl] Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'.
by Darrell Anderson 01 Mar '12

01 Mar '12

I'm seeing this message in my xsession log. I added the [tdmctl] in a patch I have not yet submitted to clarify the source of the message. ========== Bug No. 1: ========== I am starting X/TDE from the command line through the startx script. TDM is not running and should not be in the big picture anywhere. In the code I found only two apps that call tdmctl: the TDM greeter and tsak. I rebuilt tdebase with -DBUILD_TSAK=OFF. The message then disappeared from my xsession logs. Culprit found but next needed a coding solution. In tdebase/tdmlib/tdmtsak.cpp there are two calls to tdmctl. Seems this message could be handled more gracefully to avoid the mysterious xsession messages. Patching "2>/dev/null" in the source code and rebuilding without -DBUILD_TSAK=OFF again eliminated the messages. But is that what we want? I don't know the specific purpose for the error message. Possibly the message is useful, but seems a more graceful approach is to test whether TDM is running before trying to execute the tdmctl command. I presume tsak remains useful when a session is started from the command line for when a user locks the session. If so then again, there should be a test before each call whether TDM is running. The error does not appear when TDM is running. I think a simple TDM trap test is all that is needed. In C++ how do I perform the equivalent of ps ax | grep tdm? Should tsak be running when TDM is not? ========== Bug No. 2: ========== Both calls to tdmctl in tdmtsak use the format "tdmctl list" yet there is no "list" option in tdmctl --help. What is the "list" parameter supposed to do? ========== Bug No. 3: ========== When I built tdebase without tsak support (-DBUILD_TSAK=OFF), and in my tdmrc I have UseSAK=false, TDM starts with the dialog to press Ctrl-Alt-Del. That should not happen. I will submit a bug report but I'd appreciate some conversation about the topic before filing to make sure I'm not missing anything obvious. Darrell

1 0

Improving community involvement
by Darrell Anderson 29 Feb '12

29 Feb '12

I found this online article useful: http://stormyscorner.com/2012/02/its-scary-to-join-an-open-source-project.h… I found Boudewijn Rempt's (lead maintainer of krita) comments insightful: http://stormyscorner.com/2012/02/its-scary-to-join-an-open-source-project.h… 1. Can we modify our bugzilla to send an immediate reply to the filer: "Hi XXX [this information is available when the user creates an account], thank you for your bug report/enhancement request. Our general policy is to review and comment within one to two weeks on all reports submitted." 2. We have discussed review boards. First, we need two or three people beyond Tim who is willing to review new reports. (Yes, I volunteer. :) ) Thereafter, can we start a policy as Boudewijn suggested that within a week or two somebody on the Trinity teams responds with a comment? For example: "Thanks XXX for helping! This is a build/compile issue. I elevated the bug report to Blocker status." "Thanks XXX for helping! I have confirmed this bug. This is a serious usability issue. I elevated the bug report to Major status." "Thanks XXX for helping! Although irritating, this is a seldom used feature. We appreciate the frustration but we can get to this bug only after resolving those with a higher status." "Thanks XXX for helping! This sounds like a legitimate issue but manpower limits our ability to dig deeper at this time. If you don't hear anything further in two months please provide a comment." Perhaps at the end of each initial response for reports marked Blocker, Critical, and Major, we add the following statement: "Please know that except under unusual circumstances, bug reports marked Blocker, Critical, and Major will be resolved before the next official release." Seems another good policy is providing a decent explanation any time a bug report is resolved as WONTFIX. In that comment should be a statement that if anybody disagrees to post comments why they disagree. Lastly, we need people who have some skills to start helping with bugs. Many bugs do not require C++ skills but require makefile, cmake, automake skills, etc. Other bugs require little more than knowing how to use grep and sed once the solution is realized. People don't need commit access, just get the patches submitted. Somebody who is qualified will review the patch. Comments? Ideas? Darrell

2 2

ARM and Trinity and Raspberry Pi
by Calvin Morrison 29 Feb '12

29 Feb '12

Hello All, Raspberry Pi is on it's way to being launched and is no available for preorder. I think this product would be a good candidate for Trinity and ARM. Raspberry Pi is a $35 arm board. I am going to order one, any maybe one of you would be interested in purchasing them as well. Currently we have ARM builds, but no arm devices have been physically tested (right?) so I think this could be a opportunity for us to do that with a very low cost Calvin

2 1

Proposed starttde patch
by Darrell Anderson 29 Feb '12

29 Feb '12

Update starttde consistent with the changes made to tdelibs/tdesu/stub.cpp in bug report 766. The first snippet that is deleted is redundant and conflicts with the same $PATH test several lines later in the script. The second change ensures $PATH is consistent with stub.cpp, which places $PREFIX/bin in the path order just before /usr/bin and not blindly as first in the search path. If, oddly, /usr/bin is not in the search path then the script falls back to placing $PREFIX/bin first in the search path. ============================================================== diff -urN tdebase/starttde tdebase.new/starttde --- tdebase/starttde 2012-02-15 13:26:30.000000000 -0600 +++ tdebase.new/starttde 2012-02-26 19:08:44.000000000 -0600 @@ -76,15 +76,6 @@ fi fi -# In case we have been started with full pathname spec without being in PATH. -bindir=`echo "$0" | sed -n 's,^$/.*$/[^/][^/]*$,\1,p'` -if [ -n "$bindir" ]; then - case $PATH in - $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;; - *) PATH=$bindir:$PATH; export PATH;; - esac -fi - # Boot sequence: # # tdeinit is used to fork off processes which improves memory usage @@ -165,7 +156,14 @@ fi if [ -d $TDEDIR/bin ]; then if [ -z "`echo $PATH | grep \"$TDEDIR/bin\"`" ]; then - export PATH=$TDEDIR/bin:$PATH + # Respect the traditional path order. Don't blindly place $TDEDIR/bin + # first in the path. Only place $TDEDIR/bin before /usr/bin. This order is + # consistent with tdelibs/tdesu/stub.cpp. + if [ -n "`echo $PATH | grep \"/usr/bin\"`" ]; then + export PATH="`echo $PATH | sed \"s|/usr/bin|$TDEDIR/bin:/usr/bin|\"`" + else + export PATH=$TDEDIR/bin:$PATH + fi fi fi if [ -d $TDEDIR/share ]; then ============================================================== I have tested the change. If there are no objections then I would like to push the patch.

6 23

TDE kwrite improvement (add the sort from kate->tools->sort)
by David C. Rankin 29 Feb '12

29 Feb '12

Tim, All kate/kwrite are two of the crown jewels of tde. It would be nice to improve things as this project goes along. One simple idea is to provide the kate->tools->sort feature to kwrite. Is this the type of thing that warrants a feature request on the bug tracker to make sure it doesn't get lost or is there some other etherpad or tool that would be better. My .02 is it should go in the tracker as pads seem to come and go. -- David C. Rankin, J.D.,P.E.

3 11

tqt3 build failure In member function 'virtual int TQODBCResult::numRowsAffected() rror: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}
by David C. Rankin 29 Feb '12

29 Feb '12

Tim, Darrell, This is my first attempt a building tqt3 from the git tree and I've run into a problem. The good news it the build continued for quite some time. I wasn't timing, but is estimate 60+% of the build completed. The errors at the end of the build were: ../../../../src/sql/drivers/odbc/qsql_odbc.cpp: In member function 'virtual int TQODBCResult::numRowsAffected()': ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:983:60: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '2' to 'SQLRETURN SQLRowCount(SQLHSTMT, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp: In member function 'bool TQODBCResult::exec()': ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1109:43: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1127:50: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1149:43: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1163:43: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1177:43: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1192:12: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1210:16: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1227:12: error: cannot convert 'SQLINTEGER* {aka int*}' to 'SQLLEN* {aka long int*}' for argument '10' to 'SQLRETURN SQLBindParameter(SQLHSTMT, SQLUSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLSMALLINT, SQLULEN, SQLSMALLINT, SQLPOINTER, SQLLEN, SQLLEN*)' ../../../../src/sql/drivers/odbc/qsql_odbc.cpp: In member function 'virtual bool TQODBCDriver::beginTransaction()': ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1666:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../../src/sql/drivers/odbc/qsql_odbc.cpp: In member function 'bool TQODBCDriver::endTrans()': ../../../../src/sql/drivers/odbc/qsql_odbc.cpp:1716:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] make[3]: *** [.obj/qsql_odbc.o] Error 1 make[3]: Leaving directory `/build/src/tqt3/plugins/src/sqldrivers/odbc' make[2]: *** [sub-odbc] Error 2 make[2]: Leaving directory `/build/src/tqt3/plugins/src/sqldrivers' make[1]: *** [sub-sqldrivers] Error 2 make[1]: Leaving directory `/build/src/tqt3/plugins/src' make: *** [sub-plugins] Error 2 This looks liek issues with the odbc driver type definitions. Is this something that you are familiar with and can help me with it? Or, is this something you don't recognize and need me to send more to help narrow it down? Looks like the src/sql/drivers/odbc/qsql_odbc.cpp code is not happy. The good news, is that I've got the Arch build script developed to get (or should I say git) it this for :) Let me know. Thanks! -- David C. Rankin, J.D.,P.E.

2 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels