tde-devels

devels@trinitydesktop.org

4 participants
3812 discussions

Start a nNew thread

3.5.13.2
by Darrell Anderson 22 May '13

22 May '13

What is the status of 3.5.13.2? Darrell

3 6

Notice before updating the common module 'admin'
by Slávek Banko 22 May '13

22 May '13

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

1 0

Re: [trinity-devel] Window settings broken?
by Darrell Anderson 21 May '13

21 May '13

>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

1 0

Window settings broken?
by Darrell Anderson 21 May '13

21 May '13

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

1 0

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

19 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 18 May '13

18 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels