tde-devels May 2013

devels@trinitydesktop.org

10 participants
54 discussions

Start a nNew thread

3.5.13.2

by Darrell Anderson

What is the status of 3.5.13.2? Darrell

10 years, 11 months

Notice before updating the common module 'admin'

by Slávek Banko

Hi all. To solve build with automake 1.13 (see bug 1520) I'm going to push the patch into common module 'admin'. This will subsequently lead to the updating of almost all other modules. And the resulting rebuild almost all packages. Tim, because it is fast approaching the conclusion of version 3.5.13.2, I will soon completely rebuild all packages for the final version => I'll also have a heavy burden for the build-farm. Slavek

10 years, 11 months

Re: [trinity-devel] Window settings broken?

by Darrell Anderson

>I rebuilt a full package set on Sunday. Today I notice kpdf opens >in a tiny 470x285 window. Maximzing kpdf, then closing, then >reopening results in the same tiny window. Forced settings fail to > >override. Previously kpdf always opened maximum screen for me. >kpdf >now seems to ignore the kpdfrc [MainWindow] settings, which I >verified have not changed. I don't know whether this behavior is >limited to kpdf or affects all apps. > >I believe this is a very new bug. I'm asking for confirmation >before filing a report. I haven't yet tried to try to bisect when >this behavior began by reinstalling packages from older build >sets. The problem is caused by building tqt3 with the -glibmainloop configure option. Building without that option results in kpdf opening correctly. Darrell

10 years, 11 months

Window settings broken?

by Darrell Anderson

I rebuilt a full package set on Sunday. Today I notice kpdf opens in a tiny 470x285 window. Maximzing kpdf, then closing, then reopening results in the same tiny window. Forced settings fail to override. Previously kpdf always opened maximum screen for me. kpdf now seems to ignore the kpdfrc [MainWindow] settings, which I verified have not changed. I don't know whether this behavior is limited to kpdf or affects all apps. I believe this is a very new bug. I'm asking for confirmation before filing a report. I haven't yet tried to try to bisect when this behavior began by reinstalling packages from older build sets. Thanks. :) Darrell

10 years, 11 months

kdesktoplockcontrol can never work

by Slávek Banko

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

10 years, 11 months

Planned maintenance

by Timothy Pearson

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

10 years, 11 months

Re: [trinity-devel] [Fwd: [trinity-users] xdg-open issue]

by Darrell Anderson

>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

10 years, 11 months

Re: [trinity-devel] [Fwd: [trinity-users] xdg-open issue]

by Darrell Anderson

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

10 years, 11 months

[Fwd: [trinity-users] xdg-open issue]

by Timothy Pearson

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

10 years, 11 months

Re: [trinity-devel] [kinit wrapper] -> [tdeinit wrapper]

by Darrell Anderson

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

10 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels May 2013