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