Felix Miata posted on Mon, 15 Apr 2013 12:53:16 -0400 as excerpted:
> In openSUSE,
> /usr/share/kde4/apps/plasma/layout-templates/org.kde.plasma-
desktop.defaultPanel/contents/layout.js
> contains this line:
>
> panel.height = screenGeometry(panel.screen).height > 899 ? 35 : 27
>
> I always want 25%-33% more panel height than KDE developers think is
> appropriate, so I have been changing it to
>
> panel.height = screenGeometry(panel.screen).height > 899 ? 47 : 35
>
> Each system update that included this file was overwriting my change. To
> compensate, I've been setting the immutable flag on the file. But this
> causes rpm failure when overwrite fails, and the updated package
> according to the package management system remains available for
> installation, not installed.
>
> What and where can be done to globally change the default height so that
> for each new user creation it starts out taller when KDE is first
> launched, but without causing this recurring updates headache caused by
> using the immutable flag?
>
> Note: all this would be unnecessary if
> https://bugs.kde.org/show_bug.cgi?id=229984 were fixed, so that
> personalizing panel height, as in KDE3, to a fixed and known value were
> possible without spending 20 minutes stabbing the panel with a mouse
> until the right number appeared at random.
I definitely agree with you that there should be a spinbox or similar
widget with the specific pixel size, so people don't have to fiddle with
mouse dragging if they want a specific size. They should be able to
simply set a specific size if that's what they want, and they shouldn't
have to figure out which text-based-config-file it's in and hand-edit
that to do it.
However, Todd's absolutely correct in the bug. That setting is per-
panel, not kde-global (let alone system global), so it should be in panel
settings, not in kde settings (which as I've said many times, are NOT in
general system settings, as they're mostly per-user settings for kde
only, having little to do with non-kde/non-X, except in the occasional
exception case, so the kde3 name, kcontrol, was way more accurate and way
less confusing than kde4's "systemsettings" that aren't actually SYSTEM!,
but be that as it may...). So were it me, as the bug is currently
worded, it'd get Resolved/WONTFIX, since you're insisting on the kde
settings placement, but that's too bad, as while I strongly disagree with
the kde settings placement, I equally strongly agree that there should be
a text-based size setting method, WITHOUT having to manually edit the
config file to get it.
Meanwhile....
It's worth noting that kde's configuration setup is extremely flexible,
and that there's specific provision for machine or site level
configuration as well as upstream kde, distro, and user level config.
The machine/site config level appears to be just what you need at this
point, so you can let the distro packages update without killing your
site config, and the site config can still be overruled by individual
users, if desired.
The documentation for all that is in kde's sysadmin guide, on techbase:
http://techbase.kde.org/KDE_System_Administration
Specifically, check out the KDE Filesystem Hierarchy page found here:
http://techbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy
Of particular interest here is the KDEDIRS variable (section 2.3), the
example under it (2.3.1), the following Directory Tree discussion (3),
and the Adding Lookup Locations section (5, particularly 5.1) at the
bottom.
With that information, you should be able to setup a site-config that
won't be overwritten by further kde distro package updates.
Or alternatively, pick a distro that lets you set directories and files
that won't be overwritten, with tools that let you merge config file
updates into your existing configuration without overwriting your
customizations. In general I believe most distros have some form of
this, but some are better at it than others. Here on gentoo, for
instance, there's the CONFIG_PROTECT and CONFIG_PROTECT_MASK settings
which define dirs and files that are not to be directly overwritten, and
a choice of tools including etc-update (my choice) and dispatch-conf to
manage the updates, presenting diffs between the old and new config, and
letting you merge them a diff at a time if needed. Some of these tools
even use a version control system such as git, allowing you to manage
changes and revert back to an older version of a particular file if
desired. =:^)
So here, all I'd have to do would be to add /usr/share/apps/plasma/layout-
templates/org.kde.plasma-desktop.defaultPanel/contents/layout.js
(slightly different path here, no kde4/ component) to CONFIG_PROTECT, and
every time I did an update, that file would be protected. If there
hadn't been any changes in the shipped version since the last update,
it'd simply keep the file as it was. If the shipped version had changed,
it'd keep the existing file but would install the update as a hidden file
(.000 prefix or the similar, .001 would be the next one if the first was
still there, etc) in the same dir, and I'd run etc-update to let me see
what had changed and allow me to keep my existing file, replace it with
the update, or merge individual differences one at a time as appropriate.
Since this file is unlikely to change, I'd only get the update prompt the
first time, and after that the tool would know I wanted my custom version
and would throw away the shipped version... unless it DID change.
All of which is a pretty good thing, seeing as I'm running the live-git
4.10.49.9999 branch package, updating direct from kde upstream every few
days, so I'd have a LOT of manual file replacement to do if gentoo didn't
already come with a config file management system that let me customize
and protect once, get prompted once on the next update whether I wanted
to keep the customization or not, and then just automatically keep the
customization unless the shipped version did change, in which case I'd
get another prompt. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
