[Kroupware] Re: kroupware_branch: kdepim/korganizer

[Cornelius Schumacher]

On Wednesday 06 November 2002 08:39, Steffen Hansen wrote:
> * Cornelius Schumacher <schumacher@kde.org> [Nov 05. 2002 15:55]:
> > On Tuesday 05 November 2002 14:31, Steffen Hansen wrote:
> > > CVS commit by steffen:
> > >
> > > Simpler handling of todo items. #define NO_KROUPWARE_TODOS to get
> > > the old behaviour
> >
> > This is exactly the kind of stuff which will make a lot of work,
> > when merging into HEAD.
>
> Yeah, but what can I do when I'm asked to implement this...

Resist ;-)

> > We can't just remove existing KOrganizer functionality and replace
> > it by some kroupware specific functionality. Keeping the define is
> > also not acceptable, because it would mean that we still would need
> > different builds for the original KOrganizer and the kroupware
> > version. I really think our goal has to be to make the standard KDE
> > clients compatible with the kolab server and to not provide special
> > versions for this case.
>
> I know the commit touches quite a number of files, but most of the
> changes are trivial (like making a method virtual, adding a new
> contructor etc.).
>
> Only one .h and one .cpp use the NO_KROUPWARE_TODOS macro. I didn't
> _remove_ any code from korganizer -- I just reimplemented a method in
> a subclass. If you remove this method, you get the original behaviour
> again.

Yes, but that means it's not possible to get both in the same binary, 
the original KOrganizer behaviour and the Kroupware behaviour. We have 
to find some way to integrate it. That's the main problem with merging 
the kroupware_branch. It currently is separated quite well from the 
original code, but that's not what we want. We want a real integration, 
so that the original code benefits from the improvements of the branch 
and the code of the branch benefits from current and future 
improvements of the original code.

> > And another side note: it would be more consistent, if you would
> > respect the KOrganizer naming conventions for ui files. This also
> > will make merging easier. In this case it's probably not very good
> > to use a ui file at all.
>
> I often find it much easier to modify other peoples .ui files than
> their code.

Hmm, I don't share this expericene, I even sometimes find it more 
diffcult to change my own .ui files than changing some code.

One reason why .ui files aren't that good in this case is that we need a 
special version of the editor dialog for KOrganizer/Embedded which has 
to be much smaller. It is much easier to maintain two different 
dynamically generated dialogs than two different .ui files.

> About the naming convention: I can s/Base/_base/ on that .ui file if
> you want.

That would be great. We have this convention, because it makes it easier 
to identify uic generated files by using regular expressions, e.g. for 
grep or a .cvsignore file.

-- 
Cornelius Schumacher <schumacher@kde.org>