[Kde-pim] [RFC] cleaning up libkdepim

Kevin Krammer kevin.krammer at gmx.at
Sun Mar 21 15:43:21 GMT 2010


On Sunday, 2010-03-21, Ingo Klöcker wrote:
> On Thursday 18 March 2010, Tobias Koenig wrote:

> > # Some new notification library in kdepimlibs?
> > agentprogressmonitor
> > broadcaststatus
> > overlaywidget
> > progressdialog
> > progressmanager
> > ssllabel
> > statusbarprogresswidget
> 
> I'm wondering whether this is still needed. Do we really need progress
> meters in the applications? KDE (or even fd.o) has a central place for
> progress notifications. Shouldn't we use that instead?

It is probably more a question whether an application can be a notification 
host on its own, so the same mechanism can be used regardless of whether the 
application is running in an environment  supporting such central 
notifications (e.g. on Windows and I am not sure OS X's growl supports 
progress displays)

> > # Still needed? or replaced by a new parameterized AkonadiDrag
> > object?
> > kvcarddrag
> 
> If this creates a drag object with the standard mime type for vCards
> then this should be retained (or AkonadiDrag should be extended) because
> this would allow dragging contacts to applications that support
> drag&drop of vCards but that do not (and never will) support drag&drop
> of Akonadi objects.

Drag&Drop (as well as Clipboard) operations are designed to negotiate a data 
type at time of transfer. The source application prepares a list of offers and 
the target application decides which ones it wants [1]. The source application 
then provides the data in the requested format.

An Akonadi enabled application should therefore always offer the Akonadi ID 
(e.g. in form of the URL) but also as the item MIME type [2] (if possible, the 
drag could have multiple items with different MIME types).

As for the URL, we might have to consider adding more information to it.
I remember a discussion followed by a series of fixes in the context of file 
URIs, where KDE's original implementation was not including the hostname, thus 
making it  impossible for the target application to check whether the file was 
local to it as well (e.g. either one being a remote window).

For us that probably means having both hostname and username as part of the 
drag URI (fortunately we don't support more than one Akonadi instance per user 
anyway).

Cheers,
Kevin

[1] Actually I think it can ask for any number of offerings
[2] That probably means that the application has to retrieve missing parts on 
demand when this type is requested
-- 
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/kde-pim/attachments/20100321/fddf6d1c/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list