[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Use of library names (Akonadi, Solid, Nepomuk,
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: 2008-06-08 2:06:14
Message-ID: 200806080406.14506.kevin.krammer () gmx ! at
[Download RAW message or body]
On Saturday 07 June 2008, Robert Knight wrote:
> Some examples:
>
> - While testing Mailody from trunk I noticed the 'Akonadi tray'
> utility which gets started in the system tray.
> The user interface for this tray doesn't mention anywhere what Akonadi
> actually is.
The tray application is probably not the ultimate solution for the problem we
have created it for, i.e. basically serving as a GUI peer for the service
processes making up the Akonadi infrastructure.
Since KDE is now even more service based than it used to be, it might make
sense to have a kind of monitoring (and probably control) factility for KDE's
and related services.
> When Mailody starts
> up, I received a warning message about a problem locating Akonadi
> resources, again, without mentioning
> what an "Akonadi resource" is.
We should definitely improve the wording here, though it will be kind of
difficult to find a user understandable error message for a quite new concept
of handling such common things as e-mail.
> - Libraries and daemons which have user interfaces for setup,
> settings, status monitoring etc.
> should use a consistent descriptive name (eg. "Semantic Desktop"
> instead of "Nepomuk", or "Hardware Management" instead of "Solid").
> I am not sure what you could use for Akonadi as its scope is very
> broad. "Akonadi Calendaring/Mail/Organisation/Backup/Tea Making" is
> probably
> too long for a menu item ;)
Akonadi is a bit in a better situation anyway, because its configuration will
in most cases happen through its client applications, e.g. in Mailody users
can configure IMAP servers just like they would expect to be able to in a
mail program and not have to deal with the fact that the IMAP server access
is actually not handled by the program itself but by a helper program running
invisibly in the background.
Even if at some point we want to have the configuration options available in
system settings as well, we can split them into task specific sections rather
than putting everything under "Mail & Calendaring", e.g. having
Mail/Usenet/Newsfeed setup somewhere in a network related section, calendar
and addressbook setup in a user/person related section.
Regarding branding it is probably more a question of creating a "powered by
$technology" kind of attribution in the usual places (about dialog, startup
pages, splashscreens, etc)
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic