[Kde-hardware-devel] Using a bitmask for device types

[Christopher Blauvelt]

Perhaps I should have put KDEHW:: in front of them.  I absolutely agree.  A
global (to KDEHW) would be fine.  It makes no difference in the code, except
for KDEHW::.  The only place where things get more hairy is when we get to
the subcapabilities.  If the device was only one type, a subtype bitmask
could have different meaning depending on the device.  This breaks down when
we have a device of more than one type.
One possible solution is to have a 16 wide array of subtype integers.  A
device with a bitmask of
if(this->DEVICE_TYPE & 2<<4)
{
    //device options are at this->OPTIONS[4]
    ...
}
One thing we need to decide is, are 16 device types and options enough or
should we go with 32?

OR . . . .

We could use the bitmask to identify what kind of devices are available and
have a **Device for arrays of *Devices, or QList<*Device> named things such
as:
QList<*Device> storage, camera, flying_machines;
Each one could then be a separate sub-class that inherits Device.

uint16 deviceDetected(QString dev, QString udi)
{
     //. . . determines it's a bluetooth phone with a storage device (for
pictures) and data functions
    storage.add( new Storage() );
    network.add(new BluetoothNetwork() );
}


On 1/12/06, Kevin Ottens <ervin at kde.org> wrote:
>
> Le Mercredi 11 Janvier 2006 12:03, Christopher Blauvelt a écrit :
> > Any thoughts?
>
> It's in the plan to move away from string based capabilities (you might
> have
> noticed some "FIXME" in the comments ;-) ).
>
> But from what you wrote it looks like you're proposing to use some
> "#define" (note that I'm guessing here). It would be better to use an enum
> type and an associated QFlags type. This way we'll be able to have the
> kind
> of notation you introduced, but we'll also be able to make stricter type
> checking.
>
> Regards.
> --
> Kévin 'ervin' Ottens, http://ervin.ipsquad.net
> "Ni le maître sans disciple, Ni le disciple sans maître,
> Ne font reculer l'ignorance."
>
>
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060112/a32b865f/attachment.html