[Kde-pim] Re: kdepimlibs and kdateedit

[Kevin Ottens]

On Tuesday 30 November 2010 10:31:45 Tom Albers wrote:
> ----- Original Message -----
> 
> > Well, having this duplicated code everywhere for even more months
> > (look at
> > lxr.kde.org to see what I mean) is enough to make me want this bugger
> > ASAP.
> 
> It's not months, in a month or so trunk is open again.

Well, my point was that to effectively start removing the duplicated code will 
require KDateEdit to be in a released kdelibs (as most of the duplicates are 
in PIM and Extragear which depends only on released kdelibs). So removing the 
duplicated code of all the apps involved will only start *after* 4.7 release 
if KDateEdit is not part of 4.6.

> > Agreed, unfortunate timing, but I had to make sure I could recollect
> > from the
> > different forks (and I probably missed some).
> 
> So, you are suggesting introducing a new class to kdelibs after beta 1 has
> been released which will immediately be used by half a dozen applications
> within KDE SC and Extragear. Introducing an important new class and only
> letting it get half the testing it should have sounds bad to me.

It's actually tested for the most part as for the core features it's the exact 
same code than what's present in most of the current forked versions.

> That also increases the chance of being stuck with an API which is not
> optimal for all the apps and which we can not change because it is already
> released.

Yep, hence why I tried to keep it minimal.

> > My concern is that if we give it six more months we'll be at the same
> > point
> > for 4.7 (since PIM and Extragear tend to use only released kdelibs).
> 
> In a month trunk is open and you can fix them all, no six months there.
> Only some ifdefs for extragear apps probably, but you would need those now
> as well probably, right?

Well not, right now they depend on their own copy of KPIM::KDateEdit and they 
could switch to the shared KDateEdit once it's in a release kdelibs.

> > I'm
> > definitely not interested in doing this work again, it's already been
> > painful
> > enough
> 
> If you are going to blackmail me with 'now or never', by all means commit.
> I've no intention in upsetting you or destroying this valueable work. I
> only want optimal KDE releases.
 
Sorry if the wording turned out unfortunate it wasn't my intent there. It was 
more about a reality check:
 a) I can't devote much time to it on a regular basis (it's rather low on my 
priority list), and I think I'm not the only one with that problem since I 
hear this "let's move KDateEdit to kdelibs since *at least* 4.3";
 b) Until it's in kdelibs people will keep doing stuff in their own corner, so 
the work I did so far will need to be done again for missing features and so 
on, David's mail actually illustrate that well... The feature he refers to 
wasn't there when I started. :-/

But OK, looks like I missed the window by a couple of weeks, so let's make it 
for a "later release".

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20101130/b2c27734/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/