tde-users

users@trinitydesktop.org

20 participants
4181 discussions

Konqueror doesn't mount drives - correct thread

by J. Drahun

Sorry for the previous hijacked thread. The problem is I get error instead of mounting a drive: Unable to mount this device. Potential reasons include: Improper device and/or user privilege level Corrupt data on storage device Technical details: org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation I checked my groups. They are: disk, floppy, cdrom, vboxusers, root. Aren't they enough?

8 years, 3 months

tdenetworkmananger stops to display the «connect» icon

by Uwe Brauer

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

8 years, 3 months

Re: [trinity-users] Konqueror in root, kedit not possible

by andre_debian＠numericable.fr

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é

8 years, 3 months

Konqueror in root, kedit not possible

by andre_debian＠numericable.fr

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é

8 years, 3 months

Re: [trinity-users] Konqueror in root, kedit not possible

by andre_debian＠numericable.fr

8 years, 3 months

serious problem with wifi cannot connect anymore

by Uwe Brauer

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

8 years, 3 months

tdenetworkmanager some progress

by Uwe Brauer

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

8 years, 3 months

[SOLVED] Undefined color: "WINDOW_FOREGROUND" and the old dot.trinity

by A M

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.

8 years, 3 months

Undefined color: "WINDOW_FOREGROUND" and the old dot.trinity

by A M

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.

8 years, 4 months

REPOST: Undefined color: "WINDOW_FOREGROUND" and the old "dot.trinity"

by A M

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.

8 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

tde-users