[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-21 8:33:18
[Download RAW message or body]

On Thu, Mar 21, 2002 at 02:35:16AM +0100, Rolf Magnus wrote:
> On Thursday 21 March 2002 01:12, Dirk Mueller wrote:
> 
> > > I'd add to that KFileMetaInfo
> >
> > Thats what I meant. It was actually a question. What part of the API needs
> > fixing ? how long does it take ? Are you working on it ?
> 
> Carsten Pfeiffer(?) and me are working on it. There was some restructuring of 
> the api and especially the plugins. I was working on it the last days (since 
> the day when everybody suddenly started complaining). See my (quite long) 
> mail I wrote about it on monday in the thread about KFileMetaInfo. I 
> suggested several different solutions what can be done. I tried to prepare 
> for the "Use the new API in 3.0" solution (Carsten convinced me to do this). 
> Nobody of the people who complained said anything about it or had any other 
> suggestions. It was said that I didn't care, which makes me sad because it's 
> not true. So I tried to do my best by describing the current situation and 
> the solutions as good as possible and working to get it done, and it seems 
> most other people don't care, because Aaron J. Seigo was the only one who 
> answered (thank you Aaron for a constructive answer and an offer to help). No 
> answer from any of the "complainers", and also no answer from the release 
> coordinator. And I'm a bit disappointed in Carsten Pfeiffer, who left me 
> alone with it once, and now after promising to help me this time, he did this 
> for one day, and then again left me alone.
> So now I'm sitting here trying to get it done without knowing if my work is 
> worth anything, everybody saying that my initial plan (making it BIC between 
> 3.0 and 3.1) is wrong and telling me why (with valid arguments), but nobody 
> even caring about argumenting on the solutions I presented. Sorry for all 
> this whining, but I'm realizing that it was an error that I wanted to add 
> something to kdelibs.
> 
> Ok, now something about the state of KFileMetaInfo, if anyone is interested:
> The API is mostly settled apart from some minor changes that could be needed, 
> and most parts are working (I'd say about 90%), but it's almost untested and 
> revising the code and fixing bugs would really be needed (just like Aaron 
> wrote). Both tool tips and the properties dialog in konqueror are working. 
> What is missing is the kdemm/noatun part and all plugins except mp3, which is 
> working 100% with the new api. Changing the other plugins is mostly typing 
> work.
> 
> Now could anyone tell me if this is worth waiting or if not, which alternative 
> I should choose? Or should I just stop caring, too, and leave kde with a 
> crippled KFileMetaInfo?

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.

I just looked at the new API in the branch. I find the API quite
nice. Some minor comments/suggestions:

- 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?)

- 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)

- KFileMetaInfo: I think the groups(), supportedGroups(),
  preferredGroups(), preferredKeys() and editableGroups() methods could 
  return a const QStringList & instead of just a const QStringList.
  
- I'm not sure, but maybe it would make sense to add private d
  pointers to containers like GroupInfo, etc.


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 :) . 

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. 


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