[Kde-accessibility] qt questions

[Volker Hilsheimer]

> Volker, if I have questions regarding qt and I will have a lot, should
I post
> them here ? cross post them to qt-interest or what do you prefeer ?

Depends on how many other people are interested in the answer, I guess.
qt-interest is not a good channel, it's to crowded and I don't read it
regularily, so either this list, or me privately will do.

> My current question is where is QFeatureListInterface ?

QFeatureListInterface is a part of the QCom project, and used in the
backend of all the plugin stuff we have in Qt to identify which plugin
does what. It's declared in the private header qcom_p.h, and has a
single pure virtual function

virtual QStringList featureList() const = 0;

It also inherits from QUnknownInterface, which handles the refcounting,
and the interface navigation. This is identical to COM's IUnknown.

> It is used in qaccessible.h:256
> struct Q_EXPORT QAccessibleFactoryInterface : public QAccessible,
public
> QFeatureListInterface
> {
>     virtual QRESULT createAccessibleInterface( const QString &,
QObject *,
> QAccessibleInterface** ) = 0;
> };

We use structs because encapsulation doesn't make sense with interfaces
(ie. every function is public by default). Otherwise structs are the
same as classes in C++. QRESULT is a unsigned long. Possible return
values are also defined in qcom_p.h.
The factory interface above is what a plugin implements (and all the
interfaces inherited, e.g. QFeatureListInterface and QUnknownInterface),
and the plugin class is exported through a C-function
(Q_EXPORT_COMPONENT/Q_CREATE_INSTANCE macros; you can see those in the
plugin code I sent you).

Since this is all a bit complicated, and to close to COM we decided to
remove the QCom APIs from the public APIs before the last beta of Qt
3.0. All the other plugin classes are encapsulated in specialized plugin
classes in Qt (ie. QWidgetPlugin), but under the hood they use the same
technique.

We can definitely add a QAccessiblePlugin class like that to Qt that
makes it easier to implement accessibility plugins without having to
fight with the details above.

> which is used in
> qaccessible.cpp:343
> qAccessibleManager->queryInterface( mo->className(), &factory );
>
> qAccessibleManager is declared as:
> static QPluginManager<QAccessibleFactoryInterface> *qAccessibleManager
= 0;
> and defined as:
> qAccessibleManager = new QPluginManager<QAccessibleFactoryInterface>(
> IID_QAccessibleFactory, QApplication::libraryPaths(), "/accessible" );

The QPluginManager template opens all shared libs in the specified
directory, and ask the plugin's exported factory interface if it
implements the correct factory interface. If it does, it asks for the
QFeatureListInterface, if it is implemented it calls the featureList()
function, and from that point on the manager knows wat the factory in
the plugin can create. If then you call
QPluginManager::queryInterface( "feature", interface ) you get the
correct interface for "feature", e.g. the QAccessibleInterface
implementation for "className" without having to know which plugin
provides it.

 and what's this:
> #ifndef IID_QAccessibleFactory
> #define IID_QAccessibleFactory QUuid( 0x49f4c6a7, 0x412f, 0x41de,
0x9e, 0x24,
> 0x64, 0x88, 0x43, 0x42, 0x1f, 0xd3 )
> #endif ?
> Where does those numbers come from ? what for ?

This is a universally unique ID (UUID), a 128 bit value generated by a
program "uuidgen" (part of most Linux distributions AFAIK) that is based
on time (system clock) and space (Mac address). Every COM or QCom
interface is associated with such an ID, and that's the only way to
compare interfaces. E.g. the implementation of queryInterface says for
which IDs it can return a valid interface pointer, and the caller of
queryInterface asks whether an object implements this or that interface.
Corba uses UUIDs for similar purposes AFAIK.

Qt has a public class QUuid for those values. QUuid is the only part of
QCom that stayed in the public API.

--
Volker