global default panel height change?

[Duncan]

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.