Import user settings in KDE4

[Saleem Khan]

I have enabled/set custom settings on KDE 4 Kmenu and desktop for user
and root. How do i add these custom made settings into /skel so that
any user will have these settings by default instead of loosing them
on install

there is one link but this is not conclusive for Unity KDE4

http://ubuntuforums.org/showthread.php?t=1373387

thanks

[jmia...@gmail.com]

Skel is not used for kde 4. Skel should be reserved for actual system config files that aren't de specific otherwise you end up with a bunch of config files for multiple applications and DEs that never get used.

So kde has it's own default config file folder that gets removed if kde is removed.

It's located in /etc/kde4/config

There's also a kde first run scritp located in /usr/share/kde4/env/

That copies over specific files depending on system varibles those files are located in /usr/share/config/default/Unity or Synergy/

All these paths are off the top of my head so excuse me if they're off a bit.

Hope this helps

Jeremiah

-- Sent from my Palm Pre

---

--
PLEASE REMOVE THIS FOOTER WHEN REPLYING & REPLY BENEATH IT!
Unsubscribe: ul-developer...@googlegroups.com
More options: http://groups.google.com/group/ul-developers

[Saleem Khan]

if only i can fix how to import/export custom made KDE4 Kmenu and
desktop settings to a new user by default, my KDE4 Minime iso ready

here is one screenshot

[Matthew Dawkins]

--
PLEASE REMOVE THIS FOOTER WHEN REPLYING & REPLY BENEATH IT!
Unsubscribe: ul-developer...@googlegroups.com
More options: http://groups.google.com/group/ul-developers

Nice work Saleem. I would try to find out what you have changed as far as the config goes and see if you can't put it in skel. I know Jman said that it doesn't need to go in there, but sometimes there is no other way around it.

[Jeremiah Summers]

Saleem are you talking Panel or Menu, the menu is a little bit tricky but the things on the panel can be configured through a simple javascript, actaully most of KDE now can be configured with a simple Javascript. I have found no need to ever use etc. skel. Let me know what files you edited and I will let you know ways to have this be the default setting there's now multiple ways to do things.

Jeremiah

[Saleem Khan]

Jeremiah,

Panel and desktop is not an issue, the biggest challange was to set K
Menu, I have regrouped all packages according to types, the user will
not need to search for any packages, they are very easily accessable.

I will upload the iso to dropbox with username and passwords and you
can look at things yourself.

meanwhile i discussed same issue at pclinuxos forum and i think for
knowledge sake it wont be bad if you go through it.

http://www.pclinuxos.com/forum/index.php/topic,74869.0.html

thanks

[Jeremiah Summers]

I didn't see anything discussed on the thread you sent that had anything to do with the menu, rather a question about /etc/kde4/ which PCLinuxOS does not have because they still use the Mandriva system. Early in packaging I developed a hatred for the system because there where multiple files spread throughout the system with no real organization or rhyme or reason as to where they were placed. In the history of Linux system wide configuration files are found in etc this makes sense from a administration stand point. This was not the case with Mandriva or PCLinuxOS so I deviated from that and went to the structure that Suse uses as I have found Suse's KDE and organization of configuration files were far superior and believe it or not they are more opt to branding, though I see few people understand this or brand Suse.

This has nothing to do with the Menu however because for the most part, as I said the menu is a complex beast. It is not Desktop Environment Specific as in it's standards..

http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

For the most part we adopted xdg standards a while ago.. why is this complex and important?

A vast Majority of GTK and QT based applications now follow this Standard when the program gets build from source it generates a *.desktop file. The xdg based menu reads this file, actually it reads, the Categories line normally located at the bottom of the desktop file. The Categories listed tells the menu were the Program needs to be placed in the menu based on the registered categories within the xdg standard. When someone writes a KDE application and wants there application to be see in a KDE menu they create a .desktop file for their application and place their application in the Category for which they feel it fits as the application's developer. If we want to permanently change where that program is place on install or reinstall we will have to patch the program's desktop file on build. Otherwise if we just change it's location in the menu on resinstall the menu will reread the desktop file and place the program where we don't want it. You have to realize at this point the work that would have to do into patching each programs desktop file to fit in a category, you also have to realize what you feel might be easier from the users perspective may not be.

Sometimes an application's mime types or even the category we feel is not correct show a patch is generated, Mandriva has a few packages it patches to fix desktop file issues, however I have over 1000+ applications in the kde4 repo and I would say at the very least a quarter of those might have desktop files using the xdg category spec unless this suddenly becomes a paid position that I can spend loads of time on I don't see us deviating from the xdg menu standard anytime soon nor do I see quite frankly any good reasoning to do so. It comes down to the user are they willing to learn something different? If not you're not going to be able to satisfy them anyways your just going to end up with something that looks like what they're used too, but it can be never exactly the same so there will always be dissatisfaction.

So it's great you've changed the menu, but basically you have just change it at the service and have not really addressed the issue when the User installs a new application that doesn't fit to your scheme. There's ways you can change some things without a major overhaul, we see this with the present categories we've adopted from them for our menuing system, but that hasn't came without costs we just don't see it because we're not the ones doing the patching, rather we're just importing applications some with patches already.

In conclusion it's not something as simple as change changing a config file and expecting it too stick and I hope now you understand the menu's configuration does not have to do with a file in /etc/skel or in anything related to kde configuration for that matter, your barking up the wrong tree and the tree you should be barking up is a very large one.

Jeremiah

[Jeremiah Summers]

The file you need to work with is here:

/etc/xdg/menus/applications.menu

You can keep the same categories that xdg uses however organized these categories within your own. Look at the file and see how Mandriva has currently done it as an example. That's really the best way to do it. Some applications may still have to be patched but ti will have no where near the work load as deviating from the xdg standards, you're just basically creating wrapper categories.

Jeremiah

[Saleem Khan]

Thanks JM, i clearly understand your point and i know its a difficult
task indeed.

I have made and iso ( the size is bigger than expected because i made
it with mklivecd rather than build_unity because build_unity failed as
usual for me and i have uploaded the log of that also )

the iso will take sometime to upload, please give it a test once you
can download it from my dropbox for which i have sent a link to
ul-dev...@googlegroups.com

thanks

[Jeremiah Summers]

In the mean time can you break down your menu? Maybe it's possible to do in a similar manor Mandriva has. 

[Saleem Khan]

The ISO has been fully uploaded to dropbox, please test it now JM

thanks