KDE TechBase - User contributions [en]

Schedules/KDE4/4.3 Feature Plan

2008-11-28T10:07:14Z

Cbs: Typo: Suuport->Support

This is a list of planned features for the 4.3 release.

See also:
* [[Schedules/KDE4/4.3 Release Schedule]]
* [[Schedules/KDE4/4.2 Feature Plan]]
* [[Schedules/KDE4/4.3 Release Goals]]

Legend:
* todo => not started yet
* in-progress => started, but not completed yet
* done => completed
__TOC__

= Other =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Akonadi|Various Akonadi related items can be found here http://techbase.kde.org/Projects/PIM/Akonadi#Scheduled_for_4.3|kde-pim@kde.org|Akonadi Developers}}
|}

= kdelibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KLocale|Investigate adding Currency Code and currency minor units support based on ISO 4217 (http://en.wikipedia.org/wiki/ISO_4217).|john@layt.net|John Layt}}
{{FeatureTodo|KCalenderSystem|Add new astronomical calculation support classes to be used in kdelibs to build new astronomically based calendar systems, and in kdepim to build new version of libkholiday.|john@layt.net|John Layt}}
{{FeatureTodo|KCalenderSystem|Add new calendar systems: Indian Civil (Saka), Ethiopean, Chinese, Pure Julian, Pure Gregorian, etc.|john@layt.net|John Layt}}
{{FeatureTodo|KDEPrint|If no file printing support in Qt4.5, migrate FilePrinter class from Okular to enable file printing for all apps via QPrinter. To be discussed on k-c-d first.|john@layt.net|John Layt}}
{{FeatureTodo|KDEPrint|Add framework for standard actions for 'Send to...' for e-mail, fax, etc by printing to PDF/PS.|john@layt.net|John Layt}}
{{FeatureTodo|new bookmark system|Port KBookmarks to akonadi/nepomuk. Will need help on this. [[Projects/PIM/Akonadi/Bookmarks|Details]]|xavier.vello@gmail.com|Xavier Vello}}
|}

= kdebase-workspace =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |Non-Plasma, Non-KWin
{{FeatureTodo|Kxkb|Support for keyboard hotplugging|rysin:AT:kde.org|Andriy Rysin}}
{{FeatureTodo|Kxkb|Support for languages in keyboard layout descriptions|rysin:AT:kde.org|Andriy Rysin}}

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |KRunner

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |Plasma - Priority Features

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |Plasma
{{FeatureTodo|Now Playing data engine|Support for MPD|kde:AT:randomguy3.me.uk|Alex Merry}}
|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |KWin - Core
{{FeatureTodo|KWin|Rework of the KWin desktop effect system settings GUI|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureTodo|KWin|ARGB support for decorations|lmurray@undefinedfire.com|Lucas Murray}}
|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |KWin - Desktop Effects
{{FeatureInProgress|KWin|Improved mouse mark/scribble effect|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureTodo|KWin|Make PresentWindows effect available for other effects (e.g. Desktop Grid)|kde@martin-graesslin.com|Martin Gräßlin}}
|}

= kdepimlibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdenetwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Kopete|Jabber Jingle video support|detlev.casanova@gmail.com|Detlev Casanova}}
{{FeatureTodo|Kopete|Jabber Jingle ICE support|detlev.casanova@gmail.com|Detlev Casanova}}
{{FeatureInProgress|Kopete|Contacts plasmoid|earthwings@gentoo.org|Dennis Nienhüser}}
|}

= kdepim =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeutils =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|printer-applet|Restore feature parity with KDEPrint3 where possible.|john@layt.net|John Layt}}
{{FeatureTodo|Okteta|make editing capability to Decoding table |kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add Kate-like search tool|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for import by drop, both url and data|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|copy again puts also a value or char variant of the data to clipboard|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for memory mapping of files|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add further export formats like s-record and intel 16|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for jobs like io, printing, string search or filter|kossebau@kde.org|Friedrich W. H. Kossebau}}
|}

= kdebindings =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|krossjava|Integrate into e.g. SuperKaramba and fix issues that show up.|mail@dipe.org|Sebastian Sauer}}
{{FeatureTodo|krossjava|Documentation++|mail@dipe.org|Sebastian Sauer}}
{{FeatureTodo|krossfalcon|Documentation++|mail@dipe.org|Sebastian Sauer}}
|}

= kdegames =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KSpaceDuel|rewrite AI code|dirkrathlev@gmx.de|Dirk Rathlev}}
{{FeatureTodo|KsirK|rewrite AI code or at least correct most problems related in bug #170777. Volunteers wanted!|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|KsirK|Previous/Next in start new game as described in bug #170774|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|KsirK|Polish the skin editor (doc, contextual help, ...)|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|KsirK|Boost playing over Jabber|kleag@free.fr|Gaël de Chalendar}}
|}

= kdeadmin =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KGrubEditor|Integrate KGrubEditor into KDE Admin http://sourceforge.net/projects/kgrubeditor. Approved by Nicolas Ternisien <nicolas.ternisien@gmail.com> |artemis_dot_fowl_dot_2007@gmail_dot_com|Konstantinos Smanis}}
{{FeatureTodo|Guidance|Port Guidance to KDE 4, and move it to KDE Admin http://www.simonzone.com/software/guidance/.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureTodo|system-config-printer-kde|Restore feature parity with KDEPrint3 where possible.|john@layt.net|john Layt}}
|}

= kdesdk =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeedu =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Kalzium|Port Kalzium's periodic table to use new QGraphicsView.|marcus@cryos.org|Marcus D. Hanwell}}
{{FeatureTodo|Kalzium|Remove the libavogadro snapshot, depend on libavogadro directly.|jacob@math.jussieu.fr|Benoit Jacob}}
|}

= kdemultimedia =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeaccessibility =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdegraphics =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Okular|Generator for Mobipocket format|qbast@go2.pl|Jakub Stachowski}}
{{FeatureInProgress|strigi|Thumbnailer and analyzer for Mobipocket format|qbast@go2.pl|Jakub Stachowski}}
{{FeatureInProgress|strigi|Thumbnailer and analyzer for epub format|qbast@go2.pl|Jakub Stachowski}}
|}

= kdebase-runtime =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|kio_bookmarks|Refactoring using the new bookmarks system and qt/plasma for displaying|xavier.vello@gmail.com|Xavier Vello}}
|}

= kdebase-apps =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeplasma-addons =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

Development/Tutorials/Decibel/GettingStarted

2008-05-25T10:19:05Z

Cbs: /* Accounthandling */ - link to walkthrough section

{{TutorialBrowser|

series=Decibel Tutorial|

name=Getting Started with Decibel|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt]|
next=[[Development/Tutorials/Decibel/Handling_TextChannels|Handling TextChannels]]|

reading=|
}}
= Getting started with Decibel =

This is a short tutorial describing how to set up the Decibel realtime communication system. It is intended for developers interested in working on or with Decibel.

'''Note:''' ''Decibel is no IM client. You can not use Decibel to chat with your friends without additional software!''

