Development/Architecture/KDE4/Solid: Difference between revisions

    From KDE TechBase
    No edit summary
    (add translate tags)
    Line 1: Line 1:
    <languages />


    == <translate>Seamless Hardware Interaction</translate> ==
    <translate>With Solid, KDE developers are able to easily write applications with hardware interaction features. The necessary abstraction to support
    cross-platform application development is provided by Solid's clear and comprehensive API.</translate>


    == Seamless Hardware Interaction ==
    <translate>Its aim is not the control of the devices (Solid doesn't let you synchronize your mobile phone with your local address book): Solid ''looks for'' devices and gives you access to the information it has about them. This way, you could easily look at the functions of the cpu, or at the driver that handles your camera, or the mount point of your usb pen. In sum: it gives you the possibility of "seeing without touching" your devices.</translate>
    With Solid, KDE developers are able to easily write applications with hardware interaction features. The necessary abstraction to support
    cross-platform application development is provided by Solid's clear and comprehensive API.


    Its aim is not the control of the devices (Solid doesn't let you synchronize your mobile phone with your local address book): Solid ''looks for'' devices and gives you access to the information it has about them. This way, you could easily look at the functions of the cpu, or at the driver that handles your camera, or the mount point of your usb pen. In sum: it gives you the possibility of "seeing without touching" your devices.
    <translate>Now you would ask (at least, I asked myself): "Why should I need this library? I want to control the available hardware, not just see it!"</translate>


    Now you would ask (at least, I asked myself): "Why should I need this library? I want to control the available hardware, not just see it!"
    <translate>Well, Solid helps you a lot again: for any device interface, it gives you enough information to easily access it using other libraries or stacks. This way, if you want to manage your camera, you can use Solid to recognize it (you can use Solid::Notifier that will let you know when your camera has been plugged in), and then you can ask Solid to give you the information you need to handle it, for example with GPhoto or any other library you can think of. The same applies for any other plugged device: DVB cards (once recognized, Solid gives you the name of the associated device), audio cards (you can use ALSA, OSS or whatever you want: Solid knows the data to access it), portable media players, network cards, et cetera.
    Moreover, it lets you check if you're connected to any network or not, and you can use Solid to tell the system to connect (that is, you can ask Solid: "Give me access to the network, I don't want to care about details").</translate>


    Well, Solid helps you a lot again: for any device interface, it gives you enough information to easily access it using other libraries or stacks. This way, if you want to manage your camera, you can use Solid to recognize it (you can use Solid::Notifier that will let you know when your camera has been plugged in), and then you can ask Solid to give you the information you need to handle it, for example with GPhoto or any other library you can think of. The same applies for any other plugged device: DVB cards (once recognized, Solid gives you the name of the associated device), audio cards (you can use ALSA, OSS or whatever you want: Solid knows the data to access it), portable media players, network cards, et cetera.
    <translate>Anyway, some other things need to be said about network devices and Bluetooth. For these two classes of devices, Solid provides the "Control" namespace: that is, it lets you control them directly, without using external libraries. This means that with Solid, you can even handle your wireless or wired network interfaces, associate them to an essid, and choose ip configuration for them. You can even access your phone through Bluetooth, and so on.</translate>
    Moreover, it lets you check if you're connected to any network or not, and you can use Solid to tell the system to connect (that is, you can ask Solid: "Give me access to the network, I don't want to care about details").


    Anyway, some other things need to be said about network devices and Bluetooth. For these two classes of devices, Solid provides the "Control" namespace: that is, it lets you control them directly, without using external libraries. This means that with Solid, you can even handle your wireless or wired network interfaces, associate them to an essid, and choose ip configuration for them. You can even access your phone through Bluetooth, and so on.
    <translate>The "listing" part of Solid resides in kdelibs, while the Control namespace is in kdebase.</translate>


    The "listing" part of Solid resides in kdelibs, while the Control namespace is in kdebase.
    == <translate>Architecture Summary</translate> ==


    == Architecture Summary ==
    <translate>Solid was implemented using a frontend/backend approach aiming portability among platforms like Linux and Windows. The frontend provides the high-level API for developers using Solid and backends deal with the specific hardware issues for the different platforms.</translate>


    Solid was implemented using a frontend/backend approach aiming portability among platforms like Linux and Windows. The frontend provides the high-level API for developers using Solid and backends deal with the specific hardware issues for the different platforms.
    === <translate>Frontend View</translate> ===


    === Frontend View ===
    <translate>The frontend classes provide the API for developers and are also wrappers for several kinds of devices. All frontend clases are available in ''kdelibs/solid/solid''.</translate>
     
    The frontend classes provide the API for developers and are also wrappers for several kinds of devices. All frontend clases are available in ''kdelibs/solid/solid''.


    ==== Solid::DeviceNotifier ====
    ==== Solid::DeviceNotifier ====
    The device notifier is a singleton used to obtain information about the hardware available on the system. It provides to applications the unique entry point for hardware discovery and/or notifications about changes (with the use of Solid::DeviceNotifier::deviceAdded(const QString) and Solid::DeviceNotifier::deviceRemoved(const QString) signals). This class calls the following Solid::DeviceManager.
    <translate>The device notifier is a singleton used to obtain information about the hardware available on the system. It provides to applications the unique entry point for hardware discovery and/or notifications about changes (with the use of Solid::DeviceNotifier::deviceAdded(const QString) and Solid::DeviceNotifier::deviceRemoved(const QString) signals). This class calls the following Solid::DeviceManager.</translate>


    ==== Solid::DeviceManager ====
    ==== Solid::DeviceManager ====


    This (private) class maintains the state of all devices currently available on the system. Through it is possible to get, for example, the list of all devices or a list of device matching with some criteria (using Solid::Predicate).
    <translate>This (private) class maintains the state of all devices currently available on the system. Through it is possible to get, for example, the list of all devices or a list of device matching with some criteria (using Solid::Predicate).</translate>


    ==== Solid::Device ====
    ==== Solid::Device ====


    This class represents a general hardware device. A device contains one or more device interfaces (capabilities).  
    <translate>This class represents a general hardware device. A device contains one or more device interfaces (capabilities).</translate>


    ==== Solid::DeviceInterface ====
    ==== Solid::DeviceInterface ====


    A device interface represents a certain feature that a device contains. This class is on the top of the device interfaces inheritance tree. All specialized device interfaces implement it.
    <translate>A device interface represents a certain feature that a device contains. This class is on the top of the device interfaces inheritance tree. All specialized device interfaces implement it.</translate>


    ==== Specialized classes (Solid::Processor, Solid::OpticalDrive, Solid::Battery, etc.) ====
    ==== <translate>Specialized classes (Solid::Processor, Solid::OpticalDrive, Solid::Battery, etc.)</translate> ====


    These classes actually represent the capabilities that a device can have. All classes extend Solid::DeviceInterface.
    <translate>These classes actually represent the capabilities that a device can have. All classes extend Solid::DeviceInterface.</translate>


    === Backend View ===
    === <translate>Backend View</translate> ===


    A Solid backend deal with the platform-specific ways of handle devices. Developers using libsolid do not use the backend classes directly. Applications do it through frontend/wrapping classes in the Solid namespace.
    <translate>A Solid backend deal with the platform-specific ways of handle devices. Developers using libsolid do not use the backend classes directly. Applications do it through frontend/wrapping classes in the Solid namespace.</translate>


    All backends have to implement the interfaces in ''kdelibs/solid/solid/ifaces'' (namespace Solid::Ifaces) correspondent to its devices. These interfaces are the basics of which API a given device has to provide to the frontend classes.
    <translate>All backends have to implement the interfaces in ''kdelibs/solid/solid/ifaces'' (namespace Solid::Ifaces) correspondent to its devices. These interfaces are the basics of which API a given device has to provide to the frontend classes.</translate>


    === UML Diagram ===
    === <translate>UML Diagram</translate> ===


    This diagram shows the relationships between the Solid frontend classes and the platform-specific backend classes (''Foo'' backend).
    <translate>This diagram shows the relationships between the Solid frontend classes and the platform-specific backend classes (''Foo'' backend).</translate>


    [[File:Solid_Class_diagram.png|600px]]
    [[File:Solid_Class_diagram.png|600px]]


    [[Category:KDE4]]
    <translate>[[Category:KDE4]]</translate>
    [[Category:Architecture]]
    <translate>[[Category:Architecture]]</translate>
    [[Category:Solid]]
    <translate>[[Category:Solid]]</translate>

    Revision as of 01:16, 4 January 2013


    Seamless Hardware Interaction

    With Solid, KDE developers are able to easily write applications with hardware interaction features. The necessary abstraction to support cross-platform application development is provided by Solid's clear and comprehensive API.

    Its aim is not the control of the devices (Solid doesn't let you synchronize your mobile phone with your local address book): Solid looks for devices and gives you access to the information it has about them. This way, you could easily look at the functions of the cpu, or at the driver that handles your camera, or the mount point of your usb pen. In sum: it gives you the possibility of "seeing without touching" your devices.

    Now you would ask (at least, I asked myself): "Why should I need this library? I want to control the available hardware, not just see it!"

    Well, Solid helps you a lot again: for any device interface, it gives you enough information to easily access it using other libraries or stacks. This way, if you want to manage your camera, you can use Solid to recognize it (you can use Solid::Notifier that will let you know when your camera has been plugged in), and then you can ask Solid to give you the information you need to handle it, for example with GPhoto or any other library you can think of. The same applies for any other plugged device: DVB cards (once recognized, Solid gives you the name of the associated device), audio cards (you can use ALSA, OSS or whatever you want: Solid knows the data to access it), portable media players, network cards, et cetera. Moreover, it lets you check if you're connected to any network or not, and you can use Solid to tell the system to connect (that is, you can ask Solid: "Give me access to the network, I don't want to care about details").

    Anyway, some other things need to be said about network devices and Bluetooth. For these two classes of devices, Solid provides the "Control" namespace: that is, it lets you control them directly, without using external libraries. This means that with Solid, you can even handle your wireless or wired network interfaces, associate them to an essid, and choose ip configuration for them. You can even access your phone through Bluetooth, and so on.

    The "listing" part of Solid resides in kdelibs, while the Control namespace is in kdebase.

    Architecture Summary

    Solid was implemented using a frontend/backend approach aiming portability among platforms like Linux and Windows. The frontend provides the high-level API for developers using Solid and backends deal with the specific hardware issues for the different platforms.

    Frontend View

    The frontend classes provide the API for developers and are also wrappers for several kinds of devices. All frontend clases are available in kdelibs/solid/solid.

    Solid::DeviceNotifier

    The device notifier is a singleton used to obtain information about the hardware available on the system. It provides to applications the unique entry point for hardware discovery and/or notifications about changes (with the use of Solid::DeviceNotifier::deviceAdded(const QString) and Solid::DeviceNotifier::deviceRemoved(const QString) signals). This class calls the following Solid::DeviceManager.

    Solid::DeviceManager

    This (private) class maintains the state of all devices currently available on the system. Through it is possible to get, for example, the list of all devices or a list of device matching with some criteria (using Solid::Predicate).

    Solid::Device

    This class represents a general hardware device. A device contains one or more device interfaces (capabilities).

    Solid::DeviceInterface

    A device interface represents a certain feature that a device contains. This class is on the top of the device interfaces inheritance tree. All specialized device interfaces implement it.

    Specialized classes (Solid::Processor, Solid::OpticalDrive, Solid::Battery, etc.)

    These classes actually represent the capabilities that a device can have. All classes extend Solid::DeviceInterface.

    Backend View

    A Solid backend deal with the platform-specific ways of handle devices. Developers using libsolid do not use the backend classes directly. Applications do it through frontend/wrapping classes in the Solid namespace.

    All backends have to implement the interfaces in kdelibs/solid/solid/ifaces (namespace Solid::Ifaces) correspondent to its devices. These interfaces are the basics of which API a given device has to provide to the frontend classes.

    UML Diagram

    This diagram shows the relationships between the Solid frontend classes and the platform-specific backend classes (Foo backend).