Development/Architecture/KDE4/Solid - Revision history

Neverendingo: Marked this version for translation

2013-01-04T01:17:54Z

Marked this version for translation

Neverendingo: add translate tags

2013-01-04T01:16:39Z

add translate tags

AnneW at 16:26, 13 July 2012

2012-07-13T16:26:43Z

Promulo at 05:05, 6 October 2010

2010-10-06T05:05:45Z

Rakuco: /* Seamless Hardware Interaction */ Fix typo

2009-08-19T18:27:03Z

‎Seamless Hardware Interaction: Fix typo

Rakuco: /* Seamless Hardware Interaction */ Fix typo and formatting

2009-08-19T18:21:32Z

‎Seamless Hardware Interaction: Fix typo and formatting

DrSlowDecay: Added language navigation

2008-11-29T18:32:29Z

Added language navigation

Tampakrap: spelling

2008-03-22T12:20:27Z

spelling

Tampakrap: move category text to architecure page. better suited than categories

2008-02-05T15:58:47Z

move category text to architecure page. better suited than categories

Tampakrap: Redirecting to Category:Solid

2007-03-20T10:28:15Z

Redirecting to Category:Solid

New page

#REDIRECT [[Category:Solid]]

@@ Line 1: / Line 1: @@
 <languages />
-== <translate>Seamless Hardware Interaction</translate> ==
+== <translate><!--T:1-->
-<translate>With Solid, KDE developers are able to easily write applications with hardware interaction features. The necessary abstraction to support
+Seamless Hardware Interaction</translate> ==
 cross-platform application development is provided by Solid's clear and comprehensive API.</translate>
-<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>
+<translate><!--T:3-->
-<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>
+<translate><!--T:4-->
-<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><!--T:5-->
 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>
-<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>
+<translate><!--T:6-->
-<translate>The "listing" part of Solid resides in kdelibs, while the Control namespace is in kdebase.</translate>
+<translate><!--T:7-->
-== <translate>Architecture Summary</translate> ==
+== <translate><!--T:8-->
-<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>
+<translate><!--T:9-->
-=== <translate>Frontend View</translate> ===
+=== <translate><!--T:10-->
-<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>
+<translate><!--T:11-->
 ==== Solid::DeviceNotifier ====
-<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>
+<translate><!--T:12-->
 ==== Solid::DeviceManager ====
-<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>
+<translate><!--T:13-->
 ==== Solid::Device ====
-<translate>This class represents a general hardware device. A device contains one or more device interfaces (capabilities).</translate>
+<translate><!--T:14-->
 ==== Solid::DeviceInterface ====
-<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>
+<translate><!--T:15-->
-==== <translate>Specialized classes (Solid::Processor, Solid::OpticalDrive, Solid::Battery, etc.)</translate> ====
+==== <translate><!--T:16-->
-<translate>These classes actually represent the capabilities that a device can have. All classes extend Solid::DeviceInterface.</translate>
+<translate><!--T:17-->
-=== <translate>Backend View</translate> ===
+=== <translate><!--T:18-->
-<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>
+<translate><!--T:19-->
-<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>
+<translate><!--T:20-->
-=== <translate>UML Diagram</translate> ===
+=== <translate><!--T:21-->
-<translate>This diagram shows the relationships between the Solid frontend classes and the platform-specific backend classes (''Foo'' backend).</translate>
+<translate><!--T:22-->
 [[File:Solid_Class_diagram.png|600px]]
-<translate>[[Category:KDE4]]</translate>
+<translate><!--T:23-->
-<translate>[[Category:Architecture]]</translate>
+[[Category:KDE4]]</translate>
-<translate>[[Category:Solid]]</translate>
+<translate><!--T:24-->

@@ Line 1: / Line 1: @@
-== 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.
-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 ====
-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 ====
-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 ====
-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 ====
-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]]
-[[Category:KDE4]]
+<translate>[[Category:KDE4]]</translate>
-[[Category:Architecture]]
+<translate>[[Category:Architecture]]</translate>
-[[Category:Solid]]
+<translate>[[Category:Solid]]</translate>

← Older revision		Revision as of 16:26, 13 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Development/Architecture/KDE4/Solid}}~~	+

	== Seamless Hardware Interaction ==		== Seamless Hardware Interaction ==

@@ Line 15: / Line 15: @@
 The "listing" part of Solid resides in kdelibs, while the Control namespace is in kdebase.
 [[Category:KDE4]]
 [[Category:Architecture]]
 [[Category:Solid]]

@@ Line 12: / Line 12: @@
 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 needs 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.
+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.

← Older revision		Revision as of 18:32, 29 November 2008
Line 1:		Line 1:
		+	{{Template:I18n/Language Navigation Bar\|Development/Architecture/KDE4/Solid}}
		+
	== Seamless Hardware Interaction ==		== Seamless Hardware Interaction ==
	With Solid, KDE developers are able to easily write applications with hardware interaction features. The necessary abstraction to support		With Solid, KDE developers are able to easily write applications with hardware interaction features. The necessary abstraction to support

← Older revision		Revision as of 15:58, 5 February 2008
Line 1:		Line 1:
−	~~#REDIRECT~~ [[Category:Solid]]	+	== 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 syncronize your mobile phone with your local addressbook): Solid looks for devices and let 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 needs to be said about network devices and Bluetooth. For this 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 throught Bluetooth, et so on.
		+
		+	The "listing" part of Solid resides in kdelibs, while the Control namespace is in kdebase.
		+
		+	[[Category:KDE4]]
		+	[[Category:Architecture]]
		+	[[Category:Solid]]