tde-devels

devels@trinitydesktop.org

9 participants
3818 discussions

kdesktoplockcontrol can never work
by Slávek Banko 18 May '13

18 May '13

Hi all, during the research around kdesktop_lock I found that kdesktoplockcontrol (formerly pipe, now socket) can never work. Pipe / socket is created in folder /tmp/tdesocket-global, but into this folder can enter and write only 'root'. The folder is created with permissions 0644, which is a bit unusual for the folders. I also noticed (when I was allowed to write to the folder tdesocket-global also for others) that kdesktoplockcontrol and kdesktoplockcontrol_out are created but never removed. Please can anyone confirm my findings? How kdesktoplockcontrol was intended? Currently obviously can never work. Slavek

2 2

Planned maintenance
by Timothy Pearson 18 May '13

18 May '13

All, Due to scheduled maintenance, all TDE services will be either fully unavailable or partially offline starting late 05/17/2013. Planned service restoration date is 05/18/2013. Thank you for your patience, Timothy Pearson Trinity Desktop Project

1 1

Re: [trinity-devel] [Fwd: [trinity-users] xdg-open issue]
by Darrell Anderson 17 May '13

17 May '13

>Took a while to investigate. > >The xdg-open app is a shell script, part of xdg-utils. On >Slackware >the file is installed to /usr/bin. > >The script offers no support for Trinity. Perusing the script >indicates a poorly written script rather than anything robust. No >error-checking or "idiot-proofing" at all. The script provides no >optional methods of detecting the desktop. The presumed desktops >are hard-coded and the "generic" functions are poorly written. > >On my system anything I try to open wih xdg-open is opened in my >default browser, Firefox. > >I tested in KDE4 and everything works but only because KDE is one >of the few supported desktops. > >I have no idea why GIMP is opened. The user could edit xdg-open >and >add some echo statements to help debug. > >Setting DE=kde doesn't work in my GIT setup. The reason is in GIT >we changed the environment variables, but 3.5.13.x still uses KDE >environment variables. Hence the partial success. > >Other than submitting a patch for xdg-open to upstream I doubt >there is little we can do. By the way, xdg-mime is another script from xdg-utils and the similar presumptions are in that script. The only supported desktops are KDE, GNOME, Xfce, and LXDE. Otherwise the desktop is presumed to be "generic." The Arch folks have a discussion about xdg-utils and they say xdg- open is broken. https://wiki.archlinux.org/index.php/Default_Applications Searching the web for "xdg-open" indicates the script has been broken through the years. As I wrote, the scripts are not robust and contain limited presumptions. :-) Darrell

1 0

Re: [trinity-devel] [Fwd: [trinity-users] xdg-open issue]
by Darrell Anderson 17 May '13

17 May '13

On Fri, 17 May 2013 13:18:17 -0500 "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> wrote: >Darrell, as our resident XDG/desktop file expert, any ideas on >this one? ;-) Took a while to investigate. The xdg-open app is a shell script, part of xdg-utils. On Slackware the file is installed to /usr/bin. The script offers no support for Trinity. Perusing the script indicates a poorly written script rather than anything robust. No error-checking or "idiot-proofing" at all. The script provides no optional methods of detecting the desktop. The presumed desktops are hard-coded and the "generic" functions are poorly written. On my system anything I try to open wih xdg-open is opened in my default browser, Firefox. I tested in KDE4 and everything works but only because KDE is one of the few supported desktops. I have no idea why GIMP is opened. The user could edit xdg-open and add some echo statements to help debug. Setting DE=kde doesn't work in my GIT setup. The reason is in GIT we changed the environment variables, but 3.5.13.x still uses KDE environment variables. Hence the partial success. Other than submitting a patch for xdg-open to upstream I doubt there is little we can do. Darrell

1 0

[Fwd: [trinity-users] xdg-open issue]
by Timothy Pearson 17 May '13

17 May '13

Darrell, as our resident XDG/desktop file expert, any ideas on this one? ;-) Tim ---------------------------- Original Message ---------------------------- Subject: [trinity-users] xdg-open issue From: "Mag. Dr. Nikolaus Klepp" <office(a)klepp.biz> Date: Fri, May 17, 2013 3:30 am To: trinity-users(a)lists.pearsoncomputing.net -------------------------------------------------------------------------- Hi all! I just came around an anoying xdg issue: $ xdg-open justapdf.pdf This opens a pdf, but with Gimp! I fiddeled around with gimp.desktop without success. I fiddeled around with xdg-mime without success: $ xdg-mime query default application/pdf /opt/trinity/share/applications/kde/kpdf.desktop but it opens gimp. IMO xdg-* is quite broken. :-( Now the only workaround I came up with is setting the environment variabe DE to kde: export DE=kde Then xdg-open uses kfmclient and that calles the kpdf. Now, would it be possibel to let TDE set that variable by default or am I missing a vital point? Nik --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

1 0

Re: [trinity-devel] [kinit wrapper] -> [tdeinit wrapper]
by Darrell Anderson 16 May '13

16 May '13

>> I notice in my xsession-error log a mixture of [tdeinit] and [kinit >> wrapper] identifiers. To remain consistent, should we change [kinit >> wrapper] to [tdeinit wrapper]? > >Yes, unifying name sounds like a good idea. I searched the entire source tree. To help improve consistency I don't see why tdelibs/kinit and kinit.cpp can't be renamed to tdeinit. Only a few changes required and they only affect compiling. The tde-i18n module has a lot of po files that would need updating, but all of that is just text. Similarly, I searched the sources and don't see why kdessh and kdelirc, both from tdeutils, can't be renamed to tdessh and tdelirc. I can create some patches and test unless there are serious objections. Lastly, there are many README files in the sources, most containing incorrect references to "KDE" or "KDE3." We probably should update those files with proper rebranding references. Not the text used in historical contexts, just the text used in real-time references. Darrell

2 1

Re: [trinity-devel] Tim: Unable to build a simple Qt3 test.
by Darrell Anderson 15 May '13

15 May '13

>I updated my GIT repo this morning. After building tqt3, I receive > >the following build failure when trying to build tqtinterface. I >noticed the failure last night when I tried to rebuild tqt3 and >tdeutils. I then saw the same failure trying to build tdeutils. >Something changed when the 1508 patches were merged to GIT, but I >don't know what. > >-- Checking for Qt3... >-- QT_PREFIX_DIR is set to QTDIR >-- QT_PREFIX_DIR : /opt/trinity >-- QT_INCLUDE_DIR: /opt/trinity/include >-- Native TQt3 detected >-- QT_LIBRARY_DIR: /opt/trinity/lib >-- QT_BINARY_DIR : /opt/trinity/bin >-- MOC_EXECUTABLE: /opt/trinity/bin/tqmoc (using Qt 3.5.0) >-- UIC_EXECUTABLE: /opt/trinity/bin/tquic >-- Performing Test HAVE_USABLE_QT3 >-- Performing Test HAVE_USABLE_QT3 - Failed >-- Looking for native TQt3... >-- Performing Test HAVE_USABLE_QT3 >-- Performing Test HAVE_USABLE_QT3 - Failed >CMake Error at cmake/modules/TDEMacros.cmake:23 (message): > ################################################# > > Unable to build a simple Qt3 test. > > ################################################# >Call Stack (most recent call first): > ConfigureChecks.cmake:194 (tde_message_fatal) > CMakeLists.txt:29 (include) > > >-- Configuring incomplete, errors occurred! Update: Reversing commit 9a4765a6 and rebuilding tqt3 avoids the build error with tqtinterface. I'll guess that something in the automated qt3-tqt3 update did not convert correctly? Darrell

1 0

Tim: Unable to build a simple Qt3 test.
by Darrell Anderson 15 May '13

15 May '13

Tim, I updated my GIT repo this morning. After building tqt3, I receive the following build failure when trying to build tqtinterface. I noticed the failure last night when I tried to rebuild tqt3 and tdeutils. I then saw the same failure trying to build tdeutils. Something changed when the 1508 patches were merged to GIT, but I don't know what. -- Checking for Qt3... -- QT_PREFIX_DIR is set to QTDIR -- QT_PREFIX_DIR : /opt/trinity -- QT_INCLUDE_DIR: /opt/trinity/include -- Native TQt3 detected -- QT_LIBRARY_DIR: /opt/trinity/lib -- QT_BINARY_DIR : /opt/trinity/bin -- MOC_EXECUTABLE: /opt/trinity/bin/tqmoc (using Qt 3.5.0) -- UIC_EXECUTABLE: /opt/trinity/bin/tquic -- Performing Test HAVE_USABLE_QT3 -- Performing Test HAVE_USABLE_QT3 - Failed -- Looking for native TQt3... -- Performing Test HAVE_USABLE_QT3 -- Performing Test HAVE_USABLE_QT3 - Failed CMake Error at cmake/modules/TDEMacros.cmake:23 (message): ################################################# Unable to build a simple Qt3 test. ################################################# Call Stack (most recent call first): ConfigureChecks.cmake:194 (tde_message_fatal) CMakeLists.txt:29 (include) -- Configuring incomplete, errors occurred! Darrell

1 0

[kinit wrapper] -> [tdeinit wrapper]
by Darrell Anderson 15 May '13

15 May '13

I notice in my xsession-error log a mixture of [tdeinit] and [kinit wrapper] identifiers. To remain consistent, should we change [kinit wrapper] to [tdeinit wrapper]? Darrell

2 1

Re: [trinity-devel] kdesktoplockcontrol can never work
by Darrell Anderson 15 May '13

15 May '13

>during the research around kdesktop_lock I found that >kdesktoplockcontrol >(formerly pipe, now socket) can never work. Pipe / socket is >created in >folder /tmp/tdesocket-global, but into this folder can enter and >write >only 'root'. The folder is created with permissions 0644, which is >a bit >unusual for the folders. > >I also noticed (when I was allowed to write to the folder >tdesocket-global >also for others) that kdesktoplockcontrol and >kdesktoplockcontrol_out are >created but never removed. > >Please can anyone confirm my findings? >How kdesktoplockcontrol was intended? >Currently obviously can never work. I'm using pre R14 from GIT. I start X from the command line with startx and not in graphical mode with TDM. Therefore during a normal user session, /tmp/tdesocket-global does not exist because I am not using TDM. When I lock the screen I see the following created: $TMP/tde-$USER/kdesktop_lock_lockfile /tmp/tdesocket-global I do not see any files named kdesktoplockcontrol or kdesktoplockcontrol_out. There are no files in /tmp/tdesocket-global. /tmp/tdesocket-global is created with 0644 $USER:$USER permissions yet through konqueror and the command line I cannot access the directory. From my perspective, the /tmp/tdesocket-global directory should never be created when a user locks the screen, which is a user- based action, not global. Second, seems to me whenever /tmp/tdesocket-global is created the ownership should always be root:root, not $USER:$USER. Third, permissions should be 0755, not 0644. I remember raising the topic of housekeeping a long time ago. When I experiment with TDM to help with nominal testing, I notice that /tmp/tdesocket-global remains across a reboot, as does files in that directory. Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels