[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-hardware-devel
Subject: Re: [Kde-hardware-devel] Using a bitmask for device types
From: Christopher Blauvelt <cblauvelt () gmail ! com>
Date: 2006-01-12 6:47:02
Message-ID: ffa898c90601112247y662475dah827960d38749421f () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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, excep=
t
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 whe=
n
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@kde.org> wrote:
>
> Le Mercredi 11 Janvier 2006 12:03, Christopher Blauvelt a =E9crit :
> > 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 enu=
m
> 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=E9vin 'ervin' Ottens, http://ervin.ipsquad.net
> "Ni le ma=EEtre sans disciple, Ni le disciple sans ma=EEtre,
> Ne font reculer l'ignorance."
>
>
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>
>
>
>
[Attachment #5 (text/html)]
<div>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. </div>
<div>One possible solution is to have a 16 wide array of subtype integers. A \
device with a bitmask of</div> <div>if(this->DEVICE_TYPE & 2<<4)</div>
<div>{</div>
<div> //device options are at this->OPTIONS[4]</div>
<div> ...</div>
<div>}<br>One thing we need to decide is, are 16 device types and options enough or \
should we go with 32?</div> <div> </div>
<div>OR . . . .</div>
<div> </div>
<div>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:</div> <div>QList<*Device> storage, camera, flying_machines;</div>
<div>Each one could then be a separate sub-class that inherits \
Device.<br> </div> <div>uint16 deviceDetected(QString dev, QString udi)</div>
<div>{</div>
<div> //. . . determines it's a bluetooth phone with a \
storage device (for pictures) and data functions</div> <div> \
storage.add( new Storage() );</div> <div> network.add(new \
BluetoothNetwork() );</div> <div>}</div><br><br>
<div><span class="gmail_quote">On 1/12/06, <b class="gmail_sendername">Kevin \
Ottens</b> <<a href="mailto:ervin@kde.org">ervin@kde.org</a>> wrote:</span> \
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; \
BORDER-LEFT: #ccc 1px solid">Le Mercredi 11 Janvier 2006 12:03, Christopher Blauvelt \
a écrit :<br>> Any thoughts?<br><br>It's in the plan to move away from string \
based capabilities (you might have <br>noticed some "FIXME" in the comments \
;-) ).<br><br>But from what you wrote it looks like you're proposing to use \
some<br>"#define" (note that I'm guessing here). It would be better to use \
an enum<br> type and an associated QFlags type. This way we'll be able to have the \
kind<br>of notation you introduced, but we'll also be able to make stricter \
type<br>checking.<br><br>Regards.<br>--<br>Kévin 'ervin' Ottens, <a \
href="http://ervin.ipsquad.net"> http://ervin.ipsquad.net</a><br>"Ni le maître \
sans disciple, Ni le disciple sans maître,<br>Ne font reculer \
l'ignorance."<br><br><br>_______________________________________________<br>Kde-hardware-devel \
mailing list <br><a href="mailto:Kde-hardware-devel@kde.org">Kde-hardware-devel@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/kde-hardware-devel">https://mail.kde.org/mailman/listinfo/kde-hardware-devel</a><br><br><br>
<br></blockquote></div><br>
_______________________________________________
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic