tde-users

users@trinitydesktop.org

4290 discussions

tdenetworkmananger stops to display the «connect» icon
by Uwe Brauer 24 Sep '16

24 Sep '16

Hi I purged and reinstalled network-manager-tde Tdenetworkmananger connects but does not display the nm_signal_100.png or similar This is really annoying (but better than not connect) Any ideas? Uwe Brauer

3 2

Re: [trinity-users] Konqueror in root, kedit not possible
by andre_debian＠numericable.fr 23 Sep '16

23 Sep '16

On Thursday 22 September 2016 21:58:50 Kate Draven wrote: > > I open my TDE-trinity session with the user "andre". > > If I use Konqueror as files-manager, with the user "root", > > (to modify root text files), > > I cannot open a text file with kedit or kwrite. > > "TDEInit cannot launch kedit". > > In user "andre", it works fine. > > André > Hi André > When that happens to me, I usually delete the files > .xsession-errors > .Xauthority > As root in konq, then close it up and start over. Works fine after that. > If you see more than one .Xauthority, clear them all. > I hope this helps, Kate I deleted ".xsession-errors" and ".Xauthority" in the "andre" account, (/home/andre/) it worked, I could open text files with kedit. And now, after booting my PC in the morning, I cannot do it. "TDEInit cannot launch kedit". On Friday 23 September 2016 03:45:11 Dave Lers wrote: > > If I use Konqueror as files-manager, with the user "root" : > Do you use su Konqueror as user andre (menu > System > SuperUser > > Konqueror)? The two solutions : System > SuperUser > Konqueror and by creating an icon on the desktop, with : Excecute with a different user = root. Now, the both don't work to open text files with kedit. Thanks. André

2 1

Konqueror in root, kedit not possible
by andre_debian＠numericable.fr 23 Sep '16

23 Sep '16

Hello, I open my TDE-trinity session with the user "andre". If I use Konqueror as files-manager, with the user "root", (to modify root text files), I cannot open a text file with kedit or kwrite. "TDEInit cannot launch kedit". In user "andre", it works fine. Thanks. André

4 3

Re: [trinity-users] Konqueror in root, kedit not possible
by andre_debian＠numericable.fr 22 Sep '16

22 Sep '16

1 0

serious problem with wifi cannot connect anymore
by Uwe Brauer 21 Sep '16

21 Sep '16

Hi This problem is much more serious than my other one, since I only have for coming days wifi available, however one laptop does not connect anymore. I am on Kubuntu 14.04 and the connection does not work neigher with the plasma networkmananger nor with tdenetworkmanager. I deleted a link from /run/resolvconf/resolv.conf to /etc/resolv.conf Then the following file was created as /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 search telefonica.net Even as root I cannot anymore modify nor delete it, I wanted to set again the link mentioned above but without success. When I start tdenetworkmanager I obtain the following error (no idea whether this related to the above problem) any help is strongly appreciated since outwise I have to reinstall everything. Uwe Brauer

3 2

tdenetworkmanager some progress
by Uwe Brauer 20 Sep '16

20 Sep '16

Hi I run Sudo dpkg-reconfigure resolvconf which did not help, but I deleted the line dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf I still obtain the message of the sort ,---- | [TDE NM Backend ERROR] | [/tmp/buildd/tdelibs-trinity-14.0.4~pre12/tdecore/tdehw/networkbackends/network-manager/network-manager.cpp:1823] | Attempting to access the network-manager VPN service returned: | org.freedesktop.DBus.Error.ServiceUnknown: The name | org.freedesktop.NetworkManager.VPN.Plugin was not provided by any | .service files [TDE NM Backend ERROR] | [/tmp/buildd/tdelibs-trinity-14.0.4~pre12/tdecore/tdehw/networkbackends/network-manager/network-manager.cpp:1823] | Attempting to access the network-manager VPN service returned: | org.freedesktop.DBus.Error.ServiceUnknown: The name | org.freedesktop.NetworkManager.VPN.Plugin was not provided by any | .service files `---- but it does connect! However the icon does not change to the usual connect sign (while in my other with kubuntu 14.04/trinity everything works smoothly) I tried sudo dpkg-reconfigure network-manager-tde did not really work, I can disable wireless but I cannot switch to offline and then back to online mode, the icon looks that if there is only offline activated. I really don't want to reinstall but this is quite a bit annoying. Thanks Uwe Brauer

1 0

[SOLVED] Undefined color: "WINDOW_FOREGROUND" and the old dot.trinity
by A M 20 Sep '16

20 Sep '16

The issue was solved, thanks to the most useful comments by three list participants. The first advice, by Gerhard Zintel, was a suggestion to simply uncheck one of the preferences via the TDE Control Center: *" I had the same issue before. I cannot clearly remember but try to un-check "Apply colors to non-TDE applications" in TDE Control Center => Appearence & Themes => Colors. "* That immediately worked, thanks Gerhard! But then the next advice came from Nick Koretsky which also commented on the Gerhard's advice: *That's a bad solution - this checkbox is unfortunately named, it should be named "apply styles' - it govern not only colors, but also button styles, button placements and fonts in gtk apps The correct solution is to add following to you .xsession file ( sleep 10 xrdb -all -query|sed -e 's#[A-Z_]*BACKGROUND# gray90#' \* *-e 's#[A-Z_]*FOREGROUND# Black#' \ -e 's#[A-Z_]*HIGHLIGHT# White#' \ -e 's#[A-Z_]*LOWLIGHT# Black#'|xrdb -merge ) &* I tried this as well, and it works and seems in fact to be more appropriate for our environment. I've applied it by adding to the system-wide script that is executed at login and does it one time per session. It works pretty well (and has no impact on gtk applications). So we'll stick to this method. Finally, another advice came from "iadest": *Hello Try to edit ~/.Xresourced adding: *.WINDOW_FOREGROUND: black Then execute command: xrdb -merge ~/.Xresources I had similar problems with Perl/Tk and *.BACKGROUND color. Maybe this solution will work for Emacs too.* *MCbx* As this solution was basically quite similar to that of Nick's which was already nicely implemented, I did not try this.. In any case, these advices saved me a day. Thanks a lot for all those who replied! Andy. ------ ORIGINAL MAIL ------ Hello, I am happily using Trinity since a couple of years, and never had any insolvable issues with it. However, currently I am standing before a "blocker" confguration issue, and would highly appreciate some useful hint/help from the community. This is what happens: - I've installed a remote Centos 7 host equipped with a complete Trinity 14.0.3-1.el7.x86_64 desktop. The desktop is being accessed via Freenx and, as this machine will also be used by people with French and German keyboards, the working keyboard switcher apllet present in the 14.03 distro seems to become a really indispensable feature. - Everyrthing seemingly works well, the desktop looks beautiful, but very soon I discovered that there is a couple off issues. In particular, I cannot start emacs on this machine, it ends up with this error: [ Undefined color: "WINDOW_FOREGROUND" ]. Atfter a bit of googling, it came out that this is a known problem, and it has to do with KDE configuration. People then stated the the issue was essentially solved by simply migrating to the updated version of KDE and no other clues were provided. - After quite some time spent on searches, I decided to replace "dot.trinity" and "dot.tderc" with their well-customized versions taken from one of my working Centos 6 machines with Trinity 3.5.13-15.1 (which in turn, inherited them from Centos 5 with KDE 3.5.4-1). Surprise: emacs worked like a charm, and also some other issues like remote app submission not working before were gone! - The old "dot.trinity" configuration, however, has an outdated K-menu, and it does not allow me to add the Keyboard Switcher applet. Thus I have a sort of a "blocker" situation. On one hand, I am almost done with an old "dot.trinity" and may dig in further and try to replace the K-menu under dot.trinity/share/config (this would hopefully give me a chance to add the switcher). Or I have to dig more into the issue of the brand-new install (no good ideas of where to begin, though..) The funny thing is, there is in fact an almost-working solution. Thus it is only a TDE configuration issue: something is present, or missing, or set up in a wrong way.. Thanks a lot ahead for any there or a useful hint on how to proceed! Andy.

2 1

Undefined color: "WINDOW_FOREGROUND" and the old dot.trinity
by A M 20 Sep '16

20 Sep '16

Hello, I am happily using Trinity since a couple of years, and never had any insolvable issues with it. However, currently I am standing before a "blocker" confguration issue, and would higly appreciate some useful hint/help from the community. This is what happens: - I have installed a remote Centos 7 host eqipped with a complete Trinity 14.0.3-1.el7.x86_64 desktop. The desktop is being accessed via Freenx and, as this machine will also be used by people with French and German keyboards, the working keyboard switcher apllet present in the 14.03 distro seems to become a rellay indispensable feature. - Everyrthing seemingly works well, the desktop looks beautiful, but very soon I discovered discovered that there is a couple off issues. In particular, I cannot start emacs on this machine, it ends up with this error: [ Undefined color: "WINDOW_FOREGROUND" ]. Atfter a bit of googling, it came out that this is a known As well, I had an issue submittig a graphical app I have a well-working Trinity desktop on Centos 6 with Trinity 3.5.13-15.1, and Andy.

4 3

REPOST: Undefined color: "WINDOW_FOREGROUND" and the old "dot.trinity"
by A M 20 Sep '16

20 Sep '16

REPOSTING, THE PREVIOUS MAIL WAS INCOMPLETE, SORRY.. Hello, I am happily using Trinity since a couple of years, and never had any insolvable issues with it. However, currently I am standing before a "blocker" confguration issue, and would highly appreciate some useful hint/help from the community. This is what happens: - I've installed a remote Centos 7 host equipped with a complete Trinity 14.0.3-1.el7.x86_64 desktop. The desktop is being accessed via Freenx and, as this machine will also be used by people with French and German keyboards, the working keyboard switcher apllet present in the 14.03 distro seems to become a really indispensable feature. - Everyrthing seemingly works well, the desktop looks beautiful, but very soon I discovered that there is a couple off issues. In particular, I cannot start emacs on this machine, it ends up with this error: [ Undefined color: "WINDOW_FOREGROUND" ]. Atfter a bit of googling, it came out that this is a known problem, and it has to do with KDE configuration. People then stated the the issue was essentially solved by simply migrating to the updated version of KDE and no other clues were provided. - After quite some time spent on searches, I decided to replace "dot.trinity" and "dot.tderc" with their well-customized versions taken from one of my working Centos 6 machines with Trinity 3.5.13-15.1 (which in turn, inherited them from Centos 5 with KDE 3.5.4-1). Surprise: emacs worked like a charm, and also some other issues like remote app submission not working before were gone! - The old "dot.trinity" configuration, however, has an outdated K-menu, and it does not allow me to add the Keyboard Switcher applet. Thus I have a sort of a "blocker" situation. On one hand, I am almost done with an old "dot.trinity" and may dig in further and try to replace the K-menu under dot.trinity/share/config (this would hopefully give me a chance to add the switcher). Or I have to dig more into the issue of the brand-new install (no good ideas of where to begin, though..) The funny thing is, there is in fact an almost-working solution. Thus it is only a TDE configuration issue: something is present, or missing, or set up in a wrong way.. Thanks a lot ahead for any there or a useful hint on how to proceed! Andy.

1 0

Re: [trinity-users] konqueror classifies files with no extension as octet-stream
by Nathan Rugg 18 Sep '16

18 Sep '16

On 09/17/2016 09:57 AM, Kate Draven wrote: >> I recently installed Trinity and everything is going well except that >> konqueror classifies all files with no extension as octet-stream. Any >> idea how to fix that problem? If I use `file` from the command line like >> this `file --mime-type FILENAME`, it will give the correct mime type. >> GTK programs also work correctly. It appears to be something specific >> with TDE. >> >> Thanks. >> >> Nathan > Use kcontrol or tcontrol? Either way go to file associations. Usually under > kde/TDE Components. I don't have a TDE computer in front of me now so I'm > only going be memory. This should be enough to get you there. > > However, I have to point out that it seems odd that the distro can't identify > the files. > > Hope this helps, > > Kate Hi Kate, Thanks for the reply. I've looked in the File Associations settings, but I can't see a way to fix files without an extension. Files with an extension are recognized just fine. But konqueror should be able to check the magic number thing to determine the type of a file, but something caused this to stop working.

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

tde-users