[kdepim-users] New computer

[Kevin Krammer]

On Sunday, 2010-08-15, ianseeks wrote:
> On Sunday 15 August 2010 12:10:31 Ingo Klöcker wrote:
> > On Sunday 15 August 2010, ianseeks wrote:

[snip]

> > > and the home directory is littered with "." files.
> > 
> > Historical reasons. In the stone age of Unix user specific configuration
> > was stored directly in '.' files in the home directory.
> 
> I know, but thats not a reason for lack of improvement.

True.
Given the time most of these applications have been around, new standard 
locations like specified in the XDG base dir spec are relatively new.
Those traditional Unix applications are often in a maintenance only mode, kept 
running but not adding new stuff.

Of course it doesn't hurt to let their maintainers know about these 
improvements.

Relatively new applications, e.g. those developed by big projects such as KDE, 
GNOME or Mozilla have switched to directories containing user local data and 
config years ago, which ultimately resulted in the converging to the same 
locations.

A totally new system could probably already be setup that way, e.g. by 
applying small patches to path finding functions in the respective base 
libraries or creating symlinks in old locations to point to new ones.

The latter of course having the problem that the resulting paths could 
potentially be stored somewhere, making these values dependent on the 
symlinks.
The other approach having the disadvantage of making existing documentation 
inaccurate or no longer applicable.

Probably the main reasons why switches happen on major releases, due to being 
conceptually close to "replace" than "update/upgrade".

> > > Its all a matter of making things
> > > self-explanatory e.g. why is the data directory
> > > "~/.kde/share/apps/<appname>" not called "~/.kde/data/<appname>"
> > 
> > Historical reasons.
> 
> Sure, but KDE3 -> KDE4 would have been a good time to change it and a few
> of the other points i've suggested.

Also true. Unfortunately there were a lot of things to do during this 
transition, lots of things that turned out to be less ideal being replaced 
with better techniques.
The KDE resource system was one of the things that worked very well, so 
changes regarding it were in the "nice to have" category instead of the "need 
to have" one other sub systems were in.

It could probably be done for new user accounts, i.e. create ~/.config/KDE and 
use it instead of creating ~/.kde/share/config if it doesn't exist.

That is for all the resource locations that there is already a new replacement 
for, certain things like a directory to put sockets in are not yet covered by 
any non-project specific spec.

> > > All "." files should be under a directory called ".config" (or
> > > similar)
> > 
> > And that's exactly what newer applications do. Old applications cannot
> > simply move their '.' files from the home directory to .config because
> > this would break many installations relying on the current location.
> 
> Yes, but a link could be used until the application gets updated to use the
> correct place at which point the app can remove the link automatically.

Probably the other way around, i.e. accessing the file at the old location 
through a symlink.
Making the old location the symlink to the new one could wreak havoc with 
backup/restore setups, e.g. replacing the symlink with a real file on restore, 
making manual changes later on have no effect on the program.

Of course the problem then shifts to when the new location gets backed up. In 
either case it requires the user (or admin) to know exactly what is going on, 
no simple solution there.

> > > Home directories should not be littered with files, it
> > > looks like the very old MSDOS days where people should file in the
> > > route directory until it filled up.
> > 
> > Well, Unix predates MS DOS. ;-)
> 
> Yep, but MSdos is where a lot of people cut their teeth on computers and
> learnt very bad habits through ignorance which have been passed down the
> chain.

Granted. Though developers with Unix background are usually already more aware 
of such things, e.g. not even thinking about trying to write into an 
applications installation location during runtime.

>  >Consequently, there's no way on earth to
>  >
> > make it user friendly by creating "a simple template structure that all
> > KDE programs should follow". (BTW, it wouldn't help a bit if just KDE
> > applications follow it.)
> 
> If they don't follow it, they should not be allowed to known as a true KDE
> application and get stuck in the playground.,

Ingo was not referring to KDE applications not following a certain pattern, he 
was referring to non-KDE applications.
KDE applications already follow the same pattern by virtue of using the KDE 
resource directory system for determining paths.

> > > I understand that Akonadi is not a KDE component but as it is being
> > > integrated into main KDE programs and is now by association, an
> > > absolute KDE app dependency as certain apps will not run without it.
> > > In my opinion, it should follow the KDE config and data structures.
> > 
> > I'm sorry, but that's not how it works. Akonadi aims at being used not
> > only by KDE but also by Gnome, OpenOffice, Thunderbird, Firefox, etc. I
> > guess this makes clear why putting Akonadi's settings and data below
> > ~/.kde makes absolutely no sense.
> 
> Question:  does each application that uses Akonadi have its own settings
> and data or do all apps share one database and settings database , a bit
> like the Registry on that other OS?

That depends on what level you look at it.
Akonadi is neither a configuration database like the Windows registry nor a 
general dumping ground for application data.

Depending on an applications purpose and functionality it could not require 
any configuration on its own and just work with data provided through Akonadi.
But it is also possible, or actually quite likely, that an application will 
have some configuration items that are specific to its purpose, e.g. which of 
its toolbars to show.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20100815/eeceeba3/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users