On July 1, 2018 7:41 PM, Mike Bird <mgb-trinity(a)yosemite.net> wrote:
FWIW I just tried that here and what I saw was
different.
(1) Possible typo but I have a dot before trinity in that path you cite.
yup, was indeed a typo.
(2) Upon clicking Monitor & Display I was prompted
for a root password.
(I usually get to these controls from RandR / Configure Displays / Admin Mode
which also requires a root password).
as does mine, now that i have set a root password. for some reason distributions
discourage the creation of a root password -- i cannot imagine how it enhances security,
except that it might discourage morons from logging in as root all the time -- and then
applications demand a password that doesn't exist. in the error i encountered, if i
clicked past it there was later the opportunity to enter administrator mode with (if
memory serves) the user password. (how any of this is an improvement over plain old su
escapes me, but i didn't write it and my opinion wasn't solicited).
though michael's script is actually a more elegant solution imho to the issue i was
tryingt to address. and i was mostly puzzled by the permissions on this single
configuration file -- seemed kind of odd.
(3) I made some changes and they affected three
files:
twinrulesrc
tdesurc
kdeglobals
once i saw it i realized i was familiar with that configuration screen and remembered that
many things one does there can break stuff in an especially inconvenient way -- so i am
happy to know which files to squirrel away some place in case i ever go experimenting with
it again.
(4) I checked all the systems I maintain. None had a
kiccconfigrc. They're
currently a mix of Devuan 1.0 and Devuan 2.0 and they're at TDE 14.0.5 as
I haven't started testing today's new version yet.
apparently it isn't as big a deal as it seemed. but thanks to the maintainers, anyway.
i hadn't heard of the file before, either. one of the things on the todo list was
rename it, log out, log back in, and see if a.) it made and difference and b.) if a new
one got generated and if so what its permissions were. (fortunately, alt-ctrl-f1 on the
gpd gives us a nice normal text screen, unlike the gemini which is, yes, weird. (and part
of the reason i'm about to dclare linux on the gemini a noble but ultimately useless
exercise and switch it all over to sailfish.)
(5) Again, on all of the systems I maintain,
both /home/*/.trinity/share/config/ and all the files therein are owned
by the relevant user's owner and group.
At a guess you at sometime in the past logged into TDE (or a predecessor)
as root. I see no reason not to fix the ownership of that file. I don't
currently have a GIT of TDE handy so I can't figure out why you might have
a kiccconfigrc while I don't but I wouldn't worry about that. Maybe my test
didn't touch the exact area you're working with. Also I don't understand
why you were not prompted for a root password.
now this *is* a puzzle, the only thing i can think of is a couple of scripts that one
runs, if one is not foolhardy, on the gpd after any significant upgrade (desktop, kernel)
to protect the device from any waywardness the upgrade might have introduced. they're
done by the guy who has tuned various linuces for the gpd, and a good job he has done,
too:
https://github.com/stockmind/gpd-pocket-ubuntu-respin
because none of the various iso images have trinity as the desktop, they're configured
to be especially hospitable to unity; there is a "kde" switch that can be
applied, but surely that is aimed at the wants and desires of current kde. i have not seen
the switch making any difference with TDE.
and that having been said, i hope you get this before the snows of winter -- protonmail
has been under a really orchestrated dds attack for a couple of days now, so the mail is
in fits and starts, and in the lulls i ponder happily the punishments one wishes on the
perpetrators . . . and conclude that while nothing available in this life would suffice,
use of a baseball bat as a dental instrument would be a nice preview.
dep
Sent withProtonMailSecure Email. Because privacy matters.