'''Note:''' ''This guide assumes that you have the telepathy Gabble connection manager installed which enables Jabber access. Other connection managers may work as well, but are not as well tested. Telepathy Gabble is part of most recent linux distributions and can be found [http://telepathy.freedesktop.org/releases/telepathy-gabble/ here].''

== Requirements ==

All demos shipped with Decibel require the Decibel daemon to be up and running. After building Decibel this daemon is located in {{path|src/server/decibel}}. The daemon does (so far) not fork and blocks the terminal it is run from: Very useful behaviour when debugging problems.

The Decibel daemon in turn requires an active D-Bus session bus. This is a precondition for all KDE 4 applications, so it is mentioned for completeness sake only.

== Walkthrough ==

This section describes a sequence of command line demos recommended to try and test decibel.

# Make one or more of your accounts known to the Account Manager in Decibel. (see decibel_registeraccount_demo).
# List all stored accounts and find the account handle. (See decibel_listaccounts_demo).
# Set the desired presence state of an account to "online" using decibel_setpresence_demo.
# Have someone connect to and send a "ping?" message to your now online account. Decibel will launch a ping-handler which in turn will reply with a "pong!". See decibel_simpleclient_demo).
# Use Decibel to connect to other accounts. See decibel_chatstarter_demo.

'''Note:''' ''Steps 1 to 3 can be done using the account manager KControl module as well. Run <tt>kcmshell4 decibel_accountmanager</tt> if you prefer to use this more convenient method.''

== Demos ==

=== Accounthandling ===

The demos in {{path|demos/accounthandling}} are showing how to manipulate the account storage of the Decibel daemon. They can be used as simple command line tools to manipulate accounts known to Decibel.

Please note that the accountmanager KControl Module that is installed together with Decibel provides the same functionality as these command line demos. See the [[Development/Tutorials/Decibel/GettingStarted#Walkthrough|Walkthrough section]] for instructions on how to use the KControl module.

==== decibel_registeraccount_demo ====

'''Warning:''' When ''not'' using KDE4, then passwords that are part of the account data are stored in clear text in the configuration files of the Decibel daemon. When KDE4 is found during configuration of Decibel then KWallet is used to store passwords in a secure location.

This demo registers an account with the Decibel daemon. Note that this command does ''not'' create new accounts and can only register already existing accounts with Decibel.

The demo expects several sets of key-value pairs. These are of the following form: <tt>key=type:value</tt> where type is either <tt>i</tt> for integer values or <tt>s</tt> for string values. Other types are not supported by this simplistic demo.

You must register all the keys the connection manager you wish to use for the account requires (see the documentation of the connection manager for a complete list). In addition to those settings Decibel requires a further key-value pair: <tt>decibel_protocol</tt> of type <tt>s</tt> containing the protocol this account is for.

==== decibel_deleteaccount_demo ====

This demo removes a account from Decibel's account storage. This demo expects a account handle (see decibel_listaccounts_demo) and removes the account associated with that handle.

==== decibel_listaccounts_demo ====

The listaccounts demo prints a list of all accounts known to Decibel together with the account handle associated with it. It expects no parameters.

==== decibel_setpresence_demo ====

This demo is used to manipulate the presence state of an account managed by Decibel.

It expects two parameters and accepts an optional third. The first is the handle to the account to change (see decibel_listaccounts_demo). The second is the new presence level. This is an integer value in the range of 1 to 6. 1 is Offline, 2 Available, 3 Away, 4 XA, 5 Hidden and 6 Busy.

The optional third argument is a presence message.

'''Note:''' Changing the presence state from 1 to any other valid value causes Decibel to create a connection to the server the account is for. Changing from a valid value not equal to 1 to 1 disconnects the account again.

=== Protocolhandling ===

The demos in {{path|demos/protocolhandling}} can be used to examine various settings on the Telepathy Connection Managers.

==== decibel_listcms_demo ====

This demo lists all Telepathy Connection Managers installed in the system. This demo does not expect any parameters.

==== decibel_supportedprotocols_demo ====

This demo lists all protocols supported by Telepathy Connection Managers installed on the system. This demo does not expect any parameters.

==== decibel_listcmsfor_demo ====

This demo lists all Telepathy Connection Managers installed in the system that support a protocol. This protocol has to be given as the first parameter to the demo.

==== decibel_defaultcmfor_demo ====

This demo expects a protocol name as its only argument. It reports the Telepathy connection manager configured in Decibel to handle all connections made using this protocol.

==== decibel_setdefaultcmfor_demo ====

This demo expects two parameters. The first is a protocol name and the second a name of a Telepathy Connection Manager installed.

Using this demo the Connection Manager used by Decibel to handle a protocol can be changed. By default one of the possible Connection Managers is chosen for each protocol supported.

=== Contacthandling ===

The demos in {{path|demos/contacthandling}} can be used to create connections to contacts. Decibel communicates with the users personal information management (PIM) system to get contact data and identifies contacts by the IDs they got in that system.

'''Note:''' Proper integration into KDE4's Akonadi is still in development.

'''Note:''' If you have not choosen to integrate Decibel with the KDE 4 environment then the SimplisticContactConnector was configured to provide a really simplistic contact management tool. It reads contact data from an INI file in {{path|~/.decibel_contact_data.ini}}. For the contacthandling demos to work you need to set up some contacts in this file. See {{path|docs/examples/decibel_contact_data.ini}} for an example file.

==== decibel_chatstarter_demo ====

This demo expects an account handle (see decibel_listaccounts_demo) and a contact ID from the connected PIM system (or the INI file of the SimplisticContactConnector).

I will cause Decibel to bring up the account associated with the account handle checks whether the contact of the given ID is on line and sends him a little ping-message.

=== simpleclient ===

By default the decibel_simpleclient_demo is started on incoming (jabber) connections by the Decibel daemon. It uses D-Bus activation for this, so a .service file needs to be installed into a D-Bus service directory. During installation Decibel creates such a file (in {{path|demos/simpleclient}} of the build directory) and installs it into {{path|share/dbus-1/services}}. This directory should work out fine if Decibel is installed alongside KDE4.

If the simpleclient is not started on incoming jabber channels, then you might want to copy the .service file into the {{path|~/.local/dbus-1/services}} directory and try again.

As its name advertises this client is pretty simple: It sends a "pong!"
message in response to every "ping?" message it receives.

Development/Tutorials/Decibel/GettingStarted

2008-05-25T10:14:00Z

Cbs: /* Walkthrough */ minor style changes

{{TutorialBrowser|

series=Decibel Tutorial|

name=Getting Started with Decibel|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt]|
next=[[Development/Tutorials/Decibel/Handling_TextChannels|Handling TextChannels]]|

reading=|
}}
= Getting started with Decibel =

This is a short tutorial describing how to set up the Decibel realtime communication system. It is intended for developers interested in working on or with Decibel.

'''Note:''' ''Decibel is no IM client. You can not use Decibel to chat with your friends without additional software!''

'''Note:''' ''This guide assumes that you have the telepathy Gabble connection manager installed which enables Jabber access. Other connection managers may work as well, but are not as well tested. Telepathy Gabble is part of most recent linux distributions and can be found [http://telepathy.freedesktop.org/releases/telepathy-gabble/ here].''

== Requirements ==

All demos shipped with Decibel require the Decibel daemon to be up and running. After building Decibel this daemon is located in {{path|src/server/decibel}}. The daemon does (so far) not fork and blocks the terminal it is run from: Very useful behaviour when debugging problems.

The Decibel daemon in turn requires an active D-Bus session bus. This is a precondition for all KDE 4 applications, so it is mentioned for completeness sake only.

== Walkthrough ==

This section describes a sequence of command line demos recommended to try and test decibel.

# Make one or more of your accounts known to the Account Manager in Decibel. (see decibel_registeraccount_demo).
# List all stored accounts and find the account handle. (See decibel_listaccounts_demo).
# Set the desired presence state of an account to "online" using decibel_setpresence_demo.
# Have someone connect to and send a "ping?" message to your now online account. Decibel will launch a ping-handler which in turn will reply with a "pong!". See decibel_simpleclient_demo).
# Use Decibel to connect to other accounts. See decibel_chatstarter_demo.

'''Note:''' ''Steps 1 to 3 can be done using the account manager KControl module as well. Run <tt>kcmshell4 decibel_accountmanager</tt> if you prefer to use this more convenient method.''

== Demos ==

=== Accounthandling ===

The demos in {{path|demos/accounthandling}} are showing how to manipulate the account storage of the Decibel daemon. They can be used as simple command line tools to manipulate accounts known to Decibel.

Please note that the accountmanager KControl Module that is installed together with Decibel provides the same functionality as these command line demos. See the Walkthrough section for instructions on how to use the KControl module.

==== decibel_registeraccount_demo ====

'''Warning:''' When ''not'' using KDE4, then passwords that are part of the account data are stored in clear text in the configuration files of the Decibel daemon. When KDE4 is found during configuration of Decibel then KWallet is used to store passwords in a secure location.

This demo registers an account with the Decibel daemon. Note that this command does ''not'' create new accounts and can only register already existing accounts with Decibel.

The demo expects several sets of key-value pairs. These are of the following form: <tt>key=type:value</tt> where type is either <tt>i</tt> for integer values or <tt>s</tt> for string values. Other types are not supported by this simplistic demo.

You must register all the keys the connection manager you wish to use for the account requires (see the documentation of the connection manager for a complete list). In addition to those settings Decibel requires a further key-value pair: <tt>decibel_protocol</tt> of type <tt>s</tt> containing the protocol this account is for.

==== decibel_deleteaccount_demo ====

This demo removes a account from Decibel's account storage. This demo expects a account handle (see decibel_listaccounts_demo) and removes the account associated with that handle.

==== decibel_listaccounts_demo ====

The listaccounts demo prints a list of all accounts known to Decibel together with the account handle associated with it. It expects no parameters.

==== decibel_setpresence_demo ====

This demo is used to manipulate the presence state of an account managed by Decibel.

It expects two parameters and accepts an optional third. The first is the handle to the account to change (see decibel_listaccounts_demo). The second is the new presence level. This is an integer value in the range of 1 to 6. 1 is Offline, 2 Available, 3 Away, 4 XA, 5 Hidden and 6 Busy.

The optional third argument is a presence message.

'''Note:''' Changing the presence state from 1 to any other valid value causes Decibel to create a connection to the server the account is for. Changing from a valid value not equal to 1 to 1 disconnects the account again.

=== Protocolhandling ===

The demos in {{path|demos/protocolhandling}} can be used to examine various settings on the Telepathy Connection Managers.

==== decibel_listcms_demo ====

This demo lists all Telepathy Connection Managers installed in the system. This demo does not expect any parameters.

==== decibel_supportedprotocols_demo ====

This demo lists all protocols supported by Telepathy Connection Managers installed on the system. This demo does not expect any parameters.

==== decibel_listcmsfor_demo ====

This demo lists all Telepathy Connection Managers installed in the system that support a protocol. This protocol has to be given as the first parameter to the demo.

==== decibel_defaultcmfor_demo ====

This demo expects a protocol name as its only argument. It reports the Telepathy connection manager configured in Decibel to handle all connections made using this protocol.

==== decibel_setdefaultcmfor_demo ====

This demo expects two parameters. The first is a protocol name and the second a name of a Telepathy Connection Manager installed.

Using this demo the Connection Manager used by Decibel to handle a protocol can be changed. By default one of the possible Connection Managers is chosen for each protocol supported.

=== Contacthandling ===

The demos in {{path|demos/contacthandling}} can be used to create connections to contacts. Decibel communicates with the users personal information management (PIM) system to get contact data and identifies contacts by the IDs they got in that system.

'''Note:''' Proper integration into KDE4's Akonadi is still in development.

'''Note:''' If you have not choosen to integrate Decibel with the KDE 4 environment then the SimplisticContactConnector was configured to provide a really simplistic contact management tool. It reads contact data from an INI file in {{path|~/.decibel_contact_data.ini}}. For the contacthandling demos to work you need to set up some contacts in this file. See {{path|docs/examples/decibel_contact_data.ini}} for an example file.

==== decibel_chatstarter_demo ====

This demo expects an account handle (see decibel_listaccounts_demo) and a contact ID from the connected PIM system (or the INI file of the SimplisticContactConnector).

I will cause Decibel to bring up the account associated with the account handle checks whether the contact of the given ID is on line and sends him a little ping-message.

=== simpleclient ===

By default the decibel_simpleclient_demo is started on incoming (jabber) connections by the Decibel daemon. It uses D-Bus activation for this, so a .service file needs to be installed into a D-Bus service directory. During installation Decibel creates such a file (in {{path|demos/simpleclient}} of the build directory) and installs it into {{path|share/dbus-1/services}}. This directory should work out fine if Decibel is installed alongside KDE4.

If the simpleclient is not started on incoming jabber channels, then you might want to copy the .service file into the {{path|~/.local/dbus-1/services}} directory and try again.

As its name advertises this client is pretty simple: It sends a "pong!"
message in response to every "ping?" message it receives.

Development/Tutorials/Decibel/GettingStarted

2008-05-25T10:10:08Z

Cbs: Walkthrough - fix list

{{TutorialBrowser|

series=Decibel Tutorial|

name=Getting Started with Decibel|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt]|
next=[[Development/Tutorials/Decibel/Handling_TextChannels|Handling TextChannels]]|

reading=|
}}
= Getting started with Decibel =

This is a short tutorial describing how to set up the Decibel realtime communication system. It is intended for developers interested in working on or with Decibel.

'''Note:''' ''Decibel is no IM client. You can not use Decibel to chat with your friends without additional software!''

'''Note:''' ''This guide assumes that you have the telepathy Gabble connection manager installed which enables Jabber access. Other connection managers may work as well, but are not as well tested. Telepathy Gabble is part of most recent linux distributions and can be found [http://telepathy.freedesktop.org/releases/telepathy-gabble/ here].''

== Requirements ==

All demos shipped with Decibel require the Decibel daemon to be up and running. After building Decibel this daemon is located in {{path|src/server/decibel}}. The daemon does (so far) not fork and blocks the terminal it is run from: Very useful behaviour when debugging problems.

The Decibel daemon in turn requires an active D-Bus session bus. This is a precondition for all KDE 4 applications, so it is mentioned for completeness sake only.

== Walkthrough ==

This section gives a recommended sequence of command line demos to try.

# Make one or more of your accounts known to the Account Manager in Decibel. (see decibel_registeraccount_demo).
# List all stored accounts and find the account handle. (See decibel_listaccounts_demo).
# Set the desired presence state of an account to "online" using decibel_setpresence_demo.
# Have someone connect to your now online account and have him send a "ping?" message. Decibel will launch a ping-handler which in turn will reply with a "pong!". See decibel_simpleclient_demo).
# Use Decibel to connect to other accounts. See decibel_chatstarter_demo.

'''Note:''' ''Steps 1 to 3 can be done using the account manager KControl module as well. Run <tt>kcmshell4 decibel_accountmanager</tt> if you prefer to use this more convenient method.''

== Demos ==

=== Accounthandling ===

The demos in {{path|demos/accounthandling}} are showing how to manipulate the account storage of the Decibel daemon. They can be used as simple command line tools to manipulate accounts known to Decibel.

Please note that the accountmanager KControl Module that is installed together with Decibel provides the same functionality as these command line demos. See the Walkthrough section for instructions on how to use the KControl module.

==== decibel_registeraccount_demo ====

'''Warning:''' When ''not'' using KDE4, then passwords that are part of the account data are stored in clear text in the configuration files of the Decibel daemon. When KDE4 is found during configuration of Decibel then KWallet is used to store passwords in a secure location.

This demo registers an account with the Decibel daemon. Note that this command does ''not'' create new accounts and can only register already existing accounts with Decibel.

The demo expects several sets of key-value pairs. These are of the following form: <tt>key=type:value</tt> where type is either <tt>i</tt> for integer values or <tt>s</tt> for string values. Other types are not supported by this simplistic demo.

You must register all the keys the connection manager you wish to use for the account requires (see the documentation of the connection manager for a complete list). In addition to those settings Decibel requires a further key-value pair: <tt>decibel_protocol</tt> of type <tt>s</tt> containing the protocol this account is for.

==== decibel_deleteaccount_demo ====

This demo removes a account from Decibel's account storage. This demo expects a account handle (see decibel_listaccounts_demo) and removes the account associated with that handle.

==== decibel_listaccounts_demo ====

The listaccounts demo prints a list of all accounts known to Decibel together with the account handle associated with it. It expects no parameters.

==== decibel_setpresence_demo ====

This demo is used to manipulate the presence state of an account managed by Decibel.

It expects two parameters and accepts an optional third. The first is the handle to the account to change (see decibel_listaccounts_demo). The second is the new presence level. This is an integer value in the range of 1 to 6. 1 is Offline, 2 Available, 3 Away, 4 XA, 5 Hidden and 6 Busy.

The optional third argument is a presence message.

'''Note:''' Changing the presence state from 1 to any other valid value causes Decibel to create a connection to the server the account is for. Changing from a valid value not equal to 1 to 1 disconnects the account again.

=== Protocolhandling ===

The demos in {{path|demos/protocolhandling}} can be used to examine various settings on the Telepathy Connection Managers.

==== decibel_listcms_demo ====

This demo lists all Telepathy Connection Managers installed in the system. This demo does not expect any parameters.

==== decibel_supportedprotocols_demo ====

This demo lists all protocols supported by Telepathy Connection Managers installed on the system. This demo does not expect any parameters.

==== decibel_listcmsfor_demo ====

This demo lists all Telepathy Connection Managers installed in the system that support a protocol. This protocol has to be given as the first parameter to the demo.

==== decibel_defaultcmfor_demo ====

This demo expects a protocol name as its only argument. It reports the Telepathy connection manager configured in Decibel to handle all connections made using this protocol.

==== decibel_setdefaultcmfor_demo ====

This demo expects two parameters. The first is a protocol name and the second a name of a Telepathy Connection Manager installed.

Using this demo the Connection Manager used by Decibel to handle a protocol can be changed. By default one of the possible Connection Managers is chosen for each protocol supported.

=== Contacthandling ===

The demos in {{path|demos/contacthandling}} can be used to create connections to contacts. Decibel communicates with the users personal information management (PIM) system to get contact data and identifies contacts by the IDs they got in that system.

'''Note:''' Proper integration into KDE4's Akonadi is still in development.

'''Note:''' If you have not choosen to integrate Decibel with the KDE 4 environment then the SimplisticContactConnector was configured to provide a really simplistic contact management tool. It reads contact data from an INI file in {{path|~/.decibel_contact_data.ini}}. For the contacthandling demos to work you need to set up some contacts in this file. See {{path|docs/examples/decibel_contact_data.ini}} for an example file.

==== decibel_chatstarter_demo ====

This demo expects an account handle (see decibel_listaccounts_demo) and a contact ID from the connected PIM system (or the INI file of the SimplisticContactConnector).

I will cause Decibel to bring up the account associated with the account handle checks whether the contact of the given ID is on line and sends him a little ping-message.

=== simpleclient ===

By default the decibel_simpleclient_demo is started on incoming (jabber) connections by the Decibel daemon. It uses D-Bus activation for this, so a .service file needs to be installed into a D-Bus service directory. During installation Decibel creates such a file (in {{path|demos/simpleclient}} of the build directory) and installs it into {{path|share/dbus-1/services}}. This directory should work out fine if Decibel is installed alongside KDE4.

If the simpleclient is not started on incoming jabber channels, then you might want to copy the .service file into the {{path|~/.local/dbus-1/services}} directory and try again.

As its name advertises this client is pretty simple: It sends a "pong!"
message in response to every "ping?" message it receives.

Development/Tutorials/Decibel/GettingStarted

2008-05-25T10:07:30Z

Cbs: /* Requirements */

{{TutorialBrowser|

series=Decibel Tutorial|

name=Getting Started with Decibel|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt]|
next=[[Development/Tutorials/Decibel/Handling_TextChannels|Handling TextChannels]]|

reading=|
}}
= Getting started with Decibel =

This is a short tutorial describing how to set up the Decibel realtime communication system. It is intended for developers interested in working on or with Decibel.

'''Note:''' ''Decibel is no IM client. You can not use Decibel to chat with your friends without additional software!''

'''Note:''' ''This guide assumes that you have the telepathy Gabble connection manager installed which enables Jabber access. Other connection managers may work as well, but are not as well tested. Telepathy Gabble is part of most recent linux distributions and can be found [http://telepathy.freedesktop.org/releases/telepathy-gabble/ here].''

== Requirements ==

All demos shipped with Decibel require the Decibel daemon to be up and running. After building Decibel this daemon is located in {{path|src/server/decibel}}. The daemon does (so far) not fork and blocks the terminal it is run from: Very useful behaviour when debugging problems.

The Decibel daemon in turn requires an active D-Bus session bus. This is a precondition for all KDE 4 applications, so it is mentioned for completeness sake only.

== Walkthrough ==

This section gives a recommended sequence of command line demos to try.

# Make one or more of your accounts known to the Account Manager in Decibel. (see decibel_registeraccount_demo).

# List all stored accounts and find the account handle. (See decibel_listaccounts_demo).

# Set the desired presence state of an account to "online" using decibel_setpresence_demo.

# Have someone connect to your now online account and have him send a "ping?" message. Decibel will launch a ping-handler which in turn will reply with a "pong!". See decibel_simpleclient_demo).

# Use Decibel to connect to other accounts. See decibel_chatstarter_demo.

'''Note:''' ''Steps 1 to 3 can be done using the account manager KControl module as well. Run <tt>kcmshell4 decibel_accountmanager</tt> if you prefer to use this more convenient method.''

== Demos ==

=== Accounthandling ===

The demos in {{path|demos/accounthandling}} are showing how to manipulate the account storage of the Decibel daemon. They can be used as simple command line tools to manipulate accounts known to Decibel.

Please note that the accountmanager KControl Module that is installed together with Decibel provides the same functionality as these command line demos. See the Walkthrough section for instructions on how to use the KControl module.

==== decibel_registeraccount_demo ====

'''Warning:''' When ''not'' using KDE4, then passwords that are part of the account data are stored in clear text in the configuration files of the Decibel daemon. When KDE4 is found during configuration of Decibel then KWallet is used to store passwords in a secure location.

This demo registers an account with the Decibel daemon. Note that this command does ''not'' create new accounts and can only register already existing accounts with Decibel.

The demo expects several sets of key-value pairs. These are of the following form: <tt>key=type:value</tt> where type is either <tt>i</tt> for integer values or <tt>s</tt> for string values. Other types are not supported by this simplistic demo.

You must register all the keys the connection manager you wish to use for the account requires (see the documentation of the connection manager for a complete list). In addition to those settings Decibel requires a further key-value pair: <tt>decibel_protocol</tt> of type <tt>s</tt> containing the protocol this account is for.

==== decibel_deleteaccount_demo ====

This demo removes a account from Decibel's account storage. This demo expects a account handle (see decibel_listaccounts_demo) and removes the account associated with that handle.

==== decibel_listaccounts_demo ====

The listaccounts demo prints a list of all accounts known to Decibel together with the account handle associated with it. It expects no parameters.

==== decibel_setpresence_demo ====

This demo is used to manipulate the presence state of an account managed by Decibel.

It expects two parameters and accepts an optional third. The first is the handle to the account to change (see decibel_listaccounts_demo). The second is the new presence level. This is an integer value in the range of 1 to 6. 1 is Offline, 2 Available, 3 Away, 4 XA, 5 Hidden and 6 Busy.

The optional third argument is a presence message.

'''Note:''' Changing the presence state from 1 to any other valid value causes Decibel to create a connection to the server the account is for. Changing from a valid value not equal to 1 to 1 disconnects the account again.

=== Protocolhandling ===

The demos in {{path|demos/protocolhandling}} can be used to examine various settings on the Telepathy Connection Managers.

==== decibel_listcms_demo ====

This demo lists all Telepathy Connection Managers installed in the system. This demo does not expect any parameters.

==== decibel_supportedprotocols_demo ====

This demo lists all protocols supported by Telepathy Connection Managers installed on the system. This demo does not expect any parameters.

==== decibel_listcmsfor_demo ====

This demo lists all Telepathy Connection Managers installed in the system that support a protocol. This protocol has to be given as the first parameter to the demo.

==== decibel_defaultcmfor_demo ====

This demo expects a protocol name as its only argument. It reports the Telepathy connection manager configured in Decibel to handle all connections made using this protocol.

==== decibel_setdefaultcmfor_demo ====

This demo expects two parameters. The first is a protocol name and the second a name of a Telepathy Connection Manager installed.

Using this demo the Connection Manager used by Decibel to handle a protocol can be changed. By default one of the possible Connection Managers is chosen for each protocol supported.

=== Contacthandling ===

The demos in {{path|demos/contacthandling}} can be used to create connections to contacts. Decibel communicates with the users personal information management (PIM) system to get contact data and identifies contacts by the IDs they got in that system.

'''Note:''' Proper integration into KDE4's Akonadi is still in development.

'''Note:''' If you have not choosen to integrate Decibel with the KDE 4 environment then the SimplisticContactConnector was configured to provide a really simplistic contact management tool. It reads contact data from an INI file in {{path|~/.decibel_contact_data.ini}}. For the contacthandling demos to work you need to set up some contacts in this file. See {{path|docs/examples/decibel_contact_data.ini}} for an example file.

==== decibel_chatstarter_demo ====

This demo expects an account handle (see decibel_listaccounts_demo) and a contact ID from the connected PIM system (or the INI file of the SimplisticContactConnector).

I will cause Decibel to bring up the account associated with the account handle checks whether the contact of the given ID is on line and sends him a little ping-message.

=== simpleclient ===

By default the decibel_simpleclient_demo is started on incoming (jabber) connections by the Decibel daemon. It uses D-Bus activation for this, so a .service file needs to be installed into a D-Bus service directory. During installation Decibel creates such a file (in {{path|demos/simpleclient}} of the build directory) and installs it into {{path|share/dbus-1/services}}. This directory should work out fine if Decibel is installed alongside KDE4.

If the simpleclient is not started on incoming jabber channels, then you might want to copy the .service file into the {{path|~/.local/dbus-1/services}} directory and try again.

As its name advertises this client is pretty simple: It sends a "pong!"
message in response to every "ping?" message it receives.

Development/Tutorials/Decibel/GettingStarted

2008-05-25T10:06:54Z

Cbs: /* Requirements */ fixed typo: no far -> so far

{{TutorialBrowser|

series=Decibel Tutorial|

name=Getting Started with Decibel|

pre=[http://mindview.net/Books/TICPP/ThinkingInCPP2e.html C++], [http://www.trolltech.com/products/qt/ Qt]|
next=[[Development/Tutorials/Decibel/Handling_TextChannels|Handling TextChannels]]|

reading=|
}}
= Getting started with Decibel =

This is a short tutorial describing how to set up the Decibel realtime communication system. It is intended for developers interested in working on or with Decibel.

'''Note:''' ''Decibel is no IM client. You can not use Decibel to chat with your friends without additional software!''

'''Note:''' ''This guide assumes that you have the telepathy Gabble connection manager installed which enables Jabber access. Other connection managers may work as well, but are not as well tested. Telepathy Gabble is part of most recent linux distributions and can be found [http://telepathy.freedesktop.org/releases/telepathy-gabble/ here].''

== Requirements ==

All demos shipped with Decibel require the Decibel daemon to be up and running. After building Decibel this daemon is located in {{path|src/server/decibel}}. The daemon does (so far) not fork and blocks the terminal it is run from: Very useful behaviour when debugging problems.

The Decibel daemon in turn requires a active D-Bus session bus. This is a precondition for all KDE 4 applications, so it is mentioned for completeness sake only.

== Walkthrough ==

This section gives a recommended sequence of command line demos to try.

# Make one or more of your accounts known to the Account Manager in Decibel. (see decibel_registeraccount_demo).

# List all stored accounts and find the account handle. (See decibel_listaccounts_demo).

# Set the desired presence state of an account to "online" using decibel_setpresence_demo.

# Have someone connect to your now online account and have him send a "ping?" message. Decibel will launch a ping-handler which in turn will reply with a "pong!". See decibel_simpleclient_demo).

# Use Decibel to connect to other accounts. See decibel_chatstarter_demo.

'''Note:''' ''Steps 1 to 3 can be done using the account manager KControl module as well. Run <tt>kcmshell4 decibel_accountmanager</tt> if you prefer to use this more convenient method.''

== Demos ==

=== Accounthandling ===

The demos in {{path|demos/accounthandling}} are showing how to manipulate the account storage of the Decibel daemon. They can be used as simple command line tools to manipulate accounts known to Decibel.

Please note that the accountmanager KControl Module that is installed together with Decibel provides the same functionality as these command line demos. See the Walkthrough section for instructions on how to use the KControl module.

==== decibel_registeraccount_demo ====

'''Warning:''' When ''not'' using KDE4, then passwords that are part of the account data are stored in clear text in the configuration files of the Decibel daemon. When KDE4 is found during configuration of Decibel then KWallet is used to store passwords in a secure location.

This demo registers an account with the Decibel daemon. Note that this command does ''not'' create new accounts and can only register already existing accounts with Decibel.

The demo expects several sets of key-value pairs. These are of the following form: <tt>key=type:value</tt> where type is either <tt>i</tt> for integer values or <tt>s</tt> for string values. Other types are not supported by this simplistic demo.

You must register all the keys the connection manager you wish to use for the account requires (see the documentation of the connection manager for a complete list). In addition to those settings Decibel requires a further key-value pair: <tt>decibel_protocol</tt> of type <tt>s</tt> containing the protocol this account is for.

==== decibel_deleteaccount_demo ====

This demo removes a account from Decibel's account storage. This demo expects a account handle (see decibel_listaccounts_demo) and removes the account associated with that handle.

==== decibel_listaccounts_demo ====

The listaccounts demo prints a list of all accounts known to Decibel together with the account handle associated with it. It expects no parameters.

==== decibel_setpresence_demo ====

This demo is used to manipulate the presence state of an account managed by Decibel.

It expects two parameters and accepts an optional third. The first is the handle to the account to change (see decibel_listaccounts_demo). The second is the new presence level. This is an integer value in the range of 1 to 6. 1 is Offline, 2 Available, 3 Away, 4 XA, 5 Hidden and 6 Busy.

The optional third argument is a presence message.

'''Note:''' Changing the presence state from 1 to any other valid value causes Decibel to create a connection to the server the account is for. Changing from a valid value not equal to 1 to 1 disconnects the account again.

=== Protocolhandling ===

The demos in {{path|demos/protocolhandling}} can be used to examine various settings on the Telepathy Connection Managers.

==== decibel_listcms_demo ====

This demo lists all Telepathy Connection Managers installed in the system. This demo does not expect any parameters.

==== decibel_supportedprotocols_demo ====

This demo lists all protocols supported by Telepathy Connection Managers installed on the system. This demo does not expect any parameters.

==== decibel_listcmsfor_demo ====

This demo lists all Telepathy Connection Managers installed in the system that support a protocol. This protocol has to be given as the first parameter to the demo.

==== decibel_defaultcmfor_demo ====

This demo expects a protocol name as its only argument. It reports the Telepathy connection manager configured in Decibel to handle all connections made using this protocol.

==== decibel_setdefaultcmfor_demo ====

This demo expects two parameters. The first is a protocol name and the second a name of a Telepathy Connection Manager installed.

Using this demo the Connection Manager used by Decibel to handle a protocol can be changed. By default one of the possible Connection Managers is chosen for each protocol supported.

=== Contacthandling ===

The demos in {{path|demos/contacthandling}} can be used to create connections to contacts. Decibel communicates with the users personal information management (PIM) system to get contact data and identifies contacts by the IDs they got in that system.

'''Note:''' Proper integration into KDE4's Akonadi is still in development.

'''Note:''' If you have not choosen to integrate Decibel with the KDE 4 environment then the SimplisticContactConnector was configured to provide a really simplistic contact management tool. It reads contact data from an INI file in {{path|~/.decibel_contact_data.ini}}. For the contacthandling demos to work you need to set up some contacts in this file. See {{path|docs/examples/decibel_contact_data.ini}} for an example file.

==== decibel_chatstarter_demo ====

This demo expects an account handle (see decibel_listaccounts_demo) and a contact ID from the connected PIM system (or the INI file of the SimplisticContactConnector).

I will cause Decibel to bring up the account associated with the account handle checks whether the contact of the given ID is on line and sends him a little ping-message.

=== simpleclient ===

By default the decibel_simpleclient_demo is started on incoming (jabber) connections by the Decibel daemon. It uses D-Bus activation for this, so a .service file needs to be installed into a D-Bus service directory. During installation Decibel creates such a file (in {{path|demos/simpleclient}} of the build directory) and installs it into {{path|share/dbus-1/services}}. This directory should work out fine if Decibel is installed alongside KDE4.

If the simpleclient is not started on incoming jabber channels, then you might want to copy the .service file into the {{path|~/.local/dbus-1/services}} directory and try again.

As its name advertises this client is pretty simple: It sends a "pong!"
message in response to every "ping?" message it receives.

Talk:Policies

2008-02-04T16:01:35Z

Cbs: New page: Does it make sense to add a binary compatibility policy? I know that the libs are compatible until KDE 5 but this "Binary compatibility is not required. i18n string changes are allowed" on...

Does it make sense to add a binary compatibility policy? I know that the libs are compatible until KDE 5 but this "Binary compatibility is not required. i18n string changes are allowed" on [[Schedules/KDE4/4.1_Release_Schedule]] was confusing until I found "Workspace interface freeze (source and binary compatibility until KDE 4.1)" on [[Schedules/KDE4/4.0_Release_Schedule]]. Apparently there are 2 binary compatibility guarantees. One for the libs which lasts over the entire 4 series and one for the workspace which lasts from 4.0 to 4.1 (and presumably then 4.1 to 4.2)

--[[User:Cbs|Cbs]]

Development/Tutorials/Kross/Introduction

2008-01-08T02:10:06Z

Cbs: /* Advantage of Kross over other solutions */ Made first sentences bold

==Introduction==
The [http://kross.dipe.org Kross] scripting framework provides full [http://www.python.org/ Python], [http://www.ruby-lang.org/ Ruby] and [http://xmelegance.org/kjsembed KDE JavaScript] scripting support. The goal was
to limit the work needed on applications to have them fully scriptable and to provide a modular way to transparently integrate additional interpreters and in that way extend your application with a new scripting-backend without any new line of code and even without any recompile. To achieve this internally Qt's introspection-functionality like signals, slots, properties, enums, QVariant, QObject, QMetaObject, QMetaType, etc. are used to deal with functionality at runtime.

===What Kross is===
Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and JavaScript transparently into native applications to bridge the static and dynamic worlds together.

Scripting interpreters are plugins that are loaded dynamicly on demand at runtime by the Kross framework. The application that uses Kross to provide scripting functionality to the user does not need to know anything about the interpreter, itself or any other backend-details. All the application needs to know is that there exists scripting code that should be executed. Kross will then take care of it.

===What Kross is not===
Kross does not implement its own scripting language, rather, it provides access to already existing solutions. Kross does not implement a complete Toolkit-binding, rather, it provides access to already existing solutions like PyQt/PyKDE or TkInter for Python or Korundum/QtRuby for Ruby. Kross does not auto-generate code, it is not needed to maintain any configuration files, and it does not come with yet another bindings-API. All it does is to connect things transparently together and to offer optional access to already existing technologies.

===Reuse and choice are the goals===
There exists a wide range of solutions to deal with scripting. Programming languages like Python have enjoyed years of evolution and a large community around them with 3rd-party modules for nearly everything. The same goes for a lot of other languages where there sometimes exists a special function that is only available to a particular language, and where each language comes with its own way of doing things. Each user may have their own preference for what scripting language they like to use, and over time, may have acquired skills in some specific areas.

Rather than limiting users to only one specific language with its own way of doing things, Kross offers a flexible way of supporting multiple programming languages without additional code and maintenance work, at the application level. Kross allows the user to choose what they like and know the most, and it minimizes the entry-barrier to get his things done and to be able to contribute to one's own solutions significantly.

===Supported interpreters===
As of today Python, Ruby and JavaScript are supported. While all of them are passing the unittests, current state is, that Python is the most complete one followed by Ruby which is near the same state and finally JavaScript which needs some more tweaks to be as rock-stable as the other both implementations.

Work on progress are krossjava (thanks to google for supporting this plugin within the Google Summer of Code 2007) that implements support for the Java Virtual Machine and krossfalcon that implements support for The Falcon Programming Language.

For sure any interpreter-plugin you may like to implement is very welcome. At the end the open source world is about choices :)

===Advantage of Kross over other solutions===
* '''Scripting interpreter independent.''' Kross does not implement an interpreter, it provides access to already existing interpreters. You don't limit your users to a particular scripting language, each user is free to decide which scripting language is best suited.
* '''Real embedding.''' Rather then communicating with scripting backends e.g. over stdin/stdout or D-Bus Kross does come with plugins that really embed the interpreters and deal with them on the native C/C++ code level to gain optimal performance and flexibility.
* '''Kross is fast.''' Kross had a bit of luck to be adopted by Krita so early since one of the top-priorities Krita had on a scripting backend was performance. During the years we managed to increase the speed to a level where it's hard to see a difference to native in C/C++ written code.
* '''Kross is platform-independent.''' From the beginning Kross was designed with platform-independence in mind. This is the result of the origins of Kross - it started as Kexi plugin, and Kexi itself runs at least on Linux, Windows and Mac since it's early days.
* '''Kross is stable and well proven.''' Before Kross finally landed in kdelibs it was in use in KOffice for 3 major releases and was thus "tested" by a wide range of users worldwide.
* '''A lot of documentation, scripts and applications are using Kross already today.''' The latter guarantees that Kross offers the solution for many scenarios.
* '''Kross can be easily extended with a new scripting interpreter.''' There are no changes needed to the applications. So, whatever hype we are able to see in the next few years, we are ready to fullfit the possible user-requests for them without much pain.
* '''Kross benefits from applications.''' The synergy-effect if multiple applications are sharing the same interpreter plugin implementations ensures that bugs are discovered and fixed as soon as possible. Also each app is able to profit if someone writes for example a plugin for the LUA-interpreter each app is able to use the new backend without any recompile.
* '''Kross reuses existing technologies as much as possible.''' There is no need for code-generation at compile time and no new "bindings API" is introduced since we are reusing the Qt Meta-Object System. You are able to throw in a QObject and a script is able to connect with the signals, call slots as there are functions, access enumerations, get/set properties or pass QObject/QWidget instances around as there are classes.
* '''The interpreter backend is very flexible.''' Each interpreter's plugin is able to decide on its own how to implement the bridging functionality. If you like for example to have it more "pythonic" by using the decorators introduced in Python 2.4, you are free to implement it and each app that uses Kross will profit by beeing able to use such decorators from now on.
* '''Kross will stay backward-compatible.''' Kross is part of kdelibs and thus follows strict policies to provide backward-compatibility at least during the lifetime of KDE4.

==The Interpreter plugins==

Kross offers a plugin-interface to integrate interpreter backends like Python, Ruby and KDE-Javascript. They are loaded on demand at runtime. Neither the application nor Kross needs to know any details about the backends. This clear separation between the application and scripting details enables at the one hand, to deal with scripting at an abstract level without being bound to only one backend, and at the other hand makes it easy to integrate scripting into an already existing application.

Each interpreter plugin needs to implement two abstract classes;
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] class is a singleton controlled by the [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/manager.h?view=markup Kross::Manager] and could be used to setup the interpreter or do other things to share functionality between instances of the Script class.
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] class handles exactly one script instance. An application is able to deal with multiple scripts at the same time where each of them has it's own instance of the Kross::Script class controlled by an instance of the more abstract [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/action.h?view=markup Kross::Action] class.

===Python===

The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/ Python plugin] implements access to the [http://www.python.org/ Python] scripting language.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.py?view=markup unittest.py] Python script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
<pre>
cd kdelibs/kross/test
./krosstest unittest.py
</pre>

Other scripts are...
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testkross.py?view=markup testkross.py] Python script file demonstrates how to use Kross to execute some JavaScript code within a python script.
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguitk.py?view=markup testguitk.py] Python script file that creates and displays a modal dialog using the TkInter GUI-toolkit.
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguiqt.py?view=markup testguiqt.py] Python script file shows how to use PyQt while the [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguiform.py?view=markup testguiform.py] uses the Kross Form module.

The krosspython plugin consists of...
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythoninterpreter.h?view=markup Kross::PythonInterpreter] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] for the Python interpreter backend and implements the createScript factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] instances.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] for the Python backend to provide the functionality to execute Python code within a script-container.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h?view=markup Kross::PythonModule] class is the __main__ Python environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h?view=markup Kross::PythonModule] also spends access to the the whole Kross functionality and manages all the @a Kross::PythonExtension modules.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h?view=markup Kross::PythonExtension] class implements a Py::Object to wrap a QObject instance into the world of Python.
* Within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonvariant.h?view=markup Kross::PythonVariant] the Kross::PythonType helper class is used to cast between QVariant and Py::Object values while the Kross::PythonMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h?view=markup Kross::PythonExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.

===Ruby===

The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/ Ruby plugin] implements access to the [http://www.ruby-lang.org/ Ruby] scripting language.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.rb?view=markup unittest.rb] Ruby script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
<pre>
cd kdelibs/kross/test
./krosstest unittest.rb
</pre>

The krossruby plugin consists of...
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyinterpreter.h?view=markup Kross::RubyInterpreter] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] for the Ruby interpreter backend and provides with the createScript a factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] instances.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] for the Ruby backend to provide the functionality to execute Ruby code within a script-container.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h?view=markup Kross::RubyModule] class is the __main__ Ruby environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h?view=markup Kross::RubyModule] also spends access to the the whole Kross functionality and manages all the @a Kross::RubyExtension modules.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h?view=markup Kross::RubyExtension] class implements a Ruby VALUE object to wrap a QObject instance into the world of Ruby.
* Within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyvariant.h?view=markup Kross::RubyVariant] the Kross::RubyType helper class is used to cast between QVariant and Ruby VALUE values while the Kross::RubyMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h?view=markup Kross::RubyExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.

===JavaScript===

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/kjs KDE JavaScript plugin] uses the in kdelibs4 included Kjs and KjsEmbed4 frameworks to provide access to the JavaScript language.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.js?view=markup unittest.js] KDE-JavaScript script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
<pre>
cd kdelibs/kross/test
./krosstest unittest.js
</pre>

For details about KDE-JavaScript see...
* [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/README?view=markup Kjs readme]
* [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/ Kjs svn]
* [http://xmelegance.org/kjsembed KjsEmbed home]
* [https://mail.kde.org/mailman/listinfo/kjsembed KjsEmbed mailinglist]
* [http://websvn.kde.org/trunk/KDE/kdelibs/kjsembed/ KjsEmbed svn]

===Java===

The [[Projects/Summer_of_Code/2007/Projects/KrossJava|Google Summer of Code 2007]] did provide us the [http://websvn.kde.org/trunk/playground/bindings/krossjava/ krossjava] backend for Java :-)

===Falcon===

The [http://websvn.kde.org/trunk/playground/bindings/krossfalcon/ krossfalcon] plugin does implement access to [http://www.falconpl.org The Falcon Programming Language].

==The Module plugins==

Modules are plugins loaded on demand at runtime to provide additional functionality. They only provide a factory to create and return a QObject instance that is then exposed to the scripting backend.

Since Qt's introspection functionality is used, we are able to throw in just {{qt|QObject}}'s and have them act as classes/objects within a scripting backend. Slots are membermethods while properties and enumerations are membervariables. If your application also likes to offer [http://hal.freedesktop.org/wiki/Software/dbus D-Bus] support it may be an idea to reuse the {{qt|QDBusAbstractAdaptor}} implementations your application has also for scripting, like for example [[Development/Tutorials/KSpread_Scripting|KSpread]] did.

Let's take a look at the following code that implements the MyObject class which inherits from QObject;
<code cppqt>
class MyObject : public QObject {
Q_OBJECT
Q_PROPERTY(QString name READ name WRITE setName)
public:
MyObject(QObject* parent = 0) : QObject(parent) {}
virtual ~MyObject() {}
QString name() const { return objectName(); }
void setName(const QString& name) {
return setObjectName(name);
}
public slots:
QObject* create(const QString& name,
QObject* parent=0) {
MyObject* obj = new MyObject(parent);
obj->setObjectName(name);
return obj;
}
QObject* parent() const { return QObject::parent(); }
void setParent(QObject* parent) {
QObject::setParent(parent);
emit parentChanged();
}
signals:
void parentChanged();
};

extern "C" {
KDE_EXPORT QObject* krossmodule() {
return new MyObject();
}
}
</code>
At the bottom the krossmodule() function will be called by Kross and returns an instance of MyObject that is then exposed to the scripting backend.

Then we just need to have our myobject.h and myobject.cpp files, filled with the content above, defined in the CMakeLists.txt file. The library needs to be named "krossmodule..." where the "..." is then the name the module is accessible as. For our example we use "krossmodulemyobjectmod" and therefore we are able to access the module if installed as "myobjectmod". The example does not depend on Kross, so you may like to replace ${KROSS_INCLUDES} with whatever else your module depends on.
<pre>
include_directories(${CMAKE_SOURCE_DIR}
${KROSS_INCLUDES})
set(krossmodulemyobjectmod_PART_SRCS
myobject.cpp)
kde4_add_plugin(krossmodulemyobjectmod
${krossmodulemyobjectmod_PART_SRCS})
target_link_libraries(krossmodulemyobjectmod
${KDE4_KDECORE_LIBS} ${KDE4_KROSSCORE_LIBS})
install(TARGETS krossmodulemyobjectmod
DESTINATION ${PLUGIN_INSTALL_DIR})
</pre>

The following Python sample code accesses then the module at runtime and uses the QObject, calls it's slots and properties and connects a signal with a python function (e.g. save as file named "myobjecttest.py" and execute with "kross ./myobjecttest.py");

<code python>
#!/usr/bin/env kross
import Kross
m = Kross.module("myobjectmod")
m.name = "MyObjectModuleName"
obj1 = m.create("OtherObjectName")
def myCallbackFunc(args):
print "The parent of obj1 changed"
obj1.connect("parentChanged()",myCallbackFunc)
obj1.setParent(m)
print "%s %s" % (obj1.name,obj1.parent().name)
</code>

==Manager, GuiClient, Action==

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/manager.h?view=markup Kross::Manager] class is a singleton that provides access to the interpreters, to actions and to the modules. The Kross::Manager is available within scripting code as module named "Kross". Following Python script uses the Kross module to create a new Kross::Action instance, fills it with JavaScript code and executes that JavaScript code.

<code python>
#!/usr/bin/env kross
import Kross
a = Kross.action("MyKjsScript")
a.setInterpreter("javascript")
a.setCode("println(\"Hello world from Kjs\");")
a.trigger()
</code>

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/guiclient.h?view=markup Kross::GuiClient] class implements KXMLGUIClient to provide GUI functionality, handling of XML configuration files on a more abstract level and offers some predefined actions that could be optionally used in your application.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/action.h?view=markup Kross::Action] class offers an abstract container to deal with scripts like a single standalone scriptfile. Each action holds a reference to the by the matching [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] instance created by [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] instance. Following Python script accesses the Kross module and the self variable which is our Kross::Action instance that provides the context for the running Python script.

<code python>
#!/usr/bin/env kross
import Kross
print "objectName=%s" % Kross.objectName()
print "interpreters=%s" % Kross.interpreters()
print "objectName=%s" % self.objectName()
print "text=%s" % self.text
print "enabled=%s" % self.enabled
print "currentPath=%s" % self.currentPath()
print "interpreter=%s" % self.interpreter()
print "description=%s" % self.description()
print "code=%s" % self.code()
</code>

==D-Bus and Kross==

With the [http://doc.trolltech.com/4.2/qtdbus.html QtDBus module] Qt provides a library that a Qt/KDE application is able to use to make Inter-Process Communication using the [http://dbus.freedesktop.org D-BUS protocol].

The QtDBus module uses the Qt Signals and Slots mechanism. Applications that like to provide parts of their functionality to the D-Bus world are able to do so by implementing classes that inherit from the {{qt|QDBusAbstractAdaptor}} class.

Kross is able to reuse such by an application provided bindings. So, once your application supports D-Bus, Kross is able to reuse those already existing code and offers transparent access to the scripting-backends to them. How does this differ from e.g. the python-dbus package? Well, first method-calls don't go through the dbus-socket and then it's not dbus-related at all except, that we are able to reuse what your application offers anyway: a clean interface to the outside world. But that's not all, we are not limited to what's possible with D-Bus. We are also able to exchange instance-pointers to QObject or QWidget instances.

For an example you may like to take a look at how it was done in the KSpread [http://websvn.kde.org/trunk/koffice/kspread/plugins/scripting/ScriptingModule.cpp?view=markup ScriptingModule] class.

Development/Tutorials/Kross/Introduction

2008-01-08T01:56:24Z

Cbs: /* Advantage of Kross over other solutions */ tried to remove user==male assumption from text and made some minor editorial changes

==Introduction==
The [http://kross.dipe.org Kross] scripting framework provides full [http://www.python.org/ Python], [http://www.ruby-lang.org/ Ruby] and [http://xmelegance.org/kjsembed KDE JavaScript] scripting support. The goal was
to limit the work needed on applications to have them fully scriptable and to provide a modular way to transparently integrate additional interpreters and in that way extend your application with a new scripting-backend without any new line of code and even without any recompile. To achieve this internally Qt's introspection-functionality like signals, slots, properties, enums, QVariant, QObject, QMetaObject, QMetaType, etc. are used to deal with functionality at runtime.

===What Kross is===
Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and JavaScript transparently into native applications to bridge the static and dynamic worlds together.

Scripting interpreters are plugins that are loaded dynamicly on demand at runtime by the Kross framework. The application that uses Kross to provide scripting functionality to the user does not need to know anything about the interpreter, itself or any other backend-details. All the application needs to know is that there exists scripting code that should be executed. Kross will then take care of it.

===What Kross is not===
Kross does not implement its own scripting language, rather, it provides access to already existing solutions. Kross does not implement a complete Toolkit-binding, rather, it provides access to already existing solutions like PyQt/PyKDE or TkInter for Python or Korundum/QtRuby for Ruby. Kross does not auto-generate code, it is not needed to maintain any configuration files, and it does not come with yet another bindings-API. All it does is to connect things transparently together and to offer optional access to already existing technologies.

===Reuse and choice are the goals===
There exists a wide range of solutions to deal with scripting. Programming languages like Python have enjoyed years of evolution and a large community around them with 3rd-party modules for nearly everything. The same goes for a lot of other languages where there sometimes exists a special function that is only available to a particular language, and where each language comes with its own way of doing things. Each user may have their own preference for what scripting language they like to use, and over time, may have acquired skills in some specific areas.

Rather than limiting users to only one specific language with its own way of doing things, Kross offers a flexible way of supporting multiple programming languages without additional code and maintenance work, at the application level. Kross allows the user to choose what they like and know the most, and it minimizes the entry-barrier to get his things done and to be able to contribute to one's own solutions significantly.

===Supported interpreters===
As of today Python, Ruby and JavaScript are supported. While all of them are passing the unittests, current state is, that Python is the most complete one followed by Ruby which is near the same state and finally JavaScript which needs some more tweaks to be as rock-stable as the other both implementations.

Work on progress are krossjava (thanks to google for supporting this plugin within the Google Summer of Code 2007) that implements support for the Java Virtual Machine and krossfalcon that implements support for The Falcon Programming Language.

For sure any interpreter-plugin you may like to implement is very welcome. At the end the open source world is about choices :)

===Advantage of Kross over other solutions===
* Scripting interpreter independent. Kross does not implement an interpreter, it provides access to already existing interpreters. You don't limit your users to a particular scripting language, each user is free to decide which scripting language is best suited.
* Real embedding. Rather then communicating with scripting backends e.g. over stdin/stdout or D-Bus Kross does come with plugins that really embed the interpreters and deal with them on the native C/C++ code level to gain optimal performance and flexibility.
* Kross is fast. Kross had a bit of luck to be adopted by Krita so early since one of the top-priorities Krita had on a scripting backend was performance. During the years we managed to increase the speed to a level where it's hard to see a difference to native in C/C++ written code.
* Kross was designed from the beginning with platform-independence in mind. This is the result of the origins of Kross - it started as Kexi plugin, and Kexi itself runs at least on Linux, Windows and Mac since it's early days.
* Kross is stable and well proven. Before Kross finally landed in kdelibs it was in use in KOffice for 3 major releases and was thus "tested" by a wide range of users worldwide.
* A lot of documentation, scripts and applications are using Kross already today. The latter guarantees that Kross offers the solution for many scenarios.
* Kross could be easily extended with a new scripting interpreter. There are no changes needed to the applications. So, whatever hype we are able to see in the next few years, we are ready to fullfit the possible user-requests for them without much pain.
* The synergy-effect if multiple applications are sharing the same interpreter plugin implementations ensures that bugs are discovered and fixed as soon as possible. Also each app is able to profit if someone writes for example a plugin for the LUA-interpreter each app is able to use the new backend without any recompile.
* Kross does reuse existing technologies as much as possible. There is no need for code-generation at compile time and no new "bindings API" is introduced since we are reusing the Qt Meta-Object System. You are able to throw in a QObject and a script is able to connect with the signals, call slots as there are functions, access enumerations, get/set properties or pass QObject/QWidget instances around as there are classes.
* The interpreter backend is very flexible since each interpreter's plugin is able to decide on its own how to implement the bridging functionality. If you like for example to have it more "pythonic" by using the decorators introduced in Python 2.4, you are free to implement it and each app that uses Kross will profit by beeing able to use such decorators from now on.
* Kross will stay backward-compatible because as part of kdelibs it needs to follow strict policies and needs to provide backward-compatibility at least during the lifetime of KDE4.

==The Interpreter plugins==

Kross offers a plugin-interface to integrate interpreter backends like Python, Ruby and KDE-Javascript. They are loaded on demand at runtime. Neither the application nor Kross needs to know any details about the backends. This clear separation between the application and scripting details enables at the one hand, to deal with scripting at an abstract level without being bound to only one backend, and at the other hand makes it easy to integrate scripting into an already existing application.

Each interpreter plugin needs to implement two abstract classes;
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] class is a singleton controlled by the [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/manager.h?view=markup Kross::Manager] and could be used to setup the interpreter or do other things to share functionality between instances of the Script class.
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] class handles exactly one script instance. An application is able to deal with multiple scripts at the same time where each of them has it's own instance of the Kross::Script class controlled by an instance of the more abstract [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/action.h?view=markup Kross::Action] class.

===Python===

The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/ Python plugin] implements access to the [http://www.python.org/ Python] scripting language.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.py?view=markup unittest.py] Python script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
<pre>
cd kdelibs/kross/test
./krosstest unittest.py
</pre>

Other scripts are...
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testkross.py?view=markup testkross.py] Python script file demonstrates how to use Kross to execute some JavaScript code within a python script.
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguitk.py?view=markup testguitk.py] Python script file that creates and displays a modal dialog using the TkInter GUI-toolkit.
* The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguiqt.py?view=markup testguiqt.py] Python script file shows how to use PyQt while the [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguiform.py?view=markup testguiform.py] uses the Kross Form module.

The krosspython plugin consists of...
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythoninterpreter.h?view=markup Kross::PythonInterpreter] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] for the Python interpreter backend and implements the createScript factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] instances.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] for the Python backend to provide the functionality to execute Python code within a script-container.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h?view=markup Kross::PythonModule] class is the __main__ Python environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h?view=markup Kross::PythonModule] also spends access to the the whole Kross functionality and manages all the @a Kross::PythonExtension modules.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h?view=markup Kross::PythonExtension] class implements a Py::Object to wrap a QObject instance into the world of Python.
* Within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonvariant.h?view=markup Kross::PythonVariant] the Kross::PythonType helper class is used to cast between QVariant and Py::Object values while the Kross::PythonMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h?view=markup Kross::PythonExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.

===Ruby===

The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/ Ruby plugin] implements access to the [http://www.ruby-lang.org/ Ruby] scripting language.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.rb?view=markup unittest.rb] Ruby script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
<pre>
cd kdelibs/kross/test
./krosstest unittest.rb
</pre>

The krossruby plugin consists of...
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyinterpreter.h?view=markup Kross::RubyInterpreter] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] for the Ruby interpreter backend and provides with the createScript a factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] instances.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] for the Ruby backend to provide the functionality to execute Ruby code within a script-container.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h?view=markup Kross::RubyModule] class is the __main__ Ruby environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h?view=markup Kross::RubyModule] also spends access to the the whole Kross functionality and manages all the @a Kross::RubyExtension modules.
* The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h?view=markup Kross::RubyExtension] class implements a Ruby VALUE object to wrap a QObject instance into the world of Ruby.
* Within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyvariant.h?view=markup Kross::RubyVariant] the Kross::RubyType helper class is used to cast between QVariant and Ruby VALUE values while the Kross::RubyMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h?view=markup Kross::RubyExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.

===JavaScript===

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/kjs KDE JavaScript plugin] uses the in kdelibs4 included Kjs and KjsEmbed4 frameworks to provide access to the JavaScript language.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.js?view=markup unittest.js] KDE-JavaScript script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
<pre>
cd kdelibs/kross/test
./krosstest unittest.js
</pre>

For details about KDE-JavaScript see...
* [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/README?view=markup Kjs readme]
* [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/ Kjs svn]
* [http://xmelegance.org/kjsembed KjsEmbed home]
* [https://mail.kde.org/mailman/listinfo/kjsembed KjsEmbed mailinglist]
* [http://websvn.kde.org/trunk/KDE/kdelibs/kjsembed/ KjsEmbed svn]

===Java===

The [[Projects/Summer_of_Code/2007/Projects/KrossJava|Google Summer of Code 2007]] did provide us the [http://websvn.kde.org/trunk/playground/bindings/krossjava/ krossjava] backend for Java :-)

===Falcon===

The [http://websvn.kde.org/trunk/playground/bindings/krossfalcon/ krossfalcon] plugin does implement access to [http://www.falconpl.org The Falcon Programming Language].

==The Module plugins==

Modules are plugins loaded on demand at runtime to provide additional functionality. They only provide a factory to create and return a QObject instance that is then exposed to the scripting backend.

Since Qt's introspection functionality is used, we are able to throw in just {{qt|QObject}}'s and have them act as classes/objects within a scripting backend. Slots are membermethods while properties and enumerations are membervariables. If your application also likes to offer [http://hal.freedesktop.org/wiki/Software/dbus D-Bus] support it may be an idea to reuse the {{qt|QDBusAbstractAdaptor}} implementations your application has also for scripting, like for example [[Development/Tutorials/KSpread_Scripting|KSpread]] did.

Let's take a look at the following code that implements the MyObject class which inherits from QObject;
<code cppqt>
class MyObject : public QObject {
Q_OBJECT
Q_PROPERTY(QString name READ name WRITE setName)
public:
MyObject(QObject* parent = 0) : QObject(parent) {}
virtual ~MyObject() {}
QString name() const { return objectName(); }
void setName(const QString& name) {
return setObjectName(name);
}
public slots:
QObject* create(const QString& name,
QObject* parent=0) {
MyObject* obj = new MyObject(parent);
obj->setObjectName(name);
return obj;
}
QObject* parent() const { return QObject::parent(); }
void setParent(QObject* parent) {
QObject::setParent(parent);
emit parentChanged();
}
signals:
void parentChanged();
};

extern "C" {
KDE_EXPORT QObject* krossmodule() {
return new MyObject();
}
}
</code>
At the bottom the krossmodule() function will be called by Kross and returns an instance of MyObject that is then exposed to the scripting backend.

Then we just need to have our myobject.h and myobject.cpp files, filled with the content above, defined in the CMakeLists.txt file. The library needs to be named "krossmodule..." where the "..." is then the name the module is accessible as. For our example we use "krossmodulemyobjectmod" and therefore we are able to access the module if installed as "myobjectmod". The example does not depend on Kross, so you may like to replace ${KROSS_INCLUDES} with whatever else your module depends on.
<pre>
include_directories(${CMAKE_SOURCE_DIR}
${KROSS_INCLUDES})
set(krossmodulemyobjectmod_PART_SRCS
myobject.cpp)
kde4_add_plugin(krossmodulemyobjectmod
${krossmodulemyobjectmod_PART_SRCS})
target_link_libraries(krossmodulemyobjectmod
${KDE4_KDECORE_LIBS} ${KDE4_KROSSCORE_LIBS})
install(TARGETS krossmodulemyobjectmod
DESTINATION ${PLUGIN_INSTALL_DIR})
</pre>

The following Python sample code accesses then the module at runtime and uses the QObject, calls it's slots and properties and connects a signal with a python function (e.g. save as file named "myobjecttest.py" and execute with "kross ./myobjecttest.py");

<code python>
#!/usr/bin/env kross
import Kross
m = Kross.module("myobjectmod")
m.name = "MyObjectModuleName"
obj1 = m.create("OtherObjectName")
def myCallbackFunc(args):
print "The parent of obj1 changed"
obj1.connect("parentChanged()",myCallbackFunc)
obj1.setParent(m)
print "%s %s" % (obj1.name,obj1.parent().name)
</code>

==Manager, GuiClient, Action==

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/manager.h?view=markup Kross::Manager] class is a singleton that provides access to the interpreters, to actions and to the modules. The Kross::Manager is available within scripting code as module named "Kross". Following Python script uses the Kross module to create a new Kross::Action instance, fills it with JavaScript code and executes that JavaScript code.

<code python>
#!/usr/bin/env kross
import Kross
a = Kross.action("MyKjsScript")
a.setInterpreter("javascript")
a.setCode("println(\"Hello world from Kjs\");")
a.trigger()
</code>

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/guiclient.h?view=markup Kross::GuiClient] class implements KXMLGUIClient to provide GUI functionality, handling of XML configuration files on a more abstract level and offers some predefined actions that could be optionally used in your application.

The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/action.h?view=markup Kross::Action] class offers an abstract container to deal with scripts like a single standalone scriptfile. Each action holds a reference to the by the matching [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] instance created by [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] instance. Following Python script accesses the Kross module and the self variable which is our Kross::Action instance that provides the context for the running Python script.

<code python>
#!/usr/bin/env kross
import Kross
print "objectName=%s" % Kross.objectName()
print "interpreters=%s" % Kross.interpreters()
print "objectName=%s" % self.objectName()
print "text=%s" % self.text
print "enabled=%s" % self.enabled
print "currentPath=%s" % self.currentPath()
print "interpreter=%s" % self.interpreter()
print "description=%s" % self.description()
print "code=%s" % self.code()
</code>

==D-Bus and Kross==

With the [http://doc.trolltech.com/4.2/qtdbus.html QtDBus module] Qt provides a library that a Qt/KDE application is able to use to make Inter-Process Communication using the [http://dbus.freedesktop.org D-BUS protocol].

The QtDBus module uses the Qt Signals and Slots mechanism. Applications that like to provide parts of their functionality to the D-Bus world are able to do so by implementing classes that inherit from the {{qt|QDBusAbstractAdaptor}} class.

Kross is able to reuse such by an application provided bindings. So, once your application supports D-Bus, Kross is able to reuse those already existing code and offers transparent access to the scripting-backends to them. How does this differ from e.g. the python-dbus package? Well, first method-calls don't go through the dbus-socket and then it's not dbus-related at all except, that we are able to reuse what your application offers anyway: a clean interface to the outside world. But that's not all, we are not limited to what's possible with D-Bus. We are also able to exchange instance-pointers to QObject or QWidget instances.

For an example you may like to take a look at how it was done in the KSpread [http://websvn.kde.org/trunk/koffice/kspread/plugins/scripting/ScriptingModule.cpp?view=markup ScriptingModule] class.

Talk:Projects/Documentation/KDE4

2007-09-02T23:49:40Z

Cbs: New page: I wanted do add a link to the style guide. Is this the most recent version? http://l10n.kde.org/docs/styleguide/index.html ---~~~

I wanted do add a link to the style guide. Is this the most recent version?
http://l10n.kde.org/docs/styleguide/index.html

---[[User:Cbs|Cbs]]

Policies/Application Lifecycle

2007-09-01T18:50:25Z

Cbs: small style changes in the explanation of the review process

When you want to start a new application (or remove an old application), you want to know where you should place it in the Subversion repository. This document describes where to go in which stage of your application.

See [[#Stage 3: The end]] for instructions on how to deal with old, unmaintained applications.

In a diagram it all comes down to:

[[Image:svnguidelines.png]]

=== Stage 1: The start ===
The start of a new application can take place on a local disk, in a local repository or any other way. Another option is provided by KDE in the special {{path|/trunk/playground}} folder in the repository where everyone is free to commit ones own application. You can request a SVN account at sysadmin and after that you can import your project in the subfolder of your choice.

It is not meant as a backup area, so you should not develop your application somewhere else and only sync the changes now and then to KDE's repository.

As soon as you start releasing your software and match the criteria for the next stage, you should consider moving your application folder to the next stage.

Because playground is something like an 'experimental' area, there is only a small amount of applications that make it to the next stage. To keep the playground area accessible and a bit organized, we have created a {{path|/tag/unmaintained/N}} (where 'N' is the KDE major version the application was written for; e.g. 4 for KDE4 applications). If you do not want to continue your application, move it to that place in the repository. If you do not know how, contact the current contactperson which is mentioned at the bottom of this document.

Whenever an application has not received a commit for one complete year, you will be contacted via email to discuss if you want to continue the application or if it has died. In the latter case or when the email bounces, it will be moved to {{path|/tag/unmaintained/N/}}.

This also applies to the currently no longer used /trunk/kdenonbeta area.

=== Stage 2: Stable ===
When you have made one of more releases and want to continue to develop it, the term 'playground' does no longer apply to you. That is the right time to move out of here. There are two options to move to: extragear and one of the KDE main modules. If you want to move to one of the KDE main modules, you will get released with KDE. That also means you have to respect that release schedule. The fact you want your program in KDE main modules is not enough and others have to agree is valuable to have it.
In extragear you are on your own. You make the releases whenever you want and you have to talk to the translators about your release schedule. In the future it might be possible to be released together with the KDE main modules. But at this moment this is not possible.

Whatever you choose, there are some rules to follow before you are allowed to move to either location:
* There should be user documentation in docbook format
* There should be developers documentation in the form of apidox for libraries you can check this at [http://www.englishbreakfastnetwork.org/ ebn]
* There should be no krazy code checker issues reported. Again, you can check that at [http://www.englishbreakfastnetwork.org/ ebn]. There is also a [[Development/Tutorials/Code_Checking|tutorial on using Krazy]] available here on TechBase.
* If possible, there should have been a basic usability review of your application. Usability people are hard to get, so this is not crucial.
* You should have checked for basic problems with a profiler. I hope we will get a tutorial on how to do this soon
* Your application should be [[Development/Tutorials/Localization/i18n|completely translatable]].

When you decide you want to move to this second stage, move your application to {{path|/trunk/kdereview}} and announce the move on '''kde-core-devel@kde.org'''. In the announcement address the above issues and state where you want your application to move to (which KDE main module or extragear). Extragear only requires general approval on kde-core-devel. A main module requires approval from the community who manages that module (e.g. the kdepim module requires approval from the kdepim community).

The move to kdereview starts a two week review period during which the community can object to your proposal or request additional changes. If there are no objections or requested changes after this two week period, you are allowed to move your application to the place you requested. If your intention is to move to a main module you must additionally get approval from the module maintainer(s) who manage that module.

If changes are requested, you can leave your application in kdereview while you are actively working on those issues. If you lack the time to work on the changes, move your application back to playground. Once the requested changes are completed, announce to kde-core-devel that you have completed the requested changes and wait for another week for objections.

Kdereview is only meant as a transitional place from playground to the main modules or extrager. In no case can kdereview be a permanent place to develop your application.

=== Stage 3: The end ===
Whenever you decide to stop developing the application and that leaves the application without developers, please announce that to kde-core-devel. If nobody stands up to take over maintainership within two weeks, the application has to be moved to the {{path|/trunk/unmaintained/N/}} area as every application in the KDE main modules and in extragear needs to have a maintainer to stay there.

=== Translations ===
For each move in subversion, the translation files of each language need to move as well. Because this requires a complete checkout of the l10n folder and some knowledge about the structure, you can ask the release-team ('''release-team@kde.org''') to move them. Send a simple mail with the information required to do the move, for example: 'move {{path|/playground/somewhere/someapp}} to {{path|/kdereview/someapp}}'.
If you want to help out with these kinds of moves, please send a mail! You are welcome to help out.

=== Contact ===
If you need any help regarding this, please contact Tom Albers ('''tomalbers@kde.nl''')

[[Category:Policies]]

Talk:Policies/Application Lifecycle

2007-09-01T18:08:58Z

Cbs: New page: Does this "There should be developers documentation in the form of apidox for libraries you can check this at ebn" mean that it can only be checked for libraries, i.e. "There should be dev...

Does this "There should be developers documentation in the form of apidox for libraries you can check this at ebn" mean that it can only be checked for libraries, i.e. "There should be developers documentation in the form of apidox . For libraries you can check this at ebn" or that it only applies to libraries, i.e. "For libraries there should be developers documentation in the form of apidox. You can check this at ebn"

---[[User:Cbs|Cbs]]

Policies/Application Lifecycle

2007-09-01T18:04:52Z

Cbs: /* Stage 2: Stable */

When you want to start a new application (or remove an old application), you want to know where you should place it in the Subversion repository. This document describes where to go in which stage of your application.

See [[#Stage 3: The end]] for instructions on how to deal with old, unmaintained applications.

In a diagram it all comes down to:

[[Image:svnguidelines.png]]

=== Stage 1: The start ===
The start of a new application can take place on a local disk, in a local repository or any other way. Another option is provided by KDE in the special {{path|/trunk/playground}} folder in the repository where everyone is free to commit ones own application. You can request a SVN account at sysadmin and after that you can import your project in the subfolder of your choice.

It is not meant as a backup area, so you should not develop your application somewhere else and only sync the changes now and then to KDE's repository.

As soon as you start releasing your software and match the criteria for the next stage, you should consider moving your application folder to the next stage.

Because playground is something like an 'experimental' area, there is only a small amount of applications that make it to the next stage. To keep the playground area accessible and a bit organized, we have created a {{path|/tag/unmaintained/N}} (where 'N' is the KDE major version the application was written for; e.g. 4 for KDE4 applications). If you do not want to continue your application, move it to that place in the repository. If you do not know how, contact the current contactperson which is mentioned at the bottom of this document.

Whenever an application has not received a commit for one complete year, you will be contacted via email to discuss if you want to continue the application or if it has died. In the latter case or when the email bounces, it will be moved to {{path|/tag/unmaintained/N/}}.

This also applies to the currently no longer used /trunk/kdenonbeta area.

=== Stage 2: Stable ===
When you have made one of more releases and want to continue to develop it, the term 'playground' does no longer apply to you. That is the right time to move out of here. There are two options to move to: extragear and one of the KDE main modules. If you want to move to one of the KDE main modules, you will get released with KDE. That also means you have to respect that release schedule. The fact you want your program in KDE main modules is not enough and others have to agree is valuable to have it.
In extragear you are on your own. You make the releases whenever you want and you have to talk to the translators about your release schedule. In the future it might be possible to be released together with the KDE main modules. But at this moment this is not possible.

Whatever you choose, there are some rules to follow before you are allowed to move to either location:
* There should be user documentation in docbook format
* There should be developers documentation in the form of apidox for libraries you can check this at [http://www.englishbreakfastnetwork.org/ ebn]
* There should be no krazy code checker issues reported. Again, you can check that at [http://www.englishbreakfastnetwork.org/ ebn]. There is also a [[Development/Tutorials/Code_Checking|tutorial on using Krazy]] available here on TechBase.
* If possible, there should have been a basic usability review of your application. Usability people are hard to get, so this is not crucial.
* You should have checked for basic problems with a profiler. I hope we will get a tutorial on how to do this soon
* Your application should be [[Development/Tutorials/Localization/i18n|completely translatable]].

When you decide you want to move to this second stage, you move your application to {{path|/trunk/kdereview}}. Then you sent an announcement to '''kde-core-devel@kde.org''' that you have done that, address above issues and make clear where you want to move to (which kde main module or extragear). Extragear only requires general approval on kde-core-devel, while going into, for instance, kdepim requires approval from the kdepim community who manage that module.

Then the two weeks review period starts. In those two weeks people can object to your proposal or request additional changes. When there are no objections after the two week period, you are allowed to move your application to the place you decided to go. If your intention is to move to a main module you must get approval from the module maintainer(s) who manage that module.

If there are changes requested, you can make them while in kdereview. But only as long as you are working on those issues. If you decide to let it rest for a month for example, you should move it back to playground. When the requested changes are completed, announce it again to kde-core-devel and wait for one week for objections.

In no case kdereview can be a permanent place to develop your application.

=== Stage 3: The end ===
Whenever you decide to stop developing the application and that leaves the application without developers, please announce that to kde-core-devel. If nobody stands up to take over maintainership within two weeks, the application has to be moved to the {{path|/trunk/unmaintained/N/}} area as every application in the KDE main modules and in extragear needs to have a maintainer to stay there.

=== Translations ===
For each move in subversion, the translation files of each language need to move as well. Because this requires a complete checkout of the l10n folder and some knowledge about the structure, you can ask the release-team ('''release-team@kde.org''') to move them. Send a simple mail with the information required to do the move, for example: 'move {{path|/playground/somewhere/someapp}} to {{path|/kdereview/someapp}}'.
If you want to help out with these kinds of moves, please send a mail! You are welcome to help out.

=== Contact ===
If you need any help regarding this, please contact Tom Albers ('''tomalbers@kde.nl''')

[[Category:Policies]]

Projects/Plasma

2007-08-29T21:55:15Z

Cbs: fix page to point to correctly spelled one

== Developer Coordination ==
;[[/Tasks|Current tasks]]
;[[/Package|Plasmagik packages]]
;[[/Theme|Plasma::Theme]]
;[[/Widgets|Interactive widgets provided by libplasma]]
;[[/Architecture|Plasma Architecture]]
;[[/PIG|The P.I.G. (Plasma Interface Guidelines)]]
;[[/ZUI|The ZUI. (Zooming User Interface)]]

== Plasmoids ==
;[[/Clock|Clock plasmoid design]]
;[[/Calendar|Calendar plasmoid design]]
;[[/TaskMan|Task Manager plasmoid design]]

== Raptor ==
;[[/Menu|Raptor menu plasmoid design]]

== Meetings ==
Summaries and logs of scheduled plasma meetings can be found on the following pages:
;[[/20070207|February 21, 2007]]

Projects/Plasma/Architecture

2007-08-29T21:54:21Z

Cbs: Projects/Plasma/Architucture moved to Projects/Plasma/Architecture: fix spelling mistake.

Plasma should be able to have different themes for same data.For example there should be 10 different Clocks, while all of them are showing one thing: Time.
So Plasma Provides Data Engines. Data Engines will provide Data for Plasmoids.

So to have a Clock Plasmoid:

Plasma --> Time Data Engine
|---> Clock Plasmoid 1
|---> Clock Plasmoid 2

Getting Started/Distribution Packages

2007-08-20T19:54:00Z

Cbs: /* Kubuntu */ changed alpha to beta

Many distributions provide KDE SVN (KDE 4) and Qt packages, so that if you're simply porting your application to KDE4, then you don't have to worry about compiling kdelibs and kdebase frequently in order to keep up-to-date. Here's the information for a few different distributions:

== openSUSE ==

openSUSE's KDE team has very regular (every few days) KDE SVN packages built. Currently packages are built for ''all'' things in KDE's branch/.

Instructions: http://opensuse.org/KDE4

== Arch Linux ==

Arch has weekly updates of kdelibs, kdebase, and kdepimlibs.

Instructions: http://bbs.archlinux.org/viewtopic.php?id=28856

== Kubuntu ==

Kubuntu packages all the development snapshot releases of KDE4, and these are released in different repositories. The latest one is below.

Instructions: http://kubuntu.org/announcements/kde4-beta1.php

== Gentoo ==

The kde portage overlay has kde-base/kde*-9999.4 SVN monolithic ebuilds.

Instructions: http://overlays.gentoo.org/proj/kde/wiki

Projects/Plasma/Menu

2007-08-20T00:39:36Z

Cbs: /* Raptor design spec... */ Make 'Coding guidelines' not stretch over line

[[Image:Raptor.png|550px]]
== Current Development ==
The Demonstration applet for Raptor can be found in KDE SVN (http://websvn.kde.org/trunk/playground/base/kbfx_plasma/). You can run this applet under KDE3 to see few of the features we want to have on Raptor.

== Raptor design spec... ==
The main goal of Raptor is to deliver a ''unique menu'' for KDE, that is ''easy to use yet also eye-candy and with customisable look and feel''

The Main goal of Raptor Design (technically) is to abstract the source of the data.
The Data Source is implemented as DataSource Class. The DataSource Class itself is implemented directly in LibPlasma.

The loading of the Data Source is handled by the Data Engine, which is found as DataEngine Class also in Libplasma... which knows how to handle the Source. Thus it is possible to create and hook in other Plugins as wished, without changing the main Code of Raptor.

Raptor will load the Plasma DataEngines through an Interface to gain access to the DataSources. By specifying these interface for Raptor, and a plugin handler, others can write their own plugins with datasources and -engines and add it in Raptors configuration. Raptor then tells the plugins to deliver data via the interface (updateData or sthg) and the plugin sends these data in the form that it fits through the interface into it.

'''RaptorMenu Areas'''

There will be 5 basic areas of the Menu: The header, The footer, The categories pane, The elements pane and a shortstart bar. Each of them can
be configured separately: will they be displayed (available for header, footer, shortstart), where, how many rows it contains (available for shortstart, elements)
and which of the possible parts and plugins are loaded (does the header display a user logo or not, are there further plugins in the categories bar?, which
buttons are displayed in the footer, lock, logout, standby, restart?)

'''RaptorMenu Behaviour'''

Since Raptor is a Plasmoid, resizing will be handled automatically.

The first category/plugin that is opened at the press of the startmenu can be either the one with thomas' AI logic or any of the loaded categories. The proposed AI Logic of Thomas can be found at the end of the spec, as it is kind of a subproject...

Search will be done via Strigi, Tenor (even beagle is possible with a plugin) or any other search engine that is configured. The search results will be kept
in the category "search", even if another category/plugin is selected, until a new search is started.

Additionally to the scroll solution as it is now, we will provide other options, a kind of vertical adjusting wheel at the right side of the elements pane.

Instead of having some kind of context menu popping up, the right-clicked element / category could just turn around and present the options on the back
of the graphic of this Element.

Category handling can optionally be done via tagging instead of building a tree. We tag the elements with one to n tags, and it appears as soon as the tag
is called. This concept is further refined by a rating on the assignment between tag and element, so that OpenOffice.Org Writer can be rated 5 on the tag
write, but 4 on the tag OpenOffice.Org. We will then use this rating for sorting the elements. Depending how the labels are set, a task oriented start menu can be realized easily. We should predeliver a set of common label schemes.

'''Raptor Searching'''

Until Tenor is ready, Raptor will depend on the Strigi Search Plugin to provide searching capabilities.
As Strigi and Tenor will evolve and develop further, the searching capabilities of Raptor will also evolve and improve.
The search engine will provide Raptor with a DataEngine, and each search element abstracts a DataSource, so that the results can be remote or local, inside tar files or in locally mounted remote shares, such as NFS or samba. The Source of the search results does not matter for Raptor.

'''In Short'''

1.) The Menu will have Skin support. The user / artists can make raster (png like) and vector (svg like) themes for Raptor.

2.) The user will be able to blend / change the color of the skin.

3.) The user can also change the layout of the menu elements.

4.) The menu can have fancy effects like Fire and Rain :-)

5.) Configuration should be done in the Plasma-manner....

'''Coding Guide lines'''

Please read kdebase/workspace/plasma/HACKING for coding guidelines. and Try to follow this so that the plasma code is very clear and clean.

== Raptor AI Engine ==
Raptor was the most intelligent Dinosaur those days - and it's the duty of our team to make our Plasmic-Raptor intelligent as well.

Most of the Menu ideas came up during the last year provided a "My Favorite" function, whereby the applications were added to it by simple click counts, saved in a ini based data base. The application with the highest click count was the Favorite.

But one big problem with this approach is that we are not collecting data about ''when'' each of the application are executed and ''how'' they are executed. What we found from Celeste Paul's (KDE Usability Expert) work on the Menu system Usability paper was, that Applications are executed more often using the command line on *nix systems, or via other methods like quick launch or desktop shortcuts. Therefore, the methods used for Kmenu will not work for Raptor.

Thomas Lübking was developing a new approach for this problem during the past year or so with his so called ALI menu concept and a prototype was shipped with his famous Baghira theme. In this section, Thomas envisions a new and unique solution to a prehistoric problem.

Here is the functional description he emailed:

Each entry is attached to a 24 elements vector (or a 2x24 matrix to separate
week and weekend).
The vector entries represent the probability of the app to be chosen at the
current time (whether we scale it to [0,1] or [0,100] or [0,100000] doesn't
matter at the moment)
NOTICE that this is NOT the final rank!
Everytime the user updates the filter string, the apps are matched against
the filter string (IMPORTANT: one can save a lot of CPU by detecting filter
refinements and check only the left apps. And presented ordered by their
rank. (so the most probable app at this time that fits the editline->text()
is displayed on top, it will make sense to limit the displayed app amount,
say 20 or so)

'''Ranking:'''

There will be four conditions checked, concluded in the final rank.

1. Is there allready a RUNNING INSTANCE in most cases you won't open the same app twice via the launcher, e.g. konqueror opens new windows itself etc. - kwrite may be an exception beneath others what will hopefully (depends on the parameters) be catched by.

2. The probability of the app to be running at THIS TIME from the 24v entries.

3. The probability of the app to be run in THIS ENVIRONMENT. This assumes that applications are usually called to work together.
Examples: i often open kwrite to manipulate scripts or code and in addition a konsole to test them. - if you dial up, you'll have demand for konqueror/kmail after calling kppp, etc.
Thus the AI will check for each candidate the correlation to other running apps (i.e. does the running time of the candidate cover the running time of the running app.

4. The probability of the app to fit the USER TYPE Simple keyword ranking: as keywords/tags should be attached to app entries (rather than a group entry, to allow multigrouping) we collect infos about what kind of apps the user runs through keyword probabilities (is he a developer, artist, scientist,... and does the candidate have this keyword)
(We could bring in the keyword ranking here - what is currently NOT supported by the FDO desktop file definition?)

=> NOTICE THAT THIS COULD DEMAND A GUIDE ON KEYWORD USAGE!!

'''The running time stats:'''

The resolution will be hours.

- Everytime the user launches an app, its stats get a pushup during its runtime (so if the app runs from 16:00 to 18:00 the 16th and 17th entry will get a full pushup)

- Every new day ALL entries will be faded away (e.g. multiply by 0.9 - similar to the ant algorithm, a constant factor may be a bad idea ;)

- As the data is classified (24h entries instead of seamless or point information) we'll add the pushup to the hour entry relative to it's running
time in this hour and read out it linearily combined to catch hour breaks

Example:

Assume the app runs from 16:13 to 17:48 and we grant a 10% pushup - i.e.
multiply with 1.1 for 1h runtime.
We'll grant (60-13)/60*1.1 to the 16th and 48/60*1.1 to the 17th entry.
When we wanna know the probability for the app to run around 16:42 will use
48/60*p[17] + 12*p[16] (i.e. a linear combination between the hour centers)
To clarify the reason: assume you usually run an app at 16:00, thus the
pushup goes to the 16th entry but should be taken into account when the app
is started on 15:59:59 once (this is an extreme example of course)

(This is not necessarily complete =)

== Presentation (Technical part) ==

'''RaptorMenu Areas'''

There will be 5 basic areas of the Menu: The header, The footer, The categories pane, The elements pane and a shortstart bar. Each of them can
be configurated seperately: will they be displayed (available for header, footer, shortstart), where, how many rows it contains (available for shortstart, elements)
and which of the possible parts and plugins are loaded (does the header display a user logo or not, are there further plugins in the categories bar?, which
buttons are displayed in the footer, lock, logout, standby, restart?)

This section aims to define the coding of the presentation of the above-mentionned Areas. Here are the first inputs, what it will actually contain:

*A basic Abstract Item ( we already have this in the form of QGSItem, but we need to add some methods of it's own... so we need to inherit from QGSItem and make an abstract class). Lets call it RaptorVizAbstractItem class or some thing like this
*Each Raptor item derived from this abstract items will be sensitive to input events. it will have support for displaying progress and ranking also and has to take in configuration options for each item: like delete / rename etc... There must also be accessibility options available like zoom level for each item.
*We will use data structures to store such items ( maybe a link list connecting each of the items, so that item grouping is possible and it's also possible to apply input to the whole group ... We can also try to link multiple groups and stack in one on top of the other ... but this would be manged by a layout manager so that things are in proper order. this way we can also support moving a large view around like on kickoff... what we're trying to see is if we can try to move around in 3D... We're not sure yet :-) ... But based on Thomas comments, the AI agent will completely remove the need for a hierarchy in the menu, though we must still provide it as options to users who really want hierarchies.
*Next...we will also have some special QGSItems for input fields and also for button types.
*On top off all that we can have a 3rd Effects layer..where we can have some nice FX for those who like to have those. Water and fire are just two such things which would be nice... But it wouldn't be enabled by default... The user may enable it via config, if he wants it.
== TOM - Task Oriented Menu ==

What is TOM?

TOM stands for Task Oriented Menu and is a work in progress that will become a
viable alternative to the current KMenu. Its goals include:

* Be task oriented
* Be simple and clear to use
* Create a smaller but usable menu
* Limited configurability through sensible defaults
* Have all configuration needs built right into the menu, including:
* Editor dialogs that can be called up from entries in the menu
* Context menus accessed by RMB clicking on a task for powerusers
* Allow locking down of menus through immutable settings
* Obeys Kicker and KDE Kiosk settings
* By making the TOM group of kickerrc immutable all config is removed
* By making a task group's rc file immutable, config options are removed
* Not require any modifications to the KDE menu system (applnk, etc)

What is a "Task Oriented Menu"?

A task oriented menu displays it's entries as "things to do" (or tasks) rather
than simply listing all items that are available. Each of these tasks has an
application or command associated with it, and this associated command can be
changed without changing the task name or placement within the menu. The tasks
are grouped by function and may map to programs, documents or actions.

Todo list

Editor dialogs
Make the Destination entries work (only Run A Command is done)
Populate and track Recent Applications menu entries
* Application launching should be caught somewhere in the KDE libs, ala
Recent Documents
Writing out of config files to reflect runtime changes (deleted entries, etc)
* This requires keeping track of the config files used in creating the menu
KDEDIR merging
* KDEDIRS are already consulted for taskgroups, but groups of the same name
should be merged
Sane merging of menuext entries
* "Recent" items should go into the recent section
* Replace TOM's builin recent docs with the menuext version?
* Create a Recent Applications menuext?
* Add a way to quickly add/remove menuext items from TOM
(ala "Modify These Tasks")
Check for updates on launch and bring them down/install them if they exist
* this includes new apps installed on the local box showing up in the menu
* "Get cool stuff" integration?
Further refinement of wording / ordering in main menu (a perpetual TODO ;)
Creation of real-world task groups
Support plugins which can add arbitrary functionality to the menu

Debate list

What should be the default task entry format be:
a) Task Name
b) Task Name (App Name)
c) App Name (Task Name) <-- silly option =)
Should "Run A Command..." be replaced by an inline combobox?
Pros: It's more obvious and will work even if kdesktop is gone. The widget
is already written (in tom.cc)
Cons: It makes it stand out too much over other entries, takes up more room
and isn't as powerful as the full minicli

---Part above is pasted from a Mail from Aaron Seigo

Design and Architecture

''Basic requirements''

* Config is stored in an XML
* This XML is saved by the config-sets name
* This/these XML is/are read and delivered to KBFX via Plugin
* The plugin should be able to merge multiple XML config setting files
* KBFX should be able to run multiple TOM plugins
* It should be possible to use further plugins right in the TOM Plugin -> The reasons are explained later

''Store config as XML''

* Easy to edit
* Can be extended in a simple way
* Structured
* Support for foreign charsets

''Save by the config-set name''

The idea is that one can easily transfer settings and import them to test without having to delete the carefully prepared own configuration.

This/these XML is/are read and delivered to KBFX via Plugin

The normal manner to make sure that changes and improvements can be delivered without actually touching the framework

The plugin should be able to merge multiple XML config setting files during runtime

Imagine a computer used by a group of persons. I explain by means of the following family:

# Father, uses Office-Functionality, uses Graphics and his digicam, the Internet and occasionnaly plays games
# Mother, uses Office-Functionality, the Internet and occasionaly plays games
# 17yrs old son, geek and student, uses Office-Functionality, graphics and his digicam, the Internet, plays games, develops, and administers the computer
# 14yrs old son, student, uses Office functionality, Internet, plays games

They each have their own accounts. They each don't want to see the things they don't use. It would now be possible to have an XML for each of them. But 2 yrs later, the 17 yrs old leaves home, and the younger brother takes over system maintenance. Now he needs these progs. So the older one would have to set up the tom for system maintenance for his younger brother, who doesn't care of developping and gaming.

But if we provide possibility to hook in multiple XMLs per Plugin and merge them during runtime, they could have a baseXML with office and Internet functionality, a graphics XML for Graphics and Digicam, an XML for the games, an XML for developing and an XML for administration.

If a TaskGroup tag exists in multiple of those XMLs, it is only shown once, with the Tasks of all of those XML's. So the taskgroup could be "Write" and have the elements e.g. "a letter" from the office XML and "c++ code" from the developer XML. So redundant TaskGroups can be avoided and place can be saved.

Another scenario could be that a programmer writes a program set and -as enthusiast KBFX user- provides the TOM XML straight with it. No need to reconfigure KBFX TOM for the use with those programs, just hook in the new XML as well.

The Config editor should be able to merge multiple XML config setting fixed.

Now imagine that a user X is absolutely enthusiast of the program set of the above developer. But he has already created (for other programs) a task group name he likes better and also fits this developer's new program set. So he should be able to say "Import into XML", indicate in which Settings to import, from which file to import. He is then shown a list of all TaskGroups and Tasks of the XML with the import data, having checkboxes where he can select which parts (TaskGroups and/or Tasks) should be imported in the config editor, and subsequently, where in his original XML (for TaskGroups, which order, or as a subtaskgroup, for tasks into which task groups) he wants to import it to.

This makes the whole handling of new elements easier and gives developers the possibility to deliver the settings right with the programs.

KBFX should be able to run multiple TOM plugins.

That's a personal preference that - however - seems important to me. If we take the family from above as an example again. The older son - being a geek - loved tweaking the pc and did a lot of administration. The younger - in this scenario - has taken over the task of system maintenance. He is savvy enough to do it, but being no geek, it's just once in a while he touches the administration. In the example above, the old son had all in the things in the same plugin instance. He used system maintenance often, so it was not disturbing to have that lot of entries in his tom. The younger however, is a different story. As he only seldom does administration, it slows down his access to the things he really needs (by simply existing there) without bringing him advantages. So he unloads the administration XML, adds a new instance of TOM at the bottom of the KBFX Plugins and hooks it in there. He can now use the Tom at the top for his regular work and just once in a while opens tom2 with the administration XML to do system maintenance. It's still around, accessible in KBFX, but not there, where he usually starts the tasks he uses day by day, so without making him scroll longer for his applications.

XML Definition

I am no XML guru at all. I avoid the work to research a valid header definition. Instead I'll just concentrate on the content. The tags I use are (Please note that the text in red is the tags):
<code xml>
<TOM>
<TaskGroup: Browse>
<Name>
<locale:de>Durchstöbere...</locale>
<locale:en>Browse...</locale>
</Name>
<TaskAction: Internet>
<Name>
<locale:de>das Internet (WWW)</locale>
<locale:en>the Internet (WWW)</locale>
</Name>
<Program>/usr/bin/firefox.sh</Program>
<Name>Firefox</Name>
<Description>
<locale:de>Surfen Sie im Internet</locale>
<locale:en>Surf the Web</locale>
</Description>
</TaskAction>
<Plugin: Contact>
<Name>
<locale:en>Contact...</locale>
<locale:de>Kontaktiere</locale>
</Name>
<PluginLoad>ContactPlugin</PluginLoad>
</Plugin>
</TaskGroup>
</TOM>
</code>

* The TaskGroup default attribute is the name used internally, not displayed
* The locale default attribute is the iso code of the language, and is taken to display the names and descriptions according to the country settings. If no locale tag for the language is found, the language tag without language attribute should be taken - if one exists - or the one with the en attribute. The element itself should probably be in ""
* The Program tag contains the command line to be executed upon launch
* Probably, a sort order mechanism should be implemented as well, either with an tag or by means of a rating with tags
* The XML should be UTF16 for foreign charset support

''Things to be considered''

* One Thing that should be considered is that - as long as the XML's are not delivered by the distributors, it can happen that Programs disappear. The logical solution would be to mark them with white X in a red circle, and if one clicks on it, he is given 3 choices:
** Search for the file that was linked
** Delete the entry
** Assign another Program to that task
* Personal Setting files should be stored in /home/user/kbfx, and we should provide an export function that copies that file to /usr/share/kbfx somewhere
* Loading should always have the two paths prepared as proposals for people to find it quickly
* Having a possibility to enter plugins somewhere in tom would be nice and feasible, I think. Example: Tasks write (tagged , organize (tag , Contact (tagged with the information to hook that in. That could - when a contact plugin exists, listing contacts and possibilities to contact them - then let you contact the matching contact directly.
* Instead of runtime-merging of multiple XML's, a personal XML could be created during the time you add another XML to the plugin. This - however - should have the origin marked to offer the possibility of sending these modifications back to the origin file.
* To have a real TOM, we should also include a Plugin (right hooked into tom) importing the todo list of the user's PIM. It would then
** launch the PIM, and display the task, if it has no attachments
** Open the attached file, if one file is attached
** Open a list with the attached files, if multiple files are attached
** This came to mind as I do actually work with the todo a lot...

== The Raptor Team ==

Note: The team is open to everyone who wants to contribute. Not only developers are welcome, but everyone thinking he/she can contribute (as for example Dracor, who doesn't code at all). So if you want to join, join the panel-dev mailing list and mention that you want to join the RaptorMenu team, as well as what do you think you can/will contribute (is it coding, a special area there, or is it helping to refine the concept?)

'''Plasma Team Lead:'''

Aaron Seigo

'''Raptor Maintainers:'''

Siraj Razick

Thomas Lübking

'''Developers'''

[[User:Phobosk|PhobosK]] (Co-Maintainter and Distribution Management)

Christoffer Brodd-Reijer (PSP integration and Backend development (Author of KPsPManager))

Buddhika "Bud" Siddhisena

Fathi "Fabo" Boudra

Yanis (Usability and Accessibility Development)

'''UI Design and Usability'''

Mensur "Nookie" Zahirovic

'''Documentation, technical docs'''

[[User:Dracor|Nathanael "Dracor" Gogniat]]

'''Advice and Guidance and Development Support'''
Stephen Kulow (Kickoff)
Vandenoever (Strigi)
Raptor Thanks Oxygen-team for the extended support

== Current State of the Project ==

''Keys''
*In progress = +
*Complete = *
*Not started = -

''Tasks''
*Design of Menu AI Engine *
*AI Engine Plugin +
*Design UI (Nookie) +
*Documentation (Dracor) +
*Build System +

Progress (5. july 2007)

*Raptor Widget Elements ---------------------60 %
*Raptor Data Engines ------------------------90 %
*Raptor Data Sources ------------------------60 %
*Raptor Plugin Interface ----------------Complete
*Raptor XML UI component --------------------50 %
*Raptor Plugin TOM (Task Oriented Menu-------10 %
*Raptor Apps Plugin --------------------------1 %

''Progress Report Fri Sep 29 2006,''

Things completed:
*Port of the initial applet code to KDE4 kicker and loading the plasmoid has worked well.
*Cmake based build system is working and initial folder structures are created and commited to KDE svn trunk/playground/base/raptor/
*Thomas is working on the AI engine and he has started work and we can expect to see a commit soon on svn
*Nookie has made some mocks and in the process of completing the mock so that it can be published on the spec
*Oxygen-team member is making a logo/icon for Raptor and initial contacts were made by fabo
*The spec was read by Aaron and Vandenoever and waiting comments

'''Siraj Razick'''

Policies/Application Lifecycle

2007-08-13T09:55:25Z

Cbs: /* Stage 1: The start */

When you want to start a new application, you want to know where you should place it in the Subversion repository. This document describes where to go in which stage of your application.

In a diagram it all comes down to:

[[Image:svnguidelines.png]]

=== Stage 1: The start ===
The start of a new application can take place on a local disk, in a local repository or any other way. Another option is provided by KDE in the special {{path|/trunk/playground}} folder in the repository where everyone is free to commit ones own application. You can request a SVN account at sysadmin and after that you can import your project in the subfolder of your choice.

It is not meant as a backup area, so you should not develop your application somewhere else and only sync the changes now and then to KDE's repository.

As soon as you start releasing your software and match the criteria for the next stage, you should consider moving your application folder to the next stage.

Because playground is something like an 'experimental' area, there is only a small amount of applications that make it to the next stage. To keep the playground area accessible and a bit organized, we have created a {{path|/tag/unmaintained/N}} (where 'N' is the KDE major version the application was written for; e.g. 4 for KDE4 applications). If you do not want to continue your application, move it to that place in the repository. If you do not know how, contact the current contactperson which is mentioned at the bottom of this document.

Whenever an application has not received a commit for one complete year, you will be contacted via email to discuss if you want to continue the application or if it has died. In the latter case or when the email bounces, it will be moved to {{path|/tag/unmaintained/N/}}.

This also applies to the currently no longer used /trunk/kdenonbeta area.

=== Stage 2: Stable ===
When you have made one of more releases and want to continue to develop it, the term 'playground' does no longer apply to you. That is the right time to move out of here. There are two options to move to: extragear and one of the KDE main modules. If you want to move to one of the KDE main modules, you will get released with KDE. That also means you have to respect that release schedule. The fact you want your program in KDE main modules is not enough and others have to agree is valuable to have it.
In extragear you are on your own. You make the releases whenever you want and you have to talk to the translators about your release schedule. In the future it might be possible to be released together with the KDE main modules. But at this moment this is not possible.

Whatever you choose, there are some rules to follow before you are allowed to move to either location:
* There should be user documentation in the form a docbook
* There should be developers documentation in the form of apidox for libraries you can check this at [http://www.englishbreakfastnetwork.org/ ebn]
* There should be no krazy code checker issues reported. Again, you can check that at [http://www.englishbreakfastnetwork.org/ ebn]. There is also a [[Development/Tutorials/Code_Checking|tutorial on using Krazy]] available here on TechBase.
* If possible, there should have been a basic usability review of your application. Usability people are hard to get, so this is not crucial.
* You should have checked for basic problems with a profiler. I hope we will get a tutorial on how to do this soon
* Your application should be [[Development/Tutorials/Localization/i18n|completely translatable]].

When you decide you want to move to this second stage, you move your application to {{path|/trunk/kdereview}}. Then you sent an announcement to '''kde-core-devel@kde.org''' that you have done that, address above issues and make clear where you want to move to (which kde main module or extragear). Extragear only requires general approval on kde-core-devel, while going into, for instance, kdepim requires approval from the kdepim community who manage that module.

Then the two weeks review period starts. In those two weeks people can object to your proposal or request additional changes. When there are no objections after the two week period, you are allowed to move your application to the place you decided to go. If your intention is to move to a main module you must get approval from the module maintainer(s) who manage that module.

If there are changes requested, you can make them while in kdereview. But only as long as you are working on those issues. If you decide to let it rest for a month for example, you should move it back to playground. When the requested changes are completed, announce it again to kde-core-devel and wait for one week for objections.

In no case kdereview can be a permanent place to develop your application.

=== Stage 3: The end ===
Whenever you decide to stop developing the application and that leaves the application without developers, please announce that to kde-core-devel. If nobody stands up to take over maintainership within two weeks, the application has to be moved to the {{path|/trunk/unmaintained/N/}} area as every application in the KDE main modules and in extragear needs to have a maintainer to stay there.

=== Translations ===
For each move in subversion, the translation files of each language need to move as well. Because this requires a complete checkout of the l10n folder and some knowledge about the structure, you can ask the release-team ('''release-team@kde.org''') to move them. Send a simple mail with the information required to do the move, for example: 'move {{path|/playground/somewhere/someapp}} to {{path|/kdereview/someapp}}'.
If you want to help out with these kinds of moves, please send a mail! You are welcome to help out.

=== Contact ===
If you need any help regarding this, please contact Tom Albers ('''tomalbers@kde.nl''')

[[Category:Policies]]

Projects/Plasma/PIG

2007-07-28T20:34:05Z

Cbs: /* Category Names */

== What These Guidelines (Will) Cover ==

This document is a place to collect all the "do"s, "don't"s and "how to"s for interface elements in Plasma, particularly applets and plasmoids.

== Category Names ==

The following are acceptable known entries for plasmoids and applets. If your applet does not fall within one of the following categories, leave the category field empty (it will be automatically categories under "Miscellaneous" for the time being) and contact the Plasma development team to have a suitable category added to the list (at which point you may then use that category).

*'''Date and Time''' clocks, calendars, scheduling, etc
*'''Environment & Weather''' add-ons that display information regarding the weather or other environmentally related data
*'''Examples''' samples that are not meant for production systems
*'''File System''' anything that operates on files or the file system as it's primary purpose, such as file watchers or directory listings. Simply using a file as storage does not qualify the add-on for this category.
*'''Graphics''' for add-ons where displaying images, photos or graphical eye candy is the primary purpose
*'''Language''' add-ons whose primary purpose is language related, such as dictionaries and translators.
*'''Mapping''' geography and geographic data add-ons
*'''Online Services''' add-ons that provide an interface to online services such as social networking or blogging sites. If there is another more appropriate category for the add-on given the topic (e.g. mapping if the applet's purpose is to show maps), even if the data is retrieved from the Internet prefer that other category over this one.
*'''System Information''' display and interaction with information about the computer such as network activity, hardware health, memory usage, etc
*'''Windows and Tasks''' managers for application windows and/or tasks, such as taskbars

Questions from a futur plasmoid programmer. I find those categories ambiguous. For instance:

* Where would go "Disc Usage" applet go? File System? It's listing mount-points and how much free space is left on each... Or "System Information"?
* Where goes an applet that display the cover art and music information of the currently playing track in Amarok? Or any media-center related plasmoid. I propose to add a category "Multimedia".
* Where would go a "Live Road Traffic" plasmoid: "Environment & Weather", or "mapping"? Environment is quite vague
* Shouldn't "Date and Time" be renamed "Date & Time", and "Windows and Tasks" "Windows & Tasks", to keep consistency?

== Theming ==

== Animation ==

== Configuration ==

== Status Notifications ==

== Packaging Conventions ==

User:Cbs

2007-06-23T22:47:42Z

Cbs:

User talk:Cbs

2007-06-23T22:47:07Z

Cbs:

== Discussion? ==

Sorry, but I don't feel TechBase the ideal place where start such discussions, neither to be used as personal log for those kinds of stuff.
This is a '''developer''' wiki, with developer and ISVs informations. -- [[user:Pino|pino]] 00:30, 24 June 2007 (CEST)

I understand and I have not the slightest intention to leave it here. I wanted to start it at wiki.kde.org (which is down). I was not aware that my user page would be subject to any interest at all. I just wanted a wiki page to test the markup. I am sorry if I was out of line.
--[[User:Cbs|Cbs]] 00:47, 24 June 2007 (CEST)

User:Cbs

2007-06-23T22:41:01Z

Cbs:

Putting this here while I search for a better space. Also wiki.kde.org is down with a database crash.

= The Porting discussion =
A blog post by Nikolaj Hald Nielsen [http://amarok.kde.org/blog/archives/429-Amarok-2-on-windows-A-rant.html about Amarok 2 on windows] sparked replies from [http://aseigo.blogspot.com/2007/06/hoping-and-wishing.html Aaron Seigo], [http://digested.blogspot.com/2007/06/buy-high-sell-low.html Derek] [http://digested.blogspot.com/2007/06/compromises.html Kite] and [http://chehrlic.blogspot.com/2007/06/funny-discussion.html Christian Ehrlicher] as well as a lot of people commenting on these articles. In fact, this topic has had great response in 2004, when Aaron Seigo asked [http://aseigo.blogspot.com/2004/12/how-to-kill-open-source-on-desktop.html "how to kill the open source on the desktop?"] and received roughly 170 comments. This page tries to present an overview of the arguments as well as an outlook on challenges and possible strategies. I will also post all the open questions that came to my mind. Enjoy

Disclaimer: Not all of these arguments reflect my personal opinion, nor do I claim that they are right. I merely try to collect the more reasonable ones. Feel free to add missing ones. I personally think that if it is not too much effort to port KDE applications, it will happen anyways and is not necessarily a bad thing. Just so you know.

{| class="wikitable" border="1"
|+Summary of Arguments
|-
|align="center"|'''Arguments in Favour / Hopes'''
|align="center"|'''Arguments against / Fears'''
|-
|colspan="2" align="center"|'''Migration issues'''
|-
|KDE applications on Windows make switching to Linux easier. In fact, they allow Windows users to make baby steps on their way to Linux adoption, switching one application at a time. For a lot of people, this makes switching '''possible''' because once they have migrated to the applications, they can start thinking about migrating the OS.
|While switching is '''possible''' it also becomes '''uneccessary''' because windows now runs both the Linux apps '''as well as the Windows apps.''' In fact, we are increasing the value of Windows for no good reason, since Microsoft is not friendly towards Open Source.
|-
|If people have a good reason to stay on Windows, like 3rd party applications or hardware support, chances are that they would not have come over to Linux full time anyways. At least they now have '''an open source alternative''' if they have to stay on Windows.
By bringing KDE to Windows, we can make it painless to move to linux with tools such as [http://developer.kde.org/summerofcode/kamion.html Kamion] since we now where all the data is saved. The importance is that we let the '''users decide''' when to switch (i.e. when they feel that Linux is ready.
|If switching is painless, people might '''switch back''', e.g. to get around dual booting. For windows users there is '''no incentive any more''' and some people prefer windows for hardware compatibility and games.
|-
|colspan="2" align="center"|'''User/Developer base'''
|-
|We have to opportunity to '''reach more users''' because it is easier to make people try out a KDE application if it runs on windows. A greater user base will help us '''find more bugs'''.
|KDE/Linux does not stand to gain if Windows only bugs are found (there are bound to be a number of them). Also windows users are not (yet) familiar with reporting bugs, since it hardly exists for commercial software, additionally the tools required for effective bug reporting (compiler/debugger) are harder to install on windows. The increased user base will thus be of '''little benefit'''.
|}

User:Cbs

2007-06-23T22:38:17Z

Cbs: /* The Porting discussion */

Putting this here while I search for a better space. Also wiki.kde.org is down with a database crash.

= The Porting discussion =
A blog post by Nikolaj Hald Nielsen [http://amarok.kde.org/blog/archives/429-Amarok-2-on-windows-A-rant.html about Amarok 2 on windows] sparked replies from [http://aseigo.blogspot.com/2007/06/hoping-and-wishing.html Aaron Seigo], [http://digested.blogspot.com/2007/06/buy-high-sell-low.html Derek] [http://digested.blogspot.com/2007/06/compromises.html Kite] and [http://chehrlic.blogspot.com/2007/06/funny-discussion.html Christian Ehrlicher] as well as a lot of people commenting on these articles. In fact, this topic has had great response in 2004, when Aaron Seigo asked [http://aseigo.blogspot.com/2004/12/how-to-kill-open-source-on-desktop.html "how to kill the open source on the desktop?"] and received roughly 170 comments. This page tries to present an overview of the arguments as well as an outlook on challenges and possible strategies. I will also post all the open questions that came to my mind. Enjoy

Disclaimer: Not all of these arguments reflect my personal opinion, nor do I claim that they are right. I merely try to collect the more reasonable ones. Feel free to add missing ones. I personally think that if it is not too much effort to port KDE applications, it will happen anyways and is not necessarily a bad thing. Just so you know.

{| class="wikitable" border="1"
|+Summary of Arguments
|-
|align="center"|'''Arguments in Favour / Hopes'''
|align="center"|'''Arguments against / Fears'''
|-
|colspan="2" align="center"|'''Migration issues'''
|-
|KDE applications on Windows make switching to Linux easier. In fact, they allow Windows users to make baby steps on their way to Linux adoption, switching one application at a time. For a lot of people, this makes switching '''possible''' because once they have migrated to the applications, they can start thinking about migrating the OS.
|While switching is '''possible''' it also becomes '''uneccessary''' because windows now runs both the Linux apps '''as well as the Windows apps.''' In fact, we are increasing the value of Windows for no good reason, since Microsoft is not friendly towards Open Source.
|-
|If people have a good reason to stay on Windows, like 3rd party applications or hardware support, chances are that they would not have come over to Linux full time anyways.
By bringing KDE to windows, we can make it painless to move to linux with tools such as [http://developer.kde.org/summerofcode/kamion.html Kamion] since we now where all the data is saved. The importance is that we let the '''users decide''' when to switch (i.e. when they feel that Linux is ready.
|If switching is painless, people might '''switch back''', e.g. to get around dual booting. For windows users there is '''no incentive any more''' and some people prefer windows for hardware compatibility and games.
|-
|colspan="2" align="center"|'''User/Developer base'''
|-
|We have to opportunity to '''reach more users''' because it is easier to make people try out a KDE application if it runs on windows. A greater user base will help us '''find more bugs'''.
|KDE/Linux does not stand to gain if Windows only bugs are found (there are bound to be a number of them). Also windows users are not (yet) familiar with reporting bugs, since it hardly exists for commercial software, additionally the tools required for effective bug reporting (compiler/debugger) are harder to install on windows. The increased user base will thus be of '''little benefit'''.
|}

User:Cbs

2007-06-23T21:54:15Z

Cbs: Start the discussion

Schedules/KDE4/4.0 Module Status

2007-06-12T20:31:43Z

Cbs: /* kdegraphics */

This page is used by the KDE4 Release Team to keep track of the current state of the KDE4 release process.

== Moving / Removing Applications ==

Here is a quick checklist for moving or removing an application:

=== Documentation ===

Documentation for each application is kept in the {{path|doc/}} folder in the top level of the module. Be sure to move or remove the associated documentation when you move or remove an application.

=== i18n ===
When moving or removing applications from a module, be sure to move or remove the relevant pot files for the application in the {{path|/trunk/l10n-kde4/templates/messages}}
and {{path|/trunk/l10n-kde4/templates/docmessages}} folders. Then make sure you add entries to {{path|/trunk/l10n-kde4/scripts/process_orphans.txt}} that note what was done.

There is no need to checkout everything from l10n-kde4, just the {{path|templates}} and {{path|scripts}} folders.

=== Build System ===

Remember to edit all the relevant CMakeLists.txt files in both the origin and destination modules when moving an application.

== Module Status ==

{|
|-
! Module !! Description !! Release Maintainer !! Status
|-
| [http://websvn.kde.org/trunk/KDE/kdelibs kdelibs] || KDE foundational libraries || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdepimlibs kdepimlibs] || KDE personal information libraries || [mailto:winter@kde.org Allen Winter] ||
|-
| [http://websvn.kde.org/trunk/KDE/kdebase kdebase] || Runtime, workspace and essential apps || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdeaccessibility kdeaccessibility] || Accessibility applications || [mailto:gunnar@schmi-dt.de Gunnar Schmi Dt] ||
|-
| [http://websvn.kde.org/trunk/KDE/kdeartwork kdeartwork] || Additional icons, styles, etc. || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdeadmin kdeadmin] || Tools for system administration || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdeedu kdeedu] || Applications with educational content ||[mailto:annma@kde.org Anne-Marie Mahfouf] || Most applications ported
|-
| [http://websvn.kde.org/trunk/KDE/kdegames kdegames] || Entertainment || [mailto:johann.ollivierlapeyre@gmail.com Johann Ollivier-Lapeyre] ||100% compile, unmaintained and too-low quality games removed.
|-
| [http://websvn.kde.org/trunk/KDE/kdegraphics kdegraphics] || Graphics viewing and editing || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdemultimedia kdemultimedia] || Audio and video applications || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdenetwork kdenetwork] || Network-centric apps (IM, remote desktop, etc) || [mailto:uwolfer@kde.org Urs Wolfer] || not fully ported, needs lots of work
|-
| [http://websvn.kde.org/trunk/KDE/kdepim kdepim] || Groupware || [mailto:winter@kde.org Allen Winter] || not fully ported, needs lots of work
|-
| [http://websvn.kde.org/trunk/KDE/kdesdk kdesdk] || Tools for software development || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdetoys kdetoys] || Fun distractions || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdeutils kdeutils] || Miscellaneous utilities || ||
|-
| [http://websvn.kde.org/trunk/KDE/kdevelop kdevelop] || IDE || [mailto:mattr@kde.org Matt Rogers] || Ported. In development.
|-
| [http://websvn.kde.org/trunk/KDE/kdewebdev kdewebdev] || Web development tool suite || [mailto:amantia@kde.org Andras Mantia]|| Partly ported, needs lot of work.
|}

== Pending Application Issues ==

*'''Green''': discussed and approved
*'''Orange''': discussed, but pending on or blocked by other issues
*'''Red''': no progress made at this point

=== kdeedu ===

{|
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| Marble || Move into module after being ported to KDE || Torsten Rahn || Torsten Rahn || Move completed
|- style="background-color: lightgreen;"
| KAlgebra || Move into module after being ported to KDE || Aleix Pol || Aleix Pol || Move completed
|- style="background-color: lightgreen;"
| KLatin || Move to blackhole || kdeedu devels || unmaintained || Black hole
|}

=== kdegames ===

{|
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| KSquares || Move into module || Matt Williams || Matt Williams || Move Complete
|- style="background-color: lightgreen;"
| Kiriki || Move into module || Albert Astals Cid || Albert Astals Cid || Move Complete
|- style="background-color: lightgreen;"
| atlantik / atlantikdesigner || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kfouleggs || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| klickety || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kpoker || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kenolaba || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kasteroids || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| ksnake || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| ksokoban || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kjumpingcube || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| ktron || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|}

=== kdegraphics ===

{|
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: #ffc642;"
| KGhostview || Move to extragear pending GS support in Okular (currently WIP) || Aaron Seigo || Luís-Pedro Coelho || Pending
|- style="background-color: #ffc642;"
| KFax || Move to extragear pending G3/G4 raw TIFF file supoprt in Okular || Aaron Seigo || || Pending
|}

=== kdenetwork ===

{|
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: #ff4242"
| KNewsTicker || Determine if still needed with Plasma || Urs Wolfer || Frerich Raabe || TBD
|- style="background-color: lightgreen;"
| KWiFiManager || Remove. Solid based solution, NetworkManager from kdebase || Urs Wolfer || Stefan Winter || Done
|- style="background-color: lightgreen;"
| KDict || Remove. || Urs Wolfer || - || Done
|- style="background-color: lightgreen;"
| KGet|| Move back to module from branch || KGet Team || [mailto:kget@kde.org KGet Team] || Done
|}

=== kdepim ===

{|
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| Kabcclient || Move into module || Kevin Krammer || Kevin Krammer || Approved and ported. Needs a handbook, apidox, and cleanup
|- style="background-color: lightgreen;"
| kmobiletools || Move into module || Marco Gulino || Marco Gulino || Move complete.
|- style="background-color: lightgreen;"
| kpilot || Resurrect || Adriaan de Groot || Adriaan de Groot || Move complete.
|- style="background-color: lightgreen;"
| kandy || Remove from module || PIM team || PIM team || Approved and removed.
|- style="background-color: lightgreen;"
| kmobile || Remove from module || PIM team || PIM team || Approved and removed.
|- style="background-color: orange;"
| khalkhi || Move into module || Friedrich Kossebau || Friedrich Kossebau || Approved. Port incomplete. 4.1?
|}

=== kdesdk ===

{|
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: #ffc642;"
| Kaider || Move into module, replace KBabel ||colspan=2 align=center| Nick Shaforostoff || In playground
|- style="background-color: #ffc642;"
| KBabel || Remove ||colspan=2 align=center|Nick Shaforostoff || Pending Kaider
|}

Development/Tutorials/SuperKaramba

2007-04-25T09:24:29Z

Cbs: /* TkInter with Python */, style change in beginning paragraph to emphasize that pyqt is better

==SuperKaramba==

===Intro===

[http://netdragon.sourceforge.net SuperKaramba] is a tool that allows one to easily create functionality enhancement modules on a [http://www.kde.org KDE desktop]. Such modules are interactive programs written in [http://www.python.org Python] or [http://www.ruby-lang.org/ Ruby] that are usually embedded directly into the background and do not disturb the normal view of the desktop.

===Links===

* [http://netdragon.sourceforge.net Homepage]
* [http://netdragon.sourceforge.net/sinfo.html Basic Tutorial for Theme Creators]
* [http://netdragon.sourceforge.net/api.html API-Reference]
* [http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/examples/ Examples]

==Examples==

===A clock sample with Ruby and Python===

Let's take a look at one of them, the
[http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/examples/rubyclock/clock.rb?view=markup clock.rb]
theme written in Ruby. The theme just displays the current time in a RichText widget.

<pre>
require 'karamba'

def initWidget(widget)
Karamba.resizeWidget(widget, 300, 120)
@richtext = Karamba.createRichText(widget, Time.now.to_s)
Karamba.moveRichText(widget, @richtext, 10, 10)
Karamba.setRichTextWidth(widget, @richtext, 280)
Karamba.redrawWidget(widget)
end

def widgetUpdated(widget)
Karamba.changeRichText(widget, @richtext, Time.now.to_s)
Karamba.redrawWidget(widget)
end
</pre>

The initWidget method will be called once if the widget got initialized. Here we setup the RichText widget where we display the current time in. The widgetUpdated will be called each second once (the interval is defined in the [http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/examples/rubyclock/clock.theme?view=markup clock.theme] themefile) and just updates the text display in the RichText widget with the new time.

Let's take a look at another theme. The [http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/examples/text/text.py?view=markup text.py] theme written in Python just displays some text widgets. We take this is example to create our own script, that does the same as the [http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/examples/rubyclock/clock.rb?view=markup clock.rb] above, that is to display the current time within a text widget.

<pre>
import karamba, time

text = None

def initWidget(widget):
text = karamba.createText(widget, 0, 20, 200, 20, "Text meter")

def widgetUpdated(widget):
t = time.strftime("%Y-%M-%d %H:%M.%S")
karamba.changeText(widget, text, t)
</pre>

In the initWidget method we create our text widget that is updated once per second (or per interval as defined in the matching theme file) at the widgetUpdated method to display the new current time.

more infos at...
* [http://www.kde-look.org/index.php?xcontentmode=38 Themes]
* [http://www.biodesign.com.ar/blog/?cat=2 More Themes]

===Forms and Modules===

Modules are libraries loaded on demand provided by Kross. One of them is the [http://websvn.kde.org/trunk/KDE/kdelibs/kross/modules/form.h?view=markup forms] module that implements some basic dialog and widget functionality. To display just a simple messagebox or load widgets from a UI-file those module can be used within all supported scripting languages.

The following sample Python script demonstrates how to display a messagebox.

<pre>
import karamba

def widgetClicked(widget, x, y, button):
import Kross
forms = Kross.module("forms")
if button == 1: #left
forms.showMessageBox("Information",
"The Caption","The Message")
elif button == 2: #middle
forms.showMessageBox("Error",
"The Caption","The Message")
</pre>

While the next sample Python script displays a dialog with an embedded "Open File" widget.

<pre>
import karamba

def widgetClicked(widget, x, y, button):
import Kross
forms = Kross.module("forms")
dialog = forms.createDialog("MyDialog")
dialog.setButtons("Ok|Cancel")
openpage = dialog.addPage(
"Open","Open File","fileopen")
openwidget = forms.createFileWidget(
openpage, "kfiledialog:///openfile")
openwidget.setMode("Opening")
openwidget.setFilter(
"*.txt|Text Files\n*|All Files")
result = dialog.exec_loop()
if result:
print openwidget.selectedFile()
</pre>

===Connect with KSpread===

The following sample uses KSpread to read a OpenDocument spreadsheet file and to display it within a table.

For this we are loading the [[Development/Tutorials/KSpread_Scripting|KSpread Scripting]] library and control it. Compared to dbus we don't need a running KSpread instance but just load and use the library direct (so, you still need to have KSpread installed).

While the sample is written in Python, the other supported backends like Ruby are able to access the whole same rich API.

<pre>
import karamba

# The OpenDocument spreadsheet file to read.
filename = "/home/kde4/kspreaddocument.ods"

#this is called when your widget is initialized
def initWidget(widget):
# Import Kross and fetch the KSpread module.
import Kross
kspread = Kross.module("kspread")
if not kspread:
raise "KSpread is not installed"
# Try to open the file.
if not kspread.openUrl(filename):
raise "Failed to open %s" % filename
# Get the sheet we like to display.
sheet = kspread.sheetByName( kspread.sheetNames()[0] )
text = "<table>\n"
# Iterate now through all cells on the sheet.
for row in range(1, sheet.lastRow() + 1):
# Put the content of the row into the record-list.
record = []
for col in range(sheet.lastColumn() + 1, 1, -1):
value = sheet.text(col, row)
if value or len(record) > 0:
record.insert(0,value)
# If the record has at least one cell print it.
if len(record) > 0:
text += "<tr>"
for r in record:
text += "<td>%s</td>" % r
text += "</tr>\n"
text += "</table>\n"

# Create the richtext widget to display the text.
richtext = karamba.createRichText(widget, text)
karamba.moveRichText(widget, richtext, 10, 10)
karamba.setRichTextWidth(widget, richtext, 345)
karamba.redrawWidget(widget)
</pre>

more infos at...
* [[Development/Tutorials/KWord_Scripting|KWord Scripting]]
* [[Development/Tutorials/KSpread_Scripting|KSpread Scripting]]
* [[Development/Tutorials/Krita_Scripting|Krita Scripting]]

===TkInter with Python===

While you are able to use [http://www.riverbankcomputing.co.uk/pyqt/ PyQt4] which not only does look nicer but also provides the nice Qt-API pythonized, you are also able to use the default toolkit Python comes with, that is TkInter.

The following sample just displays a TkInter "hello world" dialog if you click on the widget.

<pre>
import karamba

def widgetClicked(widget, x, y, button):
from Tkinter import *
root = Tk()
w = Label(root, text="Hello, world!")
w.pack()
root.mainloop()
</pre>

more infos at...
* [http://docs.python.org/lib/module-Tkinter.html Tkinter, Python interface to Tcl/Tk]
* [http://wiki.python.org/moin/TkInter Python Tkinter]
* [http://www.pythonware.com/library/tkinter/introduction/ An Introduction to Tkinter]

===QtRuby/Korundum with Ruby===

The following sample script written in Ruby demonstrates that you are able to use [http://rubyforge.org/projects/korundum/ QtRuby/Korundum] within your Ruby scripts.

<pre>
require 'karamba'
require 'Qt'

class Dialog < Qt::Dialog
def initialize
super()
self.windowTitle = 'Hello World'
end
end

def widgetClicked(widget, x, y, button)
dialog = Dialog.new
dialog.exec
end
</pre>

The script does implement only the widgetClicked function that got called if the user clicks on the widget. What we do within that function is to create an instance of the Dialog class that implements a QDialog using QtRuby and then execute that modal dialog.

more infos at...
* [[Development/Tutorials/Qt4_Ruby_Tutorial|Qt4 Ruby Tutorial]]
* [[Development/Languages/Ruby|Ruby Development Languages]]

Getting Started/Sources/Subversion

2007-04-03T22:44:12Z

Cbs: make the sentence read a bit better

{{TutorialBrowser|

series=Getting Started|

name=Using Subversion With KDE|
}}

== Abstract ==

This is a quick KDE-specific introduction for using subversion to access files and software in KDE's repositories. For comprehensive coverage of Subversion we recommend reading the book
"[http://svnbook.red-bean.com/ Version Control with Subversion]".

== Getting started ==

In order to use the KDE Subversion repository, you will need two things:

# A Subversion client program
# An account in our repository

Note: For anonymous read-only access use protocol "svn", no "yourname@" and server "anonsvn.kde.org" instead below.

'''Installing Subversion:''' instructions on installing the client are not
presented here. Refer to your system installation instructions to find out how
you can install Subversion. You will need version 1.1 at least. If you are
compiling from sources and want to access the KDE repository by https
(and not by svn+ssh), you will need SSL and ZLIB supports,
so you will need the <tt>--with-ssl --with-zlib</tt> options.

Alternatively, you can install one of the many graphical clients out there.
This tutorial is intended for people using the <tt>svn</tt> program only, referring
to tasks accomplished with the usual <tt>cvs</tt> program.

'''Getting an account:''' if you had a CVS
account before, it has been migrated to the new Subversion client. If
you didn't, refer to the [[Contribute/Get_a_SVN_Account|corresponding tutorial]] how to get one.

Note: if you have lost your CVS password, there are simple ways to retrieve
it. Use [http://ktown.kde.org/~coolo/cvspwd.c cvspwd.c] or
[http://kdab.net/~dfaure/cvs-unscramble cvs-unscramble] (Perl).

== The KDE repository structure ==

svn.kde.org/home/kde

That's the address of the KDE Subversion repository. The repository is served by
HTTPS or SVN+SSH protocol, which means your password is secure against third-party
eavesdropping.

The SSL certificate md5 fingerprint for the repositories:
F6BF EDE2 D016 D1B2 4F18 742E 2C8F B7EF

The SSL certificate sha1 fingerprint for the repositories:
e1:e6:41:96:3c:eb:ae:78:e2:73:0d:a2:32:2f:6b:21:13:bf:3d:0f

For people using svn+ssh, here's the fingerprint of the server's RSA key:
86:f3:66:06:20:74:81:d0:1b:b4:2f:25:03:f7:8e:fb

The repository is organised in main directories:

# /branches
# /tags
# /trunk

You can explore the repository structure at [http://websvn.kde.org/ http://websvn.kde.org/]

=== The top-level directory /trunk ===

The <tt>/trunk</tt>
top-level subdirectory is where the main development for KDE occurs.
What you will find here is what will become the next KDE release, and
its associated programs. Here you will also find the <tt>www</tt> module,
which contains webpages for KDE's site and related ones.

<tt>/trunk</tt> is further subdivided into these sub-directories:

*<tt>KDE/</tt> KDE itself, what will become the next public release. It contains the following modules:
**'''arts''' - Soundserver (removed in KDE 4)
**'''kde-common''' - Common admin/ directory
**'''kdelibs''' - KDE basic libraries, used by all KDE programs
**'''kdebase''' - KDE base programs, like the KDE Control Center, Kicker (the panel) and Konqueror (the web browser)
**'''kdeaccessibility''' - Accessibility files
**'''kdeaddons''' - Add-ons and plug-ins to KDE programs
**'''kdeadmin''' - KDE Administration applications
**'''kdeartwork''' - Images, themes, sounds and other art files
**'''kdebindings''' - Bindings for languages other than C++
**'''kdeedu''' - KDE Educational applications
**'''kdegames''' - KDE Games
**'''kdegraphics''' - KDE Graphical applications
**'''kdemultimedia''' - KDE Multimedia applications
**'''kdenetwork''' - KDE Networking applications
**'''kdepim''' - KDE Personal Information Management applications
**'''kdesdk''' - KDE Software Development Kit applications
**'''kdetoys''' - KDE toy applications
**'''kdevelop''' - The KDevelop program
**'''kdeutils''' - KDE General utilities
**'''kdewebdev''' - KDE Web development applications
*<tt>bugs/</tt>
:[http://bugs.kde.org/ Bugzilla] files
*<tt>developer.kde.org/</tt>
:The content of developer.kde.org
*<tt>extragear/</tt>
:KDE programs outside the main KDE releases.
*<tt>kdereview/</tt>
:Temporary home for KDE applications that are believed to have reached release-quality. From here, once all major issues are resolved, applications are moved either to <tt>/trunk/KDE/</tt> or to <tt>/trunk/extragear/</tt>
*<tt>kdesupport/</tt>
:Supporting applications and libraries for KDE
*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kugar'''
**'''kword'''
*<tt>konstruct/</tt>
:Konstruct, the KDE build program
*<tt>l10n/</tt>
:Translations
*<tt>playground/</tt>
:The KDE playground: applications being developed, but not having yet reached release-quality.
*<tt>qt-copy/</tt>
:The convenience copy of [http://www.trolltech.com/ Trolltech's] Qt library, which KDE is based upon.
*<tt>tests/</tt>
:khtml, KOffice and ksvg testcases
*<tt>valgrind/</tt>
:The Valgrind application, which is hosted on the KDE repository, but that is not part of KDE itself. Note that newer versions of Valgrind are developed on their own repository. The KDE Valgrind modules only holds up to Valgrind 2.4.
*<tt>www/</tt>
:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== The top-level directory <tt>/tags</tt> ===

This
directory contains the official releases of the programs maintained and
developed in the KDE repository. Each individual application has a
subdirectory here. Inside it, you will find the release numbers.

For instance, the KDE 3.4.0 code can be found under <tt>/tags/KDE/3.4.0/</tt>.

=== The top-level directory <tt>/branches</tt> ===

This directory contains the branch versions of the applications after a major release.

Most
KDE applications adhere to the philosphy that new features (as well as
new user-visible strings) are added only to the next release cycle —
the one that lives in <tt>/trunk/</tt>. However, bugfixes are applied to all
applications, even after release.

In
order to do that, a branch is created at the moment of the release,
indicating the state of the files at that time. Bugfixes are then
checked in to those files. Those branches are the ones in <tt>/branches/</tt>.

For instance, the KDE 3.4.x branch can be found under <tt>/branches/KDE/3.4/</tt>

The subdirectories you will find inside <tt>/branches</tt> are the
application subdirs, like <tt>akregator/</tt>, <tt>amarok/</tt>,
<tt>arts/</tt>, <tt>k3b/</tt>, etc. You will also find a <tt>KDE/</tt>
subdir, containing the official KDE releases since time immemorial.

One special subdir is found in <tt>/branches</tt>: <tt>work/</tt>. This
subdir contains the so-called "work branches", that is, branches containing
features being worked on, sometimes highly experimental. Multi-application
work branches always are checked in to <tt>/branches/work/</tt>, but
single-application branches may be found in each application's subdir. That
is a decision left to the developers.

== Checking out and updating ==

=== Checking out ===
In order to check out something with Subversion, you use the <tt>checkout</tt> subcommand.

'''WARNING:''' If you checkout trunk/KDE/ or branches/KDE/foo/ you will download complete kde-i18n!

Suppose you wanted to check out only KDevelop from the KDE repository. You would do:

CVS command:
cvs -d :pserver:yourname@cvs.kde.org:/home/kde login
cvs -d :pserver:yourname@cvs.kde.org:/home/kde checkout kdevelop

Subversion command:

CVS users currently using ssh access, should use protocol svn+ssh,
CVS users currently using password access, should use protocol https
in the following.

svn checkout <protocol>://<username>@svn.kde.org/home/kde/trunk/KDE/kdevelop

=== Updating ===

In order to update, you use the <tt>update</tt> subcommand.

This is no different from CVS: you change into your checked out copy and issue a <tt>svn update</tt> (or, shorter, <tt>svn up</tt>) command.

== Knowing the status of a file ==

To know which local files you had modified, in CVS most people did
cvs up
and looked at the files with '''M''', this does not work with svn so you have to do
svn status
to know the status of the files.

== Committing to the repository ==

Just like in CVS, committing to the Subversion repository is accomplished
with the <tt>commit</tt> or <tt>checkin</tt> (<tt>ci</tt> for short) subcommands.

CVS command:
cvs commit
# or
cvs ci
# or
cvs ci filename.cpp

Subversion command:
svn commit
# or
svn ci
# or
svn ci filename.cpp

This way, <tt>svn</tt> will launch the editor specified in <tt>$SVN_EDITOR</tt> for you
to compose the commit message. If you prefer, you can give <tt>svn</tt> the -m
oprtion with your full message:

svn ci -m "Updating protocol to conform to HTTP/1.1"

== Ignoring files ==

Subversion stores ignored files per directory. To edit the ignored
files of the directory you are currently in, do
svn propedit svn:ignore .
that will launch your editor, write there the names of the files you want to
ignore, one file per line. Once you are done, do a commit so the ignored list
file gets updated on the server.

A lot of files were ignored in CVS with help from global ignore list which
is not supported yet by SVN. You can wait for svn 1.3 or you need to add the
ignore list to the [miscellany] group in your {{path|~/.subversion/config}} (all in
one line):

global-ignores = *.o *.lo *.la .*.rej *.rej .*~ *~ .#* #*# .DS_Store *.moc
*.moc.cc *.moc.cpp config.log config.status config.cache *.gmo .deps .libs
SunWS_cache *.lo *.la *.rpo *.la.closure *_la_closure.cpp *_la_closure.cc
*_la_closure.cxx *.all_cc.cc *.all_cpp.cpp *.all_C.C *.all_cxx.cxx
*_meta_unload.cc *_meta_unload.h *_meta_unload.cpp *_meta_unload.C
*_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in Makefile.calls.in
Makefile.rules Makefile.calls autom4te.cache *.kidl

== Working with multiple revisions and branches ==

Unlike CVS, Subversion doesn't generate a revision number for each file
modified. Instead, the full repository is versioned, as a whole. This way, a
given revision number represents the state the repository was on a given date.
In other words, a revision number is like a timestamp (in fact, the Subversion
server uses this fact to search for dates in the repository faster).

So, for instance, when you check out the KDE repository, Subversion will
tell you the following:

Updated to revision 403821.

This means that the latest revision available at the time of the operation
was 403821. If you make a modification and commit, Subversion will update the
server-side revision and will inform you of it. Like CVS, only the committed
files will be updated: you will need run <tt>cvs up</tt> to update the rest of the
files.

If you want to retrieve a specific revision of a file, you can use the <tt>-r</tt>
switch. Besides the revision number itself, -r accepts a number of other
possibilities:

* The revision number: for example, use -r 403819 to retrieve that version
* '''BASE''': the revision you updated to
* '''COMMITTED''': the revision a file was last modified, before BASE
* '''PREV''': the revision of the previous commit to the file before COMMITTED
* '''HEAD''': the most recent revision available in the server
* '''{ date }''': between curly brackets, you can specify a date for searching the closest revisions

The following illustrates the evolution of the keywords:

# You run <tt>svn up</tt> to update to the latest available revision. Suppose Subversion tells you it updated to revision 403821. This means that HEAD and BASE are 403821.
# You modify file README and commit it. Suppose Subversion tells you it committed revision 403822. This means HEAD, BASE and COMMITTED are 403822.
# You modify the file again and commit it. Now PREV is 403822, but HEAD, BASE and COMMITTED are updated to a new value (suppose it's 403823).
# Now someone else modifies the repository, and you update your working copy. If Subversion tells you it updated to 403824, this means now HEAD and BASE are moved to 403824 (but PREV and COMMITTED stay the same)
# If someone modifies the README file now, HEAD is moved. The other keywords stay the same for you, until you update. At this time, we will have HEAD = 403825 (the latest available revision), BASE = 403824 (the revision you last updated to), COMMITTED = 403823 (the revision of the latest change to the file when you last updated) and PREV = 403822 (the revision of the change before COMMITTED)

Those keywords are useful to retrieve logs and diffs for commits to the
repository.

If you want to see the difference between your working copy and BASE, you
can run:

svn diff

This is a very fast operation, since Subversion keeps a local copy of BASE.
It doesn't need a network connection to accomplish this operation.

If you want to see the difference between your local copy and the latest
available on the server, you will run:

svn diff -r HEAD

If you want to see what has changed in the repository since you've last updated, you can use:
svn diff -r BASE:HEAD

If you want to see the last change to a file before BASE, you can use:
svn diff -r PREV:BASE
# or
svn diff -r PREV:COMMITTED

That is also valid for the <tt>svn log</tt> command.

== Linking in subdirectories from other places ==

It can happen you would like to include a copy of a subdirectory from another place, but just for convenience, not for developing the code in there. Of course it should be updated automatically whenever the original changes. Subversion can help you. You need to edit the property <tt>svn:external</tt> of the directory the subdirectory should be added to. So for the current directory you use
svn propedit svn:externals .
and then enter lines of the form
libkhalkhi svn://anonsvn.kde.org/home/kde/trunk/playground/pim/khalkhi
Updating will now fetch <tt>/trunk/playground/pim/khalkhi</tt> into the subdirectoy <tt>libkhalkhi</tt>.

{{warning|Beware that you cannot commit changes you did to the local copy of the external subdirectory, it is just a readonly copy.}}

You use <tt>svn://anonsvn.kde.org</tt> and not another protocol, because <tt>anonsvn.kde.org</tt> is accessible to everyone. Using <tt>https:</tt> or <tt>svn+ssh:</tt> would only work for users of that protocol. There are still some small disadvantage with <tt>anonsvn.kde.org</tt>: It is not always in synchronization with <tt>svn.kde.org</tt>, so updates in the original branch may take a while to appear on <tt>anonsvn.kde.org</tt>. And some strict firewalls are blocking the <tt>svn:</tt> protocol.

A special case in KDE 3 is the subdirectory <tt>admin</tt>, containing the KDE 3 build utilities. It is linked in to the top directory in all modules, and maintained in <tt>/branches/KDE/3.5/kde-common</tt>. For <tt>admin</tt> the KDE subversion server is configured to allow readonly access for everyone, so if you see
admin https://svn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin
there is no need to change this.

== More information on the kde wiki ==

See [http://wiki.kde.org/tiki-index.php?page=KDE%20Subversion%20HOWTO the KDE wiki] for more
information about subversion in KDE

Schedules/KDE 3.5 Release Schedule

2007-01-23T14:57:52Z

Cbs: /* January 23rd, 2007: Expected release date of KDE 3.5.6 */

KDE 3.5 is the fifth (and this time really last) feature release in the KDE 3.x series.
All dates given here are subject to revision, but we will try our best to stick to them if possible.
[mailto:coolo@kde.org Stephan Kulow] is acting as release coordinator for the 3.5 releases.

== KDE 3.5.0 ==

===August 1st, 2005: Officially close of feature list===
The list of features for KDE 3.5 should already be settled by then, but after that date are only KDE 4 features. At this date, /branches/KDE/3.5 is frozen for feature commits that are not listed in the [[KDE 3.5 Feature Plan|feature plan]].

===August 5th, 2005: Alpha 1 prepared===
Alpha 1 will be source only - without translations.

===August 25th, 2005: branches/KDE/3.5 is feature frozen===
The 3.5 branch is frozen for feature commits. Only bugfixes are to be committed. Still, binary compatibility is not required, i18n string changes are allowed.

===September 5th, 2005: Message Freeze===
After this date the same message freeze applies as for released versions (i.e. only previously untranslated strings or clear errors in strings can be fixed - no new strings).

===September 10th, 2005: tags/KDE/3.5-beta1 created===
The 3.5 branch is tagged as Beta 1 and is frozen for nonurgent commits till 14th.

===September 13th, 2005: Beta1 is prepared===
Beta 1 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.

===October 9th, 2005: tags/KDE/3.5-beta2 created===
The 3.5 branch is tagged as Beta 2 and is frozen for nonurgent commits till 12th.

===October 12th, 2005: Beta2 is prepared===
Beta 2 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.

===November 7th, 2005: Total release freeze===
This is the very last for commiting anything that isn't reviewed on the development lists. If in doubt, ask the release coordinator.

===November 9th, 2005: Release Candidate 1===
Targetted date for first release candidate and then wait for show stoppers to appear.

===November 29th, 2005: Targetted Release Date===

== KDE 3.5.1 ==

===January 20th, 2006: Tagging KDE 3.5.1===

== KDE 3.5.2 ==

===February 26th, 2006: Message and documentation freeze===

===March 17th, 2006: Tagging KDE 3.5.2===

== KDE 3.5.3 ==

===May 23th, 2006: Tagging KDE 3.5.3===

== KDE 3.5.4 ==

===July 10th, 2006: Message and documentation freeze===

===July 24th, 2006: Tagging KDE 3.5.4===

== KDE 3.5.5 ==

===August 8th, 2006: Partial lift of message and documentation freeze===
For the GUI strings (also known as messages), you can fix typos and make small
changes to them. You can also add new error messages to improve error
feedback to users. (Adding other kinds of messages are not allowed. In case
of questions or doubts, please ask the kde-i18n-doc@kde.org mailing list.)
For the documentation, the changes should also be rather small, except when
fixing inaccurate or outdated documentation. You can also port documentation
that has been prepared in the trunk/KDE modules. (If you change any
documentation for the KDE 3.5 branch, please be sure that the change is also
in the corresponding module of trunk/KDE. However you can do a little later,
in case that you would not have much time during the lift period.)

===September 18th, 2006: Message and documentation freeze===

===October 1st-3rd, 2006: Tagging KDE 3.5.5===
The actual date depends on how well the Release Coordinator returns from Dublin.

===October 10th, 2006: Expected release date of KDE 3.5.5===

===October 12th, 2006: Partial lift of message and documentation freeze===
For the GUI strings (also known as messages), you can fix typos and make small changes to them. You can also add new error messages to improve error feedback to users. (Adding other kinds of messages are not allowed. In case of questions or doubts, please ask the kde-i18n-doc@kde.org mailing list.)

For the documentation, the changes should also be rather small, except when fixing inaccurate or outdated documentation. You can also port documentation that has been prepared in the trunk/KDE modules. (If you change any documentation for the KDE 3.5 branch, please be sure that the change is also in the corresponding module of trunk/KDE. However you can do a little later, in case that you would not have much time during the lift period.)

== KDE 3.5.6 ==

===December 16th, 2006: Message and documentation freeze===
After this date the same message freeze applies as for released versions (i.e. only previously untranslated strings or clear errors in strings can be fixed - no new strings).

===January 15th, 2007: Tagging KDE 3.5.6===

===January 23rd, 2007: Expected release date of KDE 3.5.6===
'''Status'''': DELAYED! - See also: {{Bug|140307}}

==Frequently Asked Questions==
;What's the deal with that feature-plan?:In the past, there were a lot of complaints about a rather long "freeze period", so this is an attempt to address this issue. Basically the idea is that you add an entry about what feature you want to finish in the 3.5 timeframe and mark it as done when you completed it. This helps me to get an overview about the outstanding changes and in return allows you to work on the missing parts even in the "freeze period". The feature-plan is open for commits till August 1st 2005. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule. Please understand that although this gives you greater freedom over SVN, it also requires more discipline in making sure that your additions don't have unwanted side effects.

Development/Tutorials/Solid/Introduction

2007-01-23T00:07:11Z

Cbs: /* Listing Devices */

== What is Solid ==
Solid is the new hardware device framework for KDE 4 that features, among other things, a hardware discovery layer which allows you to detect and use devices regardless of operating system or architecture. You can learn more about the Solid project at [http://solid.kde.org solid.kde.org].

== Who is this tutorial for? ==
This tutorial is written for developers looking to use the Solid hardware discovery layer within their applications. It can also serve as a good starting point for developers looking to start working on the Solid framework.

== Prerequisites ==
* A working KDE4 development environment. Documentation on setting up a KDE environment can be found [[Getting_Started|here]].

== Listing Devices ==
Our first program will be a simple console based app that gets a list of all the hardware devices and prints them out to the screen.

<code cppqt>
Solid::DeviceManager &manager = Solid::DeviceManager::self();
</code>

This gets us the device manager. All the devices are queried through and returned from the device manager. Once we have the list of devices we can interact with them as follows:

<code cppqt>foreach( Solid::Device device, manager.allDevices() )
{
//print the name of device
kDebug() << device.udi() << endl;
}
</code>

device.udi() returns the Unique Device Identifier for the device as a QString. Even if you have more than one identical device, the UDI is guaranteed to be unique. For example if you have a MythTV box with two PVR-250 T.V. capture cards in it, you will be able to refer to card #1 by it's UDI and card #2 by it's UDI.

The complete program along with the CMake files necessary to build it can be found under "[http://websvn.kde.org/trunk/KDE/kdelibs/solid/examples/tutorial1/ kdelibs/solid/examples/tutorial1/]".

== Searching for specific devices ==
This second program makes uses of filters built into the solid framework. Using these filters you can list only devices according to supported capabilities, sub-devices of a given parent, and various predicates. In our example we'll be limiting our list to only audio hardware. A full list of capabilities can be viewed under the Solid::Capability namespace.

<code cppqt>Solid::DeviceManager &manager = Solid::DeviceManager::self();
DeviceList devices = manager.findDevicesFromQuery( "",
Solid::Capability::AudioHw );
//get a list of all devices that are AudioHw
foreach ( Solid::Device device, devices )
{
kDebug() << device.udi() << endl;
}
</code>

In this example Solid::DeviceManager::findDevicesFromQuery looks for a device with any parent and the Solid::Capability::AudioHw capability. If we had wanted to specify an AudioHw device with the parent "real_specific_parent" it would look like this:

<code cppqt>manager.findDevicesFromQuery( "real_specific_parent",
Solid::Capability::AudioHw )</code>
The complete program along with the CMake files required to build it can be found under "[http://websvn.kde.org/trunk/KDE/kdelibs/solid/examples/tutorial2/ kdelibs/solid/examples/tutorial2/]".

== What do we do with a device once we get it? ==
Now that we got a device, what do we do with it? First lets look at the relationship between the Solid::Device and Solid::Capability. A Solid::Device can contain many Solid::Capability. A device can be tested to have a capability in the following way:
<code cppqt>Solid::DeviceManager &manager = Solid::DeviceManager::self();

//get a Processor
Solid::DeviceList list = manager.findDevicesFromQuery( "",
Solid::Capability::Processor );

//take the first Processor
Solid::Device device = list[0];
if ( device.is<Solid::Processor>() ) {
kDebug() << "We've got a processor!" << endl;
} else {
kDebug() << "Device is not a processor." << endl;
}
</code>

To actually use this device as a processor we need to do the following:
<code cppqt>
Solid::Processor *processor = device.as<Solid::Processor>();
</code>
The complete program along with the CMake files required to build it can be found under "[http://websvn.kde.org/trunk/KDE/kdelibs/solid/examples/tutorial3/ kdelibs/solid/examples/tutorial3/]".

[[Category:C++]]