On Friday 22 March 2002 14:24, Simon Hausmann wrote:

> > item =3D addItem(group, "key", i18n("key"));
> > setPrefix(item, "prefix");
> > setSuffix(item, "suffix");
>
> Hm, that looks ugly compared to item->setPrefix IMHO.
>
> Is this attempt of preventing the developer from doing unlikely
> stuff really worth it, at the cost of a non-OO API? :-}

Looks a bit ugly to me, too. But we didn't want public methods to set tho=
se=20
values, because only plugins are supposed to do so. So yes, basically you=
're=20
right. Carsten said that he thinks its better so, and we already did this=
=20
now. But you get the methods with only few parameters that you wanted, so=
 you=20
should be at least partially happy with it ;)

> Yes, that would be bad :) I think the difference here is that it
> simply doesn't break binary compatibility, which was the cause for
> the ramblings, not the package dependencies.

What's the difference? I mean BIC does also just result in package=20
dependancies, no?

> Would it be that hard? I mean, as soon as the new API is finished
> you could just dump the old code and convert to the new API.

Could be an option. But currently, we're workig hard on getting the new a=
pi=20
into kde3.0, and only few work is needed to be done (besides testing and=20
seeking for bugs). It looks as if we can do it.

> > That's right. But I'm still not sure what the best alternative is now=
=2E
>
> You can guess my opinion :)

Right. But we talked to Dirk, and it seems that we are definitely merging=
 the=20
KFILEMETAINFO_BRANCH back into HEAD which of course means that I don't ha=
ve=20
time to prepare for other options.

--=20
=46rom a hotline:
Tech Support: "All right ... now double-click on the File Manager icon."
Customer: "That's why I hate this Windows -- because of the icons --
          I'm a Protestant, and I don't believe in icons."