[kdepim-users] New computer

[Kevin Krammer]

On Sunday, 2010-08-15, ianseeks wrote:
> 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

Not sure what you mean, the XDG base dir spec is available for quite some time 
already. It is new relatively speaking compared to the age of a lot of 
software that traditionally stored config into $HOME.
Some of the respective development teams might not even be aware of the spec 
or ignore it if the don't consider their applications to be "desktop" apps.

> > >  >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.

Sure, just clarifying the misunderstanding between Ingo's statement and your 
reply.

> > > > > 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.

Common misunderstanding of Akonadi's purpose and Akonadi's database usage :)

The core idea of Akonadi is to have centralized access to data of the same 
type, e.g. one place to go to for contacts or emails.
So having one Akonadi per application would not make any sense at all, 
applications would be back to where they have been (e.g. file locking issues, 
etc.)

The database used by Akonadi is only occasionally used to store data (as in 
contacts or emails), i.e. only when the actual storage is unreachable (e.g. no 
network connection to a groupware server).

Its main purpose is to store relational information, e.g. where an item comes 
from, what MIME type it has, etc.

Duplicating this information over and over again into separate databases for 
each application again makes little 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.
> 
> 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.

No, see above.
Data is not stored in db files, but on servers or appropriate local files or 
directoreis (e.g. vcf for contacts, maildir for mails, etc)

> > 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

These settings are in the configuration file of the respective Akonadi 
resource (backend connector).

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/315d72fc/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users