[Kde-pim] Plugin Question re Kontact Headers

[Volker Krause]

On Monday 07 September 2009 19:22:00 Allen Winter wrote:
> On Monday 07 September 2009 4:37:36 am you wrote:
> > On Monday 07 September 2009 09:33:08 Tom Albers wrote:
> > > At Monday 07 September 2009 01:10, you wrote:
> > > > Yah. However it appears the main Kontact developers just don't want
> > > > to pursue that, doesn't fit with their vision of Kontact. Fair
> > > > enough, that's their privilege and I don't want to waste their and my
> > > > time pursing it. I appreciate their making it clear at least.
> > >
> > > I've not seen a reaction of the Kontact developers / maintainers (as
> > > far as they exist anyhow).
> >
> > That's the real problem here. We don't really have someone working on
> > Kontact and thus also noone who could make the interface public (which is
> > more work than just installing the headers). I'm in favor of doing that
> > as well btw.
>
> I was the person who took the old kontact/interfaces and made it into
> kontactinterfaces precisely for moving into kdepimlibs.  In fact, I had
> it in kdepimlibs for a day or two.  But then at least 1 former Kontact
> developer convinced me that this wasn't a good idea because
>
> 1) the API hadn't been stabilized or reviewed
> 2) we wanted to maintain control; we don't see Kontact as a general
> purpose shell for plugging anything at all.
>
> Basically, we figured any future plugins should/could become part of the
> kdepim module.
>
> After all these years, I really think the argument for 1) is getting silly.

Yep. Still, we should do the usual review for common BC pitfalls (probably 
done already) and make sure that we have the necessary safety checks in place 
to prevent Kontact from loading incompatible plugins (IIRC done as part of 
the enterprise branches, I remember seeing grayed out icons in the sidebar in 
that case).

> We can't stop folks from copying kontactinterfaces to their local source
> tree. So maybe we just give up the idea of control and move
> kontactinterfaces into kdepimlibs.  Or, we create a white list of plugins
> we know and take full control. Or.. we do both.

This is free software, there is no way we can control what people do with it 
anyway. Obviously the current approach failed in that respect. In fact the 
number one reason for problems with 3rd party plugins was not the plugin 
itself, but that it was using incompatible interfaces. So, if you are 
concerned about the impact of those plugins on the overall quality of Kontact 
you should rather ensure that people can write plugins (which they will do no 
matter what) in a safe way by using the official interfaces. Also, I don't 
think Kontact will suddenly be swamped with hundreds of plugins, I would 
rather expect a handfull of them. And most of the ideas I've seen so far made 
perfect sense to me (the new blogging app, choqok, etc.). As long as we have 
a sensible set of plugins enabled by default (eg. not all of KMail, Mailody, 
KNotes and KJots), I don't see how even multiple plugins that have a similar 
task would be a problem.

> The current situation isn't good.
>
> As for summary plugins: I want the summary page to become a Plasma
> containment and thus allow any old Plasma widget to go into the Kontact
> summary.  I don't really care what people show in their summary.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090908/4aa61dd6/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/