tde-devels

devels@trinitydesktop.org

6 participants
3784 discussions

Francois: tderadio presets
by Darrell Anderson 23 May '13

23 May '13

Francois, In bug report 1352 we updated the tderadio presets. I now believe the original patch was corrupted. Try the following search in the tderadio sources: grep -rn "ï¿½" . Thanks. Darrell

3 2

Updating generic documentation files (AUTHORS, COPYING, README, etc.)
by Darrell Anderson 22 May '13

22 May '13

I was looking into updating the README files with respect to non- historical branding references to KDE/KDE3. So as to not incorrectly update historical references, updating those files probably is a file-by-file project. There are 966 README files and that basically stopped my motivation for updating the files. Further, there are 287 AUTHORS files, 275 ChangeL|log, 298 COPYING*, 173 INSTALL, 116 NEWS, 7 PACKAGING, 11 RELEASE*, and 366 TODO. I suspect many --- possibly most --- of these text files provide little to no value anymore. The AUTHORS files are redundant of the Trinity About dialogs, likely all of the change log files have not been updated since several releases before 3.5.10 and certainly have not been updated in the Trinity era, the COPYING* files are redundant to almost all *.cpp files, the INSTALL files are irrelevant at best, the NEWS files all are outdated, PACKAGING files obsolete, RELEASE files obsolete. There might be a handful of useful ideas in some of the TODO files, but likely they could be consolidated into a wiki page or bugzilla enhancement requests --- not that we have the available personnel to accomodate most of those wish list items. Should we delete most of these text files? Comments? Darrell

1 0

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 20 May '13

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels