[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE 3.0 - the last steps
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-03-22 13:24:33
[Download RAW message or body]

On Thu, Mar 21, 2002 at 06:08:12PM +0100, Rolf Magnus wrote:
> On Thursday 21 March 2002 17:14, Simon Hausmann wrote:
> 
> > Agreed, the creation inside the call is ugly. But isn't
> >
> > KFileMimeTypeInfo::ItemInfo info;
> > info.setFoo( bar );
> > info.setBlubb( bliep );
> > ...
> > group->addItemInfo( info );
> >
> > more readable overall?
> >
> > I mean, with methods taking more than three arguments I for one tend
> > to quickly forget what each arguments means, requiring me to go for
> > the tedious task to look into the right header file :)
> 
> That's right. Now the problem is that I'd need some more methods to set all 
> those values, and the plugin should be the only one that has access to this 
> (and making the plugin class a friend doesn't work, because friendship isn't 
> inherited). I'd like to make sure that nobody gets the idea that it could be 
> a good idea to change those values from the "outside". We would need some 
> public methods the user of the framework isn't allowed to call (we only have 
> one per class currently, and because of the big amount of parameters, people 
> need to look into the docs where they would automatically see "don't use this 
> method" ;). Maybe it'd be better to make the plugin base a friend and then 
> add methods to the plugin class to set all the values, similar to this:
> 
> item = 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? :-}

> > > and some parts are not working fully yet. It'd be ok with me to remove it
> > > all in kde 3.0 and add a stable version to 3.1 then, but that would mean
> > > that every kde3.1 package that has to do with KFileMetaInfo relies on
> > > kdelibs 3.1
> >
> > That would be no problem. New features in kdelibs 3.1 and depending on them
> > from other packages is going to happen anyway :) . It happened in
> > the past with 2.x, too.
> 
> I just want to get sure that it's not the same as some time ago, when I also 
> asked such a question and was told it was ok, and then some time later, 
> suddenly people started to say it's not.

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.

> > > (Nobody told me if this would be ok or not), and it would leave noatun
> > > without id3 tags and ogg/vorbis comments, which would be bad.
> >
> > I don't know the code involved in this, but how about linking
> > statically against the id3/oggv-comment code inside kdemm?
> 
> I think that'd be hard. The problem is that the noatun plugins involved use 
> the KFMI API which in turn uses plugins. Thit would mean adding the old kfmi 
> class, but changed so that it doesn't load mp3/ogg as plugin but instead 
> directly link to it. That may also lead to name clashes with the new KFMI 
> then, though that could be avoided by wrapping the old one in a namespace.

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.

> > > help converting plugins, revising, bugfixing and testing.
> >
> > That's great news. Well, that in turn is possibly an argument to
> > delay the inclusion. An API becomes better the more people actually
> > use it and give feedback.
> 
> That's right. But I'm still not sure what the best alternative is now.

You can guess my opinion :)


Simon
[prev in list] [next in list] [prev in thread] [next in thread]