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

List:       kde-core-devel
Subject:    Re: UDSAtomTypes bitmaps??
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-04-07 12:26:58
[Download RAW message or body]

On Fri, Apr 07, 2000 at 02:52:48PM +0200, Michael Matz wrote:
> On Fri, 7 Apr 2000, David Faure wrote:
> 
> > On Fri, Apr 07, 2000 at 03:47:28AM +0200, Michael Matz wrote:
> > > Hi,
> > > 
> > > can anybody explain to me, why the KIO::UDSAtomTypes are layed out as a
> > > bitmap. This would only make sense, if one expects to later or them
> > > together. But because we are only ||'ing together the base and the
> > > specific type, it would probably better to make it two fields (say basic
> > > type 8 Bit, specific type 24), and count lineary in each group.
> > > 
> > > Or has anybody any use for (UDS_ACCESS_TIME | UDS_URL) ? ;)
> > 
> > No indeed, but the first three atoms are data types, and those ones
> > are or'ed with the others.
> 
> I know. Thats why I said "we are only ||'ing together the base and
> the specific type" ;-)

Ah ok

> > See the definition of e.g. UDS_NAME: it contains two bits, one
> > for stating it's the name field, and the other for stating its
> > type is a string, using UDS_STRING.
> 
> Yes, so we should have the base types:
> UDS_STRING=1, UDS_LONG = 2, UDS_OTHER_TYPE = 3...
> and the specific ones:
> UDS_FILE_TYPE = 256 | UDS_LONG,
> UDS_LINK_DEST = 257 | UDS_STRING,
> UDS_URL = 258 | UDS_STRING

Huh ??? No. 258 is 256 + 2, and 2 is UDS_LONG...
An URL is not a long.

> (the numbers are not the current order, but you get the idea).
Not really, no.

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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