tde-devels

devels@trinitydesktop.org

3753 discussions

by Slávek Banko

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 --

12 years, 11 months

TQLayout: Adding TQLabel/unnamed (child of TQButtonGroup/unnamed) to layout for KFocusConfig/kcmkwm

by Darrell Anderson

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

12 years, 11 months

[tdmctl] Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'.

by Darrell Anderson

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

12 years, 11 months

Improving community involvement

by Darrell Anderson

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

12 years, 11 months

ARM and Trinity and Raspberry Pi

by Calvin Morrison

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

12 years, 11 months

Proposed starttde patch

by Darrell Anderson

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.

12 years, 11 months

TDE kwrite improvement (add the sort from kate->tools->sort)

by David C. Rankin

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.

12 years, 11 months

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

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.

12 years, 11 months

Could not load library! Trying exec....

by Darrell Anderson

I'm seeing these messages in my xsession log. The standard as-is message looks like that in the subject line. My messages now look like this: [kinit] Could not load library (artswrapper)! Trying exec... [kinit] Could not load library (/usr/local/bin/run_conky)! Trying exec... [kinit] Could not load library (/usr/bin/VBoxClient-all)! Trying exec... I added the [kinit] prefix in a patch I have not yet submitted to clarify the source of the message. I also patched the error string with the %s parameter to identify the object of the message. The message sort of makes sense. kinit is trying to load/run/launch something that is not a library but is an executable. Browsing the source code (tdelibs/kinit/kinit.cpp) indicates there is a distinction between libraries and executables. Therefore I'm wondering whether the message should be displayed, clutters the xsession log, or should be revised. As you can see from the as-is format, the message is not informative at all. Worse, the exclamation mark is misleading and needlessly disturbing to anybody reading the log. An exclamation mark should indicate something serious that needs attention but that is not the case here. The message is somewhat informative but is not emergency. If the message is valuable then rewording would help. Possibly something like: [kinit] artswrapper is an executable and not a library. Launching with exec... If there are no objections then I'd like to patch that error string as above and push to GIT. Darrell

12 years, 11 months

TQLayout "unnamed" added to TQFrame "unnamed", which already has a layout"

by Darrell Anderson

I'm seeing this message in my xsession log. The message occurs during the session shutdown. Watching the log through tail, the message occurs after selecting any logout option. I believe the error is caused by the "Saving your sessions" dialog. I enabled logout confirmation and the error does not appear until after I confirm the logout, which is when the "Saving your sessions" dialog appears. The message itself is in TQt3 qabstractlayout.cpp:609: qWarning( "TQLayout \"%s\" added to %s \"%s\", which already has a" " layout", TQObject::name(), parent->className(), parent->name() ); Any ideas what to look for in the code and how to resolve? Darrell

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels