[kdepim-users] New computer

[ianseeks]

On Sunday 15 August 2010 17:11:23 Kevin Krammer wrote:
> 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.
Hopefully this will come online soon
> 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.
Yes, agreed but there is more to do to improve it as i already suggested.
 
> >  >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.
Non-KDE apps can whistle and sort themselves out.
> 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.
True, i realised that. I was thinking that if all KDE progs had separate 
Akonadi databases, the databases could still be put under the relevant .kde 
structure. Gnome apps would put them under the Gnome structures etc, but i am 
assuming that each app would have a way to configure where its data is 
located. 
> > 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.
I was looking at it from the data level i.e. if all KDE apps that used Akonadi 
would their data be held in separate database files i.e. kmail.db, 
contacts.db, calendar.db or one huge database file. 
> 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.
E.g. kmails setting for connecting to the ISPs etc, would they be in a ".file" 
or database

> Cheers,
> Kevin

I've probably not been explaining myself very well but hopefully i have now.

Thanks 

Ian
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users