[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:       Rolf Magnus <ramagnus () t-online ! de>
Date:       2002-03-21 15:22:57
[Download RAW message or body]

Argh! I wrote that mail once, and then kmail crashed and for some unknonwn 
reason didn't give me my mail back... Showstopper ;)

On Thursday 21 March 2002 09:33, Simon Hausmann wrote:
> Just to make this clear: I believe your contribution to kdelibs was
> not an error!
>
> Just in contrary, I find the feature a pretty cool one.

Thanks, and thank you also for your comments. I just went a bit mad about all 
this yesterday.

> - How about making GroupInfo::addItemInfo not take the whole lot of
>   parameters but just a const ItemInfo & argument? (ItemInfo is
>   meant to be used value based, right?)

Actually, it's not. But it might be a good idea to make it value based so that 
it's consistent with the KFileMetaInfo hierachy, which actually is value 
based. I wanted to make it impossible for the plugin to create objects of the 
MimeTypeInfo stuff themselves by making the constructor private and making 
them frinds, so I get control over it and can ensure that they are properly 
created and added to the dict. And I also thought that this method makes it 
more convenient because you need to write:
group->addItemInfo(lots, of, arguments)
instead of:
group->addItemInfo(KFileMimeTypeInfo::ItemInfo(lots, of, arguments)

> - KFileMetaInfoItem::string( bool mangled ) . I think the name is
>   not very descriptive. I'd rather do something like
>
>   enum ValueStringConversionFlags { Mangle, Unmangle };
>
>   QString valueString( ValueStringConversionFlags flags = Mangle ) const;
>
>   (ok, that's the other extreme, maybe too verbose :) -- although
>   for the caller it's easy)

Hehe, yes. KFileMetaInfoItem::ValueStringConversionFlags is a bit long for a 
name. And I think Unmangle is misleading. Better NoMangle or DontMangle or 
so, but definitely more intuitive than true or false.

> - KFileMetaInfo: I think the groups(), supportedGroups(),
>   preferredGroups(), preferredKeys() and editableGroups() methods could
>   return a const QStringList & instead of just a const QStringList.

some of them are dynamically created, which would mean returning a reference 
to a temporary. And QStringList is shared anyway, right? So it doesn't do any 
harm.

> - I'm not sure, but maybe it would make sense to add private d
>   pointers to containers like GroupInfo, etc.

Yes. I'll do this.

> Still the question whether to switch to the new API or whether to
> disable the feature for 3.0 can probably only be answered by you and
> Carsten, as you know the API and the intentions behind it best.
> (that at least I think explains the lack of comments :) .

Hmm. It's hard for me to decide this, because it can influence the KDE release 
schedule and the stability of konqueror, which I don't want to decide alone. 
If I had wanted this, I just would have added the new API to HEAD. That's why 
I asked for help in the decision. And I wasn't sure about all the 
consequences about the different solutions I suggested, so I was hoping that 
more people comment on this, since a lot of people commented about the 
general issues of introducing BIC changes between 3.0 and 3.1

> If you feel unsure then I'd rather delay the feature than pushing in
> things in a hurry. I think it's not a shame to delay something for
> the sake of an improved API. Not at all IMHO.

Yes, I also see it this way. Well, the interface is quite like I wanted it to 
be now, but it's far from being as stable and tested as I'd like, 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 
(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.

The best thing that could happen now is some other showstopper that justifies 
another delay for the release, so I'd have a week or so time to finalize 
KFileMetaInfo. ;) And I found out that there are people who care and want to 
help converting plugins, revising, bugfixing and testing.

-- 
And through Windows NT, you can see it throughout the design.
In a weak sense, it is a form of Unix.
(Bill Gates on UnixExpo '96)

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