2012/9/4 Duncan <1i5t5.duncan@xxxxxxx>:
>> To find out the solution, I tried to edit the plasma init scripts to
>> create an SaL activity and assigned the categories I wanted to show in
>> EnabledEntries options, with the order I want. However, when creating a
>> user and a whole new kde plasma-desktop-appletsrc file, the
>> EnabledEntries was written into it but the categories shown in the
>> desktop were still the very default ones - bookmarks, contacts, and some
>> other categories. I just can't understand why.
>
> I didn't understand all you wrote (plasma initscripts? you mean plasma's
> config files? initscripts normally refers to something rather more low
> level than kde and plasma, system services such as fscking and mounting
> filesystems, etc, so I'm not sure...), but...
I mean scripts in /usr/share/kde4/apps/plasma-desktop/init/00-defaultLayout.js
http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting
We now use this to customize the KDE system default settings.
>
> 1) You may have been hit with the "user only" settings I mentioned, but
> it does sound like you tried to work around that...
No. We want to set up an environment for every newly created user.
> 2) There are two ways that normally work to setup system level defaults:
>
> 2a) The kde system level settings are normally found under /usr/share
> (but it's distribution specific, your distro may have them elsewhere),
> with the same layout as the ~/.kde/share/ dir. So to setup a system kde
> config that's identical to a single user's config, in general, you simply
> copy/move the files to the corresponding location under /usr/share/ (and
> change the ownership and permissions appropriately, of course). Do note,
> however, that depending on how your distro handles updates, they may
> overwrite any changed files without warning.
Yes I know that. It worked before, but not now, at least for
plasma-desktop-appletsrc.
>
> (On gentoo there's a CONFIG_PROTECT variable that can be set; anything
> listed there doesn't get replaced directly, but instead there's a number
> of config-updating applets that an admin can choose, that will diff the
> old and new configs, and let an admin keep or reject each update line by
> line if desired. So on gentoo, an admin would simply ensure that /usr/
> share is in CONFIG_PROTECT, and he'd then be prompted to run his config-
> updater of choice if any of those files would have otherwise been
> updated.)
>
> 2b) The traditional Unix "new user skeleton" location is /etc/skel/.
> Anything placed in there should be copied to any newly created user's
> homedir, so placing files in the appropriate /etc/skel/.kde/share/*
> location will normally cause that bit of configuration to "magically" be
> applied to any new users.
I tried this either. The behavior was not like what I expected.
> HOWEVER...
>
> 3) Apparently there's some sort of "new user defaults" mechanism in kde.
> I haven't figured out where the trigger for it is stored, thus allowing a
> user to keep the same settings once setup, but wherever it is, if this
> bit of user config isn't found, kde considers the user to be a new user
> and sets some things to default regardless of what the user config file
> says. So the 2b method doesn't work for those things. I've forgotten
> what it was tho I think it was plasma related, but another poster already
> ran into that. I was hoping they'd find and post the trigger location,
> so I could tell others what specific file or file section needed to be in
> place to prevent plasma returning to defaults, but they didn't, and I've
> not looked into it further myself, either.
>
> But the 2a method, making it a system global kde setting, should still
> work.
>
The only way that works now, is to set the default settings up using
the init javascripts.
Aaron Seigo used to give me some very useful hints and I've done most
of the work we wanted, except the Search and Launch activity problems.
>> BTW, in the EnabledEntries option, some categories used desktop file
>> like plasma-sal-office.desktop and some used a name I assigned in my XDG
>> menus file like SoundVideo/ . Why didn't it just honor the categories
>> defined in the applications menu file like kde4-applications.menu in
>> /etc/xdg/menus and the customized menu files in the home directory, but
>> used another desktop instead? I can't find any document describing the
>> behavior here...
>
> That's xdg-standard (freedesktop.org standard) behavior. The menu files
> are either kde specific or a different xdg standard, but *.desktop files
> are the standard way to ship application-specific menu entries. If your
> distro layout is standard, you'll probably find many *.desktop files in
> /usr/share/applications, for instance. X-based apps will normally drop
> their desktop files in here when they're installed, and remove them when
> they're uninstalled. As I understand it, the /etc/xdg/menu files have
> some formatting information, etc, but the *.desktop files contain the
> actual application menu entries, and if there's a mismatch between the
> *.menu files and the *.desktop files, you get the problematic "menu
> leakage" that mentioned as one of the down sides, in my previous post.
>
> That "leakage" can be fixed if you're willing to put in the time to
> figure out how it works and keep up with it, but it's a continual hassle
> since every new app with its own menu entry you install, there's a chance
> it doesn't match and will either get put in lost and found, or will
> recreate a category you thought you were rid of.
>
> That's exactly why I eventually decided it wasn't worth the effort, and
> now keep an (almost, I think I've one or two customizations on individual
> entries, no category customization) standard menu. But as I said, that
> was easier since I don't normally use the menu anyway, preferring my
> hotkey launcher scripts or typing the name directly in the run dialog (or
> konsole). If I regularly used the applications menu, either in SaL or in
> kickoff (or lancelot or classic menu or...), I'd almost certainly still
> be a heavy menu customizer.
>
>
> BTW, in kde at least, *.desktop files are also used for a number of other
> things. See /usr/share/kde4/services, for example.
In the XDG menu, a category (or a menu) will read a *.directory file,
which setup the category's name and icons, ... etc. In the category
we can setup desktop files of this categories and sort them.
I saw something like SoundVideo/ in the EnabledEntries option, where
SoundVideo was the categories I defined in XDG menu structure we
defined. Search and Launch activity must have referenced it for
categories not in its default settings. I'm just wondering why it
doesn't just reference everything in the xdg menu, but have its own
standard categories instead.
>
> (Tangentially related but rather off topic: Based on your mention of
> Chinese and your name, I can now guess that's what you're working with.
> But your English is good enough I didn't think of it, originally.
Thank you! :-D
I'm working on a customized system for our local users. This year we
(finally) decide to use KDE as our default desktop, and that's why I
had a lot of questions for initial environment settings.
We may write a story about the history, the current status, the
future, and what it brings to us of "ezgo" - the system what we are
doing now. Hope that one day it can be published in some sites like
KDE Dot News. :-D
[The other comments about LL was deleted, but I'll read the blog. :-D]
Franklin
___________________________________________________
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.
