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

List:       kde-devel
Subject:    Re: Boredom, MP3s, KDE: this
From:       Charles <charles () altair ! dhs ! org>
Date:       2000-10-04 21:41:20
[Download RAW message or body]

On Wed, 04 Oct 2000, David Faure wrote:
> On Wed, 04 Oct 2000, Charles wrote :
> >On Wed, 04 Oct 2000, David Faure wrote:
> >> On Wed, 04 Oct 2000, Charles wrote :
> >> >Speaking of which, while doing the class, I had noticed of a somewhat
> >> > fatal flaw in the kiolibraries.
> >> >
> >> >You can't define your own "Atoms" for the files. (or can you?)
> >>
> >> No you can't, indeed.
> >>
> >> >For example, a rio file has, in addition to a name, also has position,
> >> >bitrate, samplerate, etc.  You should be able to have these types as
> >> > part of the ioslave.
> >>
> >> Good point.
> >>
> >> >Konq will then pick up those fields and put it into the list.  the
> >> > kioslave itself will have the fieldname i18ned.
> >>
> >> Yeah, the problem is that currently KFileItem looks for specific atoms,
> >> it doesn't "look at what's coming". It would need to be able to have
> >> some QMap for the "generic atoms", and have a way to get the names for
> >> them from the ioslave (i.e. new method in SlaveBase & Job....).
> >> And someone would have to make sure those atoms (which are numbers)
> >> are unique among all ioslaves ;-)
> >>
> >> Something for KDE 3.0, in any case :-)
> >
> >We're talking about KDE 3 before we release KDE 2.0? :)
>
> Well, 2.0 is already frozen, in case you didn't know :-)
>
> >I think in an ideal situation, we still have the integer Atom IDs, an in
> >addition a set of generic atoms.
>
> Still has to be an integer, for performance reasons. But that shouldn't be
> a problem.
I think it doesn't need to be an integer for the non-standard types, since 
they'll be used so rarely anyway (but I don't know what I'm talking about :)

>
> If it was only for passing those atoms around, we could already do that,
> but the new method to query the slave means bin incompat....
>
> >I feel, if we're breaking BC for 2.1
> >anyway, we should probably do it then.
>
> I hope we won't, but in case we do, I agree.
BC will break for 2.1 with thanks to QT3 and new compiler specifics 
(reportedly).  Hmm, if the compiler is changing so much, maybe it'l stop 
sucking all of a sudden too.... ;)




>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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