https://community.kde.org/api.php?action=feedcontributions&user=Grundleborg&feedformat=atomKDE Community Wiki - User contributions [en]2024-03-29T06:48:46ZUser contributionsMediaWiki 1.40.2https://community.kde.org/index.php?title=Frameworks/Epics/kdelibs_cleanups&diff=31490Frameworks/Epics/kdelibs cleanups2013-05-06T21:13:01Z<p>Grundleborg: /* Cleaning up kdelibs */ translate() -> tr()</p>
<hr />
<div>= Cleaning up kdelibs =<br />
<br />
Next to the other efforts for kdelibs modularization, there's also some cleanup tasks which needs to be done accross the whole kdelibs codebase. Tasks in here are probably more suitable for short term, bite sized involvement.<br />
<br />
'''Note''': For most of those tasks we try to put an estimation of the difficulty can be: easy, normal, hard (somewhat like in video games). ;-)<br />
<br />
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width:100%;"<br />
|- style="background: #ececec; white-space:nowrap;"<br />
! Status<br />
! Description<br />
! width=250 | Contact<br />
|-<br />
{{FeatureDone|remove kglobal.h include from staging/kwidgets/src/icons/kiconloader.h, fix compilation by adding the header where necessary (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move ktypelist.h from kdecore/util to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kentrymaptest from kdecore/tests to kconfig/autotests (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kascii and kasciitest to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|Port away from KGlobalSettings::singleClick() (easy)|Dominik Haumann}}<br />
{{FeatureDone|#cmakedefine -> #cmakedefine01, #ifdef -> #if, in order to catch missing includes (easy)|Nicolas Lécureuil}}<br />
{{FeatureDone|Port from KCmdLineArgs+KApp to QApp+setApplicationName in all unittests that don't use args (easy)|Jeremy Whiting}}<br />
{{FeatureInProgress|kio/netaccess.h: there are some "TODOs" about deprecating most methods in favour of job+exec (TODO: compare with synchronousRun) (normal)|Àlex Fiestas}}<br />
<br />
<br />
{{FeatureDone|Fix kfileplacesmodeltest (normal)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move to kcoreaddons the tests in kdecore/tests that are actually tests for classes in kcoreaddons, except kurltest (easy)|Anne-Marie Mahfouf}}<br />
<br />
{{FeatureDone|"cp kurlmimetest.cpp kurlmimedatatest.cpp" and port the second one to KUrlMimeData (in order to test both the deprecated API and the new API). After that, move the old one (kurlmimetest) to kde4support. (normal)|Lambert Clara}}<br />
<br />
{{FeatureDone|Port kcmdlineargs from KUrl to QUrl, then move KUrl out of kcoreaddons, and into kdecore for now, final destination will be kde4support. (easy)|Matt Williams}}<br />
<br />
{{FeatureInProgress|Port kdelibs from KProcess to QProcess (except kpty) (easy). Warning: Need to port some functionnality to Qt 5|Martin Sandsmark}}<br />
<br />
{{FeatureDone|Update qmimetype in kdelibs from the one soon merged to Qt5, port all of kdelibs to the API changes. (normal)|David Faure}}<br />
<br />
{{FeatureDone|Create a staging/kconfig framework out of kdecore/config + kdecore/kernel/kauthorized*. Code should be ready (no more dependencies on the rest of kdecore). (normal)|David}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KGlobal::config() to KSharedConfig::openConfig(), adjust includes (easy)|Claus Christensen}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KMimeType to QMimeType, see KDE5PORTING.html for details (easy)|David Faure}}<br />
<br />
{{FeatureDone|deprecate KLineEdit::clickMessage, by applying https://git.reviewboard.kde.org/r/101360/diff/#index_header and porting kdelibs (easy and quick)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move KDialog saveDialogSize+restoreDialogSize to static methods taking a QDialog.|Benjamin Port}}<br />
<br />
<br />
{{FeatureInProgress|Finish deprecating methods marked as @deprecated (add macro+ifdef, ensure kdelibs doesn't use).|Benjamin Port}}<br />
<br />
<br />
{{FeatureDone|Move KDialogQueue into separate files.|Benjamin Port}}<br />
<br />
{{FeatureDone|Port all of kdelibs (except kde*support and classes aimed for tier4) from KDialog to QDialog|Kevin Ottens}}<br />
<br />
{{FeatureDone|Port from KGlobalSettings::desktopGeometry to QApplication::desktop()->screenGeometry (very easy)|Stephen Kelly}}<br />
<br />
{{FeatureDone|extract KProtocolInfo out of ksycoca, making it simply read from installed files on demand. (normal)|David Faure}}<br />
<br />
{{FeatureDone|move KProtocolInfo to KIO, requires to split out its unittests from kmimetypetest, and to somehow sort out the call to KProtocolInfo inside kmimetype (normal)|David Faure}}<br />
<br />
{{FeatureDone|when gpgmepp is not found, make plasma only skip the Signature class, rather than skipping all of plasma (easy)|David Faure}}<br />
<br />
{{FeatureDone|One of the things we need to remove is all of the use of the Q_WS_* defines. (easy)<br />
<br />
git grep Q_WS_<br />
<br />
Some of them should be ported to a Q_OS_ define (eg, some of Q_WS_WIN should <br />
be ported to Q_OS_WIN), but *not all of them*, so this can't just be changed <br />
with a script. It should be done manually. Some of them need to be ported to <br />
QPA (lighthouse) in some way.|Kevin Ottens}}<br />
<br />
For a walk through example, see [http://thread.gmane.org/gmane.comp.kde.devel.frameworks/319/focus=328 this thread]<br />
<br />
{{FeatureInProgress|Another thing that should be done is using Find packages from ECM or CMake. (normal)<br />
<br />
For example, run 'git grep find_package' in tier1/solid. Some of the results are provided by CMake, and some come from the local kdelibs/cmake/modules folder. The kdelibs/cmake/modules folder should not need to be used. For example find_package(Flex) in solid should be replaced with find_package(FLEX) which is provided by CMake.<br />
<br />
The goal is to be able to run <br />
<br />
cd tier1/solid && mkdir build && cd build && cmake .. && make<br />
<br />
for each framework. <br />
<br />
This is already possible with the itemmodels framework.<br />
<br />
It also works with solid, because the packages it searches for are optional <br />
and the FindFoo.cmake files are not found.|George Goldberg (grundleborg)<br />
<br />
Frameworks Done:<br />
*tier1/itemmodels (except for autotests)<br />
*tier1/karchive<br />
*tier1/kcodecs<br />
*tier1/kcoreaddons<br />
*tier1/kdbusaddons<br />
*tier1/kideltime<br />
*tier1/kjs (*)<br />
*tier1/kplotting<br />
*tier1/kwidgetsaddons<br />
*tier1/kwindowsystem<br />
*tier1/solid (*)<br />
*tier1/sonnet (*)<br />
*tier1/threadweaver<br />
<br />
*tier2/kauth (*)<br />
*'''tier2/kconfig''' has problems building. need to resolve these first.<br />
<br />
(*) Means that there are still FindFOO.cmake files in the framework's directory.<br />
}}<br />
<br />
{{FeatureTodo|Find out what should be part of the link interface and what should not be. (normal but long), [[Frameworks/Epics/kdelibs_cleanups/link_private_details|details...]]|?}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC where the Qt4 API is sufficient|Albert Astals Cid}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC needs Qt 5.1 changes|?}}<br />
<br />
{{FeatureTodo|Porting in [[KDE_Core/KLocale/Frameworks]]|?}}<br />
<br />
{{FeatureTodo|After the above, removing kglobal.h from files where it is no longer<br />
used (simplifying the task of creating a framework for the people who<br />
don't realize that that needs to be done, and reducing the build fixes<br />
that are required because they don't do a clean build after moving stuff<br />
around and changing include_directories)|?}}<br />
<br />
{{FeatureInProgress|Make the code portable: port away from kde_file.h, i.e. from KDE::open/rename/stat/lstat/access/... to QFile|Martin Klapetek}}<br />
<br />
{{FeatureTodo|Investigate to what extent our use of X11 API and KWindowSystem can be replaced with QPA (hard)<br />
<br />
Some work started on adding the accessors required for this to the QPA classes.<br />
https://codereview.qt-project.org/#change,26714<br />
<br />
More generally KWindowSystem should probably not be used anywhere in kdelibs.<br />
<br />
|Martin Graesslin}}<br />
<br />
{{FeatureDone|KDEGuiAddons should be renamed and maybe repurposed|Kevin Ottens}}<br />
<br />
{{FeatureDone|qWarning << QUrl::errorString() rather than QMessageBox with QUrl::toString() (which is empty) to the user when the URL is invalid (grep for "Invalid URL"?)|Martin Klapetek}}<br />
<br />
{{FeatureDone|kdeui/colors/kcolorhelpers_p.h has at least a copy in <br />
kdeguiaddons, and perhaps another in kcolorwidgets. Resolve that.|Kévin Ottens}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KIcon to QIcon / KDE:::icon(), then move KIcon out (easy)|David Faure}}<br />
<br />
{{FeatureTodo|KGlobalSettings is initalized by KApplication. Find out if any parts of it work without that, and split it into parts that work without the initialization and parts that don't.|?}}<br />
<br />
{{FeatureTodo|KDE SC wide cleanup: replace X-KDE-StartupNotify with StartupNotify in all .desktop files, it was standardized a very long time ago|?}}<br />
<br />
{{FeatureDone|Port away from and deprecate KHBox/KVBox|Albert Astals Cid}}<br />
<br />
{{FeatureTodo|Find out if KGuiAddons should be deprecated or get an upstream equivalent. The real value is in KStandardGuiItem. See if it can be redesigned in the alternative|?}}<br />
<br />
{{FeatureDone|Port KStandardAction from KAction to QAction|Kevin Ottens}}<br />
<br />
{{FeatureInProgress|Move KTabBar to kde4support and port users in kdelibs to QTabbar. preferably KTabWidget should go the same way, but needs a feature in Qt (see the qt5.1 epic)|Kevin Kin-Foo}}<br />
<br />
{{FeatureInProgress|Use tr() again (rather than QCoreApplication::translate with empty context) in all tier1+tier2+staging frameworks (except the ones which will go to tier3, they can use i18n)|George Goldberg (grundleborg)<br />
<br />
done, however there are some incorrect uses of QObject::tr() still floating around which need fixing in a later patch.}}<br />
<br />
{{FeatureDone|Move KDialog to kde4support (once all other KDialog related cleanups are done)|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KRestrictedLine to kde4support|Kevin Kin-Foo}}<br />
<br />
{{FeatureDone|Move KDialogButtonBox to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Move KDoubleValidator to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Move KListWidget to kde4support (replace uses with QListWidget)|Martin Klapetek}}<br />
<br />
{{FeatureDone|Move KMenu to kde4support (once QMenu supports title items and keyboard navigation)|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KPushButton DnD support to an event filter|Kevin Ottens}}<br />
<br />
{{FeatureDone|Once KPushButton DnD and delayed menu support are out, move KPushButton to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KSplashScreen to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Replace KUndoStack with two methods in a namespace|Tobias Koenig}}<br />
<br />
{{FeatureDone|Move KShortcut in kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move all global shortcut facilities of KAction in KGlobalAccel (which would then register QActions)|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move all gesture facilities of KAction in KGestureMap (which would then register QActions)|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move KAction::event to an event filter, see how to make it available to all QAction instances when using the consistency framework|Kevin Ottens}}<br />
<br />
{{FeatureDone|Once KAction has no original feature left, move it to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::*Timestamp methods go to a new QObject subclass in tier4/kinterprocesswindowing|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::sessionConfig go to kconfig-gui, probably has a static method there|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::*startupId go with KStartupInfo to kwindowsystem|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KApplication to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KStatusBar to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KColorDialog to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Split KStatusNotifierItem, having the pure data part on one side and the QMenu deps in a subclass<br />
apol: why? is the plan to port away from QtWidgets? If so KMessageBox should be removed as well. Also we need more info to know how we want to feed the actions instead| ?}}<br />
<br />
{{FeatureDone|Move KMenuBar to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KToolBar to xmlgui|Miquel i Aleix}}<br />
<br />
{{FeatureDone|Move KMainWindow to xmlgui|Miquel i Aleix}}<br />
<br />
{{FeatureTodo|Move KInputDialog to kde4support once its features are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Move KDateTime to kde4support once its features are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureDone|Split WId methods of KMessageBox into tier4/kinterprocesswindowing|Valentin Rusu}}<br />
<br />
{{FeatureDone|Split queued methods of KMessageBox into kde4support|Valentin Rusu}}<br />
<br />
{{FeatureInProgress|Implement queueing directly in KDialogJobUiDelegate|Valentin Rusu}}<br />
<br />
{{FeatureDone|Add a KMessageBoxDontAskAgainInterface, with a QHash based private implementation in KMessageBox|David Faure}}<br />
<br />
{{FeatureDone|Add a setter to KMessageBox in order to change the KMessageBoxDontAskAgainInterface implementation used by KMessageBox and an implementation set in our FrameworkIntegrationPlugin which uses KConfig|David Faure}}<br />
<br />
{{FeatureDone|Move rest of KMessageBox to kwidgets|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move KProgressDialog to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Move KFileDialog to kde4support once the QUrl static methods are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Move KTextEdit to tier4/consistency|?}}<br />
<br />
{{FeatureTodo|Move KTextBrowser to kde4support once its features are in QTextBrowser (see 5.1 epic)|?}}<br />
<br />
{{FeatureInProgress|Have KMessageWidget look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|Àlex Fiestas}}<br />
<br />
{{FeatureInProgress|Have KMainWindow look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|Àlex Fiestas}}<br />
<br />
{{FeatureDone|Move KFadeWidgetEffect to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Have KIO widgets look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Have the polish() call of KStyle force the default fonts on widgets (font are picked in the same way KGlobalSettings did)|?}}<br />
<br />
{{FeatureTodo|Move KGlobalSettings to kde4support| ?}}<br />
<br />
{{FeatureInProgress|Implement KStyle::styleHint() to support the opaqueResize and animate flags (not existing yet, see 5.1 epic) value of those flags picked like KGlobalSettings did|Àlex Fiestas}}<br />
<br />
{{FeatureTodo|Move KStyle to tier4/consistency|?}}<br />
<br />
{{FeatureTodo|Import QCommandLineArguments from gitorious into libkdeqt5staging|Probably too early, implementation needs to be finished first}}<br />
<br />
{{FeatureDone|Use Q_COREAPP_STARTUP_FUNCTION to initialize KCrash|David Faure}}<br />
<br />
{{FeatureDone|Use Q_COREAPP_STARTUP_FUNCTION to initialize KCheckAccelerators|David Faure}}<br />
<br />
{{FeatureTodo|kconf_update links against kde4core libs as it uses K4AboutData. Port it away from kde4-only classes. |?}}<br />
<br />
{{FeatureTodo|Add the necessary to the integration plugin so that calling QDesktopServices::openUrl("help:/") is exactly the same as using KHelpClient::invokeHelp()|?}}<br />
<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Frameworks/Epics/kdelibs_cleanups&diff=31319Frameworks/Epics/kdelibs cleanups2013-04-26T20:25:42Z<p>Grundleborg: /* Cleaning up kdelibs */ tier 2 frameworks cmake find_package check done</p>
<hr />
<div>= Cleaning up kdelibs =<br />
<br />
Next to the other efforts for kdelibs modularization, there's also some cleanup tasks which needs to be done accross the whole kdelibs codebase. Tasks in here are probably more suitable for short term, bite sized involvement.<br />
<br />
'''Note''': For most of those tasks we try to put an estimation of the difficulty can be: easy, normal, hard (somewhat like in video games). ;-)<br />
<br />
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width:100%;"<br />
|- style="background: #ececec; white-space:nowrap;"<br />
! Status<br />
! Description<br />
! width=250 | Contact<br />
|-<br />
{{FeatureDone|remove kglobal.h include from staging/kwidgets/src/icons/kiconloader.h, fix compilation by adding the header where necessary (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move ktypelist.h from kdecore/util to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kentrymaptest from kdecore/tests to kconfig/autotests (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kascii and kasciitest to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|Port away from KGlobalSettings::singleClick() (easy)|Dominik Haumann}}<br />
{{FeatureDone|#cmakedefine -> #cmakedefine01, #ifdef -> #if, in order to catch missing includes (easy)|Nicolas Lécureuil}}<br />
{{FeatureDone|Port from KCmdLineArgs+KApp to QApp+setApplicationName in all unittests that don't use args (easy)|Jeremy Whiting}}<br />
{{FeatureInProgress|kio/netaccess.h: there are some "TODOs" about deprecating most methods in favour of job+exec (TODO: compare with synchronousRun) (normal)|Àlex Fiestas}}<br />
<br />
<br />
{{FeatureDone|Fix kfileplacesmodeltest (normal)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move to kcoreaddons the tests in kdecore/tests that are actually tests for classes in kcoreaddons, except kurltest (easy)|Anne-Marie Mahfouf}}<br />
<br />
{{FeatureDone|"cp kurlmimetest.cpp kurlmimedatatest.cpp" and port the second one to KUrlMimeData (in order to test both the deprecated API and the new API). After that, move the old one (kurlmimetest) to kde4support. (normal)|Lambert Clara}}<br />
<br />
{{FeatureDone|Port kcmdlineargs from KUrl to QUrl, then move KUrl out of kcoreaddons, and into kdecore for now, final destination will be kde4support. (easy)|Matt Williams}}<br />
<br />
{{FeatureInProgress|Port kdelibs from KProcess to QProcess (except kpty) (easy). Warning: Need to port some functionnality to Qt 5|Martin Sandsmark}}<br />
<br />
{{FeatureDone|Update qmimetype in kdelibs from the one soon merged to Qt5, port all of kdelibs to the API changes. (normal)|David Faure}}<br />
<br />
{{FeatureDone|Create a staging/kconfig framework out of kdecore/config + kdecore/kernel/kauthorized*. Code should be ready (no more dependencies on the rest of kdecore). (normal)|David}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KGlobal::config() to KSharedConfig::openConfig(), adjust includes (easy)|Claus Christensen}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KMimeType to QMimeType, see KDE5PORTING.html for details (easy)|David Faure}}<br />
<br />
{{FeatureDone|deprecate KLineEdit::clickMessage, by applying https://git.reviewboard.kde.org/r/101360/diff/#index_header and porting kdelibs (easy and quick)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move KDialog saveDialogSize+restoreDialogSize to static methods taking a QDialog.|Benjamin Port}}<br />
<br />
<br />
{{FeatureInProgress|Finish deprecating methods marked as @deprecated (add macro+ifdef, ensure kdelibs doesn't use).|Benjamin Port}}<br />
<br />
<br />
{{FeatureDone|Move KDialogQueue into separate files.|Benjamin Port}}<br />
<br />
{{FeatureDone|Port all of kdelibs (except kde*support and classes aimed for tier4) from KDialog to QDialog|Kevin Ottens}}<br />
<br />
{{FeatureDone|Port from KGlobalSettings::desktopGeometry to QApplication::desktop()->screenGeometry (very easy)|Stephen Kelly}}<br />
<br />
{{FeatureDone|extract KProtocolInfo out of ksycoca, making it simply read from installed files on demand. (normal)|David Faure}}<br />
<br />
{{FeatureDone|move KProtocolInfo to KIO, requires to split out its unittests from kmimetypetest, and to somehow sort out the call to KProtocolInfo inside kmimetype (normal)|David Faure}}<br />
<br />
{{FeatureDone|when gpgmepp is not found, make plasma only skip the Signature class, rather than skipping all of plasma (easy)|David Faure}}<br />
<br />
{{FeatureDone|One of the things we need to remove is all of the use of the Q_WS_* defines. (easy)<br />
<br />
git grep Q_WS_<br />
<br />
Some of them should be ported to a Q_OS_ define (eg, some of Q_WS_WIN should <br />
be ported to Q_OS_WIN), but *not all of them*, so this can't just be changed <br />
with a script. It should be done manually. Some of them need to be ported to <br />
QPA (lighthouse) in some way.|Kevin Ottens}}<br />
<br />
For a walk through example, see [http://thread.gmane.org/gmane.comp.kde.devel.frameworks/319/focus=328 this thread]<br />
<br />
{{FeatureInProgress|Another thing that should be done is using Find packages from ECM or CMake. (normal)<br />
<br />
For example, run 'git grep find_package' in tier1/solid. Some of the results are provided by CMake, and some come from the local kdelibs/cmake/modules folder. The kdelibs/cmake/modules folder should not need to be used. For example find_package(Flex) in solid should be replaced with find_package(FLEX) which is provided by CMake.<br />
<br />
The goal is to be able to run <br />
<br />
cd tier1/solid && mkdir build && cd build && cmake .. && make<br />
<br />
for each framework. <br />
<br />
This is already possible with the itemmodels framework.<br />
<br />
It also works with solid, because the packages it searches for are optional <br />
and the FindFoo.cmake files are not found.|George Goldberg (grundleborg)<br />
<br />
Frameworks Done:<br />
*tier1/itemmodels (except for autotests)<br />
*tier1/karchive<br />
*tier1/kcodecs<br />
*tier1/kcoreaddons<br />
*tier1/kdbusaddons<br />
*tier1/kideltime<br />
*tier1/kjs (*)<br />
*tier1/kplotting<br />
*tier1/kwidgetsaddons<br />
*tier1/kwindowsystem<br />
*tier1/solid (*)<br />
*tier1/sonnet (*)<br />
*tier1/threadweaver<br />
<br />
*tier2/kauth (*)<br />
*'''tier2/kconfig''' has problems building. need to resolve these first.<br />
<br />
(*) Means that there are still FindFOO.cmake files in the framework's directory.<br />
}}<br />
<br />
{{FeatureTodo|Find out what should be part of the link interface and what should not be. (normal but long), [[Frameworks/Epics/kdelibs_cleanups/link_private_details|details...]]|?}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC where the Qt4 API is sufficient|Albert Astals Cid}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC needs Qt 5.1 changes|?}}<br />
<br />
{{FeatureTodo|Porting in [[KDE_Core/KLocale/Frameworks]]|?}}<br />
<br />
{{FeatureTodo|After the above, removing kglobal.h from files where it is no longer<br />
used (simplifying the task of creating a framework for the people who<br />
don't realize that that needs to be done, and reducing the build fixes<br />
that are required because they don't do a clean build after moving stuff<br />
around and changing include_directories)|?}}<br />
<br />
{{FeatureInProgress|Make the code portable: port away from kde_file.h, i.e. from KDE::open/rename/stat/lstat/access/... to QFile|Martin Klapetek}}<br />
<br />
{{FeatureTodo|Investigate to what extent our use of X11 API and KWindowSystem can be replaced with QPA (hard)<br />
<br />
Some work started on adding the accessors required for this to the QPA classes.<br />
https://codereview.qt-project.org/#change,26714<br />
|?}}<br />
<br />
{{FeatureDone|KDEGuiAddons should be renamed and maybe repurposed|Kevin Ottens}}<br />
<br />
{{FeatureDone|qWarning << QUrl::errorString() rather than QMessageBox with QUrl::toString() (which is empty) to the user when the URL is invalid (grep for "Invalid URL"?)|Martin Klapetek}}<br />
<br />
{{FeatureDone|kdeui/colors/kcolorhelpers_p.h has at least a copy in <br />
kdeguiaddons, and perhaps another in kcolorwidgets. Resolve that.|Kévin Ottens}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KIcon to QIcon / KDE:::icon(), then move KIcon out (easy)|David Faure}}<br />
<br />
{{FeatureTodo|KGlobalSettings is initalized by KApplication. Find out if any parts of it work without that, and split it into parts that work without the initialization and parts that don't.|?}}<br />
<br />
{{FeatureTodo|KDE SC wide cleanup: replace X-KDE-StartupNotify with StartupNotify in all .desktop files, it was standardized a very long time ago|?}}<br />
<br />
{{FeatureDone|Port away from and deprecate KHBox/KVBox|Albert Astals Cid}}<br />
<br />
{{FeatureTodo|Find out if KGuiAddons should be deprecated or get an upstream equivalent. The real value is in KStandardGuiItem. See if it can be redesigned in the alternative|?}}<br />
<br />
{{FeatureDone|Port KStandardAction from KAction to QAction|Kevin Ottens}}<br />
<br />
{{FeatureInProgress|Move KTabBar to kde4support and port users in kdelibs to QTabbar. preferably KTabWidget should go the same way, but needs a feature in Qt (see the qt5.1 epic)|Kevin Kin-Foo}}<br />
<br />
{{FeatureInProgress|Use tr() again (rather than QCoreApplication::translate with empty context) in all tier1+tier2+staging frameworks (except the ones which will go to tier3, they can use i18n)|George Goldberg (grundleborg) did the initial conversion to translate()...}}<br />
<br />
{{FeatureDone|Move KDialog to kde4support (once all other KDialog related cleanups are done)|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KRestrictedLine to kde4support|Kevin Kin-Foo}}<br />
<br />
{{FeatureDone|Move KDialogButtonBox to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Move KDoubleValidator to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Move KListWidget to kde4support (replace uses with QListWidget)|Martin Klapetek}}<br />
<br />
{{FeatureDone|Move KMenu to kde4support (once QMenu supports title items and keyboard navigation)|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KPushButton DnD support to an event filter|Kevin Ottens}}<br />
<br />
{{FeatureDone|Once KPushButton DnD and delayed menu support are out, move KPushButton to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KSplashScreen to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Replace KUndoStack with two methods in a namespace|Tobias Koenig}}<br />
<br />
{{FeatureDone|Move KShortcut in kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move all global shortcut facilities of KAction in KGlobalAccel (which would then register QActions)|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move all gesture facilities of KAction in KGestureMap (which would then register QActions)|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move KAction::event to an event filter, see how to make it available to all QAction instances when using the consistency framework|Kevin Ottens}}<br />
<br />
{{FeatureDone|Once KAction has no original feature left, move it to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::*Timestamp methods go to a new QObject subclass in tier4/kinterprocesswindowing|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::sessionConfig go to kconfig-gui, probably has a static method there|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::*startupId go with KStartupInfo to kwindowsystem|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KApplication to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KStatusBar to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KColorDialog to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Split KStatusNotifierItem, having the pure data part on one side and the QMenu deps in a subclass<br />
apol: why? is the plan to port away from QtWidgets? If so KMessageBox should be removed as well. Also we need more info to know how we want to feed the actions instead| ?}}<br />
<br />
{{FeatureDone|Move KMenuBar to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KToolBar to xmlgui|Miquel i Aleix}}<br />
<br />
{{FeatureDone|Move KMainWindow to xmlgui|Miquel i Aleix}}<br />
<br />
{{FeatureTodo|Move KInputDialog to kde4support once its features are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Move KDateTime to kde4support once its features are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureDone|Split WId methods of KMessageBox into tier4/kinterprocesswindowing|Valentin Rusu}}<br />
<br />
{{FeatureDone|Split queued methods of KMessageBox into kde4support|Valentin Rusu}}<br />
<br />
{{FeatureInProgress|Implement queueing directly in KDialogJobUiDelegate|Valentin Rusu}}<br />
<br />
{{FeatureDone|Add a KMessageBoxDontAskAgainInterface, with a QHash based private implementation in KMessageBox|David Faure}}<br />
<br />
{{FeatureDone|Add a setter to KMessageBox in order to change the KMessageBoxDontAskAgainInterface implementation used by KMessageBox and an implementation set in our FrameworkIntegrationPlugin which uses KConfig|David Faure}}<br />
<br />
{{FeatureDone|Move rest of KMessageBox to kwidgets|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move KProgressDialog to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Move KFileDialog to kde4support once the QUrl static methods are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Move KTextEdit to tier4/consistency|?}}<br />
<br />
{{FeatureTodo|Move KTextBrowser to kde4support once its features are in QTextBrowser (see 5.1 epic)|?}}<br />
<br />
{{FeatureInProgress|Have KMessageWidget look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|Àlex Fiestas}}<br />
<br />
{{FeatureInProgress|Have KMainWindow look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|Àlex Fiestas}}<br />
<br />
{{FeatureDone|Move KFadeWidgetEffect to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Have KIO widgets look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Have the polish() call of KStyle force the default fonts on widgets (font are picked in the same way KGlobalSettings did)|?}}<br />
<br />
{{FeatureTodo|Move KGlobalSettings to kde4support| ?}}<br />
<br />
{{FeatureInProgress|Implement KStyle::styleHint() to support the opaqueResize and animate flags (not existing yet, see 5.1 epic) value of those flags picked like KGlobalSettings did|Àlex Fiestas}}<br />
<br />
{{FeatureTodo|Move KStyle to tier4/consistency|?}}<br />
<br />
{{FeatureTodo|Import QCommandLineArguments from gitorious into libkdeqt5staging|Probably too early, implementation needs to be finished first}}<br />
<br />
{{FeatureDone|Use Q_COREAPP_STARTUP_FUNCTION to initialize KCrash|David Faure}}<br />
<br />
{{FeatureDone|Use Q_COREAPP_STARTUP_FUNCTION to initialize KCheckAccelerators|David Faure}}<br />
<br />
{{FeatureTodo|Get rid of knotifyd, move the features in process for knotification* classes|?}}<br />
<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Frameworks/Epics/kdelibs_cleanups&diff=31318Frameworks/Epics/kdelibs cleanups2013-04-26T20:20:20Z<p>Grundleborg: tier1 cmake find_package files checked</p>
<hr />
<div>= Cleaning up kdelibs =<br />
<br />
Next to the other efforts for kdelibs modularization, there's also some cleanup tasks which needs to be done accross the whole kdelibs codebase. Tasks in here are probably more suitable for short term, bite sized involvement.<br />
<br />
'''Note''': For most of those tasks we try to put an estimation of the difficulty can be: easy, normal, hard (somewhat like in video games). ;-)<br />
<br />
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width:100%;"<br />
|- style="background: #ececec; white-space:nowrap;"<br />
! Status<br />
! Description<br />
! width=250 | Contact<br />
|-<br />
{{FeatureDone|remove kglobal.h include from staging/kwidgets/src/icons/kiconloader.h, fix compilation by adding the header where necessary (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move ktypelist.h from kdecore/util to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kentrymaptest from kdecore/tests to kconfig/autotests (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kascii and kasciitest to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|Port away from KGlobalSettings::singleClick() (easy)|Dominik Haumann}}<br />
{{FeatureDone|#cmakedefine -> #cmakedefine01, #ifdef -> #if, in order to catch missing includes (easy)|Nicolas Lécureuil}}<br />
{{FeatureDone|Port from KCmdLineArgs+KApp to QApp+setApplicationName in all unittests that don't use args (easy)|Jeremy Whiting}}<br />
{{FeatureInProgress|kio/netaccess.h: there are some "TODOs" about deprecating most methods in favour of job+exec (TODO: compare with synchronousRun) (normal)|Àlex Fiestas}}<br />
<br />
<br />
{{FeatureDone|Fix kfileplacesmodeltest (normal)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move to kcoreaddons the tests in kdecore/tests that are actually tests for classes in kcoreaddons, except kurltest (easy)|Anne-Marie Mahfouf}}<br />
<br />
{{FeatureDone|"cp kurlmimetest.cpp kurlmimedatatest.cpp" and port the second one to KUrlMimeData (in order to test both the deprecated API and the new API). After that, move the old one (kurlmimetest) to kde4support. (normal)|Lambert Clara}}<br />
<br />
{{FeatureDone|Port kcmdlineargs from KUrl to QUrl, then move KUrl out of kcoreaddons, and into kdecore for now, final destination will be kde4support. (easy)|Matt Williams}}<br />
<br />
{{FeatureInProgress|Port kdelibs from KProcess to QProcess (except kpty) (easy). Warning: Need to port some functionnality to Qt 5|Martin Sandsmark}}<br />
<br />
{{FeatureDone|Update qmimetype in kdelibs from the one soon merged to Qt5, port all of kdelibs to the API changes. (normal)|David Faure}}<br />
<br />
{{FeatureDone|Create a staging/kconfig framework out of kdecore/config + kdecore/kernel/kauthorized*. Code should be ready (no more dependencies on the rest of kdecore). (normal)|David}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KGlobal::config() to KSharedConfig::openConfig(), adjust includes (easy)|Claus Christensen}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KMimeType to QMimeType, see KDE5PORTING.html for details (easy)|David Faure}}<br />
<br />
{{FeatureDone|deprecate KLineEdit::clickMessage, by applying https://git.reviewboard.kde.org/r/101360/diff/#index_header and porting kdelibs (easy and quick)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move KDialog saveDialogSize+restoreDialogSize to static methods taking a QDialog.|Benjamin Port}}<br />
<br />
<br />
{{FeatureInProgress|Finish deprecating methods marked as @deprecated (add macro+ifdef, ensure kdelibs doesn't use).|Benjamin Port}}<br />
<br />
<br />
{{FeatureDone|Move KDialogQueue into separate files.|Benjamin Port}}<br />
<br />
{{FeatureDone|Port all of kdelibs (except kde*support and classes aimed for tier4) from KDialog to QDialog|Kevin Ottens}}<br />
<br />
{{FeatureDone|Port from KGlobalSettings::desktopGeometry to QApplication::desktop()->screenGeometry (very easy)|Stephen Kelly}}<br />
<br />
{{FeatureDone|extract KProtocolInfo out of ksycoca, making it simply read from installed files on demand. (normal)|David Faure}}<br />
<br />
{{FeatureDone|move KProtocolInfo to KIO, requires to split out its unittests from kmimetypetest, and to somehow sort out the call to KProtocolInfo inside kmimetype (normal)|David Faure}}<br />
<br />
{{FeatureDone|when gpgmepp is not found, make plasma only skip the Signature class, rather than skipping all of plasma (easy)|David Faure}}<br />
<br />
{{FeatureDone|One of the things we need to remove is all of the use of the Q_WS_* defines. (easy)<br />
<br />
git grep Q_WS_<br />
<br />
Some of them should be ported to a Q_OS_ define (eg, some of Q_WS_WIN should <br />
be ported to Q_OS_WIN), but *not all of them*, so this can't just be changed <br />
with a script. It should be done manually. Some of them need to be ported to <br />
QPA (lighthouse) in some way.|Kevin Ottens}}<br />
<br />
For a walk through example, see [http://thread.gmane.org/gmane.comp.kde.devel.frameworks/319/focus=328 this thread]<br />
<br />
{{FeatureInProgress|Another thing that should be done is using Find packages from ECM or CMake. (normal)<br />
<br />
For example, run 'git grep find_package' in tier1/solid. Some of the results are provided by CMake, and some come from the local kdelibs/cmake/modules folder. The kdelibs/cmake/modules folder should not need to be used. For example find_package(Flex) in solid should be replaced with find_package(FLEX) which is provided by CMake.<br />
<br />
The goal is to be able to run <br />
<br />
cd tier1/solid && mkdir build && cd build && cmake .. && make<br />
<br />
for each framework. <br />
<br />
This is already possible with the itemmodels framework.<br />
<br />
It also works with solid, because the packages it searches for are optional <br />
and the FindFoo.cmake files are not found.|George Goldberg (grundleborg)<br />
<br />
Tier 1 Done: <br />
*tier1/itemmodels (except for autotests)<br />
*tier1/karchive<br />
*tier1/kcodecs<br />
*tier1/kcoreaddons<br />
*tier1/kdbusaddons<br />
*tier1/kideltime<br />
*tier1/kjs (*)<br />
*tier1/kplotting<br />
*tier1/kwidgetsaddons<br />
*tier1/kwindowsystem<br />
*tier1/solid (*)<br />
*tier1/sonnet (*)<br />
*tier1/threadweaver<br />
<br />
(*) Means that there are still FindFOO.cmake files in the framework's directory.<br />
}}<br />
<br />
{{FeatureTodo|Find out what should be part of the link interface and what should not be. (normal but long), [[Frameworks/Epics/kdelibs_cleanups/link_private_details|details...]]|?}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC where the Qt4 API is sufficient|Albert Astals Cid}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC needs Qt 5.1 changes|?}}<br />
<br />
{{FeatureTodo|Porting in [[KDE_Core/KLocale/Frameworks]]|?}}<br />
<br />
{{FeatureTodo|After the above, removing kglobal.h from files where it is no longer<br />
used (simplifying the task of creating a framework for the people who<br />
don't realize that that needs to be done, and reducing the build fixes<br />
that are required because they don't do a clean build after moving stuff<br />
around and changing include_directories)|?}}<br />
<br />
{{FeatureInProgress|Make the code portable: port away from kde_file.h, i.e. from KDE::open/rename/stat/lstat/access/... to QFile|Martin Klapetek}}<br />
<br />
{{FeatureTodo|Investigate to what extent our use of X11 API and KWindowSystem can be replaced with QPA (hard)<br />
<br />
Some work started on adding the accessors required for this to the QPA classes.<br />
https://codereview.qt-project.org/#change,26714<br />
|?}}<br />
<br />
{{FeatureDone|KDEGuiAddons should be renamed and maybe repurposed|Kevin Ottens}}<br />
<br />
{{FeatureDone|qWarning << QUrl::errorString() rather than QMessageBox with QUrl::toString() (which is empty) to the user when the URL is invalid (grep for "Invalid URL"?)|Martin Klapetek}}<br />
<br />
{{FeatureDone|kdeui/colors/kcolorhelpers_p.h has at least a copy in <br />
kdeguiaddons, and perhaps another in kcolorwidgets. Resolve that.|Kévin Ottens}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KIcon to QIcon / KDE:::icon(), then move KIcon out (easy)|David Faure}}<br />
<br />
{{FeatureTodo|KGlobalSettings is initalized by KApplication. Find out if any parts of it work without that, and split it into parts that work without the initialization and parts that don't.|?}}<br />
<br />
{{FeatureTodo|KDE SC wide cleanup: replace X-KDE-StartupNotify with StartupNotify in all .desktop files, it was standardized a very long time ago|?}}<br />
<br />
{{FeatureDone|Port away from and deprecate KHBox/KVBox|Albert Astals Cid}}<br />
<br />
{{FeatureTodo|Find out if KGuiAddons should be deprecated or get an upstream equivalent. The real value is in KStandardGuiItem. See if it can be redesigned in the alternative|?}}<br />
<br />
{{FeatureDone|Port KStandardAction from KAction to QAction|Kevin Ottens}}<br />
<br />
{{FeatureInProgress|Move KTabBar to kde4support and port users in kdelibs to QTabbar. preferably KTabWidget should go the same way, but needs a feature in Qt (see the qt5.1 epic)|Kevin Kin-Foo}}<br />
<br />
{{FeatureInProgress|Use tr() again (rather than QCoreApplication::translate with empty context) in all tier1+tier2+staging frameworks (except the ones which will go to tier3, they can use i18n)|George Goldberg (grundleborg) did the initial conversion to translate()...}}<br />
<br />
{{FeatureDone|Move KDialog to kde4support (once all other KDialog related cleanups are done)|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KRestrictedLine to kde4support|Kevin Kin-Foo}}<br />
<br />
{{FeatureDone|Move KDialogButtonBox to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Move KDoubleValidator to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Move KListWidget to kde4support (replace uses with QListWidget)|Martin Klapetek}}<br />
<br />
{{FeatureDone|Move KMenu to kde4support (once QMenu supports title items and keyboard navigation)|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KPushButton DnD support to an event filter|Kevin Ottens}}<br />
<br />
{{FeatureDone|Once KPushButton DnD and delayed menu support are out, move KPushButton to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KSplashScreen to kde4support|David Faure}}<br />
<br />
{{FeatureDone|Replace KUndoStack with two methods in a namespace|Tobias Koenig}}<br />
<br />
{{FeatureDone|Move KShortcut in kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move all global shortcut facilities of KAction in KGlobalAccel (which would then register QActions)|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move all gesture facilities of KAction in KGestureMap (which would then register QActions)|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move KAction::event to an event filter, see how to make it available to all QAction instances when using the consistency framework|Kevin Ottens}}<br />
<br />
{{FeatureDone|Once KAction has no original feature left, move it to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::*Timestamp methods go to a new QObject subclass in tier4/kinterprocesswindowing|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::sessionConfig go to kconfig-gui, probably has a static method there|Kevin Ottens}}<br />
<br />
{{FeatureDone|KApplication::*startupId go with KStartupInfo to kwindowsystem|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KApplication to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KStatusBar to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KColorDialog to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Split KStatusNotifierItem, having the pure data part on one side and the QMenu deps in a subclass<br />
apol: why? is the plan to port away from QtWidgets? If so KMessageBox should be removed as well. Also we need more info to know how we want to feed the actions instead| ?}}<br />
<br />
{{FeatureDone|Move KMenuBar to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureDone|Move KToolBar to xmlgui|Miquel i Aleix}}<br />
<br />
{{FeatureDone|Move KMainWindow to xmlgui|Miquel i Aleix}}<br />
<br />
{{FeatureTodo|Move KInputDialog to kde4support once its features are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Move KDateTime to kde4support once its features are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureDone|Split WId methods of KMessageBox into tier4/kinterprocesswindowing|Valentin Rusu}}<br />
<br />
{{FeatureDone|Split queued methods of KMessageBox into kde4support|Valentin Rusu}}<br />
<br />
{{FeatureInProgress|Implement queueing directly in KDialogJobUiDelegate|Valentin Rusu}}<br />
<br />
{{FeatureDone|Add a KMessageBoxDontAskAgainInterface, with a QHash based private implementation in KMessageBox|David Faure}}<br />
<br />
{{FeatureDone|Add a setter to KMessageBox in order to change the KMessageBoxDontAskAgainInterface implementation used by KMessageBox and an implementation set in our FrameworkIntegrationPlugin which uses KConfig|David Faure}}<br />
<br />
{{FeatureDone|Move rest of KMessageBox to kwidgets|Valentin Rusu}}<br />
<br />
{{FeatureDone|Move KProgressDialog to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Move KFileDialog to kde4support once the QUrl static methods are in Qt (see the 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Move KTextEdit to tier4/consistency|?}}<br />
<br />
{{FeatureTodo|Move KTextBrowser to kde4support once its features are in QTextBrowser (see 5.1 epic)|?}}<br />
<br />
{{FeatureInProgress|Have KMessageWidget look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|Àlex Fiestas}}<br />
<br />
{{FeatureInProgress|Have KMainWindow look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|Àlex Fiestas}}<br />
<br />
{{FeatureDone|Move KFadeWidgetEffect to kde4support|Kevin Ottens}}<br />
<br />
{{FeatureTodo|Have KIO widgets look at the styleHint() flag to decide to animate or not (not existing yet, see 5.1 epic)|?}}<br />
<br />
{{FeatureTodo|Have the polish() call of KStyle force the default fonts on widgets (font are picked in the same way KGlobalSettings did)|?}}<br />
<br />
{{FeatureTodo|Move KGlobalSettings to kde4support| ?}}<br />
<br />
{{FeatureInProgress|Implement KStyle::styleHint() to support the opaqueResize and animate flags (not existing yet, see 5.1 epic) value of those flags picked like KGlobalSettings did|Àlex Fiestas}}<br />
<br />
{{FeatureTodo|Move KStyle to tier4/consistency|?}}<br />
<br />
{{FeatureTodo|Import QCommandLineArguments from gitorious into libkdeqt5staging|Probably too early, implementation needs to be finished first}}<br />
<br />
{{FeatureDone|Use Q_COREAPP_STARTUP_FUNCTION to initialize KCrash|David Faure}}<br />
<br />
{{FeatureDone|Use Q_COREAPP_STARTUP_FUNCTION to initialize KCheckAccelerators|David Faure}}<br />
<br />
{{FeatureTodo|Get rid of knotifyd, move the features in process for knotification* classes|?}}<br />
<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Frameworks/Epics/kdelibs_cleanups&diff=23486Frameworks/Epics/kdelibs cleanups2012-08-09T11:58:49Z<p>Grundleborg: </p>
<hr />
<div>= Cleaning up kdelibs =<br />
<br />
Next to the other efforts for kdelibs modularization, there's also some cleanup tasks which needs to be done accross the whole kdelibs codebase. Tasks in here are probably more suitable for short term, bite sized involvement.<br />
<br />
'''Note''': For most of those tasks we try to put an estimation of the difficulty can be: easy, normal, hard (somewhat like in video games). ;-)<br />
<br />
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width:100%;"<br />
|- style="background: #ececec; white-space:nowrap;"<br />
! Status<br />
! Description<br />
! width=250 | Contact<br />
|-<br />
{{FeatureDone|remove kglobal.h include from staging/kwidgets/src/icons/kiconloader.h, fix compilation by adding the header where necessary (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move ktypelist.h from kdecore/util to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kentrymaptest from kdecore/tests to kconfig/autotests (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kascii and kasciitest to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|Port away from KGlobalSettings::singleClick() (easy)|Dominik Haumann}}<br />
{{FeatureTodo|#cmakedefine -> #cmakedefine01, #ifdef -> #if, in order to catch missing includes (easy)|Nicolas Lécureuil}}<br />
{{FeatureInProgress|Port from KCmdLineArgs+KApp to QApp+setApplicationName in all unittests that don't use args (easy)|Jeremy Whiting}}<br />
{{FeatureTodo|kio/netaccess.h: there are some "TODOs" about deprecating most methods in favour of job+exec (TODO: compare with synchronousRun) (normal)|?}}<br />
<br />
<br />
{{FeatureDone|Fix kfileplacesmodeltest (normal)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move to kcoreaddons the tests in kdecore/tests that are actually tests for classes in kcoreaddons, except kurltest (easy)|Anne-Marie Mahfouf}}<br />
<br />
{{FeatureDone|"cp kurlmimetest.cpp kurlmimedatatest.cpp" and port the second one to KUrlMimeData (in order to test both the deprecated API and the new API). After that, move the old one (kurlmimetest) to kde4support. (normal)|Lambert Clara}}<br />
<br />
{{FeatureDone|Port kcmdlineargs from KUrl to QUrl, then move KUrl out of kcoreaddons, and into kdecore for now, final destination will be kde4support. (easy)|Matt Williams}}<br />
<br />
{{FeatureTodo|Port kdelibs from KProcess to QProcess (except kpty) (easy). Warning: Need to port some functionnality to Qt 5|Davide Bettio}}<br />
<br />
{{FeatureDone|Update qmimetype in kdelibs from the one soon merged to Qt5, port all of kdelibs to the API changes. (normal)|David Faure}}<br />
<br />
{{FeatureDone|Create a staging/kconfig framework out of kdecore/config + kdecore/kernel/kauthorized*. Code should be ready (no more dependencies on the rest of kdecore). (normal)|David}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KGlobal::config() to KSharedConfig::openConfig(), adjust includes (easy)|Claus Christensen}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KMimeType to QMimeType, see KDE5PORTING.html for details (easy)|David Faure}}<br />
<br />
{{FeatureDone|deprecate KLineEdit::clickMessage, by applying https://git.reviewboard.kde.org/r/101360/diff/#index_header and porting kdelibs (easy and quick)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move KDialog saveDialogSize+restoreDialogSize to static methods taking a QDialog.|Benjamin Port}}<br />
<br />
<br />
{{FeatureInProgress|Finish deprecating methods marked as @deprecated (add macro+ifdef, ensure kdelibs doesn't use).|Benjamin Port}}<br />
<br />
<br />
{{FeatureDone|Move KDialogQueue into separate files.|Benjamin Port}}<br />
<br />
{{FeatureTodo|Import QCommandLineArguments from gitorious into libkdeqt5staging|?}}<br />
<br />
{{FeatureTodo|Port all of kdelibs (except kde*support and classes aimed for tier4) from KDialog to QDialog|Davide Bettio}}<br />
<br />
{{FeatureDone|Port from KGlobalSettings::desktopGeometry to QApplication::desktop()->screenGeometry (very easy)|Stephen Kelly}}<br />
<br />
{{FeatureDone|extract KProtocolInfo out of ksycoca, making it simply read from installed files on demand. (normal)|David Faure}}<br />
<br />
{{FeatureDone|move KProtocolInfo to KIO, requires to split out its unittests from kmimetypetest, and to somehow sort out the call to KProtocolInfo inside kmimetype (normal)|David Faure}}<br />
<br />
{{FeatureDone|when gpgmepp is not found, make plasma only skip the Signature class, rather than skipping all of plasma (easy)|David Faure}}<br />
<br />
{{FeatureDone|One of the things we need to remove is all of the use of the Q_WS_* defines. (easy)<br />
<br />
git grep Q_WS_<br />
<br />
Some of them should be ported to a Q_OS_ define (eg, some of Q_WS_WIN should <br />
be ported to Q_OS_WIN), but *not all of them*, so this can't just be changed <br />
with a script. It should be done manually. Some of them need to be ported to <br />
QPA (lighthouse) in some way.|Kevin Ottens}}<br />
<br />
For a walk through example, see [http://thread.gmane.org/gmane.comp.kde.devel.frameworks/319/focus=328 this thread]<br />
<br />
{{FeatureInProgress|Another thing that should be done is using Find packages from ECM or CMake. (normal)<br />
<br />
For example, run 'git grep find_package' in tier1/solid. Some of the results are provided by CMake, and some come from the local kdelibs/cmake/modules folder. The kdelibs/cmake/modules folder should not need to be used. For example find_package(Flex) in solid should be replaced with find_package(FLEX) which is provided by CMake.<br />
<br />
The goal is to be able to run <br />
<br />
cd tier1/solid && mkdir build && cd build && cmake .. && make<br />
<br />
for each framework. <br />
<br />
This is already possible with the itemmodels framework.<br />
<br />
It also works with solid, because the packages it searches for are optional <br />
and the FindFoo.cmake files are not found.|George Goldberg (grundleborg)}}<br />
<br />
{{FeatureTodo|Find out what should be part of the link interface and what should not be. (normal but long), [[Frameworks/Epics/kdelibs_cleanups/link_private_details|details...]]|?}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC where the Qt4 API is sufficient|Albert Astals Cid}}<br />
{{FeatureTodo|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC needs Qt 5.1 changes|?}}<br />
<br />
{{FeatureTodo|Porting in [[KDE_Core/KLocale/Frameworks]]|?}}<br />
<br />
{{FeatureTodo|After the above, removing kglobal.h from files where it is no longer<br />
used (simplifying the task of creating a framework for the people who<br />
don't realize that that needs to be done, and reducing the build fixes<br />
that are required because they don't do a clean build after moving stuff<br />
around and changing include_directories)|?}}<br />
<br />
{{FeatureTodo|Investigate to what extent our use of X11 API and KWindowSystem can be replaced with QPA (hard)<br />
<br />
Some work started on adding the accessors required for this to the QPA classes.<br />
https://codereview.qt-project.org/#change,26714<br />
|?}}<br />
<br />
{{FeatureTodo|Deprecate and move classes marked "kde4support" in [[Frameworks/Epics/Reduce_class_duplication]]|?}}<br />
<br />
{{FeatureTodo|KDEGuiAddons should be renamed and maybe repurposed|?}}<br />
<br />
{{FeatureTodo|kdeui/colors/kcolorhelpers_p.h has at least a copy in <br />
kdeguiaddons, and perhaps another in kcolorwidgets. Resolve that.|?}}<br />
<br />
{{FeatureInProgress|Move icon loading from kwidgets to kdeguiaddons|Jignesh Kakadiya}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KIcon to QIcon / KDE:::icon(), then move KIcon out (easy)|David Faure}}<br />
<br />
{{FeatureTodo|KGlobalSettings is initalized by KApplication. Find out if any parts of it work without that, and split it into parts that work without the initialization and parts that don't.|?}}<br />
<br />
{{FeatureDone|Port away from and deprecate KHBox/KVBox|Albert Astals Cid}}<br />
<br />
{{FeatureTodo|Find out if KGuiAddons should be deprecated or get an upstream equivalent. The real value is in KStandardGuiItem. See if it can be redesigned in the alternative|?}}<br />
<br />
{{FeatureTodo|KPushButton should be repurposed as KAuthPushButton|?}}<br />
<br />
{{FeatureTodo|Port KStandardAction from KAction to QAction|Benjamin Port}}<br />
<br />
{{FeatureTodo|Move KTabBar to kde4support and port users in kdelibs to QTabbar. preferably KTabWidget should go the same way, but needs a feature in Qt (see the qt5.1 epic)|?}}<br />
<br />
{{FeatureInProgress|Use correct QCoreApplication::translate in all tier1+tier2+staging frameworks|George Goldberg (grundleborg)}}<br />
<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Frameworks/Epics/kdelibs_cleanups&diff=23402Frameworks/Epics/kdelibs cleanups2012-08-04T20:07:57Z<p>Grundleborg: </p>
<hr />
<div>= Cleaning up kdelibs =<br />
<br />
Next to the other efforts for kdelibs modularization, there's also some cleanup tasks which needs to be done accross the whole kdelibs codebase. Tasks in here are probably more suitable for short term, bite sized involvement.<br />
<br />
'''Note''': For most of those tasks we try to put an estimation of the difficulty can be: easy, normal, hard (somewhat like in video games). ;-)<br />
<br />
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width:100%;"<br />
|- style="background: #ececec; white-space:nowrap;"<br />
! Status<br />
! Description<br />
! width=250 | Contact<br />
|-<br />
{{FeatureDone|remove kglobal.h include from staging/kwidgets/src/icons/kiconloader.h, fix compilation by adding the header where necessary (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move ktypelist.h from kdecore/util to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kentrymaptest from kdecore/tests to kconfig/autotests (easy)|Christoph Cullmann}}<br />
{{FeatureDone|move kascii and kasciitest to kde4support (easy)|Christoph Cullmann}}<br />
{{FeatureDone|Port away from KGlobalSettings::singleClick() (easy)|Dominik Haumann}}<br />
{{FeatureTodo|#cmakedefine -> #cmakedefine01, #ifdef -> #if, in order to catch missing includes (easy)|?}}<br />
{{FeatureTodo|Port from KCmdLineArgs+KApp to QApp+setApplicationName in all unittests that don't use args (easy)|Jeremy Whiting}}<br />
{{FeatureTodo|kio/netaccess.h: there are some "TODOs" about deprecating most methods in favour of job+exec (TODO: compare with synchronousRun) (normal)|?}}<br />
<br />
<br />
{{FeatureDone|Fix kfileplacesmodeltest (normal)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move to kcoreaddons the tests in kdecore/tests that are actually tests for classes in kcoreaddons, except kurltest (easy)|Anne-Marie Mahfouf}}<br />
<br />
{{FeatureDone|"cp kurlmimetest.cpp kurlmimedatatest.cpp" and port the second one to KUrlMimeData (in order to test both the deprecated API and the new API). After that, move the old one (kurlmimetest) to kde4support. (normal)|Lambert Clara}}<br />
<br />
{{FeatureDone|Port kcmdlineargs from KUrl to QUrl, then move KUrl out of kcoreaddons, and into kdecore for now, final destination will be kde4support. (easy)|Matt Williams}}<br />
<br />
{{FeatureTodo|Port kdelibs from KProcess to QProcess (except kpty) (easy). Warning: Need to port some functionnality to Qt 5|Davide Bettio}}<br />
<br />
{{FeatureDone|Update qmimetype in kdelibs from the one soon merged to Qt5, port all of kdelibs to the API changes. (normal)|David Faure}}<br />
<br />
{{FeatureDone|Create a staging/kconfig framework out of kdecore/config + kdecore/kernel/kauthorized*. Code should be ready (no more dependencies on the rest of kdecore). (normal)|David}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KGlobal::config() to KSharedConfig::openConfig(), adjust includes (easy)|Claus Christensen}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KMimeType to QMimeType, see KDE5PORTING.html for details (easy)|David Faure}}<br />
<br />
{{FeatureDone|deprecate KLineEdit::clickMessage, by applying https://git.reviewboard.kde.org/r/101360/diff/#index_header and porting kdelibs (easy and quick)|Benjamin Port}}<br />
<br />
{{FeatureDone|Move KDialog saveDialogSize+restoreDialogSize to static methods taking a QDialog.|Benjamin Port}}<br />
<br />
<br />
{{FeatureInProgress|Finish deprecating methods marked as @deprecated (add macro+ifdef, ensure kdelibs doesn't use).|Benjamin Port}}<br />
<br />
<br />
{{FeatureDone|Move KDialogQueue into separate files.|Benjamin Port}}<br />
<br />
{{FeatureTodo|Import QCommandLineArguments from gitorious into libkdeqt5staging|?}}<br />
<br />
{{FeatureTodo|Port all of kdelibs (except kde*support and classes aimed for tier4) from KDialog to QDialog|Davide Bettio}}<br />
<br />
{{FeatureDone|Port from KGlobalSettings::desktopGeometry to QApplication::desktop()->screenGeometry (very easy)|Stephen Kelly}}<br />
<br />
{{FeatureDone|extract KProtocolInfo out of ksycoca, making it simply read from installed files on demand. (normal)|David Faure}}<br />
<br />
{{FeatureDone|move KProtocolInfo to KIO, requires to split out its unittests from kmimetypetest, and to somehow sort out the call to KProtocolInfo inside kmimetype (normal)|David Faure}}<br />
<br />
{{FeatureDone|when gpgmepp is not found, make plasma only skip the Signature class, rather than skipping all of plasma (easy)|David Faure}}<br />
<br />
{{FeatureDone|One of the things we need to remove is all of the use of the Q_WS_* defines. (easy)<br />
<br />
git grep Q_WS_<br />
<br />
Some of them should be ported to a Q_OS_ define (eg, some of Q_WS_WIN should <br />
be ported to Q_OS_WIN), but *not all of them*, so this can't just be changed <br />
with a script. It should be done manually. Some of them need to be ported to <br />
QPA (lighthouse) in some way.|Kevin Ottens}}<br />
<br />
For a walk through example, see [http://thread.gmane.org/gmane.comp.kde.devel.frameworks/319/focus=328 this thread]<br />
<br />
{{FeatureInProgress|Another thing that should be done is using Find packages from ECM or CMake. (normal)<br />
<br />
For example, run 'git grep find_package' in tier1/solid. Some of the results are provided by CMake, and some come from the local kdelibs/cmake/modules folder. The kdelibs/cmake/modules folder should not need to be used. For example find_package(Flex) in solid should be replaced with find_package(FLEX) which is provided by CMake.<br />
<br />
The goal is to be able to run <br />
<br />
cd tier1/solid && mkdir build && cd build && cmake .. && make<br />
<br />
for each framework. <br />
<br />
This is already possible with the itemmodels framework.<br />
<br />
It also works with solid, because the packages it searches for are optional <br />
and the FindFoo.cmake files are not found.|George Goldberg (grundleborg)}}<br />
<br />
{{FeatureTodo|Find out what should be part of the link interface and what should not be. (normal but long), [[Frameworks/Epics/kdelibs_cleanups/link_private_details|details...]]|?}}<br />
{{FeatureDone|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC where the Qt4 API is sufficient|Albert Astals Cid}}<br />
{{FeatureTodo|Port from K_GLOBAL_STATIC to Q_GLOBAL_STATIC needs Qt 5.1 changes|?}}<br />
<br />
{{FeatureTodo|Porting in [[KDE_Core/KLocale/Frameworks]]|?}}<br />
<br />
{{FeatureTodo|After the above, removing kglobal.h from files where it is no longer<br />
used (simplifying the task of creating a framework for the people who<br />
don't realize that that needs to be done, and reducing the build fixes<br />
that are required because they don't do a clean build after moving stuff<br />
around and changing include_directories)|?}}<br />
<br />
{{FeatureTodo|Investigate to what extent our use of X11 API and KWindowSystem can be replaced with QPA (hard)<br />
<br />
Some work started on adding the accessors required for this to the QPA classes.<br />
https://codereview.qt-project.org/#change,26714<br />
|?}}<br />
<br />
{{FeatureTodo|Deprecate and move classes marked "kde4support" in Epics/Reduce_class_duplication|?}}<br />
<br />
{{FeatureTodo|KDEGuiAddons should be renamed and maybe repurposed|?}}<br />
<br />
{{FeatureTodo|kdeui/colors/kcolorhelpers_p.h has at least a copy in <br />
kdeguiaddons, and perhaps another in kcolorwidgets. Resolve that.|?}}<br />
<br />
{{FeatureInProgress|Move icon loading from kwidgets to kdeguiaddons|Jignesh Kakadiya}}<br />
<br />
{{FeatureDone|Port all of kdelibs from KIcon to QIcon / KDE:::icon(), then move KIcon out (easy)|David Faure}}<br />
<br />
{{FeatureTodo|KGlobalSettings is initalized by KApplication. Find out if any parts of it work without that, and split it into parts that work without the initialization and parts that don't.|?}}<br />
<br />
{{FeatureDone|Port away from and deprecate KHBox/KVBox|Albert Astals Cid}}<br />
<br />
{{FeatureTodo|Find out if KGuiAddons should be deprecated or get an upstream equivalent. The real value is in KStandardGuiItem. See if it can be redesigned in the alternative|?}}<br />
<br />
{{FeatureTodo|KPushButton should be repurposed as KAuthPushButton|?}}<br />
<br />
{{FeatureTodo|Port KStandardAction from KAction to QAction|Benjamin Port}}<br />
<br />
{{FeatureTodo|Move KTabBar to kde4support and port users in kdelibs to QTabbar. preferably KTabWidget should go the same way, but needs a feature in Qt (see the qt5.1 epic)|?}}<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint2&diff=14460KTp/Events/TelepathySprint22011-08-17T20:23:20Z<p>Grundleborg: time plan</p>
<hr />
<div>==Details==<br />
*'''When''': Wednesday 14th September to Sunday 18th September 2011<br />
*'''Where''': Collabora Offices, Cambridge, UK<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
More information at https://sprints.kde.org/sprint/13<br />
<br />
==Travel==<br />
===Arriving by Train===<br />
Train is by far the easiest way to get from London to Cambridge, and there are also trains to London from several cities in mainland Europe.<br />
<br />
====Trains from Mainland Europe====<br />
All trains from mainland Europe arrive at London St Pancras station. This is located next door to London Kings Cross station from where the trains to Cambridge depart. Follow the signs for "National Rail Services (Kings Cross Station)" to get there from St Pancras, and then follow the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
====Train from Central London to Cambridge====<br />
Trains run throughout the day from Kings Cross Station to Cambridge. Avoid trains that make many stops on the way since typically the non-stop trains departing after them still get to Cambridge first. Non-stop trains run at 30 min intervals throughout most of the day and take ~45 minutes to get to Cambridge.<br />
<br />
Train tickets in the UK are notoriously complicated with many different priced tickets available all with their own confusing restrictions on which trains they are valid on. Unless you are taking a train leaving Kings Cross before 09:44 then you should be OK with an "Off Peak" ticket. If you are taking an earlier train, you will need a more expensive "Anytime" ticket. If in doubt, ask the ticket office staff, or the staff manning the turnstiles and they should be able to help you know which ticket is needed for a particular train.<br />
<br />
It is always much cheaper to buy a return ticket (which in the case of "Off Peak" and "Anytime" tickets are valid for a return journey up to 1 month away - plenty of time) than to buy a Single ticket each time you travel.<br />
<br />
===Arriving by Plane===<br />
The best way to get to Cambridge is to travel to London Stansted airport. There are many budget flights to this airport and it is located outside of London but very close to Cambridge. If you can't fly to Stansted, then London Heathrow, London City and London Gatwick airports can also be used (in that order of preference for convenience of getting to Cambridge).<br />
<br />
====London Stansted Airport====<br />
From London Stansted airport there is a direct train to Cambridge Station, running at least once per hour throughout the day, taking between 30 and 50 minutes. If you are traveling back via the same airport, it is generally cheaper to buy a return ticket rather than a single ticket each time you travel.<br />
<br />
====London Heathrow Airport====<br />
In order to get to Cambridge from Heathrow, you first need to cross London. The cheap way to take the Underground (Piccadilly Line) from Heathrow to Kings Cross St Pancras Station (about 1 hour 10 minutes), before following the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
Alternatively, there are buses from Heathrow direct to Cambridge but these are generally a slower and more expensive way to get there.<br />
<br />
====Other London Airports====<br />
If you arrive at London City airport, you should take the Docklands Light Railway to Bank and then the London Underground (Northern Line) to Kings Cross St Pancras, before following the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
If you arrive at London Gatwick, you will need to take the Gatwick Express train to London Victoria Station, then the London Underground (Victoria Line) to Kings Cross St Pancras before following the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
==Time Plan==<br />
* Wednesday - arrive, socialise<br />
* Thursday - Planning/Discussing/Hacking<br />
* Friday - Planning/Discussing/Hacking<br />
* Saturday - Planning/Discussing/Hacking<br />
* Sunday - depart<br />
<br />
==Agenda==<br />
<br />
* telepathy-logger<br />
* call ui<br />
* plasmoids<br />
** plasma-active integration<br />
* tubes<br />
** status of tubes apis in tp-qt4<br />
** krfb & krdc integration<br />
* nepomuk integration<br />
** status of nepomuk service / nepomuk-enabled contact list<br />
** nepomuk action files<br />
* central kded service<br />
** approver<br />
** disconnection messages<br />
** handle subscription requests<br />
* get stuff in spec/mc/tp-qt4<br />
** network manager integration<br />
** global presence<br />
** refcounting clients<br />
** method to set preferred handlers in mc</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint2&diff=14459KTp/Events/TelepathySprint22011-08-17T20:06:09Z<p>Grundleborg: travel details</p>
<hr />
<div>==Details==<br />
*'''When''': Wednesday 14th September to Sunday 18th September 2011<br />
*'''Where''': Collabora Offices, Cambridge, UK<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
More information at https://sprints.kde.org/sprint/13<br />
<br />
==Travel==<br />
===Arriving by Train===<br />
Train is by far the easiest way to get from London to Cambridge, and there are also trains to London from several cities in mainland Europe.<br />
<br />
====Trains from Mainland Europe====<br />
All trains from mainland Europe arrive at London St Pancras station. This is located next door to London Kings Cross station from where the trains to Cambridge depart. Follow the signs for "National Rail Services (Kings Cross Station)" to get there from St Pancras, and then follow the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
====Train from Central London to Cambridge====<br />
Trains run throughout the day from Kings Cross Station to Cambridge. Avoid trains that make many stops on the way since typically the non-stop trains departing after them still get to Cambridge first. Non-stop trains run at 30 min intervals throughout most of the day and take ~45 minutes to get to Cambridge.<br />
<br />
Train tickets in the UK are notoriously complicated with many different priced tickets available all with their own confusing restrictions on which trains they are valid on. Unless you are taking a train leaving Kings Cross before 09:44 then you should be OK with an "Off Peak" ticket. If you are taking an earlier train, you will need a more expensive "Anytime" ticket. If in doubt, ask the ticket office staff, or the staff manning the turnstiles and they should be able to help you know which ticket is needed for a particular train.<br />
<br />
It is always much cheaper to buy a return ticket (which in the case of "Off Peak" and "Anytime" tickets are valid for a return journey up to 1 month away - plenty of time) than to buy a Single ticket each time you travel.<br />
<br />
===Arriving by Plane===<br />
The best way to get to Cambridge is to travel to London Stansted airport. There are many budget flights to this airport and it is located outside of London but very close to Cambridge. If you can't fly to Stansted, then London Heathrow, London City and London Gatwick airports can also be used (in that order of preference for convenience of getting to Cambridge).<br />
<br />
====London Stansted Airport====<br />
From London Stansted airport there is a direct train to Cambridge Station, running at least once per hour throughout the day, taking between 30 and 50 minutes. If you are traveling back via the same airport, it is generally cheaper to buy a return ticket rather than a single ticket each time you travel.<br />
<br />
====London Heathrow Airport====<br />
In order to get to Cambridge from Heathrow, you first need to cross London. The cheap way to take the Underground (Piccadilly Line) from Heathrow to Kings Cross St Pancras Station (about 1 hour 10 minutes), before following the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
Alternatively, there are buses from Heathrow direct to Cambridge but these are generally a slower and more expensive way to get there.<br />
<br />
====Other London Airports====<br />
If you arrive at London City airport, you should take the Docklands Light Railway to Bank and then the London Underground (Northern Line) to Kings Cross St Pancras, before following the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
If you arrive at London Gatwick, you will need to take the Gatwick Express train to London Victoria Station, then the London Underground (Victoria Line) to Kings Cross St Pancras before following the instructions in the [[#Train_from_Central_London_to_Cambridge]] section.<br />
<br />
==Agenda==<br />
<br />
* telepathy-logger<br />
* call ui<br />
* plasmoids<br />
** plasma-active integration<br />
* tubes<br />
** status of tubes apis in tp-qt4<br />
** krfb & krdc integration<br />
* nepomuk integration<br />
** status of nepomuk service / nepomuk-enabled contact list<br />
** nepomuk action files<br />
* central kded service<br />
** approver<br />
** disconnection messages<br />
** handle subscription requests<br />
* get stuff in spec/mc/tp-qt4<br />
** network manager integration<br />
** global presence<br />
** refcounting clients<br />
** method to set preferred handlers in mc</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Installing_stable_release&diff=14231KTp/Installing stable release2011-08-04T11:20:01Z<p>Grundleborg: add download link</p>
<hr />
<div>This how-to will help you set up stable release of KDE-Telepathy from source on your computer. Most of it takes action in console, but don't worry, it's easy.<br />
<br />
Please note that the first release is a Technical Preview, that means it's not feature complete and may eat your dog. But we still encourage you to go and test it and tell us what you want or what you miss.<br />
<br />
Packagers please follow [http://community.kde.org/Real-Time_Communication_and_Collaboration/Packaging_Guide the Packaging guide] and make less users come here.<br />
<br />
==Prerequisites==<br />
<br />
You will need to install several cross-desktop Telepathy components. Packages of the following from your distribution should do fine.<br />
* telepathy-mission-control-5 (a must have)<br />
* telepathy-gabble (for GTalk/Facebook Chat/Jabber support)<br />
* telepathy-butterfly (for basic MSN support)<br />
* telepathy-haze (for all other protocols)<br />
<br />
==TelepathyQt4==<br />
<br />
The prerequisite for all the Telepathy stuff to build is the TelepathyQt4 library. Your distribution may package it, in which case you need version 0.7.1 or higher. Be careful not to confuse it with the telepathy-qt library which used to be in kdesupport SVN. This is *completely* different and in no way compatible. <br />
<br />
If your distro doesn't provide TelepathyQt4 package, don't worry, you can compile it yourself, it's easy.<br />
<br />
If you are compiling Tp-Qt4 and get a warning about needing a newer glib, simply ignore it. Glib is only needed for some internal Tp-Qt4 tests.<br />
<br />
===Compiling TelepathyQt4===<br />
<br />
First of all you need to download the latest version of TelepathyQt4 from [http://telepathy.freedesktop.org/releases/telepathy-qt4/ here]. Currently it's [http://telepathy.freedesktop.org/releases/telepathy-qt4/telepathy-qt4-0.7.1.tar.gz 0.7.1]. Extract it to some directory and then switch to terminal and cd into that directory (so if you extracted it in your home folder, do 'cd ~/telepathy-qt4').<br />
<br />
First we need to create a special build directory and then switch to it.<br />
<pre><br />
$ mkdir -p build && cd build<br />
</pre><br />
<br />
Once there, we'll run the configuration scripts:<br />
<br />
<pre><br />
$ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=release ..<br />
</pre><br />
<br />
If everything went ok and the last line says "Build files have been written", move to the compiling itself. Use -jN for how many cores you have +1, eg. -j3 for two cores CPU.<br />
<br />
<pre><br />
$ make -j3<br />
</pre><br />
<br />
Once successfully compiled, you just need to install it and you're done with TelepathyQt4. For this, you need to know the superuser password.<br />
<br />
<pre><br />
$ sudo make install<br />
</pre><br />
<br />
==Installing KDE-Telepathy components==<br />
KDE-Telepathy has several components:<br />
* Accounts KCM + Plugins<br />
* Approver<br />
* Contact List<br />
* File Transfer Handler<br />
* Presence Plasma widget + Plasma DataEngine<br />
* Send File plugin for Dolphin<br />
* Text UI (the chat window)<br />
<br />
Each component will have the exact same steps needed, so we'll put it here just once. [http://download.kde.org/download.php?url=unstable/telepathy-kde/0.1.0/src/ Download all 9 packages from here] and extract each one into it's own directory. Then just follow the steps for compiling TelepathyQt4:<br />
<br />
<pre>first cd into the component's dir, eg. 'cd telepathy-accounts-kcm'<br />
$ mkdir -p build && cd build<br />
$ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=release ..<br />
$ make -j3<br />
$ sudo make install<br />
</pre><br />
<br />
After you finish with all components, you can open System Settings and you'll find new 'Instant Messaging Accounts' icon there and you can set up your accounts there. If something's not working right after the install, you may need to log out and log back in. If you still have problems, feel free to contact us at #kde-telepathy on freenode or file a bug at [http://bugs.kde.org bugs.kde.org].<br />
<br />
Welcome online!</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Packaging_Guide&diff=11891KTp/Packaging Guide2011-04-20T13:12:28Z<p>Grundleborg: add links to components</p>
<hr />
<div>Packaging KDE-Telepathy is complicated for two reasons: firstly, due to the modular nature of Telepathy, there are several distinct components in separate git repositories. Secondly, there are large numbers of runtime interdependencies to worry about. This page attempts to ease packaging KDE-Telepathy in a useful way by explaining these issues.<br />
<br />
==Upstream Packages==<br />
Two upstream packages are essential for KDE-Telepathy to work.<br />
* [http://telepathy.freedesktop.org/releases/telepathy-qt4/ telepathy-qt4] >= 0.5.15 (Build and Runtime Dependency)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-mission-control/ telepathy-mission-control] >= 5.7.9 (Runtime Dependency)<br />
<br />
The IM networks that KDE-Telepathy can connect to are decided by which Telepathy Connection Managers are installed. These are runtime only dependencies, but which ones are installed will decide what IM networks KDE-Telepathy supports. The following are the ones we recommend - whether they are installed optionally or required is, of course, up to you.<br />
<br />
* [http://telepathy.freedesktop.org/releases/telepathy-gabble/ telepathy-gabble] (for Jabber support, including Google Talk and Facebook)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-butterfly/ telepathy-butterfly] (for MSN/Windows Live support)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-haze/ telepathy-haze] (for all the other protocols, as supported by libpurple).<br />
<br />
==KDE-Telepathy Packages==<br />
The different components of KDE-Telepathy are housed in separate git repositories on projects.kde.org. Some of these components are currently recommended to use. Others are not yet ready to be installed by users.<br />
<br />
'''''Should we recommend adding a "kde" somewhere in the names of the KDE-Telepathy packages to avoid confusion with upstream/non-KDE stuff?'''''<br />
<br />
===Ready Components===<br />
These components have reached a level of maturity where they are interesting to users. We recommend providing these components at the current time.<br />
<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-accounts-kcm telepathy-accounts-kcm] (Required)<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-accounts-kcm/telepathy-accounts-kcm-plugins telepathy-accounts-kcm-plugins] (Optional, highly recommended, could conceivably be separated out into one package per CM plugin)<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-approver telepathy-approver] (Optional, but highly recommended)<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-chat-handler telepathy-chat-handler] (Required) '''''Should we change the name of this repo to be the same as the new name for the app?'''''<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-contact-list telepathy-contact-list] (Required)<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-presence-dataengine telepathy-presence-dataengine] (Optional, highly recommended)<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-presence-applet telepathy-presence-applet] (Optional, highly recommended)<br />
<br />
===Experimental Components===<br />
We have several other components under development, however, unless they are listed above we do not recommend packaging them. This is because they are subject to major changes/removal at any time, and are not ready for end users yet.</div>Grundleborghttps://community.kde.org/index.php?title=KTp&diff=11731KTp2011-04-15T15:17:26Z<p>Grundleborg: /* Getting Started */</p>
<hr />
<div>==Introduction==<br />
<br />
Real time Communication has traditionally been a detatched feature of Desktop Computing, provided via stand-alone Instant Messaging clients with poor integration into the desktop experience. One of the primary goals of the KDE 4 series is to tighten integration between different components of the environment. The Realtime Communication and Collaboration (RTCC) project aims to tackle just this.<br />
<br />
Our aims are:<br />
* To integrate Real Time Communication deeply into the KDE Workspaces and Applications<br />
* To provide a infrastructure to aid development of Collaborative features for KDE applications.<br />
<br />
If you find these goals appealing, why not consider [[#Getting_Involved|getting involved]]. C++ programming is *not* a necessity.<br />
<br />
==Technical Information==<br />
<br />
* The RTCC project uses the cross-desktop [http://telepathy.freedesktop.org Telepathy Framework] as the basis for our work.<br />
* We should try and reuse code from Kopete/other already existing code wherever possibly. However, this should be balanced with the need to refactor/rewrite where appropriate to keep the new code true to Telepathy idioms.<br />
<br />
==Frequently Asked Questions==<br />
<br />
You can find a list of answers to frequently asked questions here: [[Real-Time_Communication_and_Collaboration/FAQ|FAQ]].<br />
<br />
See also https://gkiagia.wordpress.com/2010/09/20/what-is-telepathy-kde/<br />
<br />
==Getting Started==<br />
Before you start playing with/hacking on the Telepathy integration stuff, you need to get it all compiled: [[Real-Time_Communication_and_Collaboration/Getting_Set_Up|Instructions]]<br />
<br />
We are currently in the process of porting all our work from telepathy-qt4 0.3/0.4 to version 0.5 (which is binary incompatible with 0.3 and 0.4). [[Real-Time_Communication_and_Collaboration/Current_State|This page]] shows the progress with this task.<br />
<br />
{{Warning|If you are a distro packager, please [[Real-Time_Communication_and_Collaboration/Packaging_Guide|see here for information on packaging KDE-Telepathy]]}}<br />
<br />
==The Plan==<br />
1) Build components equivalent to a traditional IM application, using Kopete code as much as possible, and integrating with other Pillars of KDE where appropriate.<br />
<br />
2) Add advanced Telepathy features such as voice/video.<br />
<br />
3) Build components and Convenience classes to enable real-time communication and collaboration features in any KDE SC app that wants them.<br />
<br />
==The Work==<br />
<br />
What we need to get done. This is divided into two sections:<br />
* [[#Phase_1|Phase 1]] contains the tasks which *must* be completed in order for us to make a first preview release.<br />
* [[#Phase_2|Phase 2]] contains other speculative major features that we will probably implement once [[#Phase_1|Phase 1]] is complete.<br />
<br />
=== Phase 1 ===<br />
<br />
These are the essential tasks which must be completed before we can make a first release. Adding or removing tasks from this list requires a consensus on the kde-telepathy mailing list first. Click on a task title for further information about that task.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Account_Management_GUI|Account Management GUI]] || George Goldberg <grundleborg googlemail com> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Telepathy_Accounts_KCM|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Chat_Window|Chat Window App/Lib]] || David Edmundson <kde davidedmundson co uk> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Chat_window_App|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Buddy_List|Buddy List App]] || Marty Klapetek <martin.klapetek gmail com> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Contact_List_App|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Desktop-wide_Approver|Desktop Wide Tp::Approver]] || George Kiagiadakis <kiagiadakis.george gmail com> || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Integration_Daemon|Telepathy Integration Daemon]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Integration_Daemon|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Presence_Plasmoid|Presence Plasmoid]] || Dario Freddi <drf kde org> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Presence_Plasmoid_and_Dataengine|See here]]<br />
|-<br />
|}<br />
<br />
=== Phase 2 ===<br />
<br />
This section contains features that will *probably* be implemented once the first preview release has been made.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Logger|Logger Application]] || Stefano Sanfilippo <stefano.k.sanfilippo gmail com> || [http://quickgit.kde.org/?p=scratch%2Fsanfilippo%2Ftelepathy-logger-query.git&a=summary Still in a scratch repo]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Call_UI|Call UI]] || George Kiagiadakis <kiagiadakis.george gmail com> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Call_window_App|See here]]<br />
|}<br />
<br />
==Getting Involved==<br />
At this stage, the best way to get involved is to contact the existing team, either on IRC (#kde-telepathy channel on irc.freenode.net) or on our [https://mail.kde.org/mailman/listinfo/kde-telepathy mailing list].<br />
<br />
===Tasks===<br />
Here is a list of tasks that you could get involved with at this moment. Please get in contact with us before writing anything, though. You can find some more details in the work section above.<br />
<br />
* Fix bugs in the accounts KCM.<br />
* Write account plugins for the accounts KCM.<br />
* Complete some missing bits from the nepomuk integration service.<br />
* (Re-)write the contact list UI.<br />
* (Re-)write the call UI (just the UI, not the actual call mechanism).<br />
* Investigate how to implement the logger and then implement it.<br />
* Integrate telepathy into some kde application, doing something fancy and innovative (use your fantasy here).<br />
* Write a runner (or extend the existing nepomuk runner) for krunner that searches for contacts in nepomuk and allows you to start a chat with them.<br />
* Port something to tp-qt4 0.5. See [[Real-Time_Communication_and_Collaboration/Current_State|here]] for details.<br />
<br />
===Workflow===<br />
If you want to work on a feature, clone the git repository on the server side and then clone your personal clone on your local machine. Make a new git branch and start working there. Try to keep commits small and meaningful. Once you are finished, push the branch on your server-side clone and ask someone of the team to review it. Once it is reviewed, you can merge it on the master repository (or ask someone else to merge it).<br />
<br />
==Events==<br />
* [[Telepathy/Events/TelepathySprint1|Telepathy sprint - September 2010]]</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Packaging_Guide&diff=11730KTp/Packaging Guide2011-04-15T13:59:46Z<p>Grundleborg: add links</p>
<hr />
<div>Packaging KDE-Telepathy is complicated for two reasons: firstly, due to the modular nature of Telepathy, there are several distinct components in separate git repositories. Secondly, there are large numbers of runtime interdependencies to worry about. This page attempts to ease packaging KDE-Telepathy in a useful way by explaining these issues.<br />
<br />
==Upstream Packages==<br />
Two upstream packages are essential for KDE-Telepathy to work.<br />
* [http://telepathy.freedesktop.org/releases/telepathy-qt4/ telepathy-qt4] >= 0.5.15 (Build and Runtime Dependency)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-mission-control/ telepathy-mission-control] >= 5.7.9 (Runtime Dependency)<br />
<br />
The IM networks that KDE-Telepathy can connect to are decided by which Telepathy Connection Managers are installed. These are runtime only dependencies, but which ones are installed will decide what IM networks KDE-Telepathy supports. The following are the ones we recommend - whether they are installed optionally or required is, of course, up to you.<br />
<br />
* [http://telepathy.freedesktop.org/releases/telepathy-gabble/ telepathy-gabble] (for Jabber support, including Google Talk and Facebook)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-butterfly/ telepathy-butterfly] (for MSN/Windows Live support)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-haze/ telepathy-haze] (for all the other protocols, as supported by libpurple).<br />
<br />
==KDE-Telepathy Packages==<br />
The different components of KDE-Telepathy are housed in separate git repositories on projects.kde.org. Some of these components are currently recommended to use. Others are not yet ready to be installed by users.<br />
<br />
'''''Should we recommend adding a "kde" somewhere in the names of the KDE-Telepathy packages to avoid confusion with upstream/non-KDE stuff?'''''<br />
<br />
===Ready Components===<br />
These components have reached a level of maturity where they are interesting to users. We recommend providing these components at the current time.<br />
<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-accounts-kcm telepathy-accounts-kcm] (Required)<br />
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-accounts-kcm/telepathy-accounts-kcm-plugins telepathy-accounts-kcm-plugins] (Optional, highly recommended, could conceivably be separated out into one package per CM plugin)<br />
* telepathy-approver (Optional, but highly recommended)<br />
* telepathy-chat-handler (Required) '''''Should we change the name of this repo to be the same as the new name for the app?'''''<br />
* telepathy-contact-list (Required)<br />
* telepathy-presence-dataengine (Optional, highly recommended)<br />
* telepathy-presence-applet (Optional, highly recommended)<br />
<br />
===Experimental Components===<br />
We have several other components under development, however, unless they are listed above we do not recommend packaging them. This is because they are subject to major changes/removal at any time, and are not ready for end users yet.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Packaging_Guide&diff=11729KTp/Packaging Guide2011-04-15T13:56:31Z<p>Grundleborg: /* Ready Components */</p>
<hr />
<div>Packaging KDE-Telepathy is complicated for two reasons: firstly, due to the modular nature of Telepathy, there are several distinct components in separate git repositories. Secondly, there are large numbers of runtime interdependencies to worry about. This page attempts to ease packaging KDE-Telepathy in a useful way by explaining these issues.<br />
<br />
==Upstream Packages==<br />
Two upstream packages are essential for KDE-Telepathy to work.<br />
* [http://telepathy.freedesktop.org/releases/telepathy-qt4/ telepathy-qt4] >= 0.5.15 (Build and Runtime Dependency)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-mission-control/ telepathy-mission-control] >= 5.7.9 (Runtime Dependency)<br />
<br />
The IM networks that KDE-Telepathy can connect to are decided by which Telepathy Connection Managers are installed. These are runtime only dependencies, but which ones are installed will decide what IM networks KDE-Telepathy supports. The following are the ones we recommend - whether they are installed optionally or required is, of course, up to you.<br />
<br />
* [http://telepathy.freedesktop.org/releases/telepathy-gabble/ telepathy-gabble] (for Jabber support, including Google Talk and Facebook)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-butterfly/ telepathy-butterfly] (for MSN/Windows Live support)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-haze/ telepathy-haze] (for all the other protocols, as supported by libpurple).<br />
<br />
==KDE-Telepathy Packages==<br />
The different components of KDE-Telepathy are housed in separate git repositories on projects.kde.org. Some of these components are currently recommended to use. Others are not yet ready to be installed by users.<br />
<br />
'''''Should we recommend adding a "kde" somewhere in the names of the KDE-Telepathy packages to avoid confusion with upstream/non-KDE stuff?'''''<br />
<br />
===Ready Components===<br />
These components have reached a level of maturity where they are interesting to users. We recommend providing these components at the current time.<br />
<br />
* telepathy-accounts-kcm (Required)<br />
* telepathy-accounts-kcm-plugins (Optional, highly recommended, could conceivably be separated out into one package per CM plugin)<br />
* telepathy-approver (Optional, but highly recommended)<br />
* telepathy-chat-handler (Required) '''''Should we change the name of this repo to be the same as the new name for the app?'''''<br />
* telepathy-contact-list (Required)<br />
* telepathy-presence-dataengine (Optional, highly recommended)<br />
* telepathy-presence-applet (Optional, highly recommended)<br />
<br />
===Experimental Components===<br />
We have several other components under development, however, unless they are listed above we do not recommend packaging them. This is because they are subject to major changes/removal at any time, and are not ready for end users yet.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Packaging_Guide&diff=11728KTp/Packaging Guide2011-04-15T13:55:44Z<p>Grundleborg: /* Upstream Packages */ add links</p>
<hr />
<div>Packaging KDE-Telepathy is complicated for two reasons: firstly, due to the modular nature of Telepathy, there are several distinct components in separate git repositories. Secondly, there are large numbers of runtime interdependencies to worry about. This page attempts to ease packaging KDE-Telepathy in a useful way by explaining these issues.<br />
<br />
==Upstream Packages==<br />
Two upstream packages are essential for KDE-Telepathy to work.<br />
* [http://telepathy.freedesktop.org/releases/telepathy-qt4/ telepathy-qt4] >= 0.5.15 (Build and Runtime Dependency)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-mission-control/ telepathy-mission-control] >= 5.7.9 (Runtime Dependency)<br />
<br />
The IM networks that KDE-Telepathy can connect to are decided by which Telepathy Connection Managers are installed. These are runtime only dependencies, but which ones are installed will decide what IM networks KDE-Telepathy supports. The following are the ones we recommend - whether they are installed optionally or required is, of course, up to you.<br />
<br />
* [http://telepathy.freedesktop.org/releases/telepathy-gabble/ telepathy-gabble] (for Jabber support, including Google Talk and Facebook)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-butterfly/ telepathy-butterfly] (for MSN/Windows Live support)<br />
* [http://telepathy.freedesktop.org/releases/telepathy-haze/ telepathy-haze] (for all the other protocols, as supported by libpurple).<br />
<br />
==KDE-Telepathy Packages==<br />
The different components of KDE-Telepathy are housed in separate git repositories on projects.kde.org. Some of these components are currently recommended to use. Others are not yet ready to be installed by users.<br />
<br />
'''''Should we recommend adding a "kde" somewhere in the names of the KDE-Telepathy packages to avoid confusion with upstream/non-KDE stuff?'''''<br />
<br />
===Ready Components===<br />
These components have reached a level of maturity where they are interesting to users. We recommend providing these components at the current time.<br />
<br />
* telepathy-accounts-kcm (Required)<br />
* telepathy-accounts-kcm-plugins (Optional, highly recommended, could conceivably be separated out into one package per CM plugin)<br />
* telepathy-approver (Optional, but highly recommended)<br />
* telepathy-chat-handler (Required)<br />
* telepathy-contact-list (Required)<br />
* telepathy-presence-dataengine (Optional, highly recommended)<br />
* telepathy-presence-applet (Optional, highly recommended)<br />
<br />
===Experimental Components===<br />
We have several other components under development, however, unless they are listed above we do not recommend packaging them. This is because they are subject to major changes/removal at any time, and are not ready for end users yet.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Packaging_Guide&diff=11727KTp/Packaging Guide2011-04-15T13:53:16Z<p>Grundleborg: First draft</p>
<hr />
<div>Packaging KDE-Telepathy is complicated for two reasons: firstly, due to the modular nature of Telepathy, there are several distinct components in separate git repositories. Secondly, there are large numbers of runtime interdependencies to worry about. This page attempts to ease packaging KDE-Telepathy in a useful way by explaining these issues.<br />
<br />
==Upstream Packages==<br />
Two upstream packages are essential for KDE-Telepathy to work.<br />
* telepathy-qt4 >= 0.5.15 (Build and Runtime Dependency)<br />
* telepathy-mission-control >= 5.7.9 (Runtime Dependency)<br />
<br />
The IM networks that KDE-Telepathy can connect to are decided by which Telepathy Connection Managers are installed. These are runtime only dependencies, but which ones are installed will decide what IM networks KDE-Telepathy supports. The following are the ones we recommend - whether they are installed optionally or required is, of course, up to you.<br />
<br />
* telepathy-gabble (for Jabber support, including Google Talk and Facebook)<br />
* telepathy-butterfly (for MSN/Windows Live support)<br />
* telepathy-haze (for all the other protocols, as supported by libpurple).<br />
<br />
==KDE-Telepathy Packages==<br />
The different components of KDE-Telepathy are housed in separate git repositories on projects.kde.org. Some of these components are currently recommended to use. Others are not yet ready to be installed by users.<br />
<br />
'''''Should we recommend adding a "kde" somewhere in the names of the KDE-Telepathy packages to avoid confusion with upstream/non-KDE stuff?'''''<br />
<br />
===Ready Components===<br />
These components have reached a level of maturity where they are interesting to users. We recommend providing these components at the current time.<br />
<br />
* telepathy-accounts-kcm (Required)<br />
* telepathy-accounts-kcm-plugins (Optional, highly recommended, could conceivably be separated out into one package per CM plugin)<br />
* telepathy-approver (Optional, but highly recommended)<br />
* telepathy-chat-handler (Required)<br />
* telepathy-contact-list (Required)<br />
* telepathy-presence-dataengine (Optional, highly recommended)<br />
* telepathy-presence-applet (Optional, highly recommended)<br />
<br />
===Experimental Components===<br />
We have several other components under development, however, unless they are listed above we do not recommend packaging them. This is because they are subject to major changes/removal at any time, and are not ready for end users yet.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Tasks/Telepathy-Qt_0.5_Porting&diff=11726KTp/Tasks/Telepathy-Qt 0.5 Porting2011-04-15T13:36:03Z<p>Grundleborg: update testlib status</p>
<hr />
<div>This page lists the current state of the KDE Telepathy applications porting to Telepathy-Qt0.5<br />
<br />
{| class="wikitable" border="1"<br />
! Name !! Status !! Branches<br />
|- <br />
| style="background:#00ff00" | Telepathy Accounts KCM || Done in master|| <br />
|-<br />
| style="background:#00ff00" | Telepathy Accounts KCM Plugins || Done in master || <br />
|-<br />
| style="background:#00ff00" | Telepathy Approver || N/A (written with 0.5) || <br />
|-<br />
| style="background:#00ff00" | Telepathy Call UI || Done in master ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Chat Handler || Done in master ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Contact List || Rewritten in Martin branch || ???<br />
|-<br />
| style="background:#ff0000" | Telepathy KDE || Not ported || ???<br />
|-<br />
| Telepathy Launcher KDED || Not needed ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Nepomuk Service || Done in master || <br />
|-<br />
| Telepathy Presence Applet || Being rewritten to QML - No port needed as it depends solely on the dataengine ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Presence Dataengine || Done in master||<br />
|-<br />
| style="background:#00ff00" | Telepathy Testlib || Done in master ||<br />
|-<br />
| style="background:#ff0000" | Kopete Protocol Telepathy || Not ported (low priority) ||<br />
|-<br />
| style="background:#ff0000" | KWhiteboard || not ported || needs some extra qt patch... sidelined for the moment <br />
|-<br />
| style="background:#00ff00" | krfb || Done in trunk. r1221586 || <br />
|-<br />
| style="background:#00ff00" | krdc || Done in trunk. r1221586 || <br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Tasks/Telepathy-Qt_0.5_Porting&diff=11725KTp/Tasks/Telepathy-Qt 0.5 Porting2011-04-15T13:35:38Z<p>Grundleborg: update porting statuses</p>
<hr />
<div>This page lists the current state of the KDE Telepathy applications porting to Telepathy-Qt0.5<br />
<br />
{| class="wikitable" border="1"<br />
! Name !! Status !! Branches<br />
|- <br />
| style="background:#00ff00" | Telepathy Accounts KCM || Done in master|| <br />
|-<br />
| style="background:#00ff00" | Telepathy Accounts KCM Plugins || Done in master || <br />
|-<br />
| style="background:#00ff00" | Telepathy Approver || N/A (written with 0.5) || <br />
|-<br />
| style="background:#00ff00" | Telepathy Call UI || Done in master ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Chat Handler || Done in master ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Contact List || Rewritten in Martin branch || ???<br />
|-<br />
| style="background:#ff0000" | Telepathy KDE || Not ported || ???<br />
|-<br />
| Telepathy Launcher KDED || Not needed ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Nepomuk Service || Done in master || <br />
|-<br />
| Telepathy Presence Applet || Being rewritten to QML - No port needed as it depends solely on the dataengine ||<br />
|-<br />
| style="background:#00ff00" | Telepathy Presence Dataengine || Done in master||<br />
|-<br />
| style="background:#ff0000" | Telepathy Testlib || not ported ||<br />
|-<br />
| style="background:#ff0000" | Kopete Protocol Telepathy || Not ported (low priority) ||<br />
|-<br />
| style="background:#ff0000" | KWhiteboard || not ported || needs some extra qt patch... sidelined for the moment <br />
|-<br />
| style="background:#00ff00" | krfb || Done in trunk. r1221586 || <br />
|-<br />
| style="background:#00ff00" | krdc || Done in trunk. r1221586 || <br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=GSoC/2011/Ideas&diff=9595GSoC/2011/Ideas2011-02-10T15:44:00Z<p>Grundleborg: /* Telepathy */</p>
<hr />
<div>== Guidelines ==<br />
<br />
=== Information for Students ===<br />
<br />
These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at. <br />
<br />
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out. <br />
<br />
When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big! <br />
<br />
If there is no specific contact given you can ask questions on the general KDE development list kde-devel@kde.org. See [http://www.kde.org/mailinglists/ the KDE mailing lists page] for information on available mailing lists and how to subscribe. <br />
<br />
=== Adding a Proposal ===<br />
<br />
{{Note|Follow the template of other proposals!}}<br />
<br />
When adding an idea to this section, please try to include the following data: <br />
<br />
:*if the application is not widely known, a description of what it does and where its code lives <br />
:*a brief explanation <br />
:*the expected results <br />
:*pre-requisites for working on your project <br />
:*if applicable, links to more information or discussions <br />
:*mailing list or IRC channel for your application/library/module <br />
:*your name and email address for contact (if you're willing to be a mentor)<br />
<br />
If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.<br />
<br />
== Ideas ==<br />
<br />
'''How to find ideas?''' To see previous Project ideas, see: [[GSoC/2010/Ideas|2010 ideas]]. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.<br />
<br />
<br />
=== Amarok ===<br />
<br />
Amarok is a powerful KDE based music player for Linux and Unix, MacOS X and Windows with an intuitive interface. It makes playing the music you love and discovering new music easier than ever before - and it looks good doing it! <br />
<br />
<br> [http://amarok.kde.org Website] - [https://mail.kde.org/mailman/listinfo/amarok Mailing list] - IRC channel: #amarok on Freenode. <br />
<br />
==== Project: Playlist sharing ====<br />
<br />
'''Brief explanation:''' <br />
Amarok playlist sharing will allow you to select a set of tracks and share them with friends over chat. By using Telepathy lots of IM networks are available including jabber, google talk, AIM, MSN and facebook chat.<br />
<br />
'''Expected results:'''<br />
A plugin will add a PlaylistProvider to Amarok that enable the user to share via HTTP streaming (P2P) a playlist with online friends.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), Telepathy, HTTP streaming and NAT traversal.<br />
<br />
Any of these are optional but not all of them.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Bart Cerneels or Ian Monroe<br />
<br />
==== Project: Self Contained Collection ====<br />
<br />
'''Brief explanation:''' <br />
sqlite file saved in collections own folder. Tie in with USB media device.<br />
More info to follow.<br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), SQL.<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
Unless someone else from the Amarok team can be convinced: Bart Cerneels<br />
<br />
=== digiKam ===<br />
<br />
Photo Management program <br />
<br />
[http://www.digikam.org digiKam project web site] - [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist] - IRC channel: #digikam on Freenode. <br />
<br />
==== Project: Camera UI Revamp ====<br />
<br />
'''Brief explanation:''' <br />
DigiKam features a UI for accessing and downloading pictures from cameras.<br />
The code is rather old, using Qt3Support classes for the icon view, the UI code intermangled deeply with backend code, and has not seen very much care and love for some years.<br />
<br />
This project would involve taking the old code apart, rewriting a clean code base backend and frontend, but also adding user interface elements to make the most important everyday task as easy as possible.<br />
<br />
In more detail: Write a model listing images on a camera (There are two backends, USB mass storage cameras, which are basically files on disk, and gphoto2 cameras, which require access through a library). Take the existing digikam icon view and delegate classes, which are prepared for code reuse, and put together an icon view for the model. Cleanly separate the code that does the actual work (downloading, converting, renaming) from the UI. Wrap that in the main window.<br />
<br />
UI design: The current interface is powerful, exposing many options. We want to preserve that. But at the same time, there are three very common actions: a) Download all new files to the last used album b) Download all new files to a new album c) Download all new files to an existing album.<br/><br />
It should be possible to carry out task (a) with one click, task (b) and (c) with two or three clicks, without opening a dialog. Friendly to the new user, preserving access to all options for the poweruser.<br />
<br />
'''Expected results:'''<br />
A camera UI based on Qt model/view and clean code which provides the currently available functionality, offering a quick path to download new pictures.<br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Interest in Qt model/view and UI code.<br />
<br />
'''Mentor:''' Gilles Caulier? (Marcel Wiesweg)<br />
<br />
<br />
==== Project: Presentation View ====<br />
<br />
'''Brief explanation:''' <br />
The presentation view is a full-screen workplace which you can use to present photos to yourself or your audience. At first glance it is looking like the current slide show, but then it is much more flexible: At any moment, you can access UI components like the map view, the metadata tab, the image properties tab, to access information, assign metadata, or show your audience the location of the picture on OpenStreetMap. You can access an icon view component to change the collection your are currently presenting, or a thumbbar component to switch to a different image.<br />
<br />
The main view typically shows one image full screen, but you can zoom; You can also change to a layout that shows four or five images at a time, like images put in a paper album.<br />
You can change the order of images presented, and store order and layout (preferably in some XML format). You can load these presentations later, playing them automatically, coming back to the traditional slide show.<br />
<br />
Technically, it should be future proof as much as possible (Qt Quick. QGraphicsView. scene graph in the future? Will embed QWidgets though) The job is not to develop any of the components mentioned above, but to avoid that, and reuse the existing digikam components and models.<br />
<br />
'''Expected results:'''<br />
Something resembling the vision outlined above<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Marcel Wiesweg<br />
<br />
<br />
==== Project: MacOSX support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
digiKam needs to be available under MacOSX in native. Currently, [http://www.macports.org - Macports project] is the only way to get last digiKam under Mac.<br />
Macports require to compile all depencies and digiKam as well. It's a long and hazardous solution to see digiKam running under Mac.<br />
<br />
Also, current digiKam implementation is not optimized for Mac desktop. A lots of point need to be improved to support better this operating system.<br />
Graphical interface need to polished too.<br />
<br />
See relevant entries in KDE bugzilla about MacOSX support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=257679 257679] <br />
[https://bugs.kde.org/show_bug.cgi?id=257773 257773]<br />
<br />
'''Expected results:'''<br />
Provide scripts and configurations to build automatically a DMG archive of digiKam for MacOSX.<br />
Improve digiKam GUI everywhere to be more elegant and more optimized for MacOSX.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, MacOSX, scripting, DMG, packaging<br />
<br />
'''Mentor:'''<br />
Julien Narboux ? (Gilles Caulier)<br />
<br />
<br />
==== Project: Video metadata support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
All recent digital-still camera device provide video capture. digiKam must be able to manage these files as images.<br />
digiKam can already play video and register files to the database, but it lack important metadata used to catalog and sort item (as date, camera name, and all record condition).<br />
<br />
To improve video file support, video metadata management done in background need to be improved, to patch [http://www.exiv2.org Exiv2 shared library] (already used by digiKam)<br />
<br />
See relevant entries in KDE bugzilla about video support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=164442 164442] <br />
[https://bugs.kde.org/show_bug.cgi?id=229543 229543]<br />
<br />
'''Expected results:'''<br />
Add video files support to Exiv2.<br />
Patch digiKam metadata interface to handle video information.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, video format, metadata<br />
<br />
'''Mentor:'''<br />
Gilles Caulier, Andreas Huggel<br />
<br />
==== Project: Clone Tool for Image Editor ====<br />
<br />
'''Brief explanation:'''<br />
<br />
In digiKam image editor we need a simple clone tool to be able to remove quickly <br />
dusts, spots, and other unwanted artefact from an image.<br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=132483 132483] <br />
<br />
'''Expected results:'''<br />
add a new tool (as new image editor plugin) with the clone feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
==== Project: Panorama Tool ====<br />
<br />
'''Brief explanation:'''<br />
<br />
With recent digital still camera, it's possible using a tripod to take images to create panoramic view.<br />
We need a tool to assemble these images automatically. Common image corners must be detected and merged without to ask any settings to user.<br />
Colors and luminosity of each shot must be adjusted automatically too. <br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=235766 235766] <br />
<br />
'''Expected results:'''<br />
add a new tool (as kipi plugin) with auto-panorama feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
=== KDE Edu ===<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Games ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDevelop ===<br />
<br />
KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages. <br />
<br />
[http://www.kdevelop.org Website] - [http://www.kdevelop.org/index.html?filename=mailinglist.html Mailing list] - IRC channel: #kdevelop on Freenode. <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDE Core ===<br />
<br />
KDE Core is the interest group working on the underlying KDE development platform such as kdelibs and kde-runtime. KDE Core provides libraries that are used by all KDE applications and so essentially define what a KDE application is. Working on KDE Core is highly challenging as it requires much forward thinking for maximum utility and flexibility as well as guaranteeing backwards compatibility and cross-platform support.<br />
<br />
==== Project: Support for astronomical calendar systems ====<br />
<br />
'''Brief explanation:''' Add support for astronomical calendar systems. KDE is unique in the Linux eco-system for providing support for alternative calendar systems, such as the Hebrew, Islamic Civil, and Japanese calendar systems. Support for such calendar systems is standard in the Windows and Mac worlds. However, KDE does not as yet support calendar systems that require astronomical calculations, such as the Chinese and Islamic Lunar calendars, This project would fill this gap.<br />
<br />
'''Expected results:''' Documentation, design and production of Chinese, Indian, Islamic and Jalali/Persian calendar systems and their numerous derivatives. The documentation to be of a high enough standard to submit to various standardization bodies. Production of an astronomical library for calculating sunrise, sunset and moon phase (and any other useful calculations) for shared use between the calendar systems and other KDE libraries and applications such as KHolidays, KStars and Marble.<br />
<br />
'''Knowledge Prerequisite:''' C++, especially an understanding of Binary Compatibility rules and good API design. Some knowledge of Celestial Mechanics and good mathematical literacy. Any experience with regular cultural use of astronomical calendars would be highly useful.<br />
<br />
'''Mentor:''' John Layt<br />
<br />
=== KDE PIM ===<br />
<br />
KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc. <br />
<br />
There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc. <br />
<br />
[http://pim.kde.org/ Website] - [http://techbase.kde.org/Projects/PIM Project Wiki] - [https://mail.kde.org/mailman/listinfo/kde-pim Mailing list] - IRC channel: #kontact and #akonadi on Freenode.<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Calligra Karbon ===<br />
<br />
Karbon is a vector drawing application with an user interface that is easy to use, highly customizable and extensible. <br />
<br />
[http://www.calligra-suite.org/karbon/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Variable thickness lines ====<br />
<br />
'''Brief explanation:''' <br />
One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.<br />
<br />
This proposal is to modify the path a tool that, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.<br />
<br />
As Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.<br />
<br />
'''Expected results:'''<br />
Modify path tool is able to scale the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup.<br />
<br />
'''Technologies Used:''' <br />
C++,Qt,SVG?<br />
<br />
'''Mentor:'''<br />
Jan H? jaham @t gmx,net (need to ask :P )<br />
<br />
=== Calligra Kexi ===<br />
<br />
Kexi is an open source data management application, long-awaited competitor for programs like MS Access or Filemaker.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kexi/<br />
<br />
Project Page: http://kexi-project.org/<br />
<br />
Irc channel: #kexi on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=203<br />
<br />
Development Wiki: http://community.kde.org/Kexi<br />
<br />
TODO...<br />
<br />
=== Calligra Words ===<br />
<br />
[http://www.calligra-suite.org/words/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Improve quality of ODF write support ====<br />
<br />
'''Brief explanation:''' While a lot of work went into improving the quality of loading ODF text-documents, saving them can still be improved a lot. The goal of the gsoc would be to improve the quality of the by Calligra Words produced ODF. This means fixing the produced ODF text-documents so they a) do validate against the ODF XML-schema and b) are proper loaded with Calligra Words, LibreOffice.org/OpenOffice.org, Microsoft Word, etc. By identifying and fixing bugs and adding unittests for regression-testing we could improve the quality of the core of Calligra significantly.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Implement notes-support ====<br />
<br />
'''Brief explanation:''' Implement and extend the notes-support in Calligra Words to view+add+edit+delete+load+save notes/comments/annotations in Calligra Words.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260138 260138] and [https://bugs.kde.org/show_bug.cgi?id=260184 260184] and [https://bugs.kde.org/show_bug.cgi?id=260102 260102] and [https://bugs.kde.org/show_bug.cgi?id=260127 260127].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Fix and extend LaTEX support ====<br />
<br />
'''Brief explanation:''' Calligra Words has an import and export filter for LaTEX documents. Those need to be extended to proper import/export and produce better results. We could also implement a new view in Calligra Words to support latex like working.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260063 260063] and [https://bugs.kde.org/show_bug.cgi?id=260056 260056].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: PDF-Import and/or PDF-Export ====<br />
<br />
'''Brief explanation:''' Currently Calligra Words supports exporting the drawn canvas as images using the File=>ExportPDF menu-item. The idea is to create an export and/or import filter to import and/or export to/from PDF (not as images but as text) using poppler.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Integrate with Akonadi ====<br />
<br />
'''Brief explanation:''' Integrate with Akonadi to provide access to resources (contacts-variables, mail-merge, ...).<br />
<br />
See also bug [https://bugs.kde.org/show_bug.cgi?id=260220 260220].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: References tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we don't have yet is a references tool that provide the ui for creating table of contents, citations/bibliography, and end notes. Table of centents has all the underlying engine in place. That same engine can be reused/copied/modified for bibliography (maybe planning for the use of http://www.zotero.org )<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
==== Project: Layout tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we need is completion of this layout tool. Much of it is just ui allowing the user to set all sorts of layout options using the engine which is already in place.<br />
<br />
As it's not such a big project, we expect everything about this tool to be perfect so it can enter directly into the next version of Calligra Words.<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
=== Calligra Krita ===<br />
<br />
Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/ <br />
<br />
Project Page: http://www.krita.org/ <br />
<br />
Irc channel: #krita on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=136.<br />
<br />
Wiki: http://community.kde.org/Krita<br />
<br />
==== Project: ABR Brush Support ====<br />
<br />
'''Brief Explanation''': Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resource''': http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita<br />
<br />
==== Project: PSD File import/export Support ====<br />
<br />
'''Brief Explanation''': The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
'''Resources''': existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd<br />
<br />
==== Project: Flow and drying: real media support ====<br />
<br />
'''Brief Explanation''': As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects. Particularly challenging is the flow of undo and redo.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven<br />
<br />
==== Project: 3D Sketching tool ====<br />
<br />
'''Brief Explanation''': When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup<br />
<br />
'''Mentor''': Lukáš Tvrdý or Cyrille Berger <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
==== Project: Text Balloon support for Comics work ====<br />
<br />
'''Brief Explanation''': Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt, SVG<br />
<br />
'''Expected results''': a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.<br />
<br />
'''Resources''': http://en.wikipedia.org/wiki/Speech_balloon<br />
<br />
==== Project: Painting and Separation of 3D Textures ====<br />
<br />
'''Brief Explanation''': As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.<br />
<br />
Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.krita.org<br />
<br />
==== Project: Advanced selection using SIOX ====<br />
<br />
'''Brief explanation''': SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.<br />
<br />
'''Possible mentor''': Cyrille Berger (or Sven Langkamp)<br />
<br />
'''Used Technologies''': C++, Qt<br />
<br />
'''Resources:'''<br />
* http://www.siox.org/ website describing the algorithm,<br />
* https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,<br />
* http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,<br />
* http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction<br />
<br />
==== Project: Tagging and management for Krita resources ====<br />
<br />
'''Brief explanation''': Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.<br />
<br />
'''Expected results''': A functioning implementation of resource management and tagging.<br />
<br />
'''Used Technologies''': C++, Qt, digital art.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: GPU-acceleration for Krita ====<br />
<br />
'''Brief explanation''': Although Krita was one of the first painting applications with OpenGL and shader support, Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming.<br />
Expected results: optimized composition operators, transformation code<br />
Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
==== Project: GPU-backend for OpenGTL ====<br />
<br />
'''Brief explanation''': Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements.<br />
There are two possibilities to implement such a change:<br />
<br />
* Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend<br />
* The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library<br />
<br />
The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.<br />
<br />
This is a very challenging task!<br />
<br />
'''Resources''': http://www.opengtl.org<br />
<br />
'''Expected results''': OpenCL AST generator, report on the possibility to interface OpenGTL with mesa<br />
<br />
'''Used Technologies''': C++, GLSL, OpenCL (possibly LLVM)<br />
<br />
'''Mentor''': Cyrille Berger <br />
<br />
==== Project: Substrate simulation ====<br />
<br />
'''Brief explanation''': Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings.<br />
Expected results: an optional substrate simulation that works with all current Krita tools<br />
<br />
'''Used Technologies''': C++, Qt, OpenGL<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: Color Mixing ====<br />
<br />
'''Brief explanation''': Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.<br />
<br />
'''Expected results''': a color mixer that works, layer composition and painting.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: 3D Material Image Maps ====<br />
'''Brief explanation''': 3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:<br />
<br />
<br />
1. Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.<br />
<br />
2. When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.<br />
<br />
3. In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).<br />
<br />
For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita. <br />
<br />
Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.<br />
<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: Shift drag sensors ====<br />
<br />
'''Brief explanation''': Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
=== KDE on Windows ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KWin ===<br />
<br />
KDE's window manager <br />
<br />
[http://techbase.kde.org/Projects/KWin Techbase page] - [https://mail.kde.org/mailman/listinfo/kwin Mailinglist] - IRC channel: #kwin on Freenode. <br />
<br />
==== Project: Modularization of Workspace ====<br />
<br />
'''Brief explanation:''' <br />
The Workspace class is the monolithic core of KWin. Nevertheless many parts of it do not depend on each other and can be split out of Workspace into own classes. The modularization is an important prerequisite to a port of KWin to Wayland and providing a small window manager for mobile devices.<br />
<br />
'''Expected results:'''<br />
A concept for what can be moved into own classes exists and several classes have been split out of Workspace. The X11 dependend code is moved into an own plugin. Plus if tests for the new classes are written.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of window management. Plus for X11 knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Unit Testing Framework ====<br />
<br />
'''Brief explanation:''' <br />
Testing a window manager is rather difficult as it requires a running instance and windows need to be created and interacted with. This project should set up a test framework based on Xephyr, KWin's scripting interface and QTest.<br />
<br />
'''Expected results:'''<br />
An infrastructure to test the core of KWin with simple KWin scripts should exist and several unit tests for existing functionality should be implemented<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++, JavaScript, QTest<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Initial Support for Wayland Clients ====<br />
<br />
'''Brief explanation:''' <br />
Wayland is the next iteration for composited window management. The task of this project is to add support for managing Wayland clients on X11 and integrate them into the existing compositing rendering code for GLES.<br />
<br />
'''Expected results:'''<br />
KWin is able to manage Wayland clients and can render the clients. Plus for support to interact with them (move/activate/restack).<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of Window management. Plus for OpenGL knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
=== Nepomuk ===<br />
<br />
[http://nepomuk.kde.org Website]- [http://techbase.kde.org/Development/Tutorials#Nepomuk Documentation/Howtos] - [http://www.semanticdesktop.org/ontologies/ Ontologies] - [https://mail.kde.org/mailman/listinfo/nepomuk Mailing list] - IRC channel: #nepomuk-kde on Freenode. <br />
<br />
(Also see the [http://techbase.kde.org/Projects/Nepomuk Nepomuk techbase page] for a long list of Nepomuk-related ToDos and ideas.)<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Plasma ===<br />
<br />
[http://plasma.kde.org Website] - [https://mail.kde.org/mailman/listinfo/panel-dev Mailing list] - IRC channel: #plasma on Freenode. <br />
<br />
==== Project: QML QtComponents set ====<br />
<br />
'''Brief explanation:''' The QtComponents project is aiming to provide an api and a series of widget sets completely based upon QML. the actual implementation is platform-dependent, so KDE needs its own platform specific set made with the plasma theming mechanism,for both the desktop and the mobile.<br />
<br />
'''Expected results:''' A complete set of QtComponents for the use in QML based plasmoid for the desktop, if there is enough time, the start of a mobile version (with as less as possible changed from the desktop case)<br />
<br />
'''Knowledge Prerequisite:''' both QML and Qt C++ programming are useful (and preferred), most of it can be learned on the way<br />
<br />
'''Mentor:''' either Marco Martin and/or Artur De Souza<br />
<br />
==== Project: Plasma media center first release ====<br />
<br />
'''Brief explanation:''' The Plasma media center project needs some work to get to a first alpha release quality: mostly a reingeneering of the components of the main gui and porting the graphical elements to qml<br />
<br />
'''Expected results:''' a basically working media center at least with an index of local media files (videos, pictures and music)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++, QML and some ideas on the Plasma architecture, QML can be learned on the way<br />
<br />
'''Mentor:''' Marco Martin<br />
<br />
==== Project: QML-ify Plasma widgets ====<br />
<br />
'''Brief explanation:''' The Plasma2 library will be heavily based on QML, probably dropping qgraphicswidget support altogether.<br />
All the default plasmoid set will heve to be ported to be either pure QML/Javascript or QML/C++ in the meantime.<br />
<br />
'''Expected results:''' At least 6-7 minor plasmoids ported to QML or some (to define) of the main ones (like kickoff,taskbar, systray, whatever)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++ some idea on Plasma and kdelibs arch, already knowing something of QML helps<br />
<br />
'''Mentor:''' Marco MArtin<br />
<br />
==== Project: Move Plasma Functionality in Compositor ====<br />
<br />
'''Brief explanation:''' <br />
Plasma uses lots of functionality which are better served in the window and compositing manager (KWin). For example Plasma uses an own glow animation before showing a hidden panel. This could be OpenGL accelerated when moved into KWin. Other examples involve Wallpaper rendering or Tooltips.<br />
<br />
It would be the task of the project to identify these areas and to discuss strategies with the Plasma and KWin community how to better handle these areas and to implement the solution.<br />
<br />
'''Expected results:''' <br />
Rendering functionality moved from Plasma to KWin with fallback for legacy (non-composited) and other window managers.<br />
<br />
'''Knowledge Prerequisite:''' <br />
C++/Qt, basic understanding of X, OpenGL useful but not required.<br />
<br />
'''Mentor:'''<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:''' <br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Phonon ===<br />
<br />
Abstraction library for sound and video support. Used by KDE notifications, Amarok, Dragon Player and Qt Software. <br />
<br />
[http://phonon.kde.org Website] - [https://mail.kde.org/mailman/listinfo/phonon-backends Mailing list] - IRC channel: #phonon on Freenode. <br />
<br />
[http://community.kde.org/Phonon Community wiki with TODOs and outstanding issues.]<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Kate ===<br />
<br />
Kate is a powerful programmer's editor. <br />
<br />
<br> [http://www.kate-editor.org Website] - [https://mail.kde.org/mailman/listinfo/kwrite-devel Mailing list] - IRC channel: #kate on Freenode. <br />
<br />
==== Project: Modeline Editor ====<br />
<br />
'''Brief explanation:''' Kate supports modelines, also called [http://docs.kde.org/stable/en/kdesdk/kate/config-variables.html document variables]. Through this, users can configure individual settings for specific documents. The task of this project is to add a modeline editor, that can write/change the document variables in the document.<br />
<br />
'''Expected results:''' A modeline editor that is able to edit the current modeliens. This editor could be reused in the "Modes" tab in Kate's config page.<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, Qt-Designer, high motivation<br />
<br />
'''Mentor:''' Dominik Haumann / Christoph Cullmann<br />
<br />
==== Project: Further improve the Vi Input Mode ====<br />
<br />
'''Brief explanation:''' Kate supports a modal, Vi[m]-like editing mode. The support for Vim features is already quite good in some areas, but there is more to be done:<br />
<br />
* A “jump list” should be maintained of the last cursor positions, making it possible to jump back to earlier positions and forward again (ctrl+i/ctrl+o in vim)<br />
* More command line mode commands should be supported, and it should be possible to use marks in ranges, i.e. “:'a,'bs/foo/bar/”<br />
* A thorough test suite<br />
* [your favourite feature]<br />
<br />
'''Expected results:''' An improved vi input mode for kate<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, high motivation<br />
<br />
'''Mentor:''' Erlend Hamberg<br />
<br />
<br />
==== Project: Elastic Tabstop support ====<br />
<br />
'''Brief explanation:''' [http://nickgravgaard.com/elastictabstops/ Elastic tabstops] are a way to visually align code automatically. Current ways of indentation are a relic from the typewriter era and it is time to try new concepts. Elastic tabstops<br />
<br />
* Put an end to the “tabs vs spaces” debate<br />
* Save the programmer from tinkering with alignment<br />
* Allow the use of proportional fonts<br />
* Degrade gracefully for non-supporting editors<br />
<br />
Apart from implementing the feature itself, one should care about the following:<br />
<br />
* the option “align dynamically wrapped lines to the indentation level” has to be extended to allow the setting “align dynamically wrapped lines to the last tabstop”<br />
* A way has to be found to integrate existing options such as tab width and indentation step width.<br />
<br />
'''Expected results:''' A working option to use elastic tabstops instead of traditional alignment. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt<br />
<br />
'''Mentor:''' Joseph Wenninger<br />
<br />
=== Konqueror ===<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kfm-devel/ https://mail.kde.org/mailman/listinfo/kfm-devel/ <br />
<br />
Project Page: http://www.konqueror.org/ <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Finance ===<br />
<br />
KDE Finance is an emerging group of applications dedicated to financial topics, such as Personal Finances Management, Invoices Management, Point of Sales... <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Rekonq ===<br />
<br />
Rekonq is a web browser for KDE based on WebKit. It first focuses on being a light, fast & clean way to access to net. Its development is doubly based on using the new amazing features offered by the WebKit rendering engine and on the rock solid network KDE technologies.<br />
<br />
==== Project: Adblock improvements & elements manipulation ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq currently has an initial implementation of an ads blocking mechanism. This project aims to expand it providing the feature parity with AdBlockPlus and implement a sort of HTML elements manipulation system (enable it, and then click on the page on the elements you want to hide. When you're ok, save your changes, reset them or leave them just for this time)<br />
<br />
<br />
'''Expected results:'''<br />
<br />
An improvements in the adblock rules handling, some (new) tests to check adblock behavior and performance, the elements manipulation feature with (possibly) the ability to save and remember applied changes.<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
C++ programming and hopefully Qt<br />
<br />
<br />
'''Mentor:'''<br />
[mailto:adjam7@gmail.com Andrea Diamantini]<br />
<br />
==== Project: Plasma KPart for Rekonq ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq provides a specific webpage displayed when the user clicks on the "new tab" button. This webpage has features like: previews of favorite pages, previews of closed tabs, an history list, a bookmark list, and a download list.<br />
The goal of this project is develop the same features as this webpage but using plasmoids displayed in a Plasma KPart.<br />
Additional plasmoids, eg. RSS feeder, could be integrated.<br />
<br />
'''Expected results:'''<br />
<br />
*Customizable new tab page.<br />
*Plasma theme integration<br />
*Same plasmoids inside Rekonq and on the desktop<br />
<br />
'''Mentor:'''<br />
[mailto:megabigbug@yahoo.fr Lionel Chauvin]<br />
<br />
=== ownCloud ===<br />
<br />
An open personal cloud which runs on your personal server. It enables accessing your data from all of your devices. Sharing with other people is also possible. It support automatic backups, versioning and encryption.<br />
<br />
<br> [http://ownCloud.org Website] - [https://mail.kde.org/mailman/listinfo/owncloud Mailing list] - IRC channel: #owncloud on Freenode. <br />
<br />
==== Project: Local sync client ====<br />
<br />
'''Brief explanation:''' <br />
Build a client to sync your ownCloud files with your local disc to enable offline use.<br />
<br />
'''Expected results:'''<br />
Development of an application you run on your local PC. This applications syncs local folders with folders on your personal ownCloud server everytime you are online. This applications needs a GUI written in KDE/Qt to configure the ownCloud url, folders, login and password. The applications sits in the systray and informs the user about the syncing progress or sync conflicts. The idea is that the clients mounts the ownCloud folders via WebDAV into a "hidden" directory and syncs the folders via rsync or an own syncing script. Errors should be reported to the user. To quote Frank from the mailing list:<br />
<br />
"The client should:<br />
1. read a configuration file so see which folders to sync and which owncloud server to use.<br />
2. mount the owncloud server via fuse or a different tool into a hidden directory.<br />
3. call a syncing tool like csync to sync between the local directory and the mounted directory<br />
4. unmount owncloud<br />
5. write a log-file about the synced files and potential conflicts which the user has to solve.<br />
<br />
The client should be as portable as possible of course."<br />
<br />
Current inactive projects such as Cloudsync or owncloud-sync-client (both on Gitorious) may possibly be starting places worth investigating.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Python, Ruby, PHP or C++ and KDE/Qt depending on the technology you choose for the desktop syncing client. Enthusiasm for Cloud/Desktop integration and trying new things.<br />
<br />
'''Mentor:'''<br />
Kyle Cunningham? Robin Appleman? Frank K?<br />
<br />
=== KDE Usability ===<br />
==== Project: Usability Survey Framework ====<br />
<br />
'''Brief explanation:''' <br />
Surveys are one of many methods used in creating more usable software. Surveys allow designers to collect information about user's experiences and usability problems with software. A Usability Survey Framework would allow designers and developers to create small, custom surveys that can be attached to events or services. Users could subscribe to the Usability Survey Service and opt in to current studies. Survey studies could be one-time surveys, or several survey entries over a period of time. <br />
<br />
For example, if we wanted to learn more about how users interact with workspaces, a survey could occasionally open when a user accesses or configures the workspace. If we wanted to learn more about the Plasmoid installation process, we could open a survey when a user installs the next plasmoid.<br />
<br />
A Usability Survey Framework would help users become more involved in KDE through direct participation. Developers would be able to easily design and launch surveys to collect important usability feedback. Designers would be able to easily conduct usability studies.<br />
<br />
'''Expected results:'''<br />
The Usability Survey Framework could be implemented as a web service, downloadable Plasma widget, or mini application. It should be an easily configurable survey that collects data based on an event.<br />
<br />
Possible features:<br />
* Uses XML for survey design to make it easy to create and launch new surveys<br />
* Uploading or emailing data at end of study<br />
* Can be a single survey, or a survey study over a period of time<br />
* Configured to open on a specific event<br />
<br />
'''Knowledge Prerequisite:''' <br />
JavaScript, C++. Qt/KDE/Plasma knowledge would help greatly.<br />
<br />
'''Mentor:'''<br />
Celeste Lyn Paul, someone else?<br />
<br />
=== KDE SDK ===<br />
==== Umbrello UML Modeller QGraphicsView Port: ====<br />
<br />
'''Brief explanation:''' <br />
Umbrello UML Modeller uses the old and limited Q3Canvas class. There is an unfinished port to QGraphicsView that should be completed.<br />
<br />
'''Expected results:'''<br />
A stable Umbrello using QGraphicsView.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Programming Qt. Basic understanding of UML.<br />
<br />
'''Mentor:'''<br />
Jonathan Riddell<br />
<br />
=== KDE Language Bindings ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== Solid ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Wikis ===<br />
==== Project: One-click Spammer removal ====<br />
<br />
'''Brief explanation:'''<br />
Currently Wiki administrators have to go to the spammer's user page and block him for a specified time. Then any pages added by him must be deleted and finally any images added must be found and deleted.<br />
<br />
'''Expected results:''' It would be very useful if administrators could call up the Ban page and be able to remove pages and images with a single click from there. Ideally if spam had been added to an existing page that would be reverted, but this is a less common scenario. The work should be presented as a mediawiki extension.<br />
<br />
'''Knowledge Prerequisite:''' ?<br />
<br />
'''Mentor:''' ?<br />
<br />
=== Okular ===<br />
==== Project: Advanced text layout recognition engine ====<br />
<br />
'''Brief explanation:''' <br />
Okular has a very naive algorithm to detect the layout in text in which basically everything is considered to be layouted in a line. You will need to know some text layouting algorithms to improve the detection of columns in text so that text selection works better.<br />
<br />
See relevant entry in KDE bugzilla about it: [https://bugs.kde.org/show_bug.cgi?id=161324 161324] <br />
<br />
'''Expected results'''<br />
A better text selection experience for the user.<br />
<br />
'''Knowledge Prerequisite'''<br />
C++, Qt<br />
<br />
'''Mentor'''<br />
Albert Astals Cid<br />
<br />
=== Knights ===<br />
<br />
Knights is a chess program for KDE, it resides in Extragear/Games. It supports local plays, playing against a computer engine, an opponent on a chess server, and also watching two computers. It uses the KDE technologies to provide a consistent look-and-feel with Oxygen colors and Plasma clocks. <br />
<br />
[http://noughmad.eu/knights Knights web site]<br />
<br />
==== Project: Saving, loading and analyzing games ====<br />
<br />
'''Brief explanation:''' <br />
Knights currently does not support any form of storing and analyzing games, expect for simple undo and redo. This suffices for casual play, but for serious play something more powerful is needed. <br />
<br />
One part of the project is to enable saving board positions to a file, and reading from it at a different time. This should be done using a standard format (PGN), so that external games can be analyzed with Knights and vice-versa. <br />
<br />
Another part is an "analysis" mode, where a playerc can freely move both his and the opponent's pieces. The interface should rate the current board position, provide hints, maintain alternative timelines for comparison, etc. The student should be in contact with chess players (could be on a forum or IRC) to know the other important features of such a mode. <br />
<br />
'''Expected results:'''<br />
Ability to save move history to a file, and read from it at a later time. <br />
An advanced 'analysis' mode for direct manipulation and interaction with a chess engine, with tools to help the player. <br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Knowledge of Chess rules is not needed, but some contact with chess players is preferred. <br />
<br />
'''Mentor:''' [mailto:miha@noughmad.eu Miha Čančula]<br />
<br />
===Gluon===<br />
Gluon is a Free and Open Source framework for creating and distributing games - supporting the flow of the idea all the way from the author to the player of the finished game, and back.<br />
<br />
[http://gluon.gamingfreedom.org/ Gluon Website]<br />
<br />
[http://gluon.gamingfreedom.org/node/40 Contacting the Gluon team (irc, email etc)]<br />
<br />
====Project: Achievements/statistics system====<br />
<br />
'''Brief explanation:'''<br />
Many digital distribution platforms, such as XBox Live, PlayStation Home and Steam, have a system by which players are granted certain trophies by performing certain tasks in the games they play. Even though they can be, these tasks are not necessarily a part of the normal game-play: For example it might be that you have played a certain level a specific number of times. The Open Collaboration Services have, since version 1.7, contained [http://www.freedesktop.org/wiki/Specifications/open-collaboration-services-draft#Achievements a generalised system for storing achievements and the progress a user has made on them].<br />
<br />
This project is to integrate the OCS Achievements module into Gluon, and to create a general system by which statistics required for tracking progress in a game can be generated.<br />
<br />
'''Expected results:'''<br />
* A set of Components and Assets for storing and tracking statistics of game interactions<br />
* Same for handling the Achievements themselves<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git). Knowledge of achievements systems a plus.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Dynamic Shader Generator====<br />
<br />
'''Brief explanation:''' <br />
Gluon these days features a completely shader-based graphics library. One of the issues with this is that you need to create shaders, which is not trivial for most people. This project would alleviate that problem by creating a system similar to many professional graphics applications, where shaders are created by linking small elements - nodes - together. If time permits, this would also be exposed in the interface properly through a node-based editor.<br />
<br />
'''Expected results:'''<br />
A system that is able to create basic shaders and can be extended to create more advanced shaders.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), OpenGL/GLSL and a general knowledge of graphics programming is a definite must.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Integrating SMARTS Game AI system====<br />
'''Brief explanation:'''<br />
In the fall of 2009 and spring of 2010, three students at Aalborg University created a game AI system based on the simple Behavior Tree concept for use with Gluon. As this was an educational project, however, while the project was completed, the code was never merged into Gluon. This project is to take the project code, clean it up and adapt to new Gluon APIs, and if time permits to create a more pleasantly built and better integrated editor for the behavior trees.<br />
<br />
'''Expected results:'''<br />
* A new sub-module in Gluon containing the standalone parts of the [http://leinir.dk/perceived-challenge/ SMARTS AI system] ([http://gitorious.org/gluon-bt/ gitorious])<br />
* Cleaned up integration of the SMARTS components and assets<br />
* Optional: An editor KPart for integration directly in Gluon Creator<br />
<br />
'''Knowledge prerequisite:'''<br />
C++ development experience, Qt/KDE development experience an advantage but can be disregarded if knowledgeable of other modern OOP frameworks.<br />
<br />
Knowledge of the Behavior Tree concept in general an advantage, but this can be gained in a reasonably short amount of time (as both video tutorials on the concept as well as the reports from the university projects SMARTS resulted from are available, containing descriptions of this).<br />
<br />
Skill level: Novice to medium.<br />
<br />
'''Mentor:'''<br />
Dan Leinir Turthra Jensen and Arjen Hiemstra<br />
<br />
===Telepathy===<br />
Telepathy is a cross-desktop framework for real-time communication and collaboration - think IM, Voice/Video Conferencing and Collaborative document editing/gaming/etc.<br />
<br />
More information:<br />
*[http://telepathy.freedesktop.org Telepathy Framework]<br />
*[http://community.kde.org/Telepathy Telepathy-KDE]<br />
*We can be found on IRC in #kde-telepathy<br />
<br />
====Project: Distributed Shared-State system based on DBus tubes for KDE apps====<br />
<br />
'''Brief explanation:'''<br />
Telepathy DBus tubes provide an easy way for collaborative applications such as KWhiteboard to be built. However, a common issue is the need of applications wishing to use DBus Tubes is the need for a way for participants to keep their application states synchronised in the absence of a single "server". This is an intellectually challenging project as well as requiring coding, so please ensure you join us on IRC and get to know us and the project before submitting a proposal for this project.<br />
<br />
'''Expected results:'''<br />
* A distributed-state mechanism generic enough to be used by any KDE application wishing to build a serverless collaborative system on top of DBus tubes.<br />
* A sample implementation using this state layer, either by adding basic functionality to KWhiteboard or another application of your choice.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* Telepathy development<br />
* As a minimum, a basic understanding of how DBus works<br />
* A desire to take on a challenging project<br />
<br />
Skill level: high.<br />
<br />
'''Mentor:'''<br />
George Goldberg<br />
<br />
====Project: Amarok Playlist Sharing====<br />
See [http://community.kde.org/GSoC/2011/Ideas#Project:_Playlist_sharing]<br />
<br />
====Project: Innovative new UI/Interaction Methods====<br />
<br />
'''Brief explanation:'''<br />
Telepathy allows real-time communication to be integrated far deeper into the computing experience. Come up with some interesting novel ideas for how to make this integration happen (new ways of displaying information, novel plasma integration methods, you name it), and implement them.<br />
<br />
'''Expected results:'''<br />
* This project is very open ended, but we would expect to see a series of deliverables outlined in the proposal along with some justification for why they are interesting ideas. Sufficient research should be undertaken at the proposal stage to ensure the deliverables are suitable and achievable within the context of the rest of the KDE Software Compilation and Workspaces.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* At least basic Telepathy development<br />
* A good imagination and a keen interest in innovative interaction design.<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
George Goldberg<br />
<br />
====Project: Multi-Player gaming in KDE games====<br />
<br />
'''Brief explanation:'''<br />
Telepathy tubes allow collaborative features to easily be added to any application. This project is to develop multiplayer support on top of telepathy for the KDEgames suite of games. If you wish to propose this idea, it is important to discuss your proposal both with the KDE games team and the KDE Telepathy team.<br />
<br />
'''Expected results:'''<br />
* Infrastructure for Telepathy Tubes based multiplayer gaming in KDE games.<br />
* Support for one or more games being played multiplayer over Telepathy Tubes.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* At least basic Telepathy development<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
Someone from KDE Telepathy and someone from KDE Games.</div>Grundleborghttps://community.kde.org/index.php?title=GSoC/2011/Ideas&diff=9594GSoC/2011/Ideas2011-02-10T15:39:33Z<p>Grundleborg: /* Telepathy */</p>
<hr />
<div>== Guidelines ==<br />
<br />
=== Information for Students ===<br />
<br />
These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at. <br />
<br />
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out. <br />
<br />
When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big! <br />
<br />
If there is no specific contact given you can ask questions on the general KDE development list kde-devel@kde.org. See [http://www.kde.org/mailinglists/ the KDE mailing lists page] for information on available mailing lists and how to subscribe. <br />
<br />
=== Adding a Proposal ===<br />
<br />
{{Note|Follow the template of other proposals!}}<br />
<br />
When adding an idea to this section, please try to include the following data: <br />
<br />
:*if the application is not widely known, a description of what it does and where its code lives <br />
:*a brief explanation <br />
:*the expected results <br />
:*pre-requisites for working on your project <br />
:*if applicable, links to more information or discussions <br />
:*mailing list or IRC channel for your application/library/module <br />
:*your name and email address for contact (if you're willing to be a mentor)<br />
<br />
If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.<br />
<br />
== Ideas ==<br />
<br />
'''How to find ideas?''' To see previous Project ideas, see: [[GSoC/2010/Ideas|2010 ideas]]. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.<br />
<br />
<br />
=== Amarok ===<br />
<br />
Amarok is a powerful KDE based music player for Linux and Unix, MacOS X and Windows with an intuitive interface. It makes playing the music you love and discovering new music easier than ever before - and it looks good doing it! <br />
<br />
<br> [http://amarok.kde.org Website] - [https://mail.kde.org/mailman/listinfo/amarok Mailing list] - IRC channel: #amarok on Freenode. <br />
<br />
==== Project: Playlist sharing ====<br />
<br />
'''Brief explanation:''' <br />
Amarok playlist sharing will allow you to select a set of tracks and share them with friends over chat. By using Telepathy lots of IM networks are available including jabber, google talk, AIM, MSN and facebook chat.<br />
<br />
'''Expected results:'''<br />
A plugin will add a PlaylistProvider to Amarok that enable the user to share via HTTP streaming (P2P) a playlist with online friends.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), Telepathy, HTTP streaming and NAT traversal.<br />
<br />
Any of these are optional but not all of them.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Bart Cerneels or Ian Monroe<br />
<br />
==== Project: Self Contained Collection ====<br />
<br />
'''Brief explanation:''' <br />
sqlite file saved in collections own folder. Tie in with USB media device.<br />
More info to follow.<br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), SQL.<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
Unless someone else from the Amarok team can be convinced: Bart Cerneels<br />
<br />
=== digiKam ===<br />
<br />
Photo Management program <br />
<br />
[http://www.digikam.org digiKam project web site] - [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist] - IRC channel: #digikam on Freenode. <br />
<br />
==== Project: Camera UI Revamp ====<br />
<br />
'''Brief explanation:''' <br />
DigiKam features a UI for accessing and downloading pictures from cameras.<br />
The code is rather old, using Qt3Support classes for the icon view, the UI code intermangled deeply with backend code, and has not seen very much care and love for some years.<br />
<br />
This project would involve taking the old code apart, rewriting a clean code base backend and frontend, but also adding user interface elements to make the most important everyday task as easy as possible.<br />
<br />
In more detail: Write a model listing images on a camera (There are two backends, USB mass storage cameras, which are basically files on disk, and gphoto2 cameras, which require access through a library). Take the existing digikam icon view and delegate classes, which are prepared for code reuse, and put together an icon view for the model. Cleanly separate the code that does the actual work (downloading, converting, renaming) from the UI. Wrap that in the main window.<br />
<br />
UI design: The current interface is powerful, exposing many options. We want to preserve that. But at the same time, there are three very common actions: a) Download all new files to the last used album b) Download all new files to a new album c) Download all new files to an existing album.<br/><br />
It should be possible to carry out task (a) with one click, task (b) and (c) with two or three clicks, without opening a dialog. Friendly to the new user, preserving access to all options for the poweruser.<br />
<br />
'''Expected results:'''<br />
A camera UI based on Qt model/view and clean code which provides the currently available functionality, offering a quick path to download new pictures.<br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Interest in Qt model/view and UI code.<br />
<br />
'''Mentor:''' Gilles Caulier? (Marcel Wiesweg)<br />
<br />
<br />
==== Project: Presentation View ====<br />
<br />
'''Brief explanation:''' <br />
The presentation view is a full-screen workplace which you can use to present photos to yourself or your audience. At first glance it is looking like the current slide show, but then it is much more flexible: At any moment, you can access UI components like the map view, the metadata tab, the image properties tab, to access information, assign metadata, or show your audience the location of the picture on OpenStreetMap. You can access an icon view component to change the collection your are currently presenting, or a thumbbar component to switch to a different image.<br />
<br />
The main view typically shows one image full screen, but you can zoom; You can also change to a layout that shows four or five images at a time, like images put in a paper album.<br />
You can change the order of images presented, and store order and layout (preferably in some XML format). You can load these presentations later, playing them automatically, coming back to the traditional slide show.<br />
<br />
Technically, it should be future proof as much as possible (Qt Quick. QGraphicsView. scene graph in the future? Will embed QWidgets though) The job is not to develop any of the components mentioned above, but to avoid that, and reuse the existing digikam components and models.<br />
<br />
'''Expected results:'''<br />
Something resembling the vision outlined above<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Marcel Wiesweg<br />
<br />
<br />
==== Project: MacOSX support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
digiKam needs to be available under MacOSX in native. Currently, [http://www.macports.org - Macports project] is the only way to get last digiKam under Mac.<br />
Macports require to compile all depencies and digiKam as well. It's a long and hazardous solution to see digiKam running under Mac.<br />
<br />
Also, current digiKam implementation is not optimized for Mac desktop. A lots of point need to be improved to support better this operating system.<br />
Graphical interface need to polished too.<br />
<br />
See relevant entries in KDE bugzilla about MacOSX support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=257679 257679] <br />
[https://bugs.kde.org/show_bug.cgi?id=257773 257773]<br />
<br />
'''Expected results:'''<br />
Provide scripts and configurations to build automatically a DMG archive of digiKam for MacOSX.<br />
Improve digiKam GUI everywhere to be more elegant and more optimized for MacOSX.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, MacOSX, scripting, DMG, packaging<br />
<br />
'''Mentor:'''<br />
Julien Narboux ? (Gilles Caulier)<br />
<br />
<br />
==== Project: Video metadata support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
All recent digital-still camera device provide video capture. digiKam must be able to manage these files as images.<br />
digiKam can already play video and register files to the database, but it lack important metadata used to catalog and sort item (as date, camera name, and all record condition).<br />
<br />
To improve video file support, video metadata management done in background need to be improved, to patch [http://www.exiv2.org Exiv2 shared library] (already used by digiKam)<br />
<br />
See relevant entries in KDE bugzilla about video support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=164442 164442] <br />
[https://bugs.kde.org/show_bug.cgi?id=229543 229543]<br />
<br />
'''Expected results:'''<br />
Add video files support to Exiv2.<br />
Patch digiKam metadata interface to handle video information.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, video format, metadata<br />
<br />
'''Mentor:'''<br />
Gilles Caulier, Andreas Huggel<br />
<br />
==== Project: Clone Tool for Image Editor ====<br />
<br />
'''Brief explanation:'''<br />
<br />
In digiKam image editor we need a simple clone tool to be able to remove quickly <br />
dusts, spots, and other unwanted artefact from an image.<br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=132483 132483] <br />
<br />
'''Expected results:'''<br />
add a new tool (as new image editor plugin) with the clone feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
==== Project: Panorama Tool ====<br />
<br />
'''Brief explanation:'''<br />
<br />
With recent digital still camera, it's possible using a tripod to take images to create panoramic view.<br />
We need a tool to assemble these images automatically. Common image corners must be detected and merged without to ask any settings to user.<br />
Colors and luminosity of each shot must be adjusted automatically too. <br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=235766 235766] <br />
<br />
'''Expected results:'''<br />
add a new tool (as kipi plugin) with auto-panorama feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
=== KDE Edu ===<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Games ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDevelop ===<br />
<br />
KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages. <br />
<br />
[http://www.kdevelop.org Website] - [http://www.kdevelop.org/index.html?filename=mailinglist.html Mailing list] - IRC channel: #kdevelop on Freenode. <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDE Core ===<br />
<br />
KDE Core is the interest group working on the underlying KDE development platform such as kdelibs and kde-runtime. KDE Core provides libraries that are used by all KDE applications and so essentially define what a KDE application is. Working on KDE Core is highly challenging as it requires much forward thinking for maximum utility and flexibility as well as guaranteeing backwards compatibility and cross-platform support.<br />
<br />
==== Project: Support for astronomical calendar systems ====<br />
<br />
'''Brief explanation:''' Add support for astronomical calendar systems. KDE is unique in the Linux eco-system for providing support for alternative calendar systems, such as the Hebrew, Islamic Civil, and Japanese calendar systems. Support for such calendar systems is standard in the Windows and Mac worlds. However, KDE does not as yet support calendar systems that require astronomical calculations, such as the Chinese and Islamic Lunar calendars, This project would fill this gap.<br />
<br />
'''Expected results:''' Documentation, design and production of Chinese, Indian, Islamic and Jalali/Persian calendar systems and their numerous derivatives. The documentation to be of a high enough standard to submit to various standardization bodies. Production of an astronomical library for calculating sunrise, sunset and moon phase (and any other useful calculations) for shared use between the calendar systems and other KDE libraries and applications such as KHolidays, KStars and Marble.<br />
<br />
'''Knowledge Prerequisite:''' C++, especially an understanding of Binary Compatibility rules and good API design. Some knowledge of Celestial Mechanics and good mathematical literacy. Any experience with regular cultural use of astronomical calendars would be highly useful.<br />
<br />
'''Mentor:''' John Layt<br />
<br />
=== KDE PIM ===<br />
<br />
KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc. <br />
<br />
There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc. <br />
<br />
[http://pim.kde.org/ Website] - [http://techbase.kde.org/Projects/PIM Project Wiki] - [https://mail.kde.org/mailman/listinfo/kde-pim Mailing list] - IRC channel: #kontact and #akonadi on Freenode.<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Calligra Karbon ===<br />
<br />
Karbon is a vector drawing application with an user interface that is easy to use, highly customizable and extensible. <br />
<br />
[http://www.calligra-suite.org/karbon/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Variable thickness lines ====<br />
<br />
'''Brief explanation:''' <br />
One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.<br />
<br />
This proposal is to modify the path a tool that, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.<br />
<br />
As Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.<br />
<br />
'''Expected results:'''<br />
Modify path tool is able to scale the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup.<br />
<br />
'''Technologies Used:''' <br />
C++,Qt,SVG?<br />
<br />
'''Mentor:'''<br />
Jan H? jaham @t gmx,net (need to ask :P )<br />
<br />
=== Calligra Kexi ===<br />
<br />
Kexi is an open source data management application, long-awaited competitor for programs like MS Access or Filemaker.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kexi/<br />
<br />
Project Page: http://kexi-project.org/<br />
<br />
Irc channel: #kexi on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=203<br />
<br />
Development Wiki: http://community.kde.org/Kexi<br />
<br />
TODO...<br />
<br />
=== Calligra Words ===<br />
<br />
[http://www.calligra-suite.org/words/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Improve quality of ODF write support ====<br />
<br />
'''Brief explanation:''' While a lot of work went into improving the quality of loading ODF text-documents, saving them can still be improved a lot. The goal of the gsoc would be to improve the quality of the by Calligra Words produced ODF. This means fixing the produced ODF text-documents so they a) do validate against the ODF XML-schema and b) are proper loaded with Calligra Words, LibreOffice.org/OpenOffice.org, Microsoft Word, etc. By identifying and fixing bugs and adding unittests for regression-testing we could improve the quality of the core of Calligra significantly.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Implement notes-support ====<br />
<br />
'''Brief explanation:''' Implement and extend the notes-support in Calligra Words to view+add+edit+delete+load+save notes/comments/annotations in Calligra Words.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260138 260138] and [https://bugs.kde.org/show_bug.cgi?id=260184 260184] and [https://bugs.kde.org/show_bug.cgi?id=260102 260102] and [https://bugs.kde.org/show_bug.cgi?id=260127 260127].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Fix and extend LaTEX support ====<br />
<br />
'''Brief explanation:''' Calligra Words has an import and export filter for LaTEX documents. Those need to be extended to proper import/export and produce better results. We could also implement a new view in Calligra Words to support latex like working.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260063 260063] and [https://bugs.kde.org/show_bug.cgi?id=260056 260056].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: PDF-Import and/or PDF-Export ====<br />
<br />
'''Brief explanation:''' Currently Calligra Words supports exporting the drawn canvas as images using the File=>ExportPDF menu-item. The idea is to create an export and/or import filter to import and/or export to/from PDF (not as images but as text) using poppler.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Integrate with Akonadi ====<br />
<br />
'''Brief explanation:''' Integrate with Akonadi to provide access to resources (contacts-variables, mail-merge, ...).<br />
<br />
See also bug [https://bugs.kde.org/show_bug.cgi?id=260220 260220].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: References tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we don't have yet is a references tool that provide the ui for creating table of contents, citations/bibliography, and end notes. Table of centents has all the underlying engine in place. That same engine can be reused/copied/modified for bibliography (maybe planning for the use of http://www.zotero.org )<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
==== Project: Layout tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we need is completion of this layout tool. Much of it is just ui allowing the user to set all sorts of layout options using the engine which is already in place.<br />
<br />
As it's not such a big project, we expect everything about this tool to be perfect so it can enter directly into the next version of Calligra Words.<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
=== Calligra Krita ===<br />
<br />
Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/ <br />
<br />
Project Page: http://www.krita.org/ <br />
<br />
Irc channel: #krita on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=136.<br />
<br />
Wiki: http://community.kde.org/Krita<br />
<br />
==== Project: ABR Brush Support ====<br />
<br />
'''Brief Explanation''': Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resource''': http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita<br />
<br />
==== Project: PSD File import/export Support ====<br />
<br />
'''Brief Explanation''': The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
'''Resources''': existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd<br />
<br />
==== Project: Flow and drying: real media support ====<br />
<br />
'''Brief Explanation''': As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects. Particularly challenging is the flow of undo and redo.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven<br />
<br />
==== Project: 3D Sketching tool ====<br />
<br />
'''Brief Explanation''': When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup<br />
<br />
'''Mentor''': Lukáš Tvrdý or Cyrille Berger <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
==== Project: Text Balloon support for Comics work ====<br />
<br />
'''Brief Explanation''': Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt, SVG<br />
<br />
'''Expected results''': a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.<br />
<br />
'''Resources''': http://en.wikipedia.org/wiki/Speech_balloon<br />
<br />
==== Project: Painting and Separation of 3D Textures ====<br />
<br />
'''Brief Explanation''': As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.<br />
<br />
Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.krita.org<br />
<br />
==== Project: Advanced selection using SIOX ====<br />
<br />
'''Brief explanation''': SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.<br />
<br />
'''Possible mentor''': Cyrille Berger (or Sven Langkamp)<br />
<br />
'''Used Technologies''': C++, Qt<br />
<br />
'''Resources:'''<br />
* http://www.siox.org/ website describing the algorithm,<br />
* https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,<br />
* http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,<br />
* http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction<br />
<br />
==== Project: Tagging and management for Krita resources ====<br />
<br />
'''Brief explanation''': Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.<br />
<br />
'''Expected results''': A functioning implementation of resource management and tagging.<br />
<br />
'''Used Technologies''': C++, Qt, digital art.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: GPU-acceleration for Krita ====<br />
<br />
'''Brief explanation''': Although Krita was one of the first painting applications with OpenGL and shader support, Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming.<br />
Expected results: optimized composition operators, transformation code<br />
Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
==== Project: GPU-backend for OpenGTL ====<br />
<br />
'''Brief explanation''': Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements.<br />
There are two possibilities to implement such a change:<br />
<br />
* Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend<br />
* The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library<br />
<br />
The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.<br />
<br />
This is a very challenging task!<br />
<br />
'''Resources''': http://www.opengtl.org<br />
<br />
'''Expected results''': OpenCL AST generator, report on the possibility to interface OpenGTL with mesa<br />
<br />
'''Used Technologies''': C++, GLSL, OpenCL (possibly LLVM)<br />
<br />
'''Mentor''': Cyrille Berger <br />
<br />
==== Project: Substrate simulation ====<br />
<br />
'''Brief explanation''': Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings.<br />
Expected results: an optional substrate simulation that works with all current Krita tools<br />
<br />
'''Used Technologies''': C++, Qt, OpenGL<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: Color Mixing ====<br />
<br />
'''Brief explanation''': Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.<br />
<br />
'''Expected results''': a color mixer that works, layer composition and painting.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: 3D Material Image Maps ====<br />
'''Brief explanation''': 3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:<br />
<br />
<br />
1. Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.<br />
<br />
2. When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.<br />
<br />
3. In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).<br />
<br />
For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita. <br />
<br />
Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.<br />
<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: Shift drag sensors ====<br />
<br />
'''Brief explanation''': Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
=== KDE on Windows ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KWin ===<br />
<br />
KDE's window manager <br />
<br />
[http://techbase.kde.org/Projects/KWin Techbase page] - [https://mail.kde.org/mailman/listinfo/kwin Mailinglist] - IRC channel: #kwin on Freenode. <br />
<br />
==== Project: Modularization of Workspace ====<br />
<br />
'''Brief explanation:''' <br />
The Workspace class is the monolithic core of KWin. Nevertheless many parts of it do not depend on each other and can be split out of Workspace into own classes. The modularization is an important prerequisite to a port of KWin to Wayland and providing a small window manager for mobile devices.<br />
<br />
'''Expected results:'''<br />
A concept for what can be moved into own classes exists and several classes have been split out of Workspace. The X11 dependend code is moved into an own plugin. Plus if tests for the new classes are written.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of window management. Plus for X11 knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Unit Testing Framework ====<br />
<br />
'''Brief explanation:''' <br />
Testing a window manager is rather difficult as it requires a running instance and windows need to be created and interacted with. This project should set up a test framework based on Xephyr, KWin's scripting interface and QTest.<br />
<br />
'''Expected results:'''<br />
An infrastructure to test the core of KWin with simple KWin scripts should exist and several unit tests for existing functionality should be implemented<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++, JavaScript, QTest<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Initial Support for Wayland Clients ====<br />
<br />
'''Brief explanation:''' <br />
Wayland is the next iteration for composited window management. The task of this project is to add support for managing Wayland clients on X11 and integrate them into the existing compositing rendering code for GLES.<br />
<br />
'''Expected results:'''<br />
KWin is able to manage Wayland clients and can render the clients. Plus for support to interact with them (move/activate/restack).<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of Window management. Plus for OpenGL knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
=== Nepomuk ===<br />
<br />
[http://nepomuk.kde.org Website]- [http://techbase.kde.org/Development/Tutorials#Nepomuk Documentation/Howtos] - [http://www.semanticdesktop.org/ontologies/ Ontologies] - [https://mail.kde.org/mailman/listinfo/nepomuk Mailing list] - IRC channel: #nepomuk-kde on Freenode. <br />
<br />
(Also see the [http://techbase.kde.org/Projects/Nepomuk Nepomuk techbase page] for a long list of Nepomuk-related ToDos and ideas.)<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Plasma ===<br />
<br />
[http://plasma.kde.org Website] - [https://mail.kde.org/mailman/listinfo/panel-dev Mailing list] - IRC channel: #plasma on Freenode. <br />
<br />
==== Project: QML QtComponents set ====<br />
<br />
'''Brief explanation:''' The QtComponents project is aiming to provide an api and a series of widget sets completely based upon QML. the actual implementation is platform-dependent, so KDE needs its own platform specific set made with the plasma theming mechanism,for both the desktop and the mobile.<br />
<br />
'''Expected results:''' A complete set of QtComponents for the use in QML based plasmoid for the desktop, if there is enough time, the start of a mobile version (with as less as possible changed from the desktop case)<br />
<br />
'''Knowledge Prerequisite:''' both QML and Qt C++ programming are useful (and preferred), most of it can be learned on the way<br />
<br />
'''Mentor:''' either Marco Martin and/or Artur De Souza<br />
<br />
==== Project: Plasma media center first release ====<br />
<br />
'''Brief explanation:''' The Plasma media center project needs some work to get to a first alpha release quality: mostly a reingeneering of the components of the main gui and porting the graphical elements to qml<br />
<br />
'''Expected results:''' a basically working media center at least with an index of local media files (videos, pictures and music)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++, QML and some ideas on the Plasma architecture, QML can be learned on the way<br />
<br />
'''Mentor:''' Marco Martin<br />
<br />
==== Project: QML-ify Plasma widgets ====<br />
<br />
'''Brief explanation:''' The Plasma2 library will be heavily based on QML, probably dropping qgraphicswidget support altogether.<br />
All the default plasmoid set will heve to be ported to be either pure QML/Javascript or QML/C++ in the meantime.<br />
<br />
'''Expected results:''' At least 6-7 minor plasmoids ported to QML or some (to define) of the main ones (like kickoff,taskbar, systray, whatever)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++ some idea on Plasma and kdelibs arch, already knowing something of QML helps<br />
<br />
'''Mentor:''' Marco MArtin<br />
<br />
==== Project: Move Plasma Functionality in Compositor ====<br />
<br />
'''Brief explanation:''' <br />
Plasma uses lots of functionality which are better served in the window and compositing manager (KWin). For example Plasma uses an own glow animation before showing a hidden panel. This could be OpenGL accelerated when moved into KWin. Other examples involve Wallpaper rendering or Tooltips.<br />
<br />
It would be the task of the project to identify these areas and to discuss strategies with the Plasma and KWin community how to better handle these areas and to implement the solution.<br />
<br />
'''Expected results:''' <br />
Rendering functionality moved from Plasma to KWin with fallback for legacy (non-composited) and other window managers.<br />
<br />
'''Knowledge Prerequisite:''' <br />
C++/Qt, basic understanding of X, OpenGL useful but not required.<br />
<br />
'''Mentor:'''<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:''' <br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Phonon ===<br />
<br />
Abstraction library for sound and video support. Used by KDE notifications, Amarok, Dragon Player and Qt Software. <br />
<br />
[http://phonon.kde.org Website] - [https://mail.kde.org/mailman/listinfo/phonon-backends Mailing list] - IRC channel: #phonon on Freenode. <br />
<br />
[http://community.kde.org/Phonon Community wiki with TODOs and outstanding issues.]<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Kate ===<br />
<br />
Kate is a powerful programmer's editor. <br />
<br />
<br> [http://www.kate-editor.org Website] - [https://mail.kde.org/mailman/listinfo/kwrite-devel Mailing list] - IRC channel: #kate on Freenode. <br />
<br />
==== Project: Modeline Editor ====<br />
<br />
'''Brief explanation:''' Kate supports modelines, also called [http://docs.kde.org/stable/en/kdesdk/kate/config-variables.html document variables]. Through this, users can configure individual settings for specific documents. The task of this project is to add a modeline editor, that can write/change the document variables in the document.<br />
<br />
'''Expected results:''' A modeline editor that is able to edit the current modeliens. This editor could be reused in the "Modes" tab in Kate's config page.<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, Qt-Designer, high motivation<br />
<br />
'''Mentor:''' Dominik Haumann / Christoph Cullmann<br />
<br />
==== Project: Further improve the Vi Input Mode ====<br />
<br />
'''Brief explanation:''' Kate supports a modal, Vi[m]-like editing mode. The support for Vim features is already quite good in some areas, but there is more to be done:<br />
<br />
* A “jump list” should be maintained of the last cursor positions, making it possible to jump back to earlier positions and forward again (ctrl+i/ctrl+o in vim)<br />
* More command line mode commands should be supported, and it should be possible to use marks in ranges, i.e. “:'a,'bs/foo/bar/”<br />
* A thorough test suite<br />
* [your favourite feature]<br />
<br />
'''Expected results:''' An improved vi input mode for kate<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, high motivation<br />
<br />
'''Mentor:''' Erlend Hamberg<br />
<br />
<br />
==== Project: Elastic Tabstop support ====<br />
<br />
'''Brief explanation:''' [http://nickgravgaard.com/elastictabstops/ Elastic tabstops] are a way to visually align code automatically. Current ways of indentation are a relic from the typewriter era and it is time to try new concepts. Elastic tabstops<br />
<br />
* Put an end to the “tabs vs spaces” debate<br />
* Save the programmer from tinkering with alignment<br />
* Allow the use of proportional fonts<br />
* Degrade gracefully for non-supporting editors<br />
<br />
Apart from implementing the feature itself, one should care about the following:<br />
<br />
* the option “align dynamically wrapped lines to the indentation level” has to be extended to allow the setting “align dynamically wrapped lines to the last tabstop”<br />
* A way has to be found to integrate existing options such as tab width and indentation step width.<br />
<br />
'''Expected results:''' A working option to use elastic tabstops instead of traditional alignment. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt<br />
<br />
'''Mentor:''' Joseph Wenninger<br />
<br />
=== Konqueror ===<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kfm-devel/ https://mail.kde.org/mailman/listinfo/kfm-devel/ <br />
<br />
Project Page: http://www.konqueror.org/ <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Finance ===<br />
<br />
KDE Finance is an emerging group of applications dedicated to financial topics, such as Personal Finances Management, Invoices Management, Point of Sales... <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Rekonq ===<br />
<br />
Rekonq is a web browser for KDE based on WebKit. It first focuses on being a light, fast & clean way to access to net. Its development is doubly based on using the new amazing features offered by the WebKit rendering engine and on the rock solid network KDE technologies.<br />
<br />
==== Project: Adblock improvements & elements manipulation ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq currently has an initial implementation of an ads blocking mechanism. This project aims to expand it providing the feature parity with AdBlockPlus and implement a sort of HTML elements manipulation system (enable it, and then click on the page on the elements you want to hide. When you're ok, save your changes, reset them or leave them just for this time)<br />
<br />
<br />
'''Expected results:'''<br />
<br />
An improvements in the adblock rules handling, some (new) tests to check adblock behavior and performance, the elements manipulation feature with (possibly) the ability to save and remember applied changes.<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
C++ programming and hopefully Qt<br />
<br />
<br />
'''Mentor:'''<br />
[mailto:adjam7@gmail.com Andrea Diamantini]<br />
<br />
==== Project: Plasma KPart for Rekonq ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq provides a specific webpage displayed when the user clicks on the "new tab" button. This webpage has features like: previews of favorite pages, previews of closed tabs, an history list, a bookmark list, and a download list.<br />
The goal of this project is develop the same features as this webpage but using plasmoids displayed in a Plasma KPart.<br />
Additional plasmoids, eg. RSS feeder, could be integrated.<br />
<br />
'''Expected results:'''<br />
<br />
*Customizable new tab page.<br />
*Plasma theme integration<br />
*Same plasmoids inside Rekonq and on the desktop<br />
<br />
'''Mentor:'''<br />
[mailto:megabigbug@yahoo.fr Lionel Chauvin]<br />
<br />
=== ownCloud ===<br />
<br />
An open personal cloud which runs on your personal server. It enables accessing your data from all of your devices. Sharing with other people is also possible. It support automatic backups, versioning and encryption.<br />
<br />
<br> [http://ownCloud.org Website] - [https://mail.kde.org/mailman/listinfo/owncloud Mailing list] - IRC channel: #owncloud on Freenode. <br />
<br />
==== Project: Local sync client ====<br />
<br />
'''Brief explanation:''' <br />
Build a client to sync your ownCloud files with your local disc to enable offline use.<br />
<br />
'''Expected results:'''<br />
Development of an application you run on your local PC. This applications syncs local folders with folders on your personal ownCloud server everytime you are online. This applications needs a GUI written in KDE/Qt to configure the ownCloud url, folders, login and password. The applications sits in the systray and informs the user about the syncing progress or sync conflicts. The idea is that the clients mounts the ownCloud folders via WebDAV into a "hidden" directory and syncs the folders via rsync or an own syncing script. Errors should be reported to the user. To quote Frank from the mailing list:<br />
<br />
"The client should:<br />
1. read a configuration file so see which folders to sync and which owncloud server to use.<br />
2. mount the owncloud server via fuse or a different tool into a hidden directory.<br />
3. call a syncing tool like csync to sync between the local directory and the mounted directory<br />
4. unmount owncloud<br />
5. write a log-file about the synced files and potential conflicts which the user has to solve.<br />
<br />
The client should be as portable as possible of course."<br />
<br />
Current inactive projects such as Cloudsync or owncloud-sync-client (both on Gitorious) may possibly be starting places worth investigating.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Python, Ruby, PHP or C++ and KDE/Qt depending on the technology you choose for the desktop syncing client. Enthusiasm for Cloud/Desktop integration and trying new things.<br />
<br />
'''Mentor:'''<br />
Kyle Cunningham? Robin Appleman? Frank K?<br />
<br />
=== KDE Usability ===<br />
==== Project: Usability Survey Framework ====<br />
<br />
'''Brief explanation:''' <br />
Surveys are one of many methods used in creating more usable software. Surveys allow designers to collect information about user's experiences and usability problems with software. A Usability Survey Framework would allow designers and developers to create small, custom surveys that can be attached to events or services. Users could subscribe to the Usability Survey Service and opt in to current studies. Survey studies could be one-time surveys, or several survey entries over a period of time. <br />
<br />
For example, if we wanted to learn more about how users interact with workspaces, a survey could occasionally open when a user accesses or configures the workspace. If we wanted to learn more about the Plasmoid installation process, we could open a survey when a user installs the next plasmoid.<br />
<br />
A Usability Survey Framework would help users become more involved in KDE through direct participation. Developers would be able to easily design and launch surveys to collect important usability feedback. Designers would be able to easily conduct usability studies.<br />
<br />
'''Expected results:'''<br />
The Usability Survey Framework could be implemented as a web service, downloadable Plasma widget, or mini application. It should be an easily configurable survey that collects data based on an event.<br />
<br />
Possible features:<br />
* Uses XML for survey design to make it easy to create and launch new surveys<br />
* Uploading or emailing data at end of study<br />
* Can be a single survey, or a survey study over a period of time<br />
* Configured to open on a specific event<br />
<br />
'''Knowledge Prerequisite:''' <br />
JavaScript, C++. Qt/KDE/Plasma knowledge would help greatly.<br />
<br />
'''Mentor:'''<br />
Celeste Lyn Paul, someone else?<br />
<br />
=== KDE SDK ===<br />
==== Umbrello UML Modeller QGraphicsView Port: ====<br />
<br />
'''Brief explanation:''' <br />
Umbrello UML Modeller uses the old and limited Q3Canvas class. There is an unfinished port to QGraphicsView that should be completed.<br />
<br />
'''Expected results:'''<br />
A stable Umbrello using QGraphicsView.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Programming Qt. Basic understanding of UML.<br />
<br />
'''Mentor:'''<br />
Jonathan Riddell<br />
<br />
=== KDE Language Bindings ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== Solid ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Wikis ===<br />
==== Project: One-click Spammer removal ====<br />
<br />
'''Brief explanation:'''<br />
Currently Wiki administrators have to go to the spammer's user page and block him for a specified time. Then any pages added by him must be deleted and finally any images added must be found and deleted.<br />
<br />
'''Expected results:''' It would be very useful if administrators could call up the Ban page and be able to remove pages and images with a single click from there. Ideally if spam had been added to an existing page that would be reverted, but this is a less common scenario. The work should be presented as a mediawiki extension.<br />
<br />
'''Knowledge Prerequisite:''' ?<br />
<br />
'''Mentor:''' ?<br />
<br />
=== Okular ===<br />
==== Project: Advanced text layout recognition engine ====<br />
<br />
'''Brief explanation:''' <br />
Okular has a very naive algorithm to detect the layout in text in which basically everything is considered to be layouted in a line. You will need to know some text layouting algorithms to improve the detection of columns in text so that text selection works better.<br />
<br />
See relevant entry in KDE bugzilla about it: [https://bugs.kde.org/show_bug.cgi?id=161324 161324] <br />
<br />
'''Expected results'''<br />
A better text selection experience for the user.<br />
<br />
'''Knowledge Prerequisite'''<br />
C++, Qt<br />
<br />
'''Mentor'''<br />
Albert Astals Cid<br />
<br />
=== Knights ===<br />
<br />
Knights is a chess program for KDE, it resides in Extragear/Games. It supports local plays, playing against a computer engine, an opponent on a chess server, and also watching two computers. It uses the KDE technologies to provide a consistent look-and-feel with Oxygen colors and Plasma clocks. <br />
<br />
[http://noughmad.eu/knights Knights web site]<br />
<br />
==== Project: Saving, loading and analyzing games ====<br />
<br />
'''Brief explanation:''' <br />
Knights currently does not support any form of storing and analyzing games, expect for simple undo and redo. This suffices for casual play, but for serious play something more powerful is needed. <br />
<br />
One part of the project is to enable saving board positions to a file, and reading from it at a different time. This should be done using a standard format (PGN), so that external games can be analyzed with Knights and vice-versa. <br />
<br />
Another part is an "analysis" mode, where a playerc can freely move both his and the opponent's pieces. The interface should rate the current board position, provide hints, maintain alternative timelines for comparison, etc. The student should be in contact with chess players (could be on a forum or IRC) to know the other important features of such a mode. <br />
<br />
'''Expected results:'''<br />
Ability to save move history to a file, and read from it at a later time. <br />
An advanced 'analysis' mode for direct manipulation and interaction with a chess engine, with tools to help the player. <br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Knowledge of Chess rules is not needed, but some contact with chess players is preferred. <br />
<br />
'''Mentor:''' [mailto:miha@noughmad.eu Miha Čančula]<br />
<br />
===Gluon===<br />
Gluon is a Free and Open Source framework for creating and distributing games - supporting the flow of the idea all the way from the author to the player of the finished game, and back.<br />
<br />
[http://gluon.gamingfreedom.org/ Gluon Website]<br />
<br />
[http://gluon.gamingfreedom.org/node/40 Contacting the Gluon team (irc, email etc)]<br />
<br />
====Project: Achievements/statistics system====<br />
<br />
'''Brief explanation:'''<br />
Many digital distribution platforms, such as XBox Live, PlayStation Home and Steam, have a system by which players are granted certain trophies by performing certain tasks in the games they play. Even though they can be, these tasks are not necessarily a part of the normal game-play: For example it might be that you have played a certain level a specific number of times. The Open Collaboration Services have, since version 1.7, contained [http://www.freedesktop.org/wiki/Specifications/open-collaboration-services-draft#Achievements a generalised system for storing achievements and the progress a user has made on them].<br />
<br />
This project is to integrate the OCS Achievements module into Gluon, and to create a general system by which statistics required for tracking progress in a game can be generated.<br />
<br />
'''Expected results:'''<br />
* A set of Components and Assets for storing and tracking statistics of game interactions<br />
* Same for handling the Achievements themselves<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git). Knowledge of achievements systems a plus.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Dynamic Shader Generator====<br />
<br />
'''Brief explanation:''' <br />
Gluon these days features a completely shader-based graphics library. One of the issues with this is that you need to create shaders, which is not trivial for most people. This project would alleviate that problem by creating a system similar to many professional graphics applications, where shaders are created by linking small elements - nodes - together. If time permits, this would also be exposed in the interface properly through a node-based editor.<br />
<br />
'''Expected results:'''<br />
A system that is able to create basic shaders and can be extended to create more advanced shaders.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), OpenGL/GLSL and a general knowledge of graphics programming is a definite must.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Integrating SMARTS Game AI system====<br />
'''Brief explanation:'''<br />
In the fall of 2009 and spring of 2010, three students at Aalborg University created a game AI system based on the simple Behavior Tree concept for use with Gluon. As this was an educational project, however, while the project was completed, the code was never merged into Gluon. This project is to take the project code, clean it up and adapt to new Gluon APIs, and if time permits to create a more pleasantly built and better integrated editor for the behavior trees.<br />
<br />
'''Expected results:'''<br />
* A new sub-module in Gluon containing the standalone parts of the [http://leinir.dk/perceived-challenge/ SMARTS AI system] ([http://gitorious.org/gluon-bt/ gitorious])<br />
* Cleaned up integration of the SMARTS components and assets<br />
* Optional: An editor KPart for integration directly in Gluon Creator<br />
<br />
'''Knowledge prerequisite:'''<br />
C++ development experience, Qt/KDE development experience an advantage but can be disregarded if knowledgeable of other modern OOP frameworks.<br />
<br />
Knowledge of the Behavior Tree concept in general an advantage, but this can be gained in a reasonably short amount of time (as both video tutorials on the concept as well as the reports from the university projects SMARTS resulted from are available, containing descriptions of this).<br />
<br />
Skill level: Novice to medium.<br />
<br />
'''Mentor:'''<br />
Dan Leinir Turthra Jensen and Arjen Hiemstra<br />
<br />
===Telepathy===<br />
Telepathy is a cross-desktop framework for real-time communication and collaboration - think IM, Voice/Video Conferencing and Collaborative document editing/gaming/etc.<br />
<br />
More information:<br />
*[http://telepathy.freedesktop.org Telepathy Framework]<br />
*[http://community.kde.org/Telepathy Telepathy-KDE]<br />
*We can be found on IRC in #kde-telepathy<br />
<br />
====Project: Distributed Shared-State system based on DBus tubes for KDE apps====<br />
<br />
'''Brief explanation:'''<br />
Telepathy DBus tubes provide an easy way for collaborative applications such as KWhiteboard to be built. However, a common issue is the need of applications wishing to use DBus Tubes is the need for a way for participants to keep their application states synchronised in the absence of a single "server". This is an intellectually challenging project as well as requiring coding, so please ensure you join us on IRC and get to know us and the project before submitting a proposal for this project.<br />
<br />
'''Expected results:'''<br />
* A distributed-state mechanism generic enough to be used by any KDE application wishing to build a serverless collaborative system on top of DBus tubes.<br />
* A sample implementation using this state layer, either by adding basic functionality to KWhiteboard or another application of your choice.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* Telepathy development<br />
* As a minimum, a basic understanding of how DBus works<br />
* A desire to take on a challenging project<br />
<br />
Skill level: high.<br />
<br />
'''Mentor:'''<br />
George Goldberg<br />
<br />
====Project: Amarok Playlist Sharing====<br />
See [http://community.kde.org/GSoC/2011/Ideas#Project:_Playlist_sharing]<br />
<br />
====Project: Innovative new UI/Interaction Methods====<br />
<br />
'''Brief explanation:'''<br />
Telepathy allows real-time communication to be integrated far deeper into the computing experience. Come up with some interesting novel ideas for how to make this integration happen (new ways of displaying information, novel plasma integration methods, you name it), and implement them.<br />
<br />
'''Expected results:'''<br />
* This project is very open ended, but we would expect to see a series of deliverables outlined in the proposal along with some justification for why they are interesting ideas. Sufficient research should be undertaken at the proposal stage to ensure the deliverables are suitable and achievable within the context of the rest of the KDE Software Compilation and Workspaces.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* At least basic Telepathy development<br />
* A good imagination and a keen interest in innovative interaction design.<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
George Goldberg</div>Grundleborghttps://community.kde.org/index.php?title=GSoC/2011/Ideas&diff=9593GSoC/2011/Ideas2011-02-10T15:32:37Z<p>Grundleborg: /* Telepathy */</p>
<hr />
<div>== Guidelines ==<br />
<br />
=== Information for Students ===<br />
<br />
These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at. <br />
<br />
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out. <br />
<br />
When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big! <br />
<br />
If there is no specific contact given you can ask questions on the general KDE development list kde-devel@kde.org. See [http://www.kde.org/mailinglists/ the KDE mailing lists page] for information on available mailing lists and how to subscribe. <br />
<br />
=== Adding a Proposal ===<br />
<br />
{{Note|Follow the template of other proposals!}}<br />
<br />
When adding an idea to this section, please try to include the following data: <br />
<br />
:*if the application is not widely known, a description of what it does and where its code lives <br />
:*a brief explanation <br />
:*the expected results <br />
:*pre-requisites for working on your project <br />
:*if applicable, links to more information or discussions <br />
:*mailing list or IRC channel for your application/library/module <br />
:*your name and email address for contact (if you're willing to be a mentor)<br />
<br />
If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.<br />
<br />
== Ideas ==<br />
<br />
'''How to find ideas?''' To see previous Project ideas, see: [[GSoC/2010/Ideas|2010 ideas]]. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.<br />
<br />
<br />
=== Amarok ===<br />
<br />
Amarok is a powerful KDE based music player for Linux and Unix, MacOS X and Windows with an intuitive interface. It makes playing the music you love and discovering new music easier than ever before - and it looks good doing it! <br />
<br />
<br> [http://amarok.kde.org Website] - [https://mail.kde.org/mailman/listinfo/amarok Mailing list] - IRC channel: #amarok on Freenode. <br />
<br />
==== Project: Playlist sharing ====<br />
<br />
'''Brief explanation:''' <br />
Amarok playlist sharing will allow you to select a set of tracks and share them with friends over chat. By using Telepathy lots of IM networks are available including jabber, google talk, AIM, MSN and facebook chat.<br />
<br />
'''Expected results:'''<br />
A plugin will add a PlaylistProvider to Amarok that enable the user to share via HTTP streaming (P2P) a playlist with online friends.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), Telepathy, HTTP streaming and NAT traversal.<br />
<br />
Any of these are optional but not all of them.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Bart Cerneels or Ian Monroe<br />
<br />
==== Project: Self Contained Collection ====<br />
<br />
'''Brief explanation:''' <br />
sqlite file saved in collections own folder. Tie in with USB media device.<br />
More info to follow.<br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), SQL.<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
Unless someone else from the Amarok team can be convinced: Bart Cerneels<br />
<br />
=== digiKam ===<br />
<br />
Photo Management program <br />
<br />
[http://www.digikam.org digiKam project web site] - [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist] - IRC channel: #digikam on Freenode. <br />
<br />
==== Project: Camera UI Revamp ====<br />
<br />
'''Brief explanation:''' <br />
DigiKam features a UI for accessing and downloading pictures from cameras.<br />
The code is rather old, using Qt3Support classes for the icon view, the UI code intermangled deeply with backend code, and has not seen very much care and love for some years.<br />
<br />
This project would involve taking the old code apart, rewriting a clean code base backend and frontend, but also adding user interface elements to make the most important everyday task as easy as possible.<br />
<br />
In more detail: Write a model listing images on a camera (There are two backends, USB mass storage cameras, which are basically files on disk, and gphoto2 cameras, which require access through a library). Take the existing digikam icon view and delegate classes, which are prepared for code reuse, and put together an icon view for the model. Cleanly separate the code that does the actual work (downloading, converting, renaming) from the UI. Wrap that in the main window.<br />
<br />
UI design: The current interface is powerful, exposing many options. We want to preserve that. But at the same time, there are three very common actions: a) Download all new files to the last used album b) Download all new files to a new album c) Download all new files to an existing album.<br/><br />
It should be possible to carry out task (a) with one click, task (b) and (c) with two or three clicks, without opening a dialog. Friendly to the new user, preserving access to all options for the poweruser.<br />
<br />
'''Expected results:'''<br />
A camera UI based on Qt model/view and clean code which provides the currently available functionality, offering a quick path to download new pictures.<br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Interest in Qt model/view and UI code.<br />
<br />
'''Mentor:''' Gilles Caulier? (Marcel Wiesweg)<br />
<br />
<br />
==== Project: Presentation View ====<br />
<br />
'''Brief explanation:''' <br />
The presentation view is a full-screen workplace which you can use to present photos to yourself or your audience. At first glance it is looking like the current slide show, but then it is much more flexible: At any moment, you can access UI components like the map view, the metadata tab, the image properties tab, to access information, assign metadata, or show your audience the location of the picture on OpenStreetMap. You can access an icon view component to change the collection your are currently presenting, or a thumbbar component to switch to a different image.<br />
<br />
The main view typically shows one image full screen, but you can zoom; You can also change to a layout that shows four or five images at a time, like images put in a paper album.<br />
You can change the order of images presented, and store order and layout (preferably in some XML format). You can load these presentations later, playing them automatically, coming back to the traditional slide show.<br />
<br />
Technically, it should be future proof as much as possible (Qt Quick. QGraphicsView. scene graph in the future? Will embed QWidgets though) The job is not to develop any of the components mentioned above, but to avoid that, and reuse the existing digikam components and models.<br />
<br />
'''Expected results:'''<br />
Something resembling the vision outlined above<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Marcel Wiesweg<br />
<br />
<br />
==== Project: MacOSX support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
digiKam needs to be available under MacOSX in native. Currently, [http://www.macports.org - Macports project] is the only way to get last digiKam under Mac.<br />
Macports require to compile all depencies and digiKam as well. It's a long and hazardous solution to see digiKam running under Mac.<br />
<br />
Also, current digiKam implementation is not optimized for Mac desktop. A lots of point need to be improved to support better this operating system.<br />
Graphical interface need to polished too.<br />
<br />
See relevant entries in KDE bugzilla about MacOSX support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=257679 257679] <br />
[https://bugs.kde.org/show_bug.cgi?id=257773 257773]<br />
<br />
'''Expected results:'''<br />
Provide scripts and configurations to build automatically a DMG archive of digiKam for MacOSX.<br />
Improve digiKam GUI everywhere to be more elegant and more optimized for MacOSX.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, MacOSX, scripting, DMG, packaging<br />
<br />
'''Mentor:'''<br />
Julien Narboux ? (Gilles Caulier)<br />
<br />
<br />
==== Project: Video metadata support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
All recent digital-still camera device provide video capture. digiKam must be able to manage these files as images.<br />
digiKam can already play video and register files to the database, but it lack important metadata used to catalog and sort item (as date, camera name, and all record condition).<br />
<br />
To improve video file support, video metadata management done in background need to be improved, to patch [http://www.exiv2.org Exiv2 shared library] (already used by digiKam)<br />
<br />
See relevant entries in KDE bugzilla about video support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=164442 164442] <br />
[https://bugs.kde.org/show_bug.cgi?id=229543 229543]<br />
<br />
'''Expected results:'''<br />
Add video files support to Exiv2.<br />
Patch digiKam metadata interface to handle video information.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, video format, metadata<br />
<br />
'''Mentor:'''<br />
Gilles Caulier, Andreas Huggel<br />
<br />
==== Project: Clone Tool for Image Editor ====<br />
<br />
'''Brief explanation:'''<br />
<br />
In digiKam image editor we need a simple clone tool to be able to remove quickly <br />
dusts, spots, and other unwanted artefact from an image.<br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=132483 132483] <br />
<br />
'''Expected results:'''<br />
add a new tool (as new image editor plugin) with the clone feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
==== Project: Panorama Tool ====<br />
<br />
'''Brief explanation:'''<br />
<br />
With recent digital still camera, it's possible using a tripod to take images to create panoramic view.<br />
We need a tool to assemble these images automatically. Common image corners must be detected and merged without to ask any settings to user.<br />
Colors and luminosity of each shot must be adjusted automatically too. <br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=235766 235766] <br />
<br />
'''Expected results:'''<br />
add a new tool (as kipi plugin) with auto-panorama feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
=== KDE Edu ===<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Games ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDevelop ===<br />
<br />
KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages. <br />
<br />
[http://www.kdevelop.org Website] - [http://www.kdevelop.org/index.html?filename=mailinglist.html Mailing list] - IRC channel: #kdevelop on Freenode. <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDE Core ===<br />
<br />
KDE Core is the interest group working on the underlying KDE development platform such as kdelibs and kde-runtime. KDE Core provides libraries that are used by all KDE applications and so essentially define what a KDE application is. Working on KDE Core is highly challenging as it requires much forward thinking for maximum utility and flexibility as well as guaranteeing backwards compatibility and cross-platform support.<br />
<br />
==== Project: Support for astronomical calendar systems ====<br />
<br />
'''Brief explanation:''' Add support for astronomical calendar systems. KDE is unique in the Linux eco-system for providing support for alternative calendar systems, such as the Hebrew, Islamic Civil, and Japanese calendar systems. Support for such calendar systems is standard in the Windows and Mac worlds. However, KDE does not as yet support calendar systems that require astronomical calculations, such as the Chinese and Islamic Lunar calendars, This project would fill this gap.<br />
<br />
'''Expected results:''' Documentation, design and production of Chinese, Indian, Islamic and Jalali/Persian calendar systems and their numerous derivatives. The documentation to be of a high enough standard to submit to various standardization bodies. Production of an astronomical library for calculating sunrise, sunset and moon phase (and any other useful calculations) for shared use between the calendar systems and other KDE libraries and applications such as KHolidays, KStars and Marble.<br />
<br />
'''Knowledge Prerequisite:''' C++, especially an understanding of Binary Compatibility rules and good API design. Some knowledge of Celestial Mechanics and good mathematical literacy. Any experience with regular cultural use of astronomical calendars would be highly useful.<br />
<br />
'''Mentor:''' John Layt<br />
<br />
=== KDE PIM ===<br />
<br />
KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc. <br />
<br />
There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc. <br />
<br />
[http://pim.kde.org/ Website] - [http://techbase.kde.org/Projects/PIM Project Wiki] - [https://mail.kde.org/mailman/listinfo/kde-pim Mailing list] - IRC channel: #kontact and #akonadi on Freenode.<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Calligra Karbon ===<br />
<br />
Karbon is a vector drawing application with an user interface that is easy to use, highly customizable and extensible. <br />
<br />
[http://www.calligra-suite.org/karbon/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Variable thickness lines ====<br />
<br />
'''Brief explanation:''' <br />
One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.<br />
<br />
This proposal is to modify the path a tool that, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.<br />
<br />
As Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.<br />
<br />
'''Expected results:'''<br />
Modify path tool is able to scale the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup.<br />
<br />
'''Technologies Used:''' <br />
C++,Qt,SVG?<br />
<br />
'''Mentor:'''<br />
Jan H? jaham @t gmx,net (need to ask :P )<br />
<br />
=== Calligra Kexi ===<br />
<br />
Kexi is an open source data management application, long-awaited competitor for programs like MS Access or Filemaker.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kexi/<br />
<br />
Project Page: http://kexi-project.org/<br />
<br />
Irc channel: #kexi on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=203<br />
<br />
Development Wiki: http://community.kde.org/Kexi<br />
<br />
TODO...<br />
<br />
=== Calligra Words ===<br />
<br />
[http://www.calligra-suite.org/words/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Improve quality of ODF write support ====<br />
<br />
'''Brief explanation:''' While a lot of work went into improving the quality of loading ODF text-documents, saving them can still be improved a lot. The goal of the gsoc would be to improve the quality of the by Calligra Words produced ODF. This means fixing the produced ODF text-documents so they a) do validate against the ODF XML-schema and b) are proper loaded with Calligra Words, LibreOffice.org/OpenOffice.org, Microsoft Word, etc. By identifying and fixing bugs and adding unittests for regression-testing we could improve the quality of the core of Calligra significantly.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Implement notes-support ====<br />
<br />
'''Brief explanation:''' Implement and extend the notes-support in Calligra Words to view+add+edit+delete+load+save notes/comments/annotations in Calligra Words.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260138 260138] and [https://bugs.kde.org/show_bug.cgi?id=260184 260184] and [https://bugs.kde.org/show_bug.cgi?id=260102 260102] and [https://bugs.kde.org/show_bug.cgi?id=260127 260127].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Fix and extend LaTEX support ====<br />
<br />
'''Brief explanation:''' Calligra Words has an import and export filter for LaTEX documents. Those need to be extended to proper import/export and produce better results. We could also implement a new view in Calligra Words to support latex like working.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260063 260063] and [https://bugs.kde.org/show_bug.cgi?id=260056 260056].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: PDF-Import and/or PDF-Export ====<br />
<br />
'''Brief explanation:''' Currently Calligra Words supports exporting the drawn canvas as images using the File=>ExportPDF menu-item. The idea is to create an export and/or import filter to import and/or export to/from PDF (not as images but as text) using poppler.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Integrate with Akonadi ====<br />
<br />
'''Brief explanation:''' Integrate with Akonadi to provide access to resources (contacts-variables, mail-merge, ...).<br />
<br />
See also bug [https://bugs.kde.org/show_bug.cgi?id=260220 260220].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: References tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we don't have yet is a references tool that provide the ui for creating table of contents, citations/bibliography, and end notes. Table of centents has all the underlying engine in place. That same engine can be reused/copied/modified for bibliography (maybe planning for the use of http://www.zotero.org )<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
==== Project: Layout tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we need is completion of this layout tool. Much of it is just ui allowing the user to set all sorts of layout options using the engine which is already in place.<br />
<br />
As it's not such a big project, we expect everything about this tool to be perfect so it can enter directly into the next version of Calligra Words.<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
=== Calligra Krita ===<br />
<br />
Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/ <br />
<br />
Project Page: http://www.krita.org/ <br />
<br />
Irc channel: #krita on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=136.<br />
<br />
Wiki: http://community.kde.org/Krita<br />
<br />
==== Project: ABR Brush Support ====<br />
<br />
'''Brief Explanation''': Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resource''': http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita<br />
<br />
==== Project: PSD File import/export Support ====<br />
<br />
'''Brief Explanation''': The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
'''Resources''': existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd<br />
<br />
==== Project: Flow and drying: real media support ====<br />
<br />
'''Brief Explanation''': As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects. Particularly challenging is the flow of undo and redo.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven<br />
<br />
==== Project: 3D Sketching tool ====<br />
<br />
'''Brief Explanation''': When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup<br />
<br />
'''Mentor''': Lukáš Tvrdý or Cyrille Berger <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
==== Project: Text Balloon support for Comics work ====<br />
<br />
'''Brief Explanation''': Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt, SVG<br />
<br />
'''Expected results''': a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.<br />
<br />
'''Resources''': http://en.wikipedia.org/wiki/Speech_balloon<br />
<br />
==== Project: Painting and Separation of 3D Textures ====<br />
<br />
'''Brief Explanation''': As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.<br />
<br />
Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.krita.org<br />
<br />
==== Project: Advanced selection using SIOX ====<br />
<br />
'''Brief explanation''': SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.<br />
<br />
'''Possible mentor''': Cyrille Berger (or Sven Langkamp)<br />
<br />
'''Used Technologies''': C++, Qt<br />
<br />
'''Resources:'''<br />
* http://www.siox.org/ website describing the algorithm,<br />
* https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,<br />
* http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,<br />
* http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction<br />
<br />
==== Project: Tagging and management for Krita resources ====<br />
<br />
'''Brief explanation''': Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.<br />
<br />
'''Expected results''': A functioning implementation of resource management and tagging.<br />
<br />
'''Used Technologies''': C++, Qt, digital art.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: GPU-acceleration for Krita ====<br />
<br />
'''Brief explanation''': Although Krita was one of the first painting applications with OpenGL and shader support, Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming.<br />
Expected results: optimized composition operators, transformation code<br />
Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
==== Project: GPU-backend for OpenGTL ====<br />
<br />
'''Brief explanation''': Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements.<br />
There are two possibilities to implement such a change:<br />
<br />
* Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend<br />
* The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library<br />
<br />
The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.<br />
<br />
This is a very challenging task!<br />
<br />
'''Resources''': http://www.opengtl.org<br />
<br />
'''Expected results''': OpenCL AST generator, report on the possibility to interface OpenGTL with mesa<br />
<br />
'''Used Technologies''': C++, GLSL, OpenCL (possibly LLVM)<br />
<br />
'''Mentor''': Cyrille Berger <br />
<br />
==== Project: Substrate simulation ====<br />
<br />
'''Brief explanation''': Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings.<br />
Expected results: an optional substrate simulation that works with all current Krita tools<br />
<br />
'''Used Technologies''': C++, Qt, OpenGL<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: Color Mixing ====<br />
<br />
'''Brief explanation''': Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.<br />
<br />
'''Expected results''': a color mixer that works, layer composition and painting.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: 3D Material Image Maps ====<br />
'''Brief explanation''': 3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:<br />
<br />
<br />
1. Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.<br />
<br />
2. When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.<br />
<br />
3. In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).<br />
<br />
For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita. <br />
<br />
Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.<br />
<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: Shift drag sensors ====<br />
<br />
'''Brief explanation''': Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
=== KDE on Windows ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KWin ===<br />
<br />
KDE's window manager <br />
<br />
[http://techbase.kde.org/Projects/KWin Techbase page] - [https://mail.kde.org/mailman/listinfo/kwin Mailinglist] - IRC channel: #kwin on Freenode. <br />
<br />
==== Project: Modularization of Workspace ====<br />
<br />
'''Brief explanation:''' <br />
The Workspace class is the monolithic core of KWin. Nevertheless many parts of it do not depend on each other and can be split out of Workspace into own classes. The modularization is an important prerequisite to a port of KWin to Wayland and providing a small window manager for mobile devices.<br />
<br />
'''Expected results:'''<br />
A concept for what can be moved into own classes exists and several classes have been split out of Workspace. The X11 dependend code is moved into an own plugin. Plus if tests for the new classes are written.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of window management. Plus for X11 knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Unit Testing Framework ====<br />
<br />
'''Brief explanation:''' <br />
Testing a window manager is rather difficult as it requires a running instance and windows need to be created and interacted with. This project should set up a test framework based on Xephyr, KWin's scripting interface and QTest.<br />
<br />
'''Expected results:'''<br />
An infrastructure to test the core of KWin with simple KWin scripts should exist and several unit tests for existing functionality should be implemented<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++, JavaScript, QTest<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Initial Support for Wayland Clients ====<br />
<br />
'''Brief explanation:''' <br />
Wayland is the next iteration for composited window management. The task of this project is to add support for managing Wayland clients on X11 and integrate them into the existing compositing rendering code for GLES.<br />
<br />
'''Expected results:'''<br />
KWin is able to manage Wayland clients and can render the clients. Plus for support to interact with them (move/activate/restack).<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of Window management. Plus for OpenGL knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
=== Nepomuk ===<br />
<br />
[http://nepomuk.kde.org Website]- [http://techbase.kde.org/Development/Tutorials#Nepomuk Documentation/Howtos] - [http://www.semanticdesktop.org/ontologies/ Ontologies] - [https://mail.kde.org/mailman/listinfo/nepomuk Mailing list] - IRC channel: #nepomuk-kde on Freenode. <br />
<br />
(Also see the [http://techbase.kde.org/Projects/Nepomuk Nepomuk techbase page] for a long list of Nepomuk-related ToDos and ideas.)<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Plasma ===<br />
<br />
[http://plasma.kde.org Website] - [https://mail.kde.org/mailman/listinfo/panel-dev Mailing list] - IRC channel: #plasma on Freenode. <br />
<br />
==== Project: QML QtComponents set ====<br />
<br />
'''Brief explanation:''' The QtComponents project is aiming to provide an api and a series of widget sets completely based upon QML. the actual implementation is platform-dependent, so KDE needs its own platform specific set made with the plasma theming mechanism,for both the desktop and the mobile.<br />
<br />
'''Expected results:''' A complete set of QtComponents for the use in QML based plasmoid for the desktop, if there is enough time, the start of a mobile version (with as less as possible changed from the desktop case)<br />
<br />
'''Knowledge Prerequisite:''' both QML and Qt C++ programming are useful (and preferred), most of it can be learned on the way<br />
<br />
'''Mentor:''' either Marco Martin and/or Artur De Souza<br />
<br />
==== Project: Plasma media center first release ====<br />
<br />
'''Brief explanation:''' The Plasma media center project needs some work to get to a first alpha release quality: mostly a reingeneering of the components of the main gui and porting the graphical elements to qml<br />
<br />
'''Expected results:''' a basically working media center at least with an index of local media files (videos, pictures and music)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++, QML and some ideas on the Plasma architecture, QML can be learned on the way<br />
<br />
'''Mentor:''' Marco Martin<br />
<br />
==== Project: QML-ify Plasma widgets ====<br />
<br />
'''Brief explanation:''' The Plasma2 library will be heavily based on QML, probably dropping qgraphicswidget support altogether.<br />
All the default plasmoid set will heve to be ported to be either pure QML/Javascript or QML/C++ in the meantime.<br />
<br />
'''Expected results:''' At least 6-7 minor plasmoids ported to QML or some (to define) of the main ones (like kickoff,taskbar, systray, whatever)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++ some idea on Plasma and kdelibs arch, already knowing something of QML helps<br />
<br />
'''Mentor:''' Marco MArtin<br />
<br />
==== Project: Move Plasma Functionality in Compositor ====<br />
<br />
'''Brief explanation:''' <br />
Plasma uses lots of functionality which are better served in the window and compositing manager (KWin). For example Plasma uses an own glow animation before showing a hidden panel. This could be OpenGL accelerated when moved into KWin. Other examples involve Wallpaper rendering or Tooltips.<br />
<br />
It would be the task of the project to identify these areas and to discuss strategies with the Plasma and KWin community how to better handle these areas and to implement the solution.<br />
<br />
'''Expected results:''' <br />
Rendering functionality moved from Plasma to KWin with fallback for legacy (non-composited) and other window managers.<br />
<br />
'''Knowledge Prerequisite:''' <br />
C++/Qt, basic understanding of X, OpenGL useful but not required.<br />
<br />
'''Mentor:'''<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:''' <br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Phonon ===<br />
<br />
Abstraction library for sound and video support. Used by KDE notifications, Amarok, Dragon Player and Qt Software. <br />
<br />
[http://phonon.kde.org Website] - [https://mail.kde.org/mailman/listinfo/phonon-backends Mailing list] - IRC channel: #phonon on Freenode. <br />
<br />
[http://community.kde.org/Phonon Community wiki with TODOs and outstanding issues.]<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Kate ===<br />
<br />
Kate is a powerful programmer's editor. <br />
<br />
<br> [http://www.kate-editor.org Website] - [https://mail.kde.org/mailman/listinfo/kwrite-devel Mailing list] - IRC channel: #kate on Freenode. <br />
<br />
==== Project: Modeline Editor ====<br />
<br />
'''Brief explanation:''' Kate supports modelines, also called [http://docs.kde.org/stable/en/kdesdk/kate/config-variables.html document variables]. Through this, users can configure individual settings for specific documents. The task of this project is to add a modeline editor, that can write/change the document variables in the document.<br />
<br />
'''Expected results:''' A modeline editor that is able to edit the current modeliens. This editor could be reused in the "Modes" tab in Kate's config page.<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, Qt-Designer, high motivation<br />
<br />
'''Mentor:''' Dominik Haumann / Christoph Cullmann<br />
<br />
==== Project: Further improve the Vi Input Mode ====<br />
<br />
'''Brief explanation:''' Kate supports a modal, Vi[m]-like editing mode. The support for Vim features is already quite good in some areas, but there is more to be done:<br />
<br />
* A “jump list” should be maintained of the last cursor positions, making it possible to jump back to earlier positions and forward again (ctrl+i/ctrl+o in vim)<br />
* More command line mode commands should be supported, and it should be possible to use marks in ranges, i.e. “:'a,'bs/foo/bar/”<br />
* A thorough test suite<br />
* [your favourite feature]<br />
<br />
'''Expected results:''' An improved vi input mode for kate<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, high motivation<br />
<br />
'''Mentor:''' Erlend Hamberg<br />
<br />
<br />
==== Project: Elastic Tabstop support ====<br />
<br />
'''Brief explanation:''' [http://nickgravgaard.com/elastictabstops/ Elastic tabstops] are a way to visually align code automatically. Current ways of indentation are a relic from the typewriter era and it is time to try new concepts. Elastic tabstops<br />
<br />
* Put an end to the “tabs vs spaces” debate<br />
* Save the programmer from tinkering with alignment<br />
* Allow the use of proportional fonts<br />
* Degrade gracefully for non-supporting editors<br />
<br />
Apart from implementing the feature itself, one should care about the following:<br />
<br />
* the option “align dynamically wrapped lines to the indentation level” has to be extended to allow the setting “align dynamically wrapped lines to the last tabstop”<br />
* A way has to be found to integrate existing options such as tab width and indentation step width.<br />
<br />
'''Expected results:''' A working option to use elastic tabstops instead of traditional alignment. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt<br />
<br />
'''Mentor:''' Joseph Wenninger<br />
<br />
=== Konqueror ===<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kfm-devel/ https://mail.kde.org/mailman/listinfo/kfm-devel/ <br />
<br />
Project Page: http://www.konqueror.org/ <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Finance ===<br />
<br />
KDE Finance is an emerging group of applications dedicated to financial topics, such as Personal Finances Management, Invoices Management, Point of Sales... <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Rekonq ===<br />
<br />
Rekonq is a web browser for KDE based on WebKit. It first focuses on being a light, fast & clean way to access to net. Its development is doubly based on using the new amazing features offered by the WebKit rendering engine and on the rock solid network KDE technologies.<br />
<br />
==== Project: Adblock improvements & elements manipulation ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq currently has an initial implementation of an ads blocking mechanism. This project aims to expand it providing the feature parity with AdBlockPlus and implement a sort of HTML elements manipulation system (enable it, and then click on the page on the elements you want to hide. When you're ok, save your changes, reset them or leave them just for this time)<br />
<br />
<br />
'''Expected results:'''<br />
<br />
An improvements in the adblock rules handling, some (new) tests to check adblock behavior and performance, the elements manipulation feature with (possibly) the ability to save and remember applied changes.<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
C++ programming and hopefully Qt<br />
<br />
<br />
'''Mentor:'''<br />
[mailto:adjam7@gmail.com Andrea Diamantini]<br />
<br />
==== Project: Plasma KPart for Rekonq ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq provides a specific webpage displayed when the user clicks on the "new tab" button. This webpage has features like: previews of favorite pages, previews of closed tabs, an history list, a bookmark list, and a download list.<br />
The goal of this project is develop the same features as this webpage but using plasmoids displayed in a Plasma KPart.<br />
Additional plasmoids, eg. RSS feeder, could be integrated.<br />
<br />
'''Expected results:'''<br />
<br />
*Customizable new tab page.<br />
*Plasma theme integration<br />
*Same plasmoids inside Rekonq and on the desktop<br />
<br />
'''Mentor:'''<br />
[mailto:megabigbug@yahoo.fr Lionel Chauvin]<br />
<br />
=== ownCloud ===<br />
<br />
An open personal cloud which runs on your personal server. It enables accessing your data from all of your devices. Sharing with other people is also possible. It support automatic backups, versioning and encryption.<br />
<br />
<br> [http://ownCloud.org Website] - [https://mail.kde.org/mailman/listinfo/owncloud Mailing list] - IRC channel: #owncloud on Freenode. <br />
<br />
==== Project: Local sync client ====<br />
<br />
'''Brief explanation:''' <br />
Build a client to sync your ownCloud files with your local disc to enable offline use.<br />
<br />
'''Expected results:'''<br />
Development of an application you run on your local PC. This applications syncs local folders with folders on your personal ownCloud server everytime you are online. This applications needs a GUI written in KDE/Qt to configure the ownCloud url, folders, login and password. The applications sits in the systray and informs the user about the syncing progress or sync conflicts. The idea is that the clients mounts the ownCloud folders via WebDAV into a "hidden" directory and syncs the folders via rsync or an own syncing script. Errors should be reported to the user. To quote Frank from the mailing list:<br />
<br />
"The client should:<br />
1. read a configuration file so see which folders to sync and which owncloud server to use.<br />
2. mount the owncloud server via fuse or a different tool into a hidden directory.<br />
3. call a syncing tool like csync to sync between the local directory and the mounted directory<br />
4. unmount owncloud<br />
5. write a log-file about the synced files and potential conflicts which the user has to solve.<br />
<br />
The client should be as portable as possible of course."<br />
<br />
Current inactive projects such as Cloudsync or owncloud-sync-client (both on Gitorious) may possibly be starting places worth investigating.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Python, Ruby, PHP or C++ and KDE/Qt depending on the technology you choose for the desktop syncing client. Enthusiasm for Cloud/Desktop integration and trying new things.<br />
<br />
'''Mentor:'''<br />
Kyle Cunningham? Robin Appleman? Frank K?<br />
<br />
=== KDE Usability ===<br />
==== Project: Usability Survey Framework ====<br />
<br />
'''Brief explanation:''' <br />
Surveys are one of many methods used in creating more usable software. Surveys allow designers to collect information about user's experiences and usability problems with software. A Usability Survey Framework would allow designers and developers to create small, custom surveys that can be attached to events or services. Users could subscribe to the Usability Survey Service and opt in to current studies. Survey studies could be one-time surveys, or several survey entries over a period of time. <br />
<br />
For example, if we wanted to learn more about how users interact with workspaces, a survey could occasionally open when a user accesses or configures the workspace. If we wanted to learn more about the Plasmoid installation process, we could open a survey when a user installs the next plasmoid.<br />
<br />
A Usability Survey Framework would help users become more involved in KDE through direct participation. Developers would be able to easily design and launch surveys to collect important usability feedback. Designers would be able to easily conduct usability studies.<br />
<br />
'''Expected results:'''<br />
The Usability Survey Framework could be implemented as a web service, downloadable Plasma widget, or mini application. It should be an easily configurable survey that collects data based on an event.<br />
<br />
Possible features:<br />
* Uses XML for survey design to make it easy to create and launch new surveys<br />
* Uploading or emailing data at end of study<br />
* Can be a single survey, or a survey study over a period of time<br />
* Configured to open on a specific event<br />
<br />
'''Knowledge Prerequisite:''' <br />
JavaScript, C++. Qt/KDE/Plasma knowledge would help greatly.<br />
<br />
'''Mentor:'''<br />
Celeste Lyn Paul, someone else?<br />
<br />
=== KDE SDK ===<br />
==== Umbrello UML Modeller QGraphicsView Port: ====<br />
<br />
'''Brief explanation:''' <br />
Umbrello UML Modeller uses the old and limited Q3Canvas class. There is an unfinished port to QGraphicsView that should be completed.<br />
<br />
'''Expected results:'''<br />
A stable Umbrello using QGraphicsView.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Programming Qt. Basic understanding of UML.<br />
<br />
'''Mentor:'''<br />
Jonathan Riddell<br />
<br />
=== KDE Language Bindings ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== Solid ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Wikis ===<br />
==== Project: One-click Spammer removal ====<br />
<br />
'''Brief explanation:'''<br />
Currently Wiki administrators have to go to the spammer's user page and block him for a specified time. Then any pages added by him must be deleted and finally any images added must be found and deleted.<br />
<br />
'''Expected results:''' It would be very useful if administrators could call up the Ban page and be able to remove pages and images with a single click from there. Ideally if spam had been added to an existing page that would be reverted, but this is a less common scenario. The work should be presented as a mediawiki extension.<br />
<br />
'''Knowledge Prerequisite:''' ?<br />
<br />
'''Mentor:''' ?<br />
<br />
=== Okular ===<br />
==== Project: Advanced text layout recognition engine ====<br />
<br />
'''Brief explanation:''' <br />
Okular has a very naive algorithm to detect the layout in text in which basically everything is considered to be layouted in a line. You will need to know some text layouting algorithms to improve the detection of columns in text so that text selection works better.<br />
<br />
See relevant entry in KDE bugzilla about it: [https://bugs.kde.org/show_bug.cgi?id=161324 161324] <br />
<br />
'''Expected results'''<br />
A better text selection experience for the user.<br />
<br />
'''Knowledge Prerequisite'''<br />
C++, Qt<br />
<br />
'''Mentor'''<br />
Albert Astals Cid<br />
<br />
=== Knights ===<br />
<br />
Knights is a chess program for KDE, it resides in Extragear/Games. It supports local plays, playing against a computer engine, an opponent on a chess server, and also watching two computers. It uses the KDE technologies to provide a consistent look-and-feel with Oxygen colors and Plasma clocks. <br />
<br />
[http://noughmad.eu/knights Knights web site]<br />
<br />
==== Project: Saving, loading and analyzing games ====<br />
<br />
'''Brief explanation:''' <br />
Knights currently does not support any form of storing and analyzing games, expect for simple undo and redo. This suffices for casual play, but for serious play something more powerful is needed. <br />
<br />
One part of the project is to enable saving board positions to a file, and reading from it at a different time. This should be done using a standard format (PGN), so that external games can be analyzed with Knights and vice-versa. <br />
<br />
Another part is an "analysis" mode, where a playerc can freely move both his and the opponent's pieces. The interface should rate the current board position, provide hints, maintain alternative timelines for comparison, etc. The student should be in contact with chess players (could be on a forum or IRC) to know the other important features of such a mode. <br />
<br />
'''Expected results:'''<br />
Ability to save move history to a file, and read from it at a later time. <br />
An advanced 'analysis' mode for direct manipulation and interaction with a chess engine, with tools to help the player. <br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Knowledge of Chess rules is not needed, but some contact with chess players is preferred. <br />
<br />
'''Mentor:''' [mailto:miha@noughmad.eu Miha Čančula]<br />
<br />
===Gluon===<br />
Gluon is a Free and Open Source framework for creating and distributing games - supporting the flow of the idea all the way from the author to the player of the finished game, and back.<br />
<br />
[http://gluon.gamingfreedom.org/ Gluon Website]<br />
<br />
[http://gluon.gamingfreedom.org/node/40 Contacting the Gluon team (irc, email etc)]<br />
<br />
====Project: Achievements/statistics system====<br />
<br />
'''Brief explanation:'''<br />
Many digital distribution platforms, such as XBox Live, PlayStation Home and Steam, have a system by which players are granted certain trophies by performing certain tasks in the games they play. Even though they can be, these tasks are not necessarily a part of the normal game-play: For example it might be that you have played a certain level a specific number of times. The Open Collaboration Services have, since version 1.7, contained [http://www.freedesktop.org/wiki/Specifications/open-collaboration-services-draft#Achievements a generalised system for storing achievements and the progress a user has made on them].<br />
<br />
This project is to integrate the OCS Achievements module into Gluon, and to create a general system by which statistics required for tracking progress in a game can be generated.<br />
<br />
'''Expected results:'''<br />
* A set of Components and Assets for storing and tracking statistics of game interactions<br />
* Same for handling the Achievements themselves<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git). Knowledge of achievements systems a plus.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Dynamic Shader Generator====<br />
<br />
'''Brief explanation:''' <br />
Gluon these days features a completely shader-based graphics library. One of the issues with this is that you need to create shaders, which is not trivial for most people. This project would alleviate that problem by creating a system similar to many professional graphics applications, where shaders are created by linking small elements - nodes - together. If time permits, this would also be exposed in the interface properly through a node-based editor.<br />
<br />
'''Expected results:'''<br />
A system that is able to create basic shaders and can be extended to create more advanced shaders.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), OpenGL/GLSL and a general knowledge of graphics programming is a definite must.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Integrating SMARTS Game AI system====<br />
'''Brief explanation:'''<br />
In the fall of 2009 and spring of 2010, three students at Aalborg University created a game AI system based on the simple Behavior Tree concept for use with Gluon. As this was an educational project, however, while the project was completed, the code was never merged into Gluon. This project is to take the project code, clean it up and adapt to new Gluon APIs, and if time permits to create a more pleasantly built and better integrated editor for the behavior trees.<br />
<br />
'''Expected results:'''<br />
* A new sub-module in Gluon containing the standalone parts of the [http://leinir.dk/perceived-challenge/ SMARTS AI system] ([http://gitorious.org/gluon-bt/ gitorious])<br />
* Cleaned up integration of the SMARTS components and assets<br />
* Optional: An editor KPart for integration directly in Gluon Creator<br />
<br />
'''Knowledge prerequisite:'''<br />
C++ development experience, Qt/KDE development experience an advantage but can be disregarded if knowledgeable of other modern OOP frameworks.<br />
<br />
Knowledge of the Behavior Tree concept in general an advantage, but this can be gained in a reasonably short amount of time (as both video tutorials on the concept as well as the reports from the university projects SMARTS resulted from are available, containing descriptions of this).<br />
<br />
Skill level: Novice to medium.<br />
<br />
'''Mentor:'''<br />
Dan Leinir Turthra Jensen and Arjen Hiemstra<br />
<br />
===Telepathy===<br />
Telepathy is a cross-desktop framework for real-time communication and collaboration - think IM, Voice/Video Conferencing and Collaborative document editing/gaming/etc.<br />
<br />
More information:<br />
*[http://telepathy.freedesktop.org Telepathy Framework]<br />
*[http://community.kde.org/Telepathy Telepathy-KDE]<br />
*We can be found on IRC in #kde-telepathy<br />
<br />
====Project: Distributed Shared-State system based on DBus tubes for KDE apps====<br />
<br />
'''Brief explanation:'''<br />
Telepathy DBus tubes provide an easy way for collaborative applications such as KWhiteboard to be built. However, a common issue is the need of applications wishing to use DBus Tubes is the need for a way for participants to keep their application states synchronised in the absence of a single "server". This is an intellectually challenging project as well as requiring coding, so please ensure you join us on IRC and get to know us and the project before submitting a proposal for this project.<br />
<br />
'''Expected results:'''<br />
* A distributed-state mechanism generic enough to be used by any KDE application wishing to build a serverless collaborative system on top of DBus tubes.<br />
* A sample implementation using this state layer, either by adding basic functionality to KWhiteboard or another application of your choice.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* Telepathy development<br />
* As a minimum, a basic understanding of how DBus works<br />
* A desire to take on a challenging project<br />
<br />
Skill level: high.<br />
<br />
'''Mentor:'''<br />
George Goldberg<br />
<br />
====Project: Amarok Playlist Sharing====<br />
See [http://community.kde.org/GSoC/2011/Ideas#Project:_Playlist_sharing]</div>Grundleborghttps://community.kde.org/index.php?title=GSoC/2011/Ideas&diff=9592GSoC/2011/Ideas2011-02-10T15:31:05Z<p>Grundleborg: /* Telepathy */</p>
<hr />
<div>== Guidelines ==<br />
<br />
=== Information for Students ===<br />
<br />
These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at. <br />
<br />
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out. <br />
<br />
When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big! <br />
<br />
If there is no specific contact given you can ask questions on the general KDE development list kde-devel@kde.org. See [http://www.kde.org/mailinglists/ the KDE mailing lists page] for information on available mailing lists and how to subscribe. <br />
<br />
=== Adding a Proposal ===<br />
<br />
{{Note|Follow the template of other proposals!}}<br />
<br />
When adding an idea to this section, please try to include the following data: <br />
<br />
:*if the application is not widely known, a description of what it does and where its code lives <br />
:*a brief explanation <br />
:*the expected results <br />
:*pre-requisites for working on your project <br />
:*if applicable, links to more information or discussions <br />
:*mailing list or IRC channel for your application/library/module <br />
:*your name and email address for contact (if you're willing to be a mentor)<br />
<br />
If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.<br />
<br />
== Ideas ==<br />
<br />
'''How to find ideas?''' To see previous Project ideas, see: [[GSoC/2010/Ideas|2010 ideas]]. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.<br />
<br />
<br />
=== Amarok ===<br />
<br />
Amarok is a powerful KDE based music player for Linux and Unix, MacOS X and Windows with an intuitive interface. It makes playing the music you love and discovering new music easier than ever before - and it looks good doing it! <br />
<br />
<br> [http://amarok.kde.org Website] - [https://mail.kde.org/mailman/listinfo/amarok Mailing list] - IRC channel: #amarok on Freenode. <br />
<br />
==== Project: Playlist sharing ====<br />
<br />
'''Brief explanation:''' <br />
Amarok playlist sharing will allow you to select a set of tracks and share them with friends over chat. By using Telepathy lots of IM networks are available including jabber, google talk, AIM, MSN and facebook chat.<br />
<br />
'''Expected results:'''<br />
A plugin will add a PlaylistProvider to Amarok that enable the user to share via HTTP streaming (P2P) a playlist with online friends.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), Telepathy, HTTP streaming and NAT traversal.<br />
<br />
Any of these are optional but not all of them.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Bart Cerneels or Ian Monroe<br />
<br />
==== Project: Self Contained Collection ====<br />
<br />
'''Brief explanation:''' <br />
sqlite file saved in collections own folder. Tie in with USB media device.<br />
More info to follow.<br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), SQL.<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
Unless someone else from the Amarok team can be convinced: Bart Cerneels<br />
<br />
=== digiKam ===<br />
<br />
Photo Management program <br />
<br />
[http://www.digikam.org digiKam project web site] - [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist] - IRC channel: #digikam on Freenode. <br />
<br />
==== Project: Camera UI Revamp ====<br />
<br />
'''Brief explanation:''' <br />
DigiKam features a UI for accessing and downloading pictures from cameras.<br />
The code is rather old, using Qt3Support classes for the icon view, the UI code intermangled deeply with backend code, and has not seen very much care and love for some years.<br />
<br />
This project would involve taking the old code apart, rewriting a clean code base backend and frontend, but also adding user interface elements to make the most important everyday task as easy as possible.<br />
<br />
In more detail: Write a model listing images on a camera (There are two backends, USB mass storage cameras, which are basically files on disk, and gphoto2 cameras, which require access through a library). Take the existing digikam icon view and delegate classes, which are prepared for code reuse, and put together an icon view for the model. Cleanly separate the code that does the actual work (downloading, converting, renaming) from the UI. Wrap that in the main window.<br />
<br />
UI design: The current interface is powerful, exposing many options. We want to preserve that. But at the same time, there are three very common actions: a) Download all new files to the last used album b) Download all new files to a new album c) Download all new files to an existing album.<br/><br />
It should be possible to carry out task (a) with one click, task (b) and (c) with two or three clicks, without opening a dialog. Friendly to the new user, preserving access to all options for the poweruser.<br />
<br />
'''Expected results:'''<br />
A camera UI based on Qt model/view and clean code which provides the currently available functionality, offering a quick path to download new pictures.<br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Interest in Qt model/view and UI code.<br />
<br />
'''Mentor:''' Gilles Caulier? (Marcel Wiesweg)<br />
<br />
<br />
==== Project: Presentation View ====<br />
<br />
'''Brief explanation:''' <br />
The presentation view is a full-screen workplace which you can use to present photos to yourself or your audience. At first glance it is looking like the current slide show, but then it is much more flexible: At any moment, you can access UI components like the map view, the metadata tab, the image properties tab, to access information, assign metadata, or show your audience the location of the picture on OpenStreetMap. You can access an icon view component to change the collection your are currently presenting, or a thumbbar component to switch to a different image.<br />
<br />
The main view typically shows one image full screen, but you can zoom; You can also change to a layout that shows four or five images at a time, like images put in a paper album.<br />
You can change the order of images presented, and store order and layout (preferably in some XML format). You can load these presentations later, playing them automatically, coming back to the traditional slide show.<br />
<br />
Technically, it should be future proof as much as possible (Qt Quick. QGraphicsView. scene graph in the future? Will embed QWidgets though) The job is not to develop any of the components mentioned above, but to avoid that, and reuse the existing digikam components and models.<br />
<br />
'''Expected results:'''<br />
Something resembling the vision outlined above<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Marcel Wiesweg<br />
<br />
<br />
==== Project: MacOSX support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
digiKam needs to be available under MacOSX in native. Currently, [http://www.macports.org - Macports project] is the only way to get last digiKam under Mac.<br />
Macports require to compile all depencies and digiKam as well. It's a long and hazardous solution to see digiKam running under Mac.<br />
<br />
Also, current digiKam implementation is not optimized for Mac desktop. A lots of point need to be improved to support better this operating system.<br />
Graphical interface need to polished too.<br />
<br />
See relevant entries in KDE bugzilla about MacOSX support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=257679 257679] <br />
[https://bugs.kde.org/show_bug.cgi?id=257773 257773]<br />
<br />
'''Expected results:'''<br />
Provide scripts and configurations to build automatically a DMG archive of digiKam for MacOSX.<br />
Improve digiKam GUI everywhere to be more elegant and more optimized for MacOSX.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, MacOSX, scripting, DMG, packaging<br />
<br />
'''Mentor:'''<br />
Julien Narboux ? (Gilles Caulier)<br />
<br />
<br />
==== Project: Video metadata support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
All recent digital-still camera device provide video capture. digiKam must be able to manage these files as images.<br />
digiKam can already play video and register files to the database, but it lack important metadata used to catalog and sort item (as date, camera name, and all record condition).<br />
<br />
To improve video file support, video metadata management done in background need to be improved, to patch [http://www.exiv2.org Exiv2 shared library] (already used by digiKam)<br />
<br />
See relevant entries in KDE bugzilla about video support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=164442 164442] <br />
[https://bugs.kde.org/show_bug.cgi?id=229543 229543]<br />
<br />
'''Expected results:'''<br />
Add video files support to Exiv2.<br />
Patch digiKam metadata interface to handle video information.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, video format, metadata<br />
<br />
'''Mentor:'''<br />
Gilles Caulier, Andreas Huggel<br />
<br />
==== Project: Clone Tool for Image Editor ====<br />
<br />
'''Brief explanation:'''<br />
<br />
In digiKam image editor we need a simple clone tool to be able to remove quickly <br />
dusts, spots, and other unwanted artefact from an image.<br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=132483 132483] <br />
<br />
'''Expected results:'''<br />
add a new tool (as new image editor plugin) with the clone feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
==== Project: Panorama Tool ====<br />
<br />
'''Brief explanation:'''<br />
<br />
With recent digital still camera, it's possible using a tripod to take images to create panoramic view.<br />
We need a tool to assemble these images automatically. Common image corners must be detected and merged without to ask any settings to user.<br />
Colors and luminosity of each shot must be adjusted automatically too. <br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=235766 235766] <br />
<br />
'''Expected results:'''<br />
add a new tool (as kipi plugin) with auto-panorama feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
=== KDE Edu ===<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Games ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDevelop ===<br />
<br />
KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages. <br />
<br />
[http://www.kdevelop.org Website] - [http://www.kdevelop.org/index.html?filename=mailinglist.html Mailing list] - IRC channel: #kdevelop on Freenode. <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDE Core ===<br />
<br />
KDE Core is the interest group working on the underlying KDE development platform such as kdelibs and kde-runtime. KDE Core provides libraries that are used by all KDE applications and so essentially define what a KDE application is. Working on KDE Core is highly challenging as it requires much forward thinking for maximum utility and flexibility as well as guaranteeing backwards compatibility and cross-platform support.<br />
<br />
==== Project: Support for astronomical calendar systems ====<br />
<br />
'''Brief explanation:''' Add support for astronomical calendar systems. KDE is unique in the Linux eco-system for providing support for alternative calendar systems, such as the Hebrew, Islamic Civil, and Japanese calendar systems. Support for such calendar systems is standard in the Windows and Mac worlds. However, KDE does not as yet support calendar systems that require astronomical calculations, such as the Chinese and Islamic Lunar calendars, This project would fill this gap.<br />
<br />
'''Expected results:''' Documentation, design and production of Chinese, Indian, Islamic and Jalali/Persian calendar systems and their numerous derivatives. The documentation to be of a high enough standard to submit to various standardization bodies. Production of an astronomical library for calculating sunrise, sunset and moon phase (and any other useful calculations) for shared use between the calendar systems and other KDE libraries and applications such as KHolidays, KStars and Marble.<br />
<br />
'''Knowledge Prerequisite:''' C++, especially an understanding of Binary Compatibility rules and good API design. Some knowledge of Celestial Mechanics and good mathematical literacy. Any experience with regular cultural use of astronomical calendars would be highly useful.<br />
<br />
'''Mentor:''' John Layt<br />
<br />
=== KDE PIM ===<br />
<br />
KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc. <br />
<br />
There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc. <br />
<br />
[http://pim.kde.org/ Website] - [http://techbase.kde.org/Projects/PIM Project Wiki] - [https://mail.kde.org/mailman/listinfo/kde-pim Mailing list] - IRC channel: #kontact and #akonadi on Freenode.<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Calligra Karbon ===<br />
<br />
Karbon is a vector drawing application with an user interface that is easy to use, highly customizable and extensible. <br />
<br />
[http://www.calligra-suite.org/karbon/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Variable thickness lines ====<br />
<br />
'''Brief explanation:''' <br />
One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.<br />
<br />
This proposal is to modify the path a tool that, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.<br />
<br />
As Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.<br />
<br />
'''Expected results:'''<br />
Modify path tool is able to scale the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup.<br />
<br />
'''Technologies Used:''' <br />
C++,Qt,SVG?<br />
<br />
'''Mentor:'''<br />
Jan H? jaham @t gmx,net (need to ask :P )<br />
<br />
=== Calligra Kexi ===<br />
<br />
Kexi is an open source data management application, long-awaited competitor for programs like MS Access or Filemaker.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kexi/<br />
<br />
Project Page: http://kexi-project.org/<br />
<br />
Irc channel: #kexi on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=203<br />
<br />
Development Wiki: http://community.kde.org/Kexi<br />
<br />
TODO...<br />
<br />
=== Calligra Words ===<br />
<br />
[http://www.calligra-suite.org/words/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Improve quality of ODF write support ====<br />
<br />
'''Brief explanation:''' While a lot of work went into improving the quality of loading ODF text-documents, saving them can still be improved a lot. The goal of the gsoc would be to improve the quality of the by Calligra Words produced ODF. This means fixing the produced ODF text-documents so they a) do validate against the ODF XML-schema and b) are proper loaded with Calligra Words, LibreOffice.org/OpenOffice.org, Microsoft Word, etc. By identifying and fixing bugs and adding unittests for regression-testing we could improve the quality of the core of Calligra significantly.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Implement notes-support ====<br />
<br />
'''Brief explanation:''' Implement and extend the notes-support in Calligra Words to view+add+edit+delete+load+save notes/comments/annotations in Calligra Words.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260138 260138] and [https://bugs.kde.org/show_bug.cgi?id=260184 260184] and [https://bugs.kde.org/show_bug.cgi?id=260102 260102] and [https://bugs.kde.org/show_bug.cgi?id=260127 260127].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Fix and extend LaTEX support ====<br />
<br />
'''Brief explanation:''' Calligra Words has an import and export filter for LaTEX documents. Those need to be extended to proper import/export and produce better results. We could also implement a new view in Calligra Words to support latex like working.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260063 260063] and [https://bugs.kde.org/show_bug.cgi?id=260056 260056].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: PDF-Import and/or PDF-Export ====<br />
<br />
'''Brief explanation:''' Currently Calligra Words supports exporting the drawn canvas as images using the File=>ExportPDF menu-item. The idea is to create an export and/or import filter to import and/or export to/from PDF (not as images but as text) using poppler.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Integrate with Akonadi ====<br />
<br />
'''Brief explanation:''' Integrate with Akonadi to provide access to resources (contacts-variables, mail-merge, ...).<br />
<br />
See also bug [https://bugs.kde.org/show_bug.cgi?id=260220 260220].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: References tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we don't have yet is a references tool that provide the ui for creating table of contents, citations/bibliography, and end notes. Table of centents has all the underlying engine in place. That same engine can be reused/copied/modified for bibliography (maybe planning for the use of http://www.zotero.org )<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
==== Project: Layout tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we need is completion of this layout tool. Much of it is just ui allowing the user to set all sorts of layout options using the engine which is already in place.<br />
<br />
As it's not such a big project, we expect everything about this tool to be perfect so it can enter directly into the next version of Calligra Words.<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
=== Calligra Krita ===<br />
<br />
Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/ <br />
<br />
Project Page: http://www.krita.org/ <br />
<br />
Irc channel: #krita on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=136.<br />
<br />
Wiki: http://community.kde.org/Krita<br />
<br />
==== Project: ABR Brush Support ====<br />
<br />
'''Brief Explanation''': Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resource''': http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita<br />
<br />
==== Project: PSD File import/export Support ====<br />
<br />
'''Brief Explanation''': The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
'''Resources''': existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd<br />
<br />
==== Project: Flow and drying: real media support ====<br />
<br />
'''Brief Explanation''': As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects. Particularly challenging is the flow of undo and redo.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven<br />
<br />
==== Project: 3D Sketching tool ====<br />
<br />
'''Brief Explanation''': When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup<br />
<br />
'''Mentor''': Lukáš Tvrdý or Cyrille Berger <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
==== Project: Text Balloon support for Comics work ====<br />
<br />
'''Brief Explanation''': Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt, SVG<br />
<br />
'''Expected results''': a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.<br />
<br />
'''Resources''': http://en.wikipedia.org/wiki/Speech_balloon<br />
<br />
==== Project: Painting and Separation of 3D Textures ====<br />
<br />
'''Brief Explanation''': As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.<br />
<br />
Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.krita.org<br />
<br />
==== Project: Advanced selection using SIOX ====<br />
<br />
'''Brief explanation''': SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.<br />
<br />
'''Possible mentor''': Cyrille Berger (or Sven Langkamp)<br />
<br />
'''Used Technologies''': C++, Qt<br />
<br />
'''Resources:'''<br />
* http://www.siox.org/ website describing the algorithm,<br />
* https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,<br />
* http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,<br />
* http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction<br />
<br />
==== Project: Tagging and management for Krita resources ====<br />
<br />
'''Brief explanation''': Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.<br />
<br />
'''Expected results''': A functioning implementation of resource management and tagging.<br />
<br />
'''Used Technologies''': C++, Qt, digital art.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: GPU-acceleration for Krita ====<br />
<br />
'''Brief explanation''': Although Krita was one of the first painting applications with OpenGL and shader support, Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming.<br />
Expected results: optimized composition operators, transformation code<br />
Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
==== Project: GPU-backend for OpenGTL ====<br />
<br />
'''Brief explanation''': Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements.<br />
There are two possibilities to implement such a change:<br />
<br />
* Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend<br />
* The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library<br />
<br />
The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.<br />
<br />
This is a very challenging task!<br />
<br />
'''Resources''': http://www.opengtl.org<br />
<br />
'''Expected results''': OpenCL AST generator, report on the possibility to interface OpenGTL with mesa<br />
<br />
'''Used Technologies''': C++, GLSL, OpenCL (possibly LLVM)<br />
<br />
'''Mentor''': Cyrille Berger <br />
<br />
==== Project: Substrate simulation ====<br />
<br />
'''Brief explanation''': Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings.<br />
Expected results: an optional substrate simulation that works with all current Krita tools<br />
<br />
'''Used Technologies''': C++, Qt, OpenGL<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: Color Mixing ====<br />
<br />
'''Brief explanation''': Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.<br />
<br />
'''Expected results''': a color mixer that works, layer composition and painting.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: 3D Material Image Maps ====<br />
'''Brief explanation''': 3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:<br />
<br />
<br />
1. Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.<br />
<br />
2. When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.<br />
<br />
3. In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).<br />
<br />
For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita. <br />
<br />
Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.<br />
<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: Shift drag sensors ====<br />
<br />
'''Brief explanation''': Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
=== KDE on Windows ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KWin ===<br />
<br />
KDE's window manager <br />
<br />
[http://techbase.kde.org/Projects/KWin Techbase page] - [https://mail.kde.org/mailman/listinfo/kwin Mailinglist] - IRC channel: #kwin on Freenode. <br />
<br />
==== Project: Modularization of Workspace ====<br />
<br />
'''Brief explanation:''' <br />
The Workspace class is the monolithic core of KWin. Nevertheless many parts of it do not depend on each other and can be split out of Workspace into own classes. The modularization is an important prerequisite to a port of KWin to Wayland and providing a small window manager for mobile devices.<br />
<br />
'''Expected results:'''<br />
A concept for what can be moved into own classes exists and several classes have been split out of Workspace. The X11 dependend code is moved into an own plugin. Plus if tests for the new classes are written.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of window management. Plus for X11 knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Unit Testing Framework ====<br />
<br />
'''Brief explanation:''' <br />
Testing a window manager is rather difficult as it requires a running instance and windows need to be created and interacted with. This project should set up a test framework based on Xephyr, KWin's scripting interface and QTest.<br />
<br />
'''Expected results:'''<br />
An infrastructure to test the core of KWin with simple KWin scripts should exist and several unit tests for existing functionality should be implemented<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++, JavaScript, QTest<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Initial Support for Wayland Clients ====<br />
<br />
'''Brief explanation:''' <br />
Wayland is the next iteration for composited window management. The task of this project is to add support for managing Wayland clients on X11 and integrate them into the existing compositing rendering code for GLES.<br />
<br />
'''Expected results:'''<br />
KWin is able to manage Wayland clients and can render the clients. Plus for support to interact with them (move/activate/restack).<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of Window management. Plus for OpenGL knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
=== Nepomuk ===<br />
<br />
[http://nepomuk.kde.org Website]- [http://techbase.kde.org/Development/Tutorials#Nepomuk Documentation/Howtos] - [http://www.semanticdesktop.org/ontologies/ Ontologies] - [https://mail.kde.org/mailman/listinfo/nepomuk Mailing list] - IRC channel: #nepomuk-kde on Freenode. <br />
<br />
(Also see the [http://techbase.kde.org/Projects/Nepomuk Nepomuk techbase page] for a long list of Nepomuk-related ToDos and ideas.)<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Plasma ===<br />
<br />
[http://plasma.kde.org Website] - [https://mail.kde.org/mailman/listinfo/panel-dev Mailing list] - IRC channel: #plasma on Freenode. <br />
<br />
==== Project: QML QtComponents set ====<br />
<br />
'''Brief explanation:''' The QtComponents project is aiming to provide an api and a series of widget sets completely based upon QML. the actual implementation is platform-dependent, so KDE needs its own platform specific set made with the plasma theming mechanism,for both the desktop and the mobile.<br />
<br />
'''Expected results:''' A complete set of QtComponents for the use in QML based plasmoid for the desktop, if there is enough time, the start of a mobile version (with as less as possible changed from the desktop case)<br />
<br />
'''Knowledge Prerequisite:''' both QML and Qt C++ programming are useful (and preferred), most of it can be learned on the way<br />
<br />
'''Mentor:''' either Marco Martin and/or Artur De Souza<br />
<br />
==== Project: Plasma media center first release ====<br />
<br />
'''Brief explanation:''' The Plasma media center project needs some work to get to a first alpha release quality: mostly a reingeneering of the components of the main gui and porting the graphical elements to qml<br />
<br />
'''Expected results:''' a basically working media center at least with an index of local media files (videos, pictures and music)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++, QML and some ideas on the Plasma architecture, QML can be learned on the way<br />
<br />
'''Mentor:''' Marco Martin<br />
<br />
==== Project: QML-ify Plasma widgets ====<br />
<br />
'''Brief explanation:''' The Plasma2 library will be heavily based on QML, probably dropping qgraphicswidget support altogether.<br />
All the default plasmoid set will heve to be ported to be either pure QML/Javascript or QML/C++ in the meantime.<br />
<br />
'''Expected results:''' At least 6-7 minor plasmoids ported to QML or some (to define) of the main ones (like kickoff,taskbar, systray, whatever)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++ some idea on Plasma and kdelibs arch, already knowing something of QML helps<br />
<br />
'''Mentor:''' Marco MArtin<br />
<br />
==== Project: Move Plasma Functionality in Compositor ====<br />
<br />
'''Brief explanation:''' <br />
Plasma uses lots of functionality which are better served in the window and compositing manager (KWin). For example Plasma uses an own glow animation before showing a hidden panel. This could be OpenGL accelerated when moved into KWin. Other examples involve Wallpaper rendering or Tooltips.<br />
<br />
It would be the task of the project to identify these areas and to discuss strategies with the Plasma and KWin community how to better handle these areas and to implement the solution.<br />
<br />
'''Expected results:''' <br />
Rendering functionality moved from Plasma to KWin with fallback for legacy (non-composited) and other window managers.<br />
<br />
'''Knowledge Prerequisite:''' <br />
C++/Qt, basic understanding of X, OpenGL useful but not required.<br />
<br />
'''Mentor:'''<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:''' <br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Phonon ===<br />
<br />
Abstraction library for sound and video support. Used by KDE notifications, Amarok, Dragon Player and Qt Software. <br />
<br />
[http://phonon.kde.org Website] - [https://mail.kde.org/mailman/listinfo/phonon-backends Mailing list] - IRC channel: #phonon on Freenode. <br />
<br />
[http://community.kde.org/Phonon Community wiki with TODOs and outstanding issues.]<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Kate ===<br />
<br />
Kate is a powerful programmer's editor. <br />
<br />
<br> [http://www.kate-editor.org Website] - [https://mail.kde.org/mailman/listinfo/kwrite-devel Mailing list] - IRC channel: #kate on Freenode. <br />
<br />
==== Project: Modeline Editor ====<br />
<br />
'''Brief explanation:''' Kate supports modelines, also called [http://docs.kde.org/stable/en/kdesdk/kate/config-variables.html document variables]. Through this, users can configure individual settings for specific documents. The task of this project is to add a modeline editor, that can write/change the document variables in the document.<br />
<br />
'''Expected results:''' A modeline editor that is able to edit the current modeliens. This editor could be reused in the "Modes" tab in Kate's config page.<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, Qt-Designer, high motivation<br />
<br />
'''Mentor:''' Dominik Haumann / Christoph Cullmann<br />
<br />
==== Project: Further improve the Vi Input Mode ====<br />
<br />
'''Brief explanation:''' Kate supports a modal, Vi[m]-like editing mode. The support for Vim features is already quite good in some areas, but there is more to be done:<br />
<br />
* A “jump list” should be maintained of the last cursor positions, making it possible to jump back to earlier positions and forward again (ctrl+i/ctrl+o in vim)<br />
* More command line mode commands should be supported, and it should be possible to use marks in ranges, i.e. “:'a,'bs/foo/bar/”<br />
* A thorough test suite<br />
* [your favourite feature]<br />
<br />
'''Expected results:''' An improved vi input mode for kate<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, high motivation<br />
<br />
'''Mentor:''' Erlend Hamberg<br />
<br />
<br />
==== Project: Elastic Tabstop support ====<br />
<br />
'''Brief explanation:''' [http://nickgravgaard.com/elastictabstops/ Elastic tabstops] are a way to visually align code automatically. Current ways of indentation are a relic from the typewriter era and it is time to try new concepts. Elastic tabstops<br />
<br />
* Put an end to the “tabs vs spaces” debate<br />
* Save the programmer from tinkering with alignment<br />
* Allow the use of proportional fonts<br />
* Degrade gracefully for non-supporting editors<br />
<br />
Apart from implementing the feature itself, one should care about the following:<br />
<br />
* the option “align dynamically wrapped lines to the indentation level” has to be extended to allow the setting “align dynamically wrapped lines to the last tabstop”<br />
* A way has to be found to integrate existing options such as tab width and indentation step width.<br />
<br />
'''Expected results:''' A working option to use elastic tabstops instead of traditional alignment. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt<br />
<br />
'''Mentor:''' Joseph Wenninger<br />
<br />
=== Konqueror ===<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kfm-devel/ https://mail.kde.org/mailman/listinfo/kfm-devel/ <br />
<br />
Project Page: http://www.konqueror.org/ <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Finance ===<br />
<br />
KDE Finance is an emerging group of applications dedicated to financial topics, such as Personal Finances Management, Invoices Management, Point of Sales... <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Rekonq ===<br />
<br />
Rekonq is a web browser for KDE based on WebKit. It first focuses on being a light, fast & clean way to access to net. Its development is doubly based on using the new amazing features offered by the WebKit rendering engine and on the rock solid network KDE technologies.<br />
<br />
==== Project: Adblock improvements & elements manipulation ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq currently has an initial implementation of an ads blocking mechanism. This project aims to expand it providing the feature parity with AdBlockPlus and implement a sort of HTML elements manipulation system (enable it, and then click on the page on the elements you want to hide. When you're ok, save your changes, reset them or leave them just for this time)<br />
<br />
<br />
'''Expected results:'''<br />
<br />
An improvements in the adblock rules handling, some (new) tests to check adblock behavior and performance, the elements manipulation feature with (possibly) the ability to save and remember applied changes.<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
C++ programming and hopefully Qt<br />
<br />
<br />
'''Mentor:'''<br />
[mailto:adjam7@gmail.com Andrea Diamantini]<br />
<br />
==== Project: Plasma KPart for Rekonq ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq provides a specific webpage displayed when the user clicks on the "new tab" button. This webpage has features like: previews of favorite pages, previews of closed tabs, an history list, a bookmark list, and a download list.<br />
The goal of this project is develop the same features as this webpage but using plasmoids displayed in a Plasma KPart.<br />
Additional plasmoids, eg. RSS feeder, could be integrated.<br />
<br />
'''Expected results:'''<br />
<br />
*Customizable new tab page.<br />
*Plasma theme integration<br />
*Same plasmoids inside Rekonq and on the desktop<br />
<br />
'''Mentor:'''<br />
[mailto:megabigbug@yahoo.fr Lionel Chauvin]<br />
<br />
=== ownCloud ===<br />
<br />
An open personal cloud which runs on your personal server. It enables accessing your data from all of your devices. Sharing with other people is also possible. It support automatic backups, versioning and encryption.<br />
<br />
<br> [http://ownCloud.org Website] - [https://mail.kde.org/mailman/listinfo/owncloud Mailing list] - IRC channel: #owncloud on Freenode. <br />
<br />
==== Project: Local sync client ====<br />
<br />
'''Brief explanation:''' <br />
Build a client to sync your ownCloud files with your local disc to enable offline use.<br />
<br />
'''Expected results:'''<br />
Development of an application you run on your local PC. This applications syncs local folders with folders on your personal ownCloud server everytime you are online. This applications needs a GUI written in KDE/Qt to configure the ownCloud url, folders, login and password. The applications sits in the systray and informs the user about the syncing progress or sync conflicts. The idea is that the clients mounts the ownCloud folders via WebDAV into a "hidden" directory and syncs the folders via rsync or an own syncing script. Errors should be reported to the user. To quote Frank from the mailing list:<br />
<br />
"The client should:<br />
1. read a configuration file so see which folders to sync and which owncloud server to use.<br />
2. mount the owncloud server via fuse or a different tool into a hidden directory.<br />
3. call a syncing tool like csync to sync between the local directory and the mounted directory<br />
4. unmount owncloud<br />
5. write a log-file about the synced files and potential conflicts which the user has to solve.<br />
<br />
The client should be as portable as possible of course."<br />
<br />
Current inactive projects such as Cloudsync or owncloud-sync-client (both on Gitorious) may possibly be starting places worth investigating.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Python, Ruby, PHP or C++ and KDE/Qt depending on the technology you choose for the desktop syncing client. Enthusiasm for Cloud/Desktop integration and trying new things.<br />
<br />
'''Mentor:'''<br />
Kyle Cunningham? Robin Appleman? Frank K?<br />
<br />
=== KDE Usability ===<br />
==== Project: Usability Survey Framework ====<br />
<br />
'''Brief explanation:''' <br />
Surveys are one of many methods used in creating more usable software. Surveys allow designers to collect information about user's experiences and usability problems with software. A Usability Survey Framework would allow designers and developers to create small, custom surveys that can be attached to events or services. Users could subscribe to the Usability Survey Service and opt in to current studies. Survey studies could be one-time surveys, or several survey entries over a period of time. <br />
<br />
For example, if we wanted to learn more about how users interact with workspaces, a survey could occasionally open when a user accesses or configures the workspace. If we wanted to learn more about the Plasmoid installation process, we could open a survey when a user installs the next plasmoid.<br />
<br />
A Usability Survey Framework would help users become more involved in KDE through direct participation. Developers would be able to easily design and launch surveys to collect important usability feedback. Designers would be able to easily conduct usability studies.<br />
<br />
'''Expected results:'''<br />
The Usability Survey Framework could be implemented as a web service, downloadable Plasma widget, or mini application. It should be an easily configurable survey that collects data based on an event.<br />
<br />
Possible features:<br />
* Uses XML for survey design to make it easy to create and launch new surveys<br />
* Uploading or emailing data at end of study<br />
* Can be a single survey, or a survey study over a period of time<br />
* Configured to open on a specific event<br />
<br />
'''Knowledge Prerequisite:''' <br />
JavaScript, C++. Qt/KDE/Plasma knowledge would help greatly.<br />
<br />
'''Mentor:'''<br />
Celeste Lyn Paul, someone else?<br />
<br />
=== KDE SDK ===<br />
==== Umbrello UML Modeller QGraphicsView Port: ====<br />
<br />
'''Brief explanation:''' <br />
Umbrello UML Modeller uses the old and limited Q3Canvas class. There is an unfinished port to QGraphicsView that should be completed.<br />
<br />
'''Expected results:'''<br />
A stable Umbrello using QGraphicsView.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Programming Qt. Basic understanding of UML.<br />
<br />
'''Mentor:'''<br />
Jonathan Riddell<br />
<br />
=== KDE Language Bindings ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== Solid ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Wikis ===<br />
==== Project: One-click Spammer removal ====<br />
<br />
'''Brief explanation:'''<br />
Currently Wiki administrators have to go to the spammer's user page and block him for a specified time. Then any pages added by him must be deleted and finally any images added must be found and deleted.<br />
<br />
'''Expected results:''' It would be very useful if administrators could call up the Ban page and be able to remove pages and images with a single click from there. Ideally if spam had been added to an existing page that would be reverted, but this is a less common scenario. The work should be presented as a mediawiki extension.<br />
<br />
'''Knowledge Prerequisite:''' ?<br />
<br />
'''Mentor:''' ?<br />
<br />
=== Okular ===<br />
==== Project: Advanced text layout recognition engine ====<br />
<br />
'''Brief explanation:''' <br />
Okular has a very naive algorithm to detect the layout in text in which basically everything is considered to be layouted in a line. You will need to know some text layouting algorithms to improve the detection of columns in text so that text selection works better.<br />
<br />
See relevant entry in KDE bugzilla about it: [https://bugs.kde.org/show_bug.cgi?id=161324 161324] <br />
<br />
'''Expected results'''<br />
A better text selection experience for the user.<br />
<br />
'''Knowledge Prerequisite'''<br />
C++, Qt<br />
<br />
'''Mentor'''<br />
Albert Astals Cid<br />
<br />
=== Knights ===<br />
<br />
Knights is a chess program for KDE, it resides in Extragear/Games. It supports local plays, playing against a computer engine, an opponent on a chess server, and also watching two computers. It uses the KDE technologies to provide a consistent look-and-feel with Oxygen colors and Plasma clocks. <br />
<br />
[http://noughmad.eu/knights Knights web site]<br />
<br />
==== Project: Saving, loading and analyzing games ====<br />
<br />
'''Brief explanation:''' <br />
Knights currently does not support any form of storing and analyzing games, expect for simple undo and redo. This suffices for casual play, but for serious play something more powerful is needed. <br />
<br />
One part of the project is to enable saving board positions to a file, and reading from it at a different time. This should be done using a standard format (PGN), so that external games can be analyzed with Knights and vice-versa. <br />
<br />
Another part is an "analysis" mode, where a playerc can freely move both his and the opponent's pieces. The interface should rate the current board position, provide hints, maintain alternative timelines for comparison, etc. The student should be in contact with chess players (could be on a forum or IRC) to know the other important features of such a mode. <br />
<br />
'''Expected results:'''<br />
Ability to save move history to a file, and read from it at a later time. <br />
An advanced 'analysis' mode for direct manipulation and interaction with a chess engine, with tools to help the player. <br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Knowledge of Chess rules is not needed, but some contact with chess players is preferred. <br />
<br />
'''Mentor:''' [mailto:miha@noughmad.eu Miha Čančula]<br />
<br />
===Gluon===<br />
Gluon is a Free and Open Source framework for creating and distributing games - supporting the flow of the idea all the way from the author to the player of the finished game, and back.<br />
<br />
[http://gluon.gamingfreedom.org/ Gluon Website]<br />
<br />
[http://gluon.gamingfreedom.org/node/40 Contacting the Gluon team (irc, email etc)]<br />
<br />
====Project: Achievements/statistics system====<br />
<br />
'''Brief explanation:'''<br />
Many digital distribution platforms, such as XBox Live, PlayStation Home and Steam, have a system by which players are granted certain trophies by performing certain tasks in the games they play. Even though they can be, these tasks are not necessarily a part of the normal game-play: For example it might be that you have played a certain level a specific number of times. The Open Collaboration Services have, since version 1.7, contained [http://www.freedesktop.org/wiki/Specifications/open-collaboration-services-draft#Achievements a generalised system for storing achievements and the progress a user has made on them].<br />
<br />
This project is to integrate the OCS Achievements module into Gluon, and to create a general system by which statistics required for tracking progress in a game can be generated.<br />
<br />
'''Expected results:'''<br />
* A set of Components and Assets for storing and tracking statistics of game interactions<br />
* Same for handling the Achievements themselves<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git). Knowledge of achievements systems a plus.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Dynamic Shader Generator====<br />
<br />
'''Brief explanation:''' <br />
Gluon these days features a completely shader-based graphics library. One of the issues with this is that you need to create shaders, which is not trivial for most people. This project would alleviate that problem by creating a system similar to many professional graphics applications, where shaders are created by linking small elements - nodes - together. If time permits, this would also be exposed in the interface properly through a node-based editor.<br />
<br />
'''Expected results:'''<br />
A system that is able to create basic shaders and can be extended to create more advanced shaders.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), OpenGL/GLSL and a general knowledge of graphics programming is a definite must.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Integrating SMARTS Game AI system====<br />
'''Brief explanation:'''<br />
In the fall of 2009 and spring of 2010, three students at Aalborg University created a game AI system based on the simple Behavior Tree concept for use with Gluon. As this was an educational project, however, while the project was completed, the code was never merged into Gluon. This project is to take the project code, clean it up and adapt to new Gluon APIs, and if time permits to create a more pleasantly built and better integrated editor for the behavior trees.<br />
<br />
'''Expected results:'''<br />
* A new sub-module in Gluon containing the standalone parts of the [http://leinir.dk/perceived-challenge/ SMARTS AI system] ([http://gitorious.org/gluon-bt/ gitorious])<br />
* Cleaned up integration of the SMARTS components and assets<br />
* Optional: An editor KPart for integration directly in Gluon Creator<br />
<br />
'''Knowledge prerequisite:'''<br />
C++ development experience, Qt/KDE development experience an advantage but can be disregarded if knowledgeable of other modern OOP frameworks.<br />
<br />
Knowledge of the Behavior Tree concept in general an advantage, but this can be gained in a reasonably short amount of time (as both video tutorials on the concept as well as the reports from the university projects SMARTS resulted from are available, containing descriptions of this).<br />
<br />
Skill level: Novice to medium.<br />
<br />
'''Mentor:'''<br />
Dan Leinir Turthra Jensen and Arjen Hiemstra<br />
<br />
===Telepathy===<br />
Telepathy is a cross-desktop framework for real-time communication and collaboration - think IM, Voice/Video Conferencing and Collaborative document editing/gaming/etc.<br />
<br />
[http://telepathy.freedesktop.org] has information on the cross-desktop foundation of the Telepathy Framework.<br />
<br />
[http://community.kde.org/Telepathy] has information on the project to integrate Telepathy with KDE.<br />
<br />
#kde-telepathy on irc.freenode.net is our IRC channel.<br />
<br />
kde-telepathy AT kde DOT org is our mailing list.<br />
<br />
====Project: Distributed Shared-State system based on DBus tubes for KDE apps====<br />
<br />
'''Brief explanation:'''<br />
Telepathy DBus tubes provide an easy way for collaborative applications such as KWhiteboard to be built. However, a common issue is the need of applications wishing to use DBus Tubes is the need for a way for participants to keep their application states synchronised in the absence of a single "server". This is an intellectually challenging project as well as requiring coding, so please ensure you join us on IRC and get to know us and the project before submitting a proposal for this project.<br />
<br />
'''Expected results:'''<br />
* A distributed-state mechanism generic enough to be used by any KDE application wishing to build a serverless collaborative system on top of DBus tubes.<br />
* A sample implementation using this state layer, either by adding basic functionality to KWhiteboard or another application of your choice.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* Telepathy development<br />
* As a minimum, a basic understanding of how DBus works<br />
* A desire to take on a challenging project<br />
<br />
Skill level: high.<br />
<br />
'''Mentor:'''<br />
George Goldberg<br />
<br />
====Project: Amarok Playlist Sharing====<br />
See [http://community.kde.org/GSoC/2011/Ideas#Project:_Playlist_sharing]</div>Grundleborghttps://community.kde.org/index.php?title=GSoC/2011/Ideas&diff=9591GSoC/2011/Ideas2011-02-10T15:30:07Z<p>Grundleborg: add first telepathy stuff</p>
<hr />
<div>== Guidelines ==<br />
<br />
=== Information for Students ===<br />
<br />
These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at. <br />
<br />
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out. <br />
<br />
When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big! <br />
<br />
If there is no specific contact given you can ask questions on the general KDE development list kde-devel@kde.org. See [http://www.kde.org/mailinglists/ the KDE mailing lists page] for information on available mailing lists and how to subscribe. <br />
<br />
=== Adding a Proposal ===<br />
<br />
{{Note|Follow the template of other proposals!}}<br />
<br />
When adding an idea to this section, please try to include the following data: <br />
<br />
:*if the application is not widely known, a description of what it does and where its code lives <br />
:*a brief explanation <br />
:*the expected results <br />
:*pre-requisites for working on your project <br />
:*if applicable, links to more information or discussions <br />
:*mailing list or IRC channel for your application/library/module <br />
:*your name and email address for contact (if you're willing to be a mentor)<br />
<br />
If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.<br />
<br />
== Ideas ==<br />
<br />
'''How to find ideas?''' To see previous Project ideas, see: [[GSoC/2010/Ideas|2010 ideas]]. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.<br />
<br />
<br />
=== Amarok ===<br />
<br />
Amarok is a powerful KDE based music player for Linux and Unix, MacOS X and Windows with an intuitive interface. It makes playing the music you love and discovering new music easier than ever before - and it looks good doing it! <br />
<br />
<br> [http://amarok.kde.org Website] - [https://mail.kde.org/mailman/listinfo/amarok Mailing list] - IRC channel: #amarok on Freenode. <br />
<br />
==== Project: Playlist sharing ====<br />
<br />
'''Brief explanation:''' <br />
Amarok playlist sharing will allow you to select a set of tracks and share them with friends over chat. By using Telepathy lots of IM networks are available including jabber, google talk, AIM, MSN and facebook chat.<br />
<br />
'''Expected results:'''<br />
A plugin will add a PlaylistProvider to Amarok that enable the user to share via HTTP streaming (P2P) a playlist with online friends.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), Telepathy, HTTP streaming and NAT traversal.<br />
<br />
Any of these are optional but not all of them.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Bart Cerneels or Ian Monroe<br />
<br />
==== Project: Self Contained Collection ====<br />
<br />
'''Brief explanation:''' <br />
sqlite file saved in collections own folder. Tie in with USB media device.<br />
More info to follow.<br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), SQL.<br />
<br />
Skill level: medium.<br />
<br />
'''Mentor:'''<br />
Unless someone else from the Amarok team can be convinced: Bart Cerneels<br />
<br />
=== digiKam ===<br />
<br />
Photo Management program <br />
<br />
[http://www.digikam.org digiKam project web site] - [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist] - IRC channel: #digikam on Freenode. <br />
<br />
==== Project: Camera UI Revamp ====<br />
<br />
'''Brief explanation:''' <br />
DigiKam features a UI for accessing and downloading pictures from cameras.<br />
The code is rather old, using Qt3Support classes for the icon view, the UI code intermangled deeply with backend code, and has not seen very much care and love for some years.<br />
<br />
This project would involve taking the old code apart, rewriting a clean code base backend and frontend, but also adding user interface elements to make the most important everyday task as easy as possible.<br />
<br />
In more detail: Write a model listing images on a camera (There are two backends, USB mass storage cameras, which are basically files on disk, and gphoto2 cameras, which require access through a library). Take the existing digikam icon view and delegate classes, which are prepared for code reuse, and put together an icon view for the model. Cleanly separate the code that does the actual work (downloading, converting, renaming) from the UI. Wrap that in the main window.<br />
<br />
UI design: The current interface is powerful, exposing many options. We want to preserve that. But at the same time, there are three very common actions: a) Download all new files to the last used album b) Download all new files to a new album c) Download all new files to an existing album.<br/><br />
It should be possible to carry out task (a) with one click, task (b) and (c) with two or three clicks, without opening a dialog. Friendly to the new user, preserving access to all options for the poweruser.<br />
<br />
'''Expected results:'''<br />
A camera UI based on Qt model/view and clean code which provides the currently available functionality, offering a quick path to download new pictures.<br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Interest in Qt model/view and UI code.<br />
<br />
'''Mentor:''' Gilles Caulier? (Marcel Wiesweg)<br />
<br />
<br />
==== Project: Presentation View ====<br />
<br />
'''Brief explanation:''' <br />
The presentation view is a full-screen workplace which you can use to present photos to yourself or your audience. At first glance it is looking like the current slide show, but then it is much more flexible: At any moment, you can access UI components like the map view, the metadata tab, the image properties tab, to access information, assign metadata, or show your audience the location of the picture on OpenStreetMap. You can access an icon view component to change the collection your are currently presenting, or a thumbbar component to switch to a different image.<br />
<br />
The main view typically shows one image full screen, but you can zoom; You can also change to a layout that shows four or five images at a time, like images put in a paper album.<br />
You can change the order of images presented, and store order and layout (preferably in some XML format). You can load these presentations later, playing them automatically, coming back to the traditional slide show.<br />
<br />
Technically, it should be future proof as much as possible (Qt Quick. QGraphicsView. scene graph in the future? Will embed QWidgets though) The job is not to develop any of the components mentioned above, but to avoid that, and reuse the existing digikam components and models.<br />
<br />
'''Expected results:'''<br />
Something resembling the vision outlined above<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Marcel Wiesweg<br />
<br />
<br />
==== Project: MacOSX support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
digiKam needs to be available under MacOSX in native. Currently, [http://www.macports.org - Macports project] is the only way to get last digiKam under Mac.<br />
Macports require to compile all depencies and digiKam as well. It's a long and hazardous solution to see digiKam running under Mac.<br />
<br />
Also, current digiKam implementation is not optimized for Mac desktop. A lots of point need to be improved to support better this operating system.<br />
Graphical interface need to polished too.<br />
<br />
See relevant entries in KDE bugzilla about MacOSX support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=257679 257679] <br />
[https://bugs.kde.org/show_bug.cgi?id=257773 257773]<br />
<br />
'''Expected results:'''<br />
Provide scripts and configurations to build automatically a DMG archive of digiKam for MacOSX.<br />
Improve digiKam GUI everywhere to be more elegant and more optimized for MacOSX.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, MacOSX, scripting, DMG, packaging<br />
<br />
'''Mentor:'''<br />
Julien Narboux ? (Gilles Caulier)<br />
<br />
<br />
==== Project: Video metadata support ====<br />
<br />
'''Brief explanation:'''<br />
<br />
All recent digital-still camera device provide video capture. digiKam must be able to manage these files as images.<br />
digiKam can already play video and register files to the database, but it lack important metadata used to catalog and sort item (as date, camera name, and all record condition).<br />
<br />
To improve video file support, video metadata management done in background need to be improved, to patch [http://www.exiv2.org Exiv2 shared library] (already used by digiKam)<br />
<br />
See relevant entries in KDE bugzilla about video support :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=164442 164442] <br />
[https://bugs.kde.org/show_bug.cgi?id=229543 229543]<br />
<br />
'''Expected results:'''<br />
Add video files support to Exiv2.<br />
Patch digiKam metadata interface to handle video information.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, video format, metadata<br />
<br />
'''Mentor:'''<br />
Gilles Caulier, Andreas Huggel<br />
<br />
==== Project: Clone Tool for Image Editor ====<br />
<br />
'''Brief explanation:'''<br />
<br />
In digiKam image editor we need a simple clone tool to be able to remove quickly <br />
dusts, spots, and other unwanted artefact from an image.<br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=132483 132483] <br />
<br />
'''Expected results:'''<br />
add a new tool (as new image editor plugin) with the clone feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
==== Project: Panorama Tool ====<br />
<br />
'''Brief explanation:'''<br />
<br />
With recent digital still camera, it's possible using a tripod to take images to create panoramic view.<br />
We need a tool to assemble these images automatically. Common image corners must be detected and merged without to ask any settings to user.<br />
Colors and luminosity of each shot must be adjusted automatically too. <br />
<br />
See relevant entry in KDE bugzilla about it :<br />
<br />
[https://bugs.kde.org/show_bug.cgi?id=235766 235766] <br />
<br />
'''Expected results:'''<br />
add a new tool (as kipi plugin) with auto-panorama feature.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt<br />
<br />
'''Mentor:'''<br />
Gilles Caulier<br />
<br />
=== KDE Edu ===<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Games ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDevelop ===<br />
<br />
KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages. <br />
<br />
[http://www.kdevelop.org Website] - [http://www.kdevelop.org/index.html?filename=mailinglist.html Mailing list] - IRC channel: #kdevelop on Freenode. <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KDE Core ===<br />
<br />
KDE Core is the interest group working on the underlying KDE development platform such as kdelibs and kde-runtime. KDE Core provides libraries that are used by all KDE applications and so essentially define what a KDE application is. Working on KDE Core is highly challenging as it requires much forward thinking for maximum utility and flexibility as well as guaranteeing backwards compatibility and cross-platform support.<br />
<br />
==== Project: Support for astronomical calendar systems ====<br />
<br />
'''Brief explanation:''' Add support for astronomical calendar systems. KDE is unique in the Linux eco-system for providing support for alternative calendar systems, such as the Hebrew, Islamic Civil, and Japanese calendar systems. Support for such calendar systems is standard in the Windows and Mac worlds. However, KDE does not as yet support calendar systems that require astronomical calculations, such as the Chinese and Islamic Lunar calendars, This project would fill this gap.<br />
<br />
'''Expected results:''' Documentation, design and production of Chinese, Indian, Islamic and Jalali/Persian calendar systems and their numerous derivatives. The documentation to be of a high enough standard to submit to various standardization bodies. Production of an astronomical library for calculating sunrise, sunset and moon phase (and any other useful calculations) for shared use between the calendar systems and other KDE libraries and applications such as KHolidays, KStars and Marble.<br />
<br />
'''Knowledge Prerequisite:''' C++, especially an understanding of Binary Compatibility rules and good API design. Some knowledge of Celestial Mechanics and good mathematical literacy. Any experience with regular cultural use of astronomical calendars would be highly useful.<br />
<br />
'''Mentor:''' John Layt<br />
<br />
=== KDE PIM ===<br />
<br />
KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc. <br />
<br />
There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc. <br />
<br />
[http://pim.kde.org/ Website] - [http://techbase.kde.org/Projects/PIM Project Wiki] - [https://mail.kde.org/mailman/listinfo/kde-pim Mailing list] - IRC channel: #kontact and #akonadi on Freenode.<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Calligra Karbon ===<br />
<br />
Karbon is a vector drawing application with an user interface that is easy to use, highly customizable and extensible. <br />
<br />
[http://www.calligra-suite.org/karbon/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Variable thickness lines ====<br />
<br />
'''Brief explanation:''' <br />
One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.<br />
<br />
This proposal is to modify the path a tool that, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.<br />
<br />
As Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.<br />
<br />
'''Expected results:'''<br />
Modify path tool is able to scale the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup.<br />
<br />
'''Technologies Used:''' <br />
C++,Qt,SVG?<br />
<br />
'''Mentor:'''<br />
Jan H? jaham @t gmx,net (need to ask :P )<br />
<br />
=== Calligra Kexi ===<br />
<br />
Kexi is an open source data management application, long-awaited competitor for programs like MS Access or Filemaker.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kexi/<br />
<br />
Project Page: http://kexi-project.org/<br />
<br />
Irc channel: #kexi on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=203<br />
<br />
Development Wiki: http://community.kde.org/Kexi<br />
<br />
TODO...<br />
<br />
=== Calligra Words ===<br />
<br />
[http://www.calligra-suite.org/words/ Web] - [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.<br />
<br />
==== Project: Improve quality of ODF write support ====<br />
<br />
'''Brief explanation:''' While a lot of work went into improving the quality of loading ODF text-documents, saving them can still be improved a lot. The goal of the gsoc would be to improve the quality of the by Calligra Words produced ODF. This means fixing the produced ODF text-documents so they a) do validate against the ODF XML-schema and b) are proper loaded with Calligra Words, LibreOffice.org/OpenOffice.org, Microsoft Word, etc. By identifying and fixing bugs and adding unittests for regression-testing we could improve the quality of the core of Calligra significantly.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Implement notes-support ====<br />
<br />
'''Brief explanation:''' Implement and extend the notes-support in Calligra Words to view+add+edit+delete+load+save notes/comments/annotations in Calligra Words.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260138 260138] and [https://bugs.kde.org/show_bug.cgi?id=260184 260184] and [https://bugs.kde.org/show_bug.cgi?id=260102 260102] and [https://bugs.kde.org/show_bug.cgi?id=260127 260127].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Fix and extend LaTEX support ====<br />
<br />
'''Brief explanation:''' Calligra Words has an import and export filter for LaTEX documents. Those need to be extended to proper import/export and produce better results. We could also implement a new view in Calligra Words to support latex like working.<br />
<br />
See also bugs [https://bugs.kde.org/show_bug.cgi?id=260063 260063] and [https://bugs.kde.org/show_bug.cgi?id=260056 260056].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: PDF-Import and/or PDF-Export ====<br />
<br />
'''Brief explanation:''' Currently Calligra Words supports exporting the drawn canvas as images using the File=>ExportPDF menu-item. The idea is to create an export and/or import filter to import and/or export to/from PDF (not as images but as text) using poppler.<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: Integrate with Akonadi ====<br />
<br />
'''Brief explanation:''' Integrate with Akonadi to provide access to resources (contacts-variables, mail-merge, ...).<br />
<br />
See also bug [https://bugs.kde.org/show_bug.cgi?id=260220 260220].<br />
<br />
'''Mentor:'''<br />
Sebastian Sauer, please contact calligra-devel@kde.org<br />
<br />
==== Project: References tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we don't have yet is a references tool that provide the ui for creating table of contents, citations/bibliography, and end notes. Table of centents has all the underlying engine in place. That same engine can be reused/copied/modified for bibliography (maybe planning for the use of http://www.zotero.org )<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
==== Project: Layout tool ====<br />
<br />
'''Brief explanation:''' Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we need is completion of this layout tool. Much of it is just ui allowing the user to set all sorts of layout options using the engine which is already in place.<br />
<br />
As it's not such a big project, we expect everything about this tool to be perfect so it can enter directly into the next version of Calligra Words.<br />
<br />
'''Mentor:'''<br />
Casper Boemann, please contact calligra-devel@kde.org<br />
<br />
=== Calligra Krita ===<br />
<br />
Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/ <br />
<br />
Project Page: http://www.krita.org/ <br />
<br />
Irc channel: #krita on irc.freenode.net<br />
<br />
Forums: http://forum.kde.org/viewforum.php?f=136.<br />
<br />
Wiki: http://community.kde.org/Krita<br />
<br />
==== Project: ABR Brush Support ====<br />
<br />
'''Brief Explanation''': Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resource''': http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita<br />
<br />
==== Project: PSD File import/export Support ====<br />
<br />
'''Brief Explanation''': The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
'''Resources''': existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd<br />
<br />
==== Project: Flow and drying: real media support ====<br />
<br />
'''Brief Explanation''': As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects. Particularly challenging is the flow of undo and redo.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven<br />
<br />
==== Project: 3D Sketching tool ====<br />
<br />
'''Brief Explanation''': When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup<br />
<br />
'''Mentor''': Lukáš Tvrdý or Cyrille Berger <br />
<br />
'''Used technologies''': C++, Qt,<br />
<br />
==== Project: Text Balloon support for Comics work ====<br />
<br />
'''Brief Explanation''': Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
'''Used technologies''': C++, Qt, SVG<br />
<br />
'''Expected results''': a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.<br />
<br />
'''Resources''': http://en.wikipedia.org/wiki/Speech_balloon<br />
<br />
==== Project: Painting and Separation of 3D Textures ====<br />
<br />
'''Brief Explanation''': As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.<br />
<br />
Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
'''Used technologies''': C++, Qt<br />
<br />
'''Resources''': http://www.krita.org<br />
<br />
==== Project: Advanced selection using SIOX ====<br />
<br />
'''Brief explanation''': SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.<br />
<br />
'''Possible mentor''': Cyrille Berger (or Sven Langkamp)<br />
<br />
'''Used Technologies''': C++, Qt<br />
<br />
'''Resources:'''<br />
* http://www.siox.org/ website describing the algorithm,<br />
* https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,<br />
* http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,<br />
* http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction<br />
<br />
==== Project: Tagging and management for Krita resources ====<br />
<br />
'''Brief explanation''': Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.<br />
<br />
'''Expected results''': A functioning implementation of resource management and tagging.<br />
<br />
'''Used Technologies''': C++, Qt, digital art.<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: GPU-acceleration for Krita ====<br />
<br />
'''Brief explanation''': Although Krita was one of the first painting applications with OpenGL and shader support, Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming.<br />
Expected results: optimized composition operators, transformation code<br />
Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding<br />
<br />
'''Mentor''': Lukáš Tvrdý<br />
<br />
==== Project: GPU-backend for OpenGTL ====<br />
<br />
'''Brief explanation''': Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements.<br />
There are two possibilities to implement such a change:<br />
<br />
* Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend<br />
* The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library<br />
<br />
The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.<br />
<br />
This is a very challenging task!<br />
<br />
'''Resources''': http://www.opengtl.org<br />
<br />
'''Expected results''': OpenCL AST generator, report on the possibility to interface OpenGTL with mesa<br />
<br />
'''Used Technologies''': C++, GLSL, OpenCL (possibly LLVM)<br />
<br />
'''Mentor''': Cyrille Berger <br />
<br />
==== Project: Substrate simulation ====<br />
<br />
'''Brief explanation''': Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings.<br />
Expected results: an optional substrate simulation that works with all current Krita tools<br />
<br />
'''Used Technologies''': C++, Qt, OpenGL<br />
<br />
'''Mentor''': Boudewijn Rempt <br />
<br />
==== Project: Color Mixing ====<br />
<br />
'''Brief explanation''': Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.<br />
<br />
'''Expected results''': a color mixer that works, layer composition and painting.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: 3D Material Image Maps ====<br />
'''Brief explanation''': 3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:<br />
<br />
<br />
1. Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.<br />
<br />
2. When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.<br />
<br />
3. In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).<br />
<br />
For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita. <br />
<br />
Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.<br />
<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
==== Project: Shift drag sensors ====<br />
<br />
'''Brief explanation''': Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.<br />
<br />
'''Used Technologies''': C++, Qt, color theory, mathematics<br />
<br />
'''Mentor''': Boudewijn Rempt<br />
<br />
=== KDE on Windows ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== KWin ===<br />
<br />
KDE's window manager <br />
<br />
[http://techbase.kde.org/Projects/KWin Techbase page] - [https://mail.kde.org/mailman/listinfo/kwin Mailinglist] - IRC channel: #kwin on Freenode. <br />
<br />
==== Project: Modularization of Workspace ====<br />
<br />
'''Brief explanation:''' <br />
The Workspace class is the monolithic core of KWin. Nevertheless many parts of it do not depend on each other and can be split out of Workspace into own classes. The modularization is an important prerequisite to a port of KWin to Wayland and providing a small window manager for mobile devices.<br />
<br />
'''Expected results:'''<br />
A concept for what can be moved into own classes exists and several classes have been split out of Workspace. The X11 dependend code is moved into an own plugin. Plus if tests for the new classes are written.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of window management. Plus for X11 knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Unit Testing Framework ====<br />
<br />
'''Brief explanation:''' <br />
Testing a window manager is rather difficult as it requires a running instance and windows need to be created and interacted with. This project should set up a test framework based on Xephyr, KWin's scripting interface and QTest.<br />
<br />
'''Expected results:'''<br />
An infrastructure to test the core of KWin with simple KWin scripts should exist and several unit tests for existing functionality should be implemented<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++, JavaScript, QTest<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
==== Project: Initial Support for Wayland Clients ====<br />
<br />
'''Brief explanation:''' <br />
Wayland is the next iteration for composited window management. The task of this project is to add support for managing Wayland clients on X11 and integrate them into the existing compositing rendering code for GLES.<br />
<br />
'''Expected results:'''<br />
KWin is able to manage Wayland clients and can render the clients. Plus for support to interact with them (move/activate/restack).<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/C++ and general understanding of Window management. Plus for OpenGL knowledge<br />
<br />
'''Mentor:''' Martin Gräßlin (mgraesslin)<br />
<br />
=== Nepomuk ===<br />
<br />
[http://nepomuk.kde.org Website]- [http://techbase.kde.org/Development/Tutorials#Nepomuk Documentation/Howtos] - [http://www.semanticdesktop.org/ontologies/ Ontologies] - [https://mail.kde.org/mailman/listinfo/nepomuk Mailing list] - IRC channel: #nepomuk-kde on Freenode. <br />
<br />
(Also see the [http://techbase.kde.org/Projects/Nepomuk Nepomuk techbase page] for a long list of Nepomuk-related ToDos and ideas.)<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Plasma ===<br />
<br />
[http://plasma.kde.org Website] - [https://mail.kde.org/mailman/listinfo/panel-dev Mailing list] - IRC channel: #plasma on Freenode. <br />
<br />
==== Project: QML QtComponents set ====<br />
<br />
'''Brief explanation:''' The QtComponents project is aiming to provide an api and a series of widget sets completely based upon QML. the actual implementation is platform-dependent, so KDE needs its own platform specific set made with the plasma theming mechanism,for both the desktop and the mobile.<br />
<br />
'''Expected results:''' A complete set of QtComponents for the use in QML based plasmoid for the desktop, if there is enough time, the start of a mobile version (with as less as possible changed from the desktop case)<br />
<br />
'''Knowledge Prerequisite:''' both QML and Qt C++ programming are useful (and preferred), most of it can be learned on the way<br />
<br />
'''Mentor:''' either Marco Martin and/or Artur De Souza<br />
<br />
==== Project: Plasma media center first release ====<br />
<br />
'''Brief explanation:''' The Plasma media center project needs some work to get to a first alpha release quality: mostly a reingeneering of the components of the main gui and porting the graphical elements to qml<br />
<br />
'''Expected results:''' a basically working media center at least with an index of local media files (videos, pictures and music)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++, QML and some ideas on the Plasma architecture, QML can be learned on the way<br />
<br />
'''Mentor:''' Marco Martin<br />
<br />
==== Project: QML-ify Plasma widgets ====<br />
<br />
'''Brief explanation:''' The Plasma2 library will be heavily based on QML, probably dropping qgraphicswidget support altogether.<br />
All the default plasmoid set will heve to be ported to be either pure QML/Javascript or QML/C++ in the meantime.<br />
<br />
'''Expected results:''' At least 6-7 minor plasmoids ported to QML or some (to define) of the main ones (like kickoff,taskbar, systray, whatever)<br />
<br />
'''Knowledge Prerequisite:''' Qt C++ some idea on Plasma and kdelibs arch, already knowing something of QML helps<br />
<br />
'''Mentor:''' Marco MArtin<br />
<br />
==== Project: Move Plasma Functionality in Compositor ====<br />
<br />
'''Brief explanation:''' <br />
Plasma uses lots of functionality which are better served in the window and compositing manager (KWin). For example Plasma uses an own glow animation before showing a hidden panel. This could be OpenGL accelerated when moved into KWin. Other examples involve Wallpaper rendering or Tooltips.<br />
<br />
It would be the task of the project to identify these areas and to discuss strategies with the Plasma and KWin community how to better handle these areas and to implement the solution.<br />
<br />
'''Expected results:''' <br />
Rendering functionality moved from Plasma to KWin with fallback for legacy (non-composited) and other window managers.<br />
<br />
'''Knowledge Prerequisite:''' <br />
C++/Qt, basic understanding of X, OpenGL useful but not required.<br />
<br />
'''Mentor:'''<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:''' <br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Phonon ===<br />
<br />
Abstraction library for sound and video support. Used by KDE notifications, Amarok, Dragon Player and Qt Software. <br />
<br />
[http://phonon.kde.org Website] - [https://mail.kde.org/mailman/listinfo/phonon-backends Mailing list] - IRC channel: #phonon on Freenode. <br />
<br />
[http://community.kde.org/Phonon Community wiki with TODOs and outstanding issues.]<br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Kate ===<br />
<br />
Kate is a powerful programmer's editor. <br />
<br />
<br> [http://www.kate-editor.org Website] - [https://mail.kde.org/mailman/listinfo/kwrite-devel Mailing list] - IRC channel: #kate on Freenode. <br />
<br />
==== Project: Modeline Editor ====<br />
<br />
'''Brief explanation:''' Kate supports modelines, also called [http://docs.kde.org/stable/en/kdesdk/kate/config-variables.html document variables]. Through this, users can configure individual settings for specific documents. The task of this project is to add a modeline editor, that can write/change the document variables in the document.<br />
<br />
'''Expected results:''' A modeline editor that is able to edit the current modeliens. This editor could be reused in the "Modes" tab in Kate's config page.<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, Qt-Designer, high motivation<br />
<br />
'''Mentor:''' Dominik Haumann / Christoph Cullmann<br />
<br />
==== Project: Further improve the Vi Input Mode ====<br />
<br />
'''Brief explanation:''' Kate supports a modal, Vi[m]-like editing mode. The support for Vim features is already quite good in some areas, but there is more to be done:<br />
<br />
* A “jump list” should be maintained of the last cursor positions, making it possible to jump back to earlier positions and forward again (ctrl+i/ctrl+o in vim)<br />
* More command line mode commands should be supported, and it should be possible to use marks in ranges, i.e. “:'a,'bs/foo/bar/”<br />
* A thorough test suite<br />
* [your favourite feature]<br />
<br />
'''Expected results:''' An improved vi input mode for kate<br />
<br />
'''Knowledge Prerequisite:''' C++/Qt, high motivation<br />
<br />
'''Mentor:''' Erlend Hamberg<br />
<br />
<br />
==== Project: Elastic Tabstop support ====<br />
<br />
'''Brief explanation:''' [http://nickgravgaard.com/elastictabstops/ Elastic tabstops] are a way to visually align code automatically. Current ways of indentation are a relic from the typewriter era and it is time to try new concepts. Elastic tabstops<br />
<br />
* Put an end to the “tabs vs spaces” debate<br />
* Save the programmer from tinkering with alignment<br />
* Allow the use of proportional fonts<br />
* Degrade gracefully for non-supporting editors<br />
<br />
Apart from implementing the feature itself, one should care about the following:<br />
<br />
* the option “align dynamically wrapped lines to the indentation level” has to be extended to allow the setting “align dynamically wrapped lines to the last tabstop”<br />
* A way has to be found to integrate existing options such as tab width and indentation step width.<br />
<br />
'''Expected results:''' A working option to use elastic tabstops instead of traditional alignment. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt<br />
<br />
'''Mentor:''' Joseph Wenninger<br />
<br />
=== Konqueror ===<br />
<br />
Mailing-list: https://mail.kde.org/mailman/listinfo/kfm-devel/ https://mail.kde.org/mailman/listinfo/kfm-devel/ <br />
<br />
Project Page: http://www.konqueror.org/ <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== KDE Finance ===<br />
<br />
KDE Finance is an emerging group of applications dedicated to financial topics, such as Personal Finances Management, Invoices Management, Point of Sales... <br />
<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Rekonq ===<br />
<br />
Rekonq is a web browser for KDE based on WebKit. It first focuses on being a light, fast & clean way to access to net. Its development is doubly based on using the new amazing features offered by the WebKit rendering engine and on the rock solid network KDE technologies.<br />
<br />
==== Project: Adblock improvements & elements manipulation ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq currently has an initial implementation of an ads blocking mechanism. This project aims to expand it providing the feature parity with AdBlockPlus and implement a sort of HTML elements manipulation system (enable it, and then click on the page on the elements you want to hide. When you're ok, save your changes, reset them or leave them just for this time)<br />
<br />
<br />
'''Expected results:'''<br />
<br />
An improvements in the adblock rules handling, some (new) tests to check adblock behavior and performance, the elements manipulation feature with (possibly) the ability to save and remember applied changes.<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
C++ programming and hopefully Qt<br />
<br />
<br />
'''Mentor:'''<br />
[mailto:adjam7@gmail.com Andrea Diamantini]<br />
<br />
==== Project: Plasma KPart for Rekonq ====<br />
<br />
'''Brief explanation:''' <br />
<br />
Rekonq provides a specific webpage displayed when the user clicks on the "new tab" button. This webpage has features like: previews of favorite pages, previews of closed tabs, an history list, a bookmark list, and a download list.<br />
The goal of this project is develop the same features as this webpage but using plasmoids displayed in a Plasma KPart.<br />
Additional plasmoids, eg. RSS feeder, could be integrated.<br />
<br />
'''Expected results:'''<br />
<br />
*Customizable new tab page.<br />
*Plasma theme integration<br />
*Same plasmoids inside Rekonq and on the desktop<br />
<br />
'''Mentor:'''<br />
[mailto:megabigbug@yahoo.fr Lionel Chauvin]<br />
<br />
=== ownCloud ===<br />
<br />
An open personal cloud which runs on your personal server. It enables accessing your data from all of your devices. Sharing with other people is also possible. It support automatic backups, versioning and encryption.<br />
<br />
<br> [http://ownCloud.org Website] - [https://mail.kde.org/mailman/listinfo/owncloud Mailing list] - IRC channel: #owncloud on Freenode. <br />
<br />
==== Project: Local sync client ====<br />
<br />
'''Brief explanation:''' <br />
Build a client to sync your ownCloud files with your local disc to enable offline use.<br />
<br />
'''Expected results:'''<br />
Development of an application you run on your local PC. This applications syncs local folders with folders on your personal ownCloud server everytime you are online. This applications needs a GUI written in KDE/Qt to configure the ownCloud url, folders, login and password. The applications sits in the systray and informs the user about the syncing progress or sync conflicts. The idea is that the clients mounts the ownCloud folders via WebDAV into a "hidden" directory and syncs the folders via rsync or an own syncing script. Errors should be reported to the user. To quote Frank from the mailing list:<br />
<br />
"The client should:<br />
1. read a configuration file so see which folders to sync and which owncloud server to use.<br />
2. mount the owncloud server via fuse or a different tool into a hidden directory.<br />
3. call a syncing tool like csync to sync between the local directory and the mounted directory<br />
4. unmount owncloud<br />
5. write a log-file about the synced files and potential conflicts which the user has to solve.<br />
<br />
The client should be as portable as possible of course."<br />
<br />
Current inactive projects such as Cloudsync or owncloud-sync-client (both on Gitorious) may possibly be starting places worth investigating.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Python, Ruby, PHP or C++ and KDE/Qt depending on the technology you choose for the desktop syncing client. Enthusiasm for Cloud/Desktop integration and trying new things.<br />
<br />
'''Mentor:'''<br />
Kyle Cunningham? Robin Appleman? Frank K?<br />
<br />
=== KDE Usability ===<br />
==== Project: Usability Survey Framework ====<br />
<br />
'''Brief explanation:''' <br />
Surveys are one of many methods used in creating more usable software. Surveys allow designers to collect information about user's experiences and usability problems with software. A Usability Survey Framework would allow designers and developers to create small, custom surveys that can be attached to events or services. Users could subscribe to the Usability Survey Service and opt in to current studies. Survey studies could be one-time surveys, or several survey entries over a period of time. <br />
<br />
For example, if we wanted to learn more about how users interact with workspaces, a survey could occasionally open when a user accesses or configures the workspace. If we wanted to learn more about the Plasmoid installation process, we could open a survey when a user installs the next plasmoid.<br />
<br />
A Usability Survey Framework would help users become more involved in KDE through direct participation. Developers would be able to easily design and launch surveys to collect important usability feedback. Designers would be able to easily conduct usability studies.<br />
<br />
'''Expected results:'''<br />
The Usability Survey Framework could be implemented as a web service, downloadable Plasma widget, or mini application. It should be an easily configurable survey that collects data based on an event.<br />
<br />
Possible features:<br />
* Uses XML for survey design to make it easy to create and launch new surveys<br />
* Uploading or emailing data at end of study<br />
* Can be a single survey, or a survey study over a period of time<br />
* Configured to open on a specific event<br />
<br />
'''Knowledge Prerequisite:''' <br />
JavaScript, C++. Qt/KDE/Plasma knowledge would help greatly.<br />
<br />
'''Mentor:'''<br />
Celeste Lyn Paul, someone else?<br />
<br />
=== KDE SDK ===<br />
==== Umbrello UML Modeller QGraphicsView Port: ====<br />
<br />
'''Brief explanation:''' <br />
Umbrello UML Modeller uses the old and limited Q3Canvas class. There is an unfinished port to QGraphicsView that should be completed.<br />
<br />
'''Expected results:'''<br />
A stable Umbrello using QGraphicsView.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Programming Qt. Basic understanding of UML.<br />
<br />
'''Mentor:'''<br />
Jonathan Riddell<br />
<br />
=== KDE Language Bindings ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
<br />
=== Solid ===<br />
==== Project: ====<br />
<br />
'''Brief explanation:''' <br />
<br />
'''Expected results:'''<br />
<br />
'''Knowledge Prerequisite:''' <br />
<br />
'''Mentor:'''<br />
<br />
=== Wikis ===<br />
==== Project: One-click Spammer removal ====<br />
<br />
'''Brief explanation:'''<br />
Currently Wiki administrators have to go to the spammer's user page and block him for a specified time. Then any pages added by him must be deleted and finally any images added must be found and deleted.<br />
<br />
'''Expected results:''' It would be very useful if administrators could call up the Ban page and be able to remove pages and images with a single click from there. Ideally if spam had been added to an existing page that would be reverted, but this is a less common scenario. The work should be presented as a mediawiki extension.<br />
<br />
'''Knowledge Prerequisite:''' ?<br />
<br />
'''Mentor:''' ?<br />
<br />
=== Okular ===<br />
==== Project: Advanced text layout recognition engine ====<br />
<br />
'''Brief explanation:''' <br />
Okular has a very naive algorithm to detect the layout in text in which basically everything is considered to be layouted in a line. You will need to know some text layouting algorithms to improve the detection of columns in text so that text selection works better.<br />
<br />
See relevant entry in KDE bugzilla about it: [https://bugs.kde.org/show_bug.cgi?id=161324 161324] <br />
<br />
'''Expected results'''<br />
A better text selection experience for the user.<br />
<br />
'''Knowledge Prerequisite'''<br />
C++, Qt<br />
<br />
'''Mentor'''<br />
Albert Astals Cid<br />
<br />
=== Knights ===<br />
<br />
Knights is a chess program for KDE, it resides in Extragear/Games. It supports local plays, playing against a computer engine, an opponent on a chess server, and also watching two computers. It uses the KDE technologies to provide a consistent look-and-feel with Oxygen colors and Plasma clocks. <br />
<br />
[http://noughmad.eu/knights Knights web site]<br />
<br />
==== Project: Saving, loading and analyzing games ====<br />
<br />
'''Brief explanation:''' <br />
Knights currently does not support any form of storing and analyzing games, expect for simple undo and redo. This suffices for casual play, but for serious play something more powerful is needed. <br />
<br />
One part of the project is to enable saving board positions to a file, and reading from it at a different time. This should be done using a standard format (PGN), so that external games can be analyzed with Knights and vice-versa. <br />
<br />
Another part is an "analysis" mode, where a playerc can freely move both his and the opponent's pieces. The interface should rate the current board position, provide hints, maintain alternative timelines for comparison, etc. The student should be in contact with chess players (could be on a forum or IRC) to know the other important features of such a mode. <br />
<br />
'''Expected results:'''<br />
Ability to save move history to a file, and read from it at a later time. <br />
An advanced 'analysis' mode for direct manipulation and interaction with a chess engine, with tools to help the player. <br />
<br />
'''Knowledge Prerequisite:''' Qt, C++. Knowledge of Chess rules is not needed, but some contact with chess players is preferred. <br />
<br />
'''Mentor:''' [mailto:miha@noughmad.eu Miha Čančula]<br />
<br />
===Gluon===<br />
Gluon is a Free and Open Source framework for creating and distributing games - supporting the flow of the idea all the way from the author to the player of the finished game, and back.<br />
<br />
[http://gluon.gamingfreedom.org/ Gluon Website]<br />
<br />
[http://gluon.gamingfreedom.org/node/40 Contacting the Gluon team (irc, email etc)]<br />
<br />
====Project: Achievements/statistics system====<br />
<br />
'''Brief explanation:'''<br />
Many digital distribution platforms, such as XBox Live, PlayStation Home and Steam, have a system by which players are granted certain trophies by performing certain tasks in the games they play. Even though they can be, these tasks are not necessarily a part of the normal game-play: For example it might be that you have played a certain level a specific number of times. The Open Collaboration Services have, since version 1.7, contained [http://www.freedesktop.org/wiki/Specifications/open-collaboration-services-draft#Achievements a generalised system for storing achievements and the progress a user has made on them].<br />
<br />
This project is to integrate the OCS Achievements module into Gluon, and to create a general system by which statistics required for tracking progress in a game can be generated.<br />
<br />
'''Expected results:'''<br />
* A set of Components and Assets for storing and tracking statistics of game interactions<br />
* Same for handling the Achievements themselves<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git). Knowledge of achievements systems a plus.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Dynamic Shader Generator====<br />
<br />
'''Brief explanation:''' <br />
Gluon these days features a completely shader-based graphics library. One of the issues with this is that you need to create shaders, which is not trivial for most people. This project would alleviate that problem by creating a system similar to many professional graphics applications, where shaders are created by linking small elements - nodes - together. If time permits, this would also be exposed in the interface properly through a node-based editor.<br />
<br />
'''Expected results:'''<br />
A system that is able to create basic shaders and can be extended to create more advanced shaders.<br />
<br />
'''Knowledge Prerequisite:''' <br />
Qt/KDE development (includes C++ & git), OpenGL/GLSL and a general knowledge of graphics programming is a definite must.<br />
<br />
Skill level: medium to high.<br />
<br />
'''Mentor:'''<br />
Arjen Hiemstra and Dan Leinir Turthra Jensen<br />
<br />
====Project: Integrating SMARTS Game AI system====<br />
'''Brief explanation:'''<br />
In the fall of 2009 and spring of 2010, three students at Aalborg University created a game AI system based on the simple Behavior Tree concept for use with Gluon. As this was an educational project, however, while the project was completed, the code was never merged into Gluon. This project is to take the project code, clean it up and adapt to new Gluon APIs, and if time permits to create a more pleasantly built and better integrated editor for the behavior trees.<br />
<br />
'''Expected results:'''<br />
* A new sub-module in Gluon containing the standalone parts of the [http://leinir.dk/perceived-challenge/ SMARTS AI system] ([http://gitorious.org/gluon-bt/ gitorious])<br />
* Cleaned up integration of the SMARTS components and assets<br />
* Optional: An editor KPart for integration directly in Gluon Creator<br />
<br />
'''Knowledge prerequisite:'''<br />
C++ development experience, Qt/KDE development experience an advantage but can be disregarded if knowledgeable of other modern OOP frameworks.<br />
<br />
Knowledge of the Behavior Tree concept in general an advantage, but this can be gained in a reasonably short amount of time (as both video tutorials on the concept as well as the reports from the university projects SMARTS resulted from are available, containing descriptions of this).<br />
<br />
Skill level: Novice to medium.<br />
<br />
'''Mentor:'''<br />
Dan Leinir Turthra Jensen and Arjen Hiemstra<br />
<br />
===Telepathy===<br />
Telepathy is a cross-desktop framework for real-time communication and collaboration - think IM, Voice/Video Conferencing and Collaborative document editing/gaming/etc.<br />
<br />
[http://telepathy.freedesktop.org] has information on the cross-desktop foundation of the Telepathy Framework.<br />
<br />
[http://community.kde.org/Telepathy] has information on the project to integrate Telepathy with KDE.<br />
<br />
#kde-telepathy on irc.freenode.net is our IRC channel.<br />
<br />
kde-telepathy AT kde DOT org is our mailing list.<br />
<br />
====Project: Distributed Shared-State system based on DBus tubes for KDE apps====<br />
<br />
'''Brief explanation:'''<br />
Telepathy DBus tubes provide an easy way for collaborative applications such as KWhiteboard to be built. However, a common issue is the need of applications wishing to use DBus Tubes is the need for a way for participants to keep their application states synchronised in the absence of a single "server". This is an intellectually challenging project as well as requiring coding, so please ensure you join us on IRC and get to know us and the project before submitting a proposal for this project.<br />
<br />
'''Expected results:'''<br />
* A distributed-state mechanism generic enough to be used by any KDE application wishing to build a serverless collaborative system on top of DBus tubes.<br />
* A sample implementation using this state layer, either by adding basic functionality to KWhiteboard or another application of your choice.<br />
<br />
'''Knowledge Prerequisite:''' <br />
* Qt/KDE development (includes C++ & git).<br />
* Telepathy development<br />
* As a minimum, a basic understanding of how DBus works<br />
* A desire to take on a challenging project<br />
<br />
Skill level: high.<br />
<br />
'''Mentor:'''<br />
George Goldberg</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Components/Integration_Daemon&diff=9057KTp/Components/Integration Daemon2011-01-29T12:13:51Z<p>Grundleborg: </p>
<hr />
<div>== TODO List ==<br />
<br />
It's going to take me ages to have enough time to finish rewriting the telepathy nepomuk service, so here's the TODO list to finish off my branch (here: http://gitweb.kde.org/clones/telepathy-nepomuk-service/gberg/telepathy-nepomuk-service.git/shortlog/refs/heads/mvc-refactor ) if anyone else wants to take it on sooner.<br />
<br />
* <strike>Implement contact-properties parts of the Storage class.</strike> [[User:Grundleborg|Grundleborg]] 18:05, 6 December 2010 (UTC)<br />
<br />
* Deal with accounts being removed from MC.<br />
<br />
* <strike>Port to latest ontologies (see https://bugs.freedesktop.org/show_bug.cgi?id=31381 ).</strike> [[User:Grundleborg|Grundleborg]] 18:05, 6 December 2010 (UTC)<br />
<br />
* Re-add support for capabilities<br />
<br />
* <strike>Make sure that group changes on the server when this computer is off are correctly synchronised when we launch telepathy-nepomuk-service again. This could probably be most simply acheived by using a groupsChanged() signal with all groups we are in as the parameter instead of the current groupAdded() and groupRemoved() signals. Also check if any other properties suffer from the same issue.</strike><br />
<br />
* Re-add support for avatars, this time using the avatar cache and only storing a URL in nepomuk.<br />
<br />
* Ensure that nepomuk gets updated correctly on launch even if some properties have changed server-side since we were last running.<br />
<br />
* Re-write unit tests based on the new improved application structure.<br />
<br />
* Add a Telepathy Observer to the code base - this will observe all channels and ensure that the participants in all these channels are correctly stored in Nepomuk so that libktelepathy can build a Person list for channel participants.<br />
<br />
* Add unit-tests for the Telepathy Observer part of the codebase.<br />
<br />
==Old==<br />
<br />
===About===<br />
telepathy-integration-daemon is a Daemon that syncs details of your Telepathy accounts and their contacts into Nepomuk. It should always be running in the background (telepathy-monitor-kded or whatever it's called - basically a KDED module for keeping an eye on services that KDE requires to be running for fully integrated Telepathy functionality - should launch it on startup and keep it running.<br />
<br />
===Current Status===<br />
At the moment, this daemon works well enough for developer purposes.<br />
<br />
Current working features:<br />
* Add my accounts to Nepomuk, and sync their presence and nickname.<br />
* Add my contacts to Nepomuk, and sync their presence and nickname.<br />
<br />
Notable missing features:<br />
* Handle deletion of accounts or contacts.<br />
* Sync any other account/contact parameters.<br />
* Sync from Nepomuk to Telepathy (is this even a desirable feature? I don't yet know).<br />
* Handle avatars.<br />
* Performance/reduce unnecessary network round trips.<br />
<br />
Get the source code here: svn://svn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon<br />
<br />
===Program Structure===<br />
<br />
====TelepathyAccountMonitor====<br />
Main class '''TelepathyAccountMonitor''' monitors the Tp::AccountManager keeping track of any new accounts which are added or removed. For each existing account, creates an instance of '''TelepathyAccount'''.<br />
<br />
====TelepathyAccount====<br />
Monitors one Tp::Account. Keeps its data in sync with the relevant data in nepomuk for that account. When the account is connected, gets the contact list for the connection and creates '''TelepathyContact''' objects for each one.<br />
<br />
====TelepathyContact====<br />
Monitors one Tp::Contact. Keeps any info on it synced to Nepomuk. Destroyed when parent connection goes down.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/Meeting_11_01_31&diff=8853KTp/Events/Meeting 11 01 312011-01-24T16:53:35Z<p>Grundleborg: numbers are cool :)</p>
<hr />
<div>The meeting will start 9pm (GMT) on the 31st Jan 2011.<br />
<br />
My proposed agenda to be discussed is:<br />
<br />
Feel free to add items.<br />
<br />
1) Breakdown of the current state of each component, and what they are waiting on<br />
2) Review of the 'nearly complete' components.<br />
3) News on DBus Tubes (hopefully!) <br />
4) D_Ed's test tool<br />
5) Precisely what is in the KDE Tp library, and how it works.<br />
6) GSOC 2011 - do we have any ideas<br />
7) Task assignments<br />
8) Status of bugzilla reports<br />
9) AOB</div>Grundleborghttps://community.kde.org/index.php?title=KTp&diff=8074KTp2011-01-03T17:17:24Z<p>Grundleborg: /* Getting Started */</p>
<hr />
<div>==Introduction==<br />
<br />
Real time Communication has traditionally been a detatched feature of Desktop Computing, provided via stand-alone Instant Messaging clients with poor integration into the desktop experience. One of the primary goals of the KDE 4 series is to tighten integration between different components of the environment. The Realtime Communication and Collaboration (RTCC) project aims to tackle just this.<br />
<br />
Our aims are:<br />
* To integrate Real Time Communication deeply into the KDE Workspaces and Applications<br />
* To provide a infrastructure to aid development of Collaborative features for KDE applications.<br />
<br />
If you find these goals appealing, why not consider [[#Getting_Involved|getting involved]]. C++ programming is *not* a necessity.<br />
<br />
==Technical Information==<br />
<br />
* The RTCC project uses the cross-desktop [http://telepathy.freedesktop.org Telepathy Framework] as the basis for our work.<br />
* We should try and reuse code from Kopete/other already existing code wherever possibly. However, this should be balanced with the need to refactor/rewrite where appropriate to keep the new code true to Telepathy idioms.<br />
<br />
See also https://gkiagia.wordpress.com/2010/09/20/what-is-telepathy-kde/<br />
<br />
==Getting Started==<br />
Before you start playing with/hacking on the Telepathy integration stuff, you need to get it all compiled: [[Real-Time_Communication_and_Collaboration/Getting_Set_Up|Instructions]]<br />
<br />
We are currently in the process of porting all our work from telepathy-qt4 0.3/0.4 to version 0.5 (which is binary incompatible with 0.3 and 0.4). [[Real-Time_Communication_and_Collaboration/Current_State|This page]] shows the progress with this task.<br />
<br />
==The Plan==<br />
1) Build components equivalent to a traditional IM application, using Kopete code as much as possible, and integrating with other Pillars of KDE where appropriate.<br />
<br />
2) Add advanced Telepathy features such as voice/video.<br />
<br />
3) Build components and Convenience classes to enable real-time communication and collaboration features in any KDE SC app that wants them.<br />
<br />
==The Work==<br />
<br />
What we need to get done. This is divided into two sections:<br />
* [[#Phase_1|Phase 1]] contains the tasks which *must* be completed in order for us to make a first preview release.<br />
* [[#Phase_2|Phase 2]] contains other speculative major features that we will probably implement once [[#Phase_1|Phase 1]] is complete.<br />
<br />
=== Phase 1 ===<br />
<br />
These are the essential tasks which must be completed before we can make a first release. Adding or removing tasks from this list requires a consensus on the kde-telepathy mailing list first. Click on a task title for further information about that task.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Account_Management_GUI|Account Management GUI]] || George Goldberg <grundleborg googlemail com> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Telepathy_Accounts_KCM|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Chat_Window|Chat Window App/Lib]] || David Edmundson <kde davidedmundson co uk> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Chat_window_App|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Buddy_List|Buddy List App]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Contact_List_App|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Desktop-wide_Approver|Desktop Wide Tp::Approver]] || George Kiagiadakis <kiagiadakis.george gmail com> || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Integration_Daemon|Telepathy Integration Daemon]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Integration_Daemon|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Presence_Plasmoid|Presence Plasmoid]] || Dario Freddi <drf kde org> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Presence_Plasmoid_and_Dataengine|See here]]<br />
|-<br />
|}<br />
<br />
=== Phase 2 ===<br />
<br />
This section contains features that will *probably* be implemented once the first preview release has been made.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| NOT STARTED || [[Real-Time_Communication_and_Collaboration/Components/Logger|Logger Application]] || || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Call_UI|Call UI]] || George Kiagiadakis <kiagiadakis.george gmail com> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Call_window_App|See here]]<br />
|}<br />
<br />
==Getting Involved==<br />
At this stage, the best way to get involved is to contact the existing team, either on IRC (#kde-telepathy channel on irc.freenode.net) or on our [https://mail.kde.org/mailman/listinfo/kde-telepathy mailing list].<br />
<br />
===Tasks===<br />
Here is a list of tasks that you could get involved with at this moment. Please get in contact with us before writing anything, though. You can find some more details in the work section above.<br />
<br />
* Fix bugs in the accounts KCM.<br />
* Write account plugins for the accounts KCM.<br />
* Complete some missing bits from the nepomuk integration service.<br />
* (Re-)write the contact list UI.<br />
* (Re-)write the call UI (just the UI, not the actual call mechanism).<br />
* Investigate how to implement the logger and then implement it.<br />
* Integrate telepathy into some kde application, doing something fancy and innovative (use your fantasy here).<br />
<br />
===Workflow===<br />
If you want to work on a feature, clone the git repository on the server side and then clone your personal clone on your local machine. Make a new git branch and start working there. Try to keep commits small and meaningful. Once you are finished, push the branch on your server-side clone and ask someone of the team to review it. Once it is reviewed, you can merge it on the master repository (or ask someone else to merge it).<br />
<br />
==Events==<br />
* [[Telepathy/Events/TelepathySprint1|Telepathy sprint - September 2010]]</div>Grundleborghttps://community.kde.org/index.php?title=KTp&diff=8073KTp2011-01-03T17:17:02Z<p>Grundleborg: link to 0.5 porting table</p>
<hr />
<div>==Introduction==<br />
<br />
Real time Communication has traditionally been a detatched feature of Desktop Computing, provided via stand-alone Instant Messaging clients with poor integration into the desktop experience. One of the primary goals of the KDE 4 series is to tighten integration between different components of the environment. The Realtime Communication and Collaboration (RTCC) project aims to tackle just this.<br />
<br />
Our aims are:<br />
* To integrate Real Time Communication deeply into the KDE Workspaces and Applications<br />
* To provide a infrastructure to aid development of Collaborative features for KDE applications.<br />
<br />
If you find these goals appealing, why not consider [[#Getting_Involved|getting involved]]. C++ programming is *not* a necessity.<br />
<br />
==Technical Information==<br />
<br />
* The RTCC project uses the cross-desktop [http://telepathy.freedesktop.org Telepathy Framework] as the basis for our work.<br />
* We should try and reuse code from Kopete/other already existing code wherever possibly. However, this should be balanced with the need to refactor/rewrite where appropriate to keep the new code true to Telepathy idioms.<br />
<br />
See also https://gkiagia.wordpress.com/2010/09/20/what-is-telepathy-kde/<br />
<br />
==Getting Started==<br />
Before you start playing with/hacking on the Telepathy integration stuff, you need to get it all compiled: [[Real-Time_Communication_and_Collaboration/Getting_Set_Up|Instructions]]<br />
<br />
We are currently in the process of porting all our work from telepathy-qt4 0.3/0.4 to version 0.5 (which is binary incompatible with 0.3 and 0.4). [Real-Time_Communication_and_Collaboration/Current_State|This page] shows the progress with this task.<br />
<br />
==The Plan==<br />
1) Build components equivalent to a traditional IM application, using Kopete code as much as possible, and integrating with other Pillars of KDE where appropriate.<br />
<br />
2) Add advanced Telepathy features such as voice/video.<br />
<br />
3) Build components and Convenience classes to enable real-time communication and collaboration features in any KDE SC app that wants them.<br />
<br />
==The Work==<br />
<br />
What we need to get done. This is divided into two sections:<br />
* [[#Phase_1|Phase 1]] contains the tasks which *must* be completed in order for us to make a first preview release.<br />
* [[#Phase_2|Phase 2]] contains other speculative major features that we will probably implement once [[#Phase_1|Phase 1]] is complete.<br />
<br />
=== Phase 1 ===<br />
<br />
These are the essential tasks which must be completed before we can make a first release. Adding or removing tasks from this list requires a consensus on the kde-telepathy mailing list first. Click on a task title for further information about that task.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Account_Management_GUI|Account Management GUI]] || George Goldberg <grundleborg googlemail com> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Telepathy_Accounts_KCM|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Chat_Window|Chat Window App/Lib]] || David Edmundson <kde davidedmundson co uk> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Chat_window_App|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Buddy_List|Buddy List App]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Contact_List_App|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Desktop-wide_Approver|Desktop Wide Tp::Approver]] || George Kiagiadakis <kiagiadakis.george gmail com> || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Integration_Daemon|Telepathy Integration Daemon]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Integration_Daemon|See here]]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Presence_Plasmoid|Presence Plasmoid]] || Dario Freddi <drf kde org> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Presence_Plasmoid_and_Dataengine|See here]]<br />
|-<br />
|}<br />
<br />
=== Phase 2 ===<br />
<br />
This section contains features that will *probably* be implemented once the first preview release has been made.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| NOT STARTED || [[Real-Time_Communication_and_Collaboration/Components/Logger|Logger Application]] || || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Call_UI|Call UI]] || George Kiagiadakis <kiagiadakis.george gmail com> || [[Real-Time_Communication_and_Collaboration/Getting_Set_Up#Call_window_App|See here]]<br />
|}<br />
<br />
==Getting Involved==<br />
At this stage, the best way to get involved is to contact the existing team, either on IRC (#kde-telepathy channel on irc.freenode.net) or on our [https://mail.kde.org/mailman/listinfo/kde-telepathy mailing list].<br />
<br />
===Tasks===<br />
Here is a list of tasks that you could get involved with at this moment. Please get in contact with us before writing anything, though. You can find some more details in the work section above.<br />
<br />
* Fix bugs in the accounts KCM.<br />
* Write account plugins for the accounts KCM.<br />
* Complete some missing bits from the nepomuk integration service.<br />
* (Re-)write the contact list UI.<br />
* (Re-)write the call UI (just the UI, not the actual call mechanism).<br />
* Investigate how to implement the logger and then implement it.<br />
* Integrate telepathy into some kde application, doing something fancy and innovative (use your fantasy here).<br />
<br />
===Workflow===<br />
If you want to work on a feature, clone the git repository on the server side and then clone your personal clone on your local machine. Make a new git branch and start working there. Try to keep commits small and meaningful. Once you are finished, push the branch on your server-side clone and ask someone of the team to review it. Once it is reviewed, you can merge it on the master repository (or ask someone else to merge it).<br />
<br />
==Events==<br />
* [[Telepathy/Events/TelepathySprint1|Telepathy sprint - September 2010]]</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Tasks/Telepathy-Qt_0.5_Porting&diff=8072KTp/Tasks/Telepathy-Qt 0.5 Porting2011-01-03T17:14:10Z<p>Grundleborg: add nepomuk service details</p>
<hr />
<div>This page lists the current state of the KDE Telepathy applications porting to Telepathy-Qt0.5<br />
<br />
{| class="wikitable"<br />
! Name !! Status !! Branches<br />
|- <br />
| Telepathy Accounts KCM || Port in branch || http://gitweb.kde.org/scratch/davidedmundson/telepathy-accounts-kcm.git<br />
|-<br />
| Telepathy Accounts KCM Plugins || Port in branch || http://gitweb.kde.org/scratch/davidedmundson/telepathy-accounts-kcm-plugins.git<br />
|-<br />
| Telepathy Approver || To Check || <br />
|-<br />
| Telepathy Call UI || To Check ||<br />
|-<br />
| Telepathy Chat Handler || Done in master ||<br />
|-<br />
| Telepathy Contact List || To Check ||<br />
|-<br />
| Telepathy KDE || To Check ||<br />
|-<br />
| Telepathy Launcher KDED || To Check ||<br />
|-<br />
| Telepathy Nepomuk Service || Completed in branch || http://gitweb.kde.org/clones/telepathy-nepomuk-service/gberg/telepathy-nepomuk-service.git/shortlog/refs/heads/mvc-refactor-2<br />
|-<br />
| Telepathy Presence Applet || To Check ||<br />
|-<br />
| Telepathy Presence Dataengine || To Check ||<br />
|-<br />
| Telepathy Testlib || To Check ||<br />
|-<br />
| Kopete Protocol Telepathy || To Check ||<br />
|-<br />
| KWhiteboard || To Check ||<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Components/Integration_Daemon&diff=6783KTp/Components/Integration Daemon2010-12-06T18:05:34Z<p>Grundleborg: /* TODO List */</p>
<hr />
<div>== TODO List ==<br />
<br />
It's going to take me ages to have enough time to finish rewriting the telepathy nepomuk service, so here's the TODO list to finish off my branch (here: http://gitweb.kde.org/clones/telepathy-nepomuk-service/gberg/telepathy-nepomuk-service.git/shortlog/refs/heads/mvc-refactor ) if anyone else wants to take it on sooner.<br />
<br />
* <strike>Implement contact-properties parts of the Storage class.</strike> [[User:Grundleborg|Grundleborg]] 18:05, 6 December 2010 (UTC)<br />
<br />
* Deal with accounts being removed from MC.<br />
<br />
* <strike>Port to latest ontologies (see https://bugs.freedesktop.org/show_bug.cgi?id=31381 ).</strike> [[User:Grundleborg|Grundleborg]] 18:05, 6 December 2010 (UTC)<br />
<br />
* Re-add support for capabilities<br />
<br />
* Make sure that group changes on the server when this computer is off are correctly synchronised when we launch telepathy-nepomuk-service again. This could probably be most simply acheived by using a groupsChanged() signal with all groups we are in as the parameter instead of the current groupAdded() and groupRemoved() signals. Also check if any other properties suffer from the same issue.<br />
<br />
* Re-add support for avatars, this time using the avatar cache and only storing a URL in nepomuk.<br />
<br />
* Ensure that nepomuk gets updated correctly on launch even if some properties have changed server-side since we were last running.<br />
<br />
* Re-write unit tests based on the new improved application structure.<br />
<br />
* Add a Telepathy Observer to the code base - this will observe all channels and ensure that the participants in all these channels are correctly stored in Nepomuk so that libktelepathy can build a Person list for channel participants.<br />
<br />
* Add unit-tests for the Telepathy Observer part of the codebase.<br />
<br />
==Old==<br />
<br />
===About===<br />
telepathy-integration-daemon is a Daemon that syncs details of your Telepathy accounts and their contacts into Nepomuk. It should always be running in the background (telepathy-monitor-kded or whatever it's called - basically a KDED module for keeping an eye on services that KDE requires to be running for fully integrated Telepathy functionality - should launch it on startup and keep it running.<br />
<br />
===Current Status===<br />
At the moment, this daemon works well enough for developer purposes.<br />
<br />
Current working features:<br />
* Add my accounts to Nepomuk, and sync their presence and nickname.<br />
* Add my contacts to Nepomuk, and sync their presence and nickname.<br />
<br />
Notable missing features:<br />
* Handle deletion of accounts or contacts.<br />
* Sync any other account/contact parameters.<br />
* Sync from Nepomuk to Telepathy (is this even a desirable feature? I don't yet know).<br />
* Handle avatars.<br />
* Performance/reduce unnecessary network round trips.<br />
<br />
Get the source code here: svn://svn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon<br />
<br />
===Program Structure===<br />
<br />
====TelepathyAccountMonitor====<br />
Main class '''TelepathyAccountMonitor''' monitors the Tp::AccountManager keeping track of any new accounts which are added or removed. For each existing account, creates an instance of '''TelepathyAccount'''.<br />
<br />
====TelepathyAccount====<br />
Monitors one Tp::Account. Keeps its data in sync with the relevant data in nepomuk for that account. When the account is connected, gets the contact list for the connection and creates '''TelepathyContact''' objects for each one.<br />
<br />
====TelepathyContact====<br />
Monitors one Tp::Contact. Keeps any info on it synced to Nepomuk. Destroyed when parent connection goes down.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Components/Integration_Daemon&diff=6782KTp/Components/Integration Daemon2010-12-06T18:05:05Z<p>Grundleborg: /* TODO List */</p>
<hr />
<div>== TODO List ==<br />
<br />
It's going to take me ages to have enough time to finish rewriting the telepathy nepomuk service, so here's the TODO list to finish off my branch (here: http://gitweb.kde.org/clones/telepathy-nepomuk-service/gberg/telepathy-nepomuk-service.git/shortlog/refs/heads/mvc-refactor ) if anyone else wants to take it on sooner.<br />
<br />
* <strike>Implement contact-properties parts of the Storage class.</strike> [[User:Grundleborg|Grundleborg]] 18:05, 6 December 2010 (UTC)<br />
<br />
* Deal with accounts being removed from MC.<br />
<br />
* Port to latest ontologies (see https://bugs.freedesktop.org/show_bug.cgi?id=31381 ).<br />
<br />
* Re-add support for capabilities<br />
<br />
* Make sure that group changes on the server when this computer is off are correctly synchronised when we launch telepathy-nepomuk-service again. This could probably be most simply acheived by using a groupsChanged() signal with all groups we are in as the parameter instead of the current groupAdded() and groupRemoved() signals. Also check if any other properties suffer from the same issue.<br />
<br />
* Re-add support for avatars, this time using the avatar cache and only storing a URL in nepomuk.<br />
<br />
* Ensure that nepomuk gets updated correctly on launch even if some properties have changed server-side since we were last running.<br />
<br />
* Re-write unit tests based on the new improved application structure.<br />
<br />
* Add a Telepathy Observer to the code base - this will observe all channels and ensure that the participants in all these channels are correctly stored in Nepomuk so that libktelepathy can build a Person list for channel participants.<br />
<br />
* Add unit-tests for the Telepathy Observer part of the codebase.<br />
<br />
==Old==<br />
<br />
===About===<br />
telepathy-integration-daemon is a Daemon that syncs details of your Telepathy accounts and their contacts into Nepomuk. It should always be running in the background (telepathy-monitor-kded or whatever it's called - basically a KDED module for keeping an eye on services that KDE requires to be running for fully integrated Telepathy functionality - should launch it on startup and keep it running.<br />
<br />
===Current Status===<br />
At the moment, this daemon works well enough for developer purposes.<br />
<br />
Current working features:<br />
* Add my accounts to Nepomuk, and sync their presence and nickname.<br />
* Add my contacts to Nepomuk, and sync their presence and nickname.<br />
<br />
Notable missing features:<br />
* Handle deletion of accounts or contacts.<br />
* Sync any other account/contact parameters.<br />
* Sync from Nepomuk to Telepathy (is this even a desirable feature? I don't yet know).<br />
* Handle avatars.<br />
* Performance/reduce unnecessary network round trips.<br />
<br />
Get the source code here: svn://svn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon<br />
<br />
===Program Structure===<br />
<br />
====TelepathyAccountMonitor====<br />
Main class '''TelepathyAccountMonitor''' monitors the Tp::AccountManager keeping track of any new accounts which are added or removed. For each existing account, creates an instance of '''TelepathyAccount'''.<br />
<br />
====TelepathyAccount====<br />
Monitors one Tp::Account. Keeps its data in sync with the relevant data in nepomuk for that account. When the account is connected, gets the contact list for the connection and creates '''TelepathyContact''' objects for each one.<br />
<br />
====TelepathyContact====<br />
Monitors one Tp::Contact. Keeps any info on it synced to Nepomuk. Destroyed when parent connection goes down.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Components/Integration_Daemon&diff=6781KTp/Components/Integration Daemon2010-12-06T18:04:51Z<p>Grundleborg: </p>
<hr />
<div>== TODO List ==<br />
<br />
It's going to take me ages to have enough time to finish rewriting the telepathy nepomuk service, so here's the TODO list to finish off my branch (here: http://gitweb.kde.org/clones/telepathy-nepomuk-service/gberg/telepathy-nepomuk-service.git/shortlog/refs/heads/mvc-refactor ) if anyone else wants to take it on sooner.<br />
<br />
* <strike>Implement contact-properties parts of the Storage class.</strike> 18:04, 6 December 2010 (UTC)<br />
<br />
* Deal with accounts being removed from MC.<br />
<br />
* Port to latest ontologies (see https://bugs.freedesktop.org/show_bug.cgi?id=31381 ).<br />
<br />
* Re-add support for capabilities<br />
<br />
* Make sure that group changes on the server when this computer is off are correctly synchronised when we launch telepathy-nepomuk-service again. This could probably be most simply acheived by using a groupsChanged() signal with all groups we are in as the parameter instead of the current groupAdded() and groupRemoved() signals. Also check if any other properties suffer from the same issue.<br />
<br />
* Re-add support for avatars, this time using the avatar cache and only storing a URL in nepomuk.<br />
<br />
* Ensure that nepomuk gets updated correctly on launch even if some properties have changed server-side since we were last running.<br />
<br />
* Re-write unit tests based on the new improved application structure.<br />
<br />
* Add a Telepathy Observer to the code base - this will observe all channels and ensure that the participants in all these channels are correctly stored in Nepomuk so that libktelepathy can build a Person list for channel participants.<br />
<br />
* Add unit-tests for the Telepathy Observer part of the codebase.<br />
<br />
<br />
<br />
<br />
==Old==<br />
<br />
===About===<br />
telepathy-integration-daemon is a Daemon that syncs details of your Telepathy accounts and their contacts into Nepomuk. It should always be running in the background (telepathy-monitor-kded or whatever it's called - basically a KDED module for keeping an eye on services that KDE requires to be running for fully integrated Telepathy functionality - should launch it on startup and keep it running.<br />
<br />
===Current Status===<br />
At the moment, this daemon works well enough for developer purposes.<br />
<br />
Current working features:<br />
* Add my accounts to Nepomuk, and sync their presence and nickname.<br />
* Add my contacts to Nepomuk, and sync their presence and nickname.<br />
<br />
Notable missing features:<br />
* Handle deletion of accounts or contacts.<br />
* Sync any other account/contact parameters.<br />
* Sync from Nepomuk to Telepathy (is this even a desirable feature? I don't yet know).<br />
* Handle avatars.<br />
* Performance/reduce unnecessary network round trips.<br />
<br />
Get the source code here: svn://svn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon<br />
<br />
===Program Structure===<br />
<br />
====TelepathyAccountMonitor====<br />
Main class '''TelepathyAccountMonitor''' monitors the Tp::AccountManager keeping track of any new accounts which are added or removed. For each existing account, creates an instance of '''TelepathyAccount'''.<br />
<br />
====TelepathyAccount====<br />
Monitors one Tp::Account. Keeps its data in sync with the relevant data in nepomuk for that account. When the account is connected, gets the contact list for the connection and creates '''TelepathyContact''' objects for each one.<br />
<br />
====TelepathyContact====<br />
Monitors one Tp::Contact. Keeps any info on it synced to Nepomuk. Destroyed when parent connection goes down.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Components/Integration_Daemon&diff=6282KTp/Components/Integration Daemon2010-11-21T11:52:22Z<p>Grundleborg: </p>
<hr />
<div>== TODO List ==<br />
<br />
It's going to take me ages to have enough time to finish rewriting the telepathy nepomuk service, so here's the TODO list to finish off my branch (here: http://gitweb.kde.org/clones/telepathy-nepomuk-service/gberg/telepathy-nepomuk-service.git/shortlog/refs/heads/mvc-refactor ) if anyone else wants to take it on sooner.<br />
<br />
* Implement contact-properties parts of the Storage class.<br />
<br />
* Deal with accounts being removed from MC.<br />
<br />
* Port to latest ontologies (see https://bugs.freedesktop.org/show_bug.cgi?id=31381 ).<br />
<br />
* Re-add support for capabilities<br />
<br />
* Make sure that group changes on the server when this computer is off are correctly synchronised when we launch telepathy-nepomuk-service again. This could probably be most simply acheived by using a groupsChanged() signal with all groups we are in as the parameter instead of the current groupAdded() and groupRemoved() signals. Also check if any other properties suffer from the same issue.<br />
<br />
* Re-add support for avatars, this time using the avatar cache and only storing a URL in nepomuk.<br />
<br />
* Ensure that nepomuk gets updated correctly on launch even if some properties have changed server-side since we were last running.<br />
<br />
* Re-write unit tests based on the new improved application structure.<br />
<br />
* Add a Telepathy Observer to the code base - this will observe all channels and ensure that the participants in all these channels are correctly stored in Nepomuk so that libktelepathy can build a Person list for channel participants.<br />
<br />
* Add unit-tests for the Telepathy Observer part of the codebase.<br />
<br />
<br />
<br />
<br />
==Old==<br />
<br />
===About===<br />
telepathy-integration-daemon is a Daemon that syncs details of your Telepathy accounts and their contacts into Nepomuk. It should always be running in the background (telepathy-monitor-kded or whatever it's called - basically a KDED module for keeping an eye on services that KDE requires to be running for fully integrated Telepathy functionality - should launch it on startup and keep it running.<br />
<br />
===Current Status===<br />
At the moment, this daemon works well enough for developer purposes.<br />
<br />
Current working features:<br />
* Add my accounts to Nepomuk, and sync their presence and nickname.<br />
* Add my contacts to Nepomuk, and sync their presence and nickname.<br />
<br />
Notable missing features:<br />
* Handle deletion of accounts or contacts.<br />
* Sync any other account/contact parameters.<br />
* Sync from Nepomuk to Telepathy (is this even a desirable feature? I don't yet know).<br />
* Handle avatars.<br />
* Performance/reduce unnecessary network round trips.<br />
<br />
Get the source code here: svn://svn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon<br />
<br />
===Program Structure===<br />
<br />
====TelepathyAccountMonitor====<br />
Main class '''TelepathyAccountMonitor''' monitors the Tp::AccountManager keeping track of any new accounts which are added or removed. For each existing account, creates an instance of '''TelepathyAccount'''.<br />
<br />
====TelepathyAccount====<br />
Monitors one Tp::Account. Keeps its data in sync with the relevant data in nepomuk for that account. When the account is connected, gets the contact list for the connection and creates '''TelepathyContact''' objects for each one.<br />
<br />
====TelepathyContact====<br />
Monitors one Tp::Contact. Keeps any info on it synced to Nepomuk. Destroyed when parent connection goes down.</div>Grundleborghttps://community.kde.org/index.php?title=Schedules/KDE4/4.6_Feature_Plan&diff=51011Schedules/KDE4/4.6 Feature Plan2010-10-24T11:09:35Z<p>Grundleborg: /* kdenetwork */</p>
<hr />
<div>This is a list of planned features for the SC 4.6 release. <br />
<br />
See also: <br />
<br />
*[[Schedules/KDE4/4.6 Release Schedule]] <br />
*[[Schedules/KDE4/4.6 Release Goals]] <br />
*[[Schedules/KDE4/4.5 Feature Plan]] (previous major release)<br />
<br />
<br> Legend: <br />
<br />
*todo =&gt; not started yet <br />
*in-progress =&gt; started, but not completed yet <br />
*done =&gt; completed<br />
<br />
__TOC__ <br />
<br />
<br><br />
<br />
= kdebase-apps =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|Konsole|Move to KTabWidget|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureInProgress|Dolphin|Faceted browsing via Nepomuk|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|Dolphin|Searching support for non-indexed files|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureInProgress|Dolphin|Git-plugin (implemented by Sebastian Dörner and Johannes Steffen)|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureDone|Dolphin| Resizeable columns in the column-view|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureDone|Dolphin| Allow leading zeros when renaming multiple files (implemented by Matthias Fuchs)|peter.penz19@gmail.com|Peter Penz}}<br />
|}<br />
<br />
<br><br />
<br />
= kdebase-runtime =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Plasma|Plasma KPart|ry@n.rix.si|Ryan Rix}}<br />
{{FeatureInProgress|Plasma|Declarative AppletScript to write QML plasmoids|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|Plasma|Optimize the Newspaper containment for the use with touchscreens and the Plasma KPart|mart@kde.org|Marco Martin}}<br />
{{FeatureDone|KWin|Focus tracking for the zoom plugin (uses kaccessible)|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KWin|Extend mouse tracking modes for the zoom plugin|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureInProgress|Nepomuk Backup & Sync| Provide Backup and Sync capabilities to Nepomuk|handa.vish@gmail.com|Vishesh Handa}}<br />
|}<br />
<br />
<br />
<br><br />
<br />
= kdebase-workspace =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact<br />
|-<br />
! style="text-align: center;" colspan="4" | Plasma <br />
{{FeatureInProgress|libtaskmanager / tasks-applet| support for Windows 7 like launchers |akreuzkamp@web.de|Anton Kreuzkamp}}<br />
{{FeatureInProgress|notifications| rework notification applet appearance |mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|notifications| make various dataengines use Plasma::Storage |mart@kde.org|Marco Martin}}<br />
{{FeatureDone|plasma-desktop| UI for editing activity name and icon|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|plasma-desktop| add some default activities|fux@kde.org|Mario Fux}}<br />
{{FeatureTodo|plasma| finish support for activity templates | |??}}<br />
|-<br />
! style="text-align: center;" colspan="4" | KWin<br />
{{FeatureInProgress|dashboard effect| new effect for Plasma dashboard |ademmer@opensuse.org|Andreas Demmer}} <br />
{{FeatureInProgress|kwin/ksmserver| activity sessions |chanika@gmail.com|Chani}} <br />
{{FeatureTodo|libtaskmanager/kwin?| combine the three window-contextmenu codebases into one | |??}} <br />
|}<br />
<br />
<br><br />
<br />
= kdelibs =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|libnepomuk|Convenience operator overloads for query construction|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureDone|libnepomuk|New query flags and improved handling of full text matching scores including sorting|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureTodo|kdeui|Generic find bar widget|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureDone|kdeui|Allow getting and setting the size of the pixmap cache in KImageCache|2kmm@gmx.de|Manuel Mommertz}}<br />
{{FeatureDone|katepart|scripted actions|dhaumann@kde.org|Dominik Haumann}}<br />
{{FeatureDone|katepart|QAccessibleInterface's for document+cursor|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|libplasma|PluginLoader class|ry@n.rix.si|Ryan Rix}}<br />
{{FeatureDone|libplasma|Allow SVGs to use systemcolors before rendering|2kmm@gmx.de|Manuel Mommertz}}<br />
{{FeatureInProgress|libplasma|DeclarativeWidget to load QML scenes in Plasma|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|libplasma|finish up the gsoc project about Plasma::Storage service|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|libnepomuk/KIO|Search excerpts|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuk|Standardqueries for convenience|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuk|GUI elements for resource/file searching including faceted browsing|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuksync|Sync library to be used in BackupSync, Strigi, Akonadi, WebExtractor and Removable Media|handa.vish@gmail.com|Vishesh Handa}}<br />
{{FeatureInProgress|kdecore|Add more possible synchronization primitives to KSharedDataCache to expand OS support. POSIX Semaphores Contributed by Alberto Villa of the FreeBSD project. Windows support may still occur as well.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add fallback to QCache<QString,QByteArray> in KSharedDataCache.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add cache-wide timestamp to KSharedDataCache.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add ability to make KSharedDataCache strictly read-only for laptop support.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureInProgress|kdeui|Social About Dialog|teo@kde.org|Teo Mrnjavac}}<br />
|}<br />
<br />
<br><br />
<br />
= kdeedu =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Marble|GPX import of routes|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Route printing (map and directions, configurabe)|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Route state saving and restoring|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Convert MarbleRunners to plugins|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|worldwide and offline routing|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Extend MarbleRunner interface to handle reverse geocoding and routing requests; Display of alternative routes|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureInProgress|Marble|Routing API|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureInProgress|Marble|Implement sun locator blendings as derived classes of Marble::Blending|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureTodo|Marble|Separate thread for tile loading and texture blending (not texture mapping at the moment) for more smooth browsing|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureTodo|Marble|Tile loading "read ahead" when idle, prerequisite: threaded tile loading|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureDone|Marble|Tile download along the route for offline usage|akssps011@gmail.com|Siddharth Srivastavah}}<br />
{{FeatureInProgress|Marble|Turn-by-turn navigation mode|akssps011@gmail.com|Siddharth Srivastavah}}<br />
{{FeatureTodo|Marble|Multi threaded texture mapping|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureDone|Marble|Improve GeoData API|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Convert Gps tracking to GeoDataDocument|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Provide a treeModel for GeoDataDocuments|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Draw the geometries of multiple GeoDataDocuments|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureInProgress|Marble|Load Pnt vector data files as GeoData|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureInProgress|Marble|Manipulate Gps track data|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Cantor|Backend for GNU Octave|miha.cancula@gmail.com|Miha Čančula}}<br />
{{FeatureTodo|Cantor|Merge R improvement branch|alexanderrieder@gmail.com|Alexander Rieder}}<br />
{{FeatureTodo|Cantor|Variable management panel|alexanderrieder@gmail.com|Alexander Rieder}}<br />
{{FeatureDone|Kalzium|Port Kalzium to use QGV based periodic table widget|mhanwell@kde.org|Marcus D. Hanwell}}<br />
{{FeatureDone|KAlgebra|Implicit functions plot|percy.camilo.ta@gmail.com|Percy Aucahuasi}}<br />
{{FeatureDone|KAlgebra|Improved execution speed on the calculator|aleixpol@kde.org|Aleix Pol Gonzalez}}<br />
{{FeatureDone|KAlgebra|Better integration between the Console and the Plotting facilities|aleixpol@kde.org|Aleix Pol Gonzalez}}<br />
{{FeatureInProgress|KStars|OpenGL rendering support for KStars|akarshsimha@gmail.com|Harry de Valence, Akarsh Simha}}<br />
{{FeatureInProgress|KStars|Better designed object database|akarshsimha@gmail.com|Victor Carbune, Akarsh Simha}}<br />
{{FeatureInProgress|KStars|Star Hop Generator|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureDone|Kig|LaTeX/TikZ exporter|miha.cancula@gmail.com|Miha Čančula}}<br />
|}<br />
<br />
<br><br />
<br />
= kdemultimedia =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|JuK|Remove Qt/KDE3 support lib requirements|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Allow setting covers directly from URLs supported by KIO - drag/drop already allows this however|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Add MPRIS support to JuK so that the NowPlaying applet doesn't need to special-case JuK.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Update JuK's MusicBrainz support to a modern version of MusicBrainz.|mpyne@kde.org|Michael Pyne}}<br />
<br />
|}<br />
<br />
<br/><br />
<br />
= kdegames =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|libkdegames|Import KGameRenderer framework and [[Projects/Games/Porting|port games]] to this unified rendering infrastructure.|majewsky@gmx.net|Stefan Majewsky}}<br />
{{FeatureInProgress|Kigo|Fix KNewStuff provider issues|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureDone|Palapeli|Import Goldberg slicer as the new default slicer plugin.|loehnert.kde@gmx.de|Johannes Loehnert}}<br />
{{FeatureDone|Palapeli|Update libpala API. Improve usability of "Create new puzzle" dialog.|majewsky@gmx.net|Stefan Majewsky}}<br />
{{FeatureDone|Kajongg|Docbook: Describe the basic game, until now I supposed the player already knows how to play Mah Jong.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Tiles can be discarded with drag&drop.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make robot player AI more intelligent.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make tiles in the hand larger and the wall tiles smaller for better playability on small screens.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make games suspendable/resumable.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureInProgress|Kajongg|Animate moving tiles.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureTodo|Kajongg|Add more rulesets like other Classical Chinese variants and the international tournament rules.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|KGoldrunner|Save and restore the current control-mode, keyboard-control option and game-speed settings.|iandw.au@gmail.com|Ian Wadham}}<br />
{{FeatureDone|KGoldrunner|Add a keyboard-mode option to start moving when a direction-key is pressed and stop when it is released. Support multiple keys being pressed.|iandw.au@gmail.com|Ian Wadham}}<br />
{{FeatureDone|Klickety|An adaptation of the "clickomania" game.Rewrite the kde3 version.|shuizhuyuanluo@126.com|Ni Hui}}<br />
{{FeatureInProgress|Klickety|IMerge KSame into Klickety.|shuizhuyuanluo@126.com|Ni Hui}}<br />
{{FeatureInProgress|Kolf|Port to KGameRenderer, cleanup all QGraphicsView- and physics-related code (and physics engine), incorporate ideas from Kolf-NG.|majewsky@gmx.net|Stefan Majewsky}}<br />
|}<br />
<br />
<br/><br />
<br />
= kdesdk =<br />
<br />
{| cellspa/cing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Lokalize|Integrate snowball stemmer for glossary|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Continue implementing XLIFF spec|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Segmentation [editing] functionality|shafff@NOSPAMukr.net |Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Remote translation memories|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Integrate with nepomuk (fast stats retrieval, tag cloud - incl sharing!)|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|loading compressed files and then saving them back in the original compression format (bug 65518)|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Nepomukshell|New Nepomukshell development tool allowing to browse and debug Nepomuk data|trueg@kde.org|Sebastian Trueg}} <br />
{{FeatureInProgress|Dolphin|Git plugin|sebastian@sebastian-doerner.de|Sebastian Doerner}} <br />
|}<br />
<br />
<br><br />
<br />
= kdeutils =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Ark|Add a "Preview with..." context menu item|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Add an options dialog (maybe)|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|Ark|Add feedback for the latest operation in the status bar|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Get rid of the Observer code in Kerfuffle|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make error reporting work as expected in Kerfuffle|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make Kerfuffle really thread-safe (and use threads in less places)|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make the internal previewer optional|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Simplify Kerfuffle's API (jobs, interfaces etc) and try to make it stable|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Support for custom options from the compression interface (eg. a slider for selecting compression level for rar files)|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|Ark|Try multiple plugins for each archive type before failing|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Okteta|Add a general KPart adapter to Kasten, than finish port of Okteta KPart to Okteta Kasten|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add global toggle option for the offset display, hex or decimal|kossebau@kde.org|Friedrich W. H. Kossebau}} <br />
{{FeatureTodo|Okteta|Add Kate-like combined dialogs to query for actions on files|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add Kate-like search tool|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add Okular like embedded notifications|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for import by drop, both url and data|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for memory mapping of files and 64-bit addressing|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for jobs like io, printing, string search or filter|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add view profiles, incl. editor/manager|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|copy again puts also a value or char variant of the data to clipboard|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Improve the titels of the changes to the bytearray to be more descriptive, best using ids to avoid text string|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Make all user interaction in the KastenCore managers plugin-based|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Merge row and column widgets into one|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Store bookmarks|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Store bookmarks and other view settings for next load|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|printer-applet|Restore feature parity with KDEPrint3 where possible.||Jonathon Riddell, John Layt}} <br />
{{FeatureTodo|Okteta|Add view profiles|kossebau@kde.org|Friedrich W. H. Kossebau}} <br />
|}<br />
<br />
<br><br />
<br />
= kdepim =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|Kontact|Plasma-based Summary Page|ry@n.rix.si|Ryan Rix}}<br />
|}<br />
<br />
<br/><br />
<br />
<br />
= kdeaccessibility =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|KAccessible|Added a dbus-service and a QAccessibleBridgePlugin for focus tracking (used in KMagnifier and the KWin zoom plugin).|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KMagnifier|Follow Focus Mode for Focus Tracking (uses kaccessible).|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KAccessible|Added Screenreader (uses speech-dispatcher)|mail@dipe.org|Sebastian Sauer}}<br />
|}<br />
<br />
<br><br />
= kdeartwork =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|KDE Asciiquarium|Added a new ASCII sprite (a submarine). Contributed by Ryan Meldrum.|mpyne@kde.org.|Michael Pyne}}<br />
|}<br />
<br />
<br><br />
= kdeplasma-addons =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|Shelf|Automatic sizing of the popup|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Setting a custom popup icon|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|Shelf|Cascading popup menus for folders|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Keyboard navigation|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Search completion|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureInProgress|libLancelot-datamodels|Akonadi integration|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|libLancelot-datamodels|Folder contents sorting|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureInProgress|Lancelot|Theme improvements, animations|ivan.cukic@kde.org|Ivan Čukić}}<br />
|}<br />
<br />
<br><br />
= kdenetwork =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|krfb|Refactor Core to make it more maintainable/extensible|grundleborg@googlemail.com.|George Goldberg}}<br />
{{FeatureInProgress|krfb|Telepathy Tubes support|grundleborg@googlemail.com.|George Goldberg}}<br />
{{FeatureInProgress|krfb|UI Improvements to support new features/deal with some existing bug reports|grundleborg@googlemail.com.|George Goldberg}}<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Schedules/KDE4/4.6_Feature_Plan&diff=51010Schedules/KDE4/4.6 Feature Plan2010-10-24T11:08:41Z<p>Grundleborg: more krfb features</p>
<hr />
<div>This is a list of planned features for the SC 4.6 release. <br />
<br />
See also: <br />
<br />
*[[Schedules/KDE4/4.6 Release Schedule]] <br />
*[[Schedules/KDE4/4.6 Release Goals]] <br />
*[[Schedules/KDE4/4.5 Feature Plan]] (previous major release)<br />
<br />
<br> Legend: <br />
<br />
*todo =&gt; not started yet <br />
*in-progress =&gt; started, but not completed yet <br />
*done =&gt; completed<br />
<br />
__TOC__ <br />
<br />
<br><br />
<br />
= kdebase-apps =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|Konsole|Move to KTabWidget|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureInProgress|Dolphin|Faceted browsing via Nepomuk|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|Dolphin|Searching support for non-indexed files|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureInProgress|Dolphin|Git-plugin (implemented by Sebastian Dörner and Johannes Steffen)|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureDone|Dolphin| Resizeable columns in the column-view|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureDone|Dolphin| Allow leading zeros when renaming multiple files (implemented by Matthias Fuchs)|peter.penz19@gmail.com|Peter Penz}}<br />
|}<br />
<br />
<br><br />
<br />
= kdebase-runtime =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Plasma|Plasma KPart|ry@n.rix.si|Ryan Rix}}<br />
{{FeatureInProgress|Plasma|Declarative AppletScript to write QML plasmoids|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|Plasma|Optimize the Newspaper containment for the use with touchscreens and the Plasma KPart|mart@kde.org|Marco Martin}}<br />
{{FeatureDone|KWin|Focus tracking for the zoom plugin (uses kaccessible)|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KWin|Extend mouse tracking modes for the zoom plugin|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureInProgress|Nepomuk Backup & Sync| Provide Backup and Sync capabilities to Nepomuk|handa.vish@gmail.com|Vishesh Handa}}<br />
|}<br />
<br />
<br />
<br><br />
<br />
= kdebase-workspace =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact<br />
|-<br />
! style="text-align: center;" colspan="4" | Plasma <br />
{{FeatureInProgress|libtaskmanager / tasks-applet| support for Windows 7 like launchers |akreuzkamp@web.de|Anton Kreuzkamp}}<br />
{{FeatureInProgress|notifications| rework notification applet appearance |mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|notifications| make various dataengines use Plasma::Storage |mart@kde.org|Marco Martin}}<br />
{{FeatureDone|plasma-desktop| UI for editing activity name and icon|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|plasma-desktop| add some default activities|fux@kde.org|Mario Fux}}<br />
{{FeatureTodo|plasma| finish support for activity templates | |??}}<br />
|-<br />
! style="text-align: center;" colspan="4" | KWin<br />
{{FeatureInProgress|dashboard effect| new effect for Plasma dashboard |ademmer@opensuse.org|Andreas Demmer}} <br />
{{FeatureInProgress|kwin/ksmserver| activity sessions |chanika@gmail.com|Chani}} <br />
{{FeatureTodo|libtaskmanager/kwin?| combine the three window-contextmenu codebases into one | |??}} <br />
|}<br />
<br />
<br><br />
<br />
= kdelibs =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|libnepomuk|Convenience operator overloads for query construction|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureDone|libnepomuk|New query flags and improved handling of full text matching scores including sorting|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureTodo|kdeui|Generic find bar widget|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureDone|kdeui|Allow getting and setting the size of the pixmap cache in KImageCache|2kmm@gmx.de|Manuel Mommertz}}<br />
{{FeatureDone|katepart|scripted actions|dhaumann@kde.org|Dominik Haumann}}<br />
{{FeatureDone|katepart|QAccessibleInterface's for document+cursor|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|libplasma|PluginLoader class|ry@n.rix.si|Ryan Rix}}<br />
{{FeatureDone|libplasma|Allow SVGs to use systemcolors before rendering|2kmm@gmx.de|Manuel Mommertz}}<br />
{{FeatureInProgress|libplasma|DeclarativeWidget to load QML scenes in Plasma|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|libplasma|finish up the gsoc project about Plasma::Storage service|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|libnepomuk/KIO|Search excerpts|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuk|Standardqueries for convenience|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuk|GUI elements for resource/file searching including faceted browsing|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuksync|Sync library to be used in BackupSync, Strigi, Akonadi, WebExtractor and Removable Media|handa.vish@gmail.com|Vishesh Handa}}<br />
{{FeatureInProgress|kdecore|Add more possible synchronization primitives to KSharedDataCache to expand OS support. POSIX Semaphores Contributed by Alberto Villa of the FreeBSD project. Windows support may still occur as well.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add fallback to QCache<QString,QByteArray> in KSharedDataCache.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add cache-wide timestamp to KSharedDataCache.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add ability to make KSharedDataCache strictly read-only for laptop support.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureInProgress|kdeui|Social About Dialog|teo@kde.org|Teo Mrnjavac}}<br />
|}<br />
<br />
<br><br />
<br />
= kdeedu =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Marble|GPX import of routes|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Route printing (map and directions, configurabe)|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Route state saving and restoring|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Convert MarbleRunners to plugins|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|worldwide and offline routing|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Extend MarbleRunner interface to handle reverse geocoding and routing requests; Display of alternative routes|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureInProgress|Marble|Routing API|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureInProgress|Marble|Implement sun locator blendings as derived classes of Marble::Blending|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureTodo|Marble|Separate thread for tile loading and texture blending (not texture mapping at the moment) for more smooth browsing|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureTodo|Marble|Tile loading "read ahead" when idle, prerequisite: threaded tile loading|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureDone|Marble|Tile download along the route for offline usage|akssps011@gmail.com|Siddharth Srivastavah}}<br />
{{FeatureInProgress|Marble|Turn-by-turn navigation mode|akssps011@gmail.com|Siddharth Srivastavah}}<br />
{{FeatureTodo|Marble|Multi threaded texture mapping|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureDone|Marble|Improve GeoData API|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Convert Gps tracking to GeoDataDocument|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Provide a treeModel for GeoDataDocuments|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Draw the geometries of multiple GeoDataDocuments|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureInProgress|Marble|Load Pnt vector data files as GeoData|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureInProgress|Marble|Manipulate Gps track data|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Cantor|Backend for GNU Octave|miha.cancula@gmail.com|Miha Čančula}}<br />
{{FeatureTodo|Cantor|Merge R improvement branch|alexanderrieder@gmail.com|Alexander Rieder}}<br />
{{FeatureTodo|Cantor|Variable management panel|alexanderrieder@gmail.com|Alexander Rieder}}<br />
{{FeatureDone|Kalzium|Port Kalzium to use QGV based periodic table widget|mhanwell@kde.org|Marcus D. Hanwell}}<br />
{{FeatureDone|KAlgebra|Implicit functions plot|percy.camilo.ta@gmail.com|Percy Aucahuasi}}<br />
{{FeatureDone|KAlgebra|Improved execution speed on the calculator|aleixpol@kde.org|Aleix Pol Gonzalez}}<br />
{{FeatureDone|KAlgebra|Better integration between the Console and the Plotting facilities|aleixpol@kde.org|Aleix Pol Gonzalez}}<br />
{{FeatureInProgress|KStars|OpenGL rendering support for KStars|akarshsimha@gmail.com|Harry de Valence, Akarsh Simha}}<br />
{{FeatureInProgress|KStars|Better designed object database|akarshsimha@gmail.com|Victor Carbune, Akarsh Simha}}<br />
{{FeatureInProgress|KStars|Star Hop Generator|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureDone|Kig|LaTeX/TikZ exporter|miha.cancula@gmail.com|Miha Čančula}}<br />
|}<br />
<br />
<br><br />
<br />
= kdemultimedia =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|JuK|Remove Qt/KDE3 support lib requirements|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Allow setting covers directly from URLs supported by KIO - drag/drop already allows this however|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Add MPRIS support to JuK so that the NowPlaying applet doesn't need to special-case JuK.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Update JuK's MusicBrainz support to a modern version of MusicBrainz.|mpyne@kde.org|Michael Pyne}}<br />
<br />
|}<br />
<br />
<br/><br />
<br />
= kdegames =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|libkdegames|Import KGameRenderer framework and [[Projects/Games/Porting|port games]] to this unified rendering infrastructure.|majewsky@gmx.net|Stefan Majewsky}}<br />
{{FeatureInProgress|Kigo|Fix KNewStuff provider issues|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureDone|Palapeli|Import Goldberg slicer as the new default slicer plugin.|loehnert.kde@gmx.de|Johannes Loehnert}}<br />
{{FeatureDone|Palapeli|Update libpala API. Improve usability of "Create new puzzle" dialog.|majewsky@gmx.net|Stefan Majewsky}}<br />
{{FeatureDone|Kajongg|Docbook: Describe the basic game, until now I supposed the player already knows how to play Mah Jong.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Tiles can be discarded with drag&drop.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make robot player AI more intelligent.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make tiles in the hand larger and the wall tiles smaller for better playability on small screens.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make games suspendable/resumable.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureInProgress|Kajongg|Animate moving tiles.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureTodo|Kajongg|Add more rulesets like other Classical Chinese variants and the international tournament rules.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|KGoldrunner|Save and restore the current control-mode, keyboard-control option and game-speed settings.|iandw.au@gmail.com|Ian Wadham}}<br />
{{FeatureDone|KGoldrunner|Add a keyboard-mode option to start moving when a direction-key is pressed and stop when it is released. Support multiple keys being pressed.|iandw.au@gmail.com|Ian Wadham}}<br />
{{FeatureDone|Klickety|An adaptation of the "clickomania" game.Rewrite the kde3 version.|shuizhuyuanluo@126.com|Ni Hui}}<br />
{{FeatureInProgress|Klickety|IMerge KSame into Klickety.|shuizhuyuanluo@126.com|Ni Hui}}<br />
{{FeatureInProgress|Kolf|Port to KGameRenderer, cleanup all QGraphicsView- and physics-related code (and physics engine), incorporate ideas from Kolf-NG.|majewsky@gmx.net|Stefan Majewsky}}<br />
|}<br />
<br />
<br/><br />
<br />
= kdesdk =<br />
<br />
{| cellspa/cing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Lokalize|Integrate snowball stemmer for glossary|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Continue implementing XLIFF spec|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Segmentation [editing] functionality|shafff@NOSPAMukr.net |Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Remote translation memories|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Integrate with nepomuk (fast stats retrieval, tag cloud - incl sharing!)|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|loading compressed files and then saving them back in the original compression format (bug 65518)|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Nepomukshell|New Nepomukshell development tool allowing to browse and debug Nepomuk data|trueg@kde.org|Sebastian Trueg}} <br />
{{FeatureInProgress|Dolphin|Git plugin|sebastian@sebastian-doerner.de|Sebastian Doerner}} <br />
|}<br />
<br />
<br><br />
<br />
= kdeutils =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Ark|Add a "Preview with..." context menu item|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Add an options dialog (maybe)|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|Ark|Add feedback for the latest operation in the status bar|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Get rid of the Observer code in Kerfuffle|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make error reporting work as expected in Kerfuffle|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make Kerfuffle really thread-safe (and use threads in less places)|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make the internal previewer optional|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Simplify Kerfuffle's API (jobs, interfaces etc) and try to make it stable|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Support for custom options from the compression interface (eg. a slider for selecting compression level for rar files)|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|Ark|Try multiple plugins for each archive type before failing|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Okteta|Add a general KPart adapter to Kasten, than finish port of Okteta KPart to Okteta Kasten|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add global toggle option for the offset display, hex or decimal|kossebau@kde.org|Friedrich W. H. Kossebau}} <br />
{{FeatureTodo|Okteta|Add Kate-like combined dialogs to query for actions on files|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add Kate-like search tool|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add Okular like embedded notifications|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for import by drop, both url and data|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for memory mapping of files and 64-bit addressing|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for jobs like io, printing, string search or filter|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add view profiles, incl. editor/manager|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|copy again puts also a value or char variant of the data to clipboard|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Improve the titels of the changes to the bytearray to be more descriptive, best using ids to avoid text string|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Make all user interaction in the KastenCore managers plugin-based|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Merge row and column widgets into one|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Store bookmarks|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Store bookmarks and other view settings for next load|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|printer-applet|Restore feature parity with KDEPrint3 where possible.||Jonathon Riddell, John Layt}} <br />
{{FeatureTodo|Okteta|Add view profiles|kossebau@kde.org|Friedrich W. H. Kossebau}} <br />
|}<br />
<br />
<br><br />
<br />
= kdepim =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|Kontact|Plasma-based Summary Page|ry@n.rix.si|Ryan Rix}}<br />
|}<br />
<br />
<br/><br />
<br />
<br />
= kdeaccessibility =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|KAccessible|Added a dbus-service and a QAccessibleBridgePlugin for focus tracking (used in KMagnifier and the KWin zoom plugin).|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KMagnifier|Follow Focus Mode for Focus Tracking (uses kaccessible).|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KAccessible|Added Screenreader (uses speech-dispatcher)|mail@dipe.org|Sebastian Sauer}}<br />
|}<br />
<br />
<br><br />
= kdeartwork =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|KDE Asciiquarium|Added a new ASCII sprite (a submarine). Contributed by Ryan Meldrum.|mpyne@kde.org.|Michael Pyne}}<br />
|}<br />
<br />
<br><br />
= kdeplasma-addons =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|Shelf|Automatic sizing of the popup|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Setting a custom popup icon|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|Shelf|Cascading popup menus for folders|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Keyboard navigation|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Search completion|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureInProgress|libLancelot-datamodels|Akonadi integration|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|libLancelot-datamodels|Folder contents sorting|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureInProgress|Lancelot|Theme improvements, animations|ivan.cukic@kde.org|Ivan Čukić}}<br />
|}<br />
<br />
<br><br />
= kdenetwork =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|krfb|Refactor Core to make it more maintainable/extensible|grundleborg@googlemail.com.|George Goldberg}}<br />
{{FeatureInProgress|krfb|Telepathy Tubes support|grundleborg@googlemail.com.|George Goldberg}}<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Schedules/KDE4/4.6_Feature_Plan&diff=51009Schedules/KDE4/4.6 Feature Plan2010-10-23T18:36:22Z<p>Grundleborg: add krfb</p>
<hr />
<div>This is a list of planned features for the SC 4.6 release. <br />
<br />
See also: <br />
<br />
*[[Schedules/KDE4/4.6 Release Schedule]] <br />
*[[Schedules/KDE4/4.6 Release Goals]] <br />
*[[Schedules/KDE4/4.5 Feature Plan]] (previous major release)<br />
<br />
<br> Legend: <br />
<br />
*todo =&gt; not started yet <br />
*in-progress =&gt; started, but not completed yet <br />
*done =&gt; completed<br />
<br />
__TOC__ <br />
<br />
<br><br />
<br />
= kdebase-apps =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|Konsole|Move to KTabWidget|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureInProgress|Dolphin|Faceted browsing via Nepomuk|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|Dolphin|Searching support for non-indexed files|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureInProgress|Dolphin|Git-plugin (implemented by Sebastian Dörner and Johannes Steffen)|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureDone|Dolphin| Resizeable columns in the column-view|peter.penz19@gmail.com|Peter Penz}}<br />
{{FeatureDone|Dolphin| Allow leading zeros when renaming multiple files (implemented by Matthias Fuchs)|peter.penz19@gmail.com|Peter Penz}}<br />
|}<br />
<br />
<br><br />
<br />
= kdebase-runtime =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Plasma|Plasma KPart|ry@n.rix.si|Ryan Rix}}<br />
{{FeatureInProgress|Plasma|Declarative AppletScript to write QML plasmoids|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|Plasma|Optimize the Newspaper containment for the use with touchscreens and the Plasma KPart|mart@kde.org|Marco Martin}}<br />
{{FeatureDone|KWin|Focus tracking for the zoom plugin (uses kaccessible)|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KWin|Extend mouse tracking modes for the zoom plugin|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureInProgress|Nepomuk Backup & Sync| Provide Backup and Sync capabilities to Nepomuk|handa.vish@gmail.com|Vishesh Handa}}<br />
|}<br />
<br />
<br />
<br><br />
<br />
= kdebase-workspace =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact<br />
|-<br />
! style="text-align: center;" colspan="4" | Plasma <br />
{{FeatureInProgress|libtaskmanager / tasks-applet| support for Windows 7 like launchers |akreuzkamp@web.de|Anton Kreuzkamp}}<br />
{{FeatureInProgress|notifications| rework notification applet appearance |mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|notifications| make various dataengines use Plasma::Storage |mart@kde.org|Marco Martin}}<br />
{{FeatureDone|plasma-desktop| UI for editing activity name and icon|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|plasma-desktop| add some default activities|fux@kde.org|Mario Fux}}<br />
{{FeatureTodo|plasma| finish support for activity templates | |??}}<br />
|-<br />
! style="text-align: center;" colspan="4" | KWin<br />
{{FeatureInProgress|dashboard effect| new effect for Plasma dashboard |ademmer@opensuse.org|Andreas Demmer}} <br />
{{FeatureInProgress|kwin/ksmserver| activity sessions |chanika@gmail.com|Chani}} <br />
{{FeatureTodo|libtaskmanager/kwin?| combine the three window-contextmenu codebases into one | |??}} <br />
|}<br />
<br />
<br><br />
<br />
= kdelibs =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|libnepomuk|Convenience operator overloads for query construction|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureDone|libnepomuk|New query flags and improved handling of full text matching scores including sorting|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureTodo|kdeui|Generic find bar widget|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureDone|kdeui|Allow getting and setting the size of the pixmap cache in KImageCache|2kmm@gmx.de|Manuel Mommertz}}<br />
{{FeatureDone|katepart|scripted actions|dhaumann@kde.org|Dominik Haumann}}<br />
{{FeatureDone|katepart|QAccessibleInterface's for document+cursor|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|libplasma|PluginLoader class|ry@n.rix.si|Ryan Rix}}<br />
{{FeatureDone|libplasma|Allow SVGs to use systemcolors before rendering|2kmm@gmx.de|Manuel Mommertz}}<br />
{{FeatureInProgress|libplasma|DeclarativeWidget to load QML scenes in Plasma|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|libplasma|finish up the gsoc project about Plasma::Storage service|mart@kde.org|Marco Martin}}<br />
{{FeatureInProgress|libnepomuk/KIO|Search excerpts|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuk|Standardqueries for convenience|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuk|GUI elements for resource/file searching including faceted browsing|trueg@kde.org|Sebastian Trueg}}<br />
{{FeatureInProgress|libnepomuksync|Sync library to be used in BackupSync, Strigi, Akonadi, WebExtractor and Removable Media|handa.vish@gmail.com|Vishesh Handa}}<br />
{{FeatureInProgress|kdecore|Add more possible synchronization primitives to KSharedDataCache to expand OS support. POSIX Semaphores Contributed by Alberto Villa of the FreeBSD project. Windows support may still occur as well.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add fallback to QCache<QString,QByteArray> in KSharedDataCache.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add cache-wide timestamp to KSharedDataCache.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|kdecore|Add ability to make KSharedDataCache strictly read-only for laptop support.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureInProgress|kdeui|Social About Dialog|teo@kde.org|Teo Mrnjavac}}<br />
|}<br />
<br />
<br><br />
<br />
= kdeedu =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Marble|GPX import of routes|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Route printing (map and directions, configurabe)|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Route state saving and restoring|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Convert MarbleRunners to plugins|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|worldwide and offline routing|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureDone|Marble|Extend MarbleRunner interface to handle reverse geocoding and routing requests; Display of alternative routes|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureInProgress|Marble|Routing API|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureInProgress|Marble|Implement sun locator blendings as derived classes of Marble::Blending|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureTodo|Marble|Separate thread for tile loading and texture blending (not texture mapping at the moment) for more smooth browsing|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureTodo|Marble|Tile loading "read ahead" when idle, prerequisite: threaded tile loading|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureDone|Marble|Tile download along the route for offline usage|akssps011@gmail.com|Siddharth Srivastavah}}<br />
{{FeatureInProgress|Marble|Turn-by-turn navigation mode|akssps011@gmail.com|Siddharth Srivastavah}}<br />
{{FeatureTodo|Marble|Multi threaded texture mapping|jmho@c-xx.com|Jens-Michael Hoffmann}}<br />
{{FeatureDone|Marble|Improve GeoData API|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Convert Gps tracking to GeoDataDocument|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Provide a treeModel for GeoDataDocuments|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Marble|Draw the geometries of multiple GeoDataDocuments|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureInProgress|Marble|Load Pnt vector data files as GeoData|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureInProgress|Marble|Manipulate Gps track data|tgridel@freedotfr|Thibaut Gridel}}<br />
{{FeatureDone|Cantor|Backend for GNU Octave|miha.cancula@gmail.com|Miha Čančula}}<br />
{{FeatureTodo|Cantor|Merge R improvement branch|alexanderrieder@gmail.com|Alexander Rieder}}<br />
{{FeatureTodo|Cantor|Variable management panel|alexanderrieder@gmail.com|Alexander Rieder}}<br />
{{FeatureDone|Kalzium|Port Kalzium to use QGV based periodic table widget|mhanwell@kde.org|Marcus D. Hanwell}}<br />
{{FeatureDone|KAlgebra|Implicit functions plot|percy.camilo.ta@gmail.com|Percy Aucahuasi}}<br />
{{FeatureDone|KAlgebra|Improved execution speed on the calculator|aleixpol@kde.org|Aleix Pol Gonzalez}}<br />
{{FeatureDone|KAlgebra|Better integration between the Console and the Plotting facilities|aleixpol@kde.org|Aleix Pol Gonzalez}}<br />
{{FeatureInProgress|KStars|OpenGL rendering support for KStars|akarshsimha@gmail.com|Harry de Valence, Akarsh Simha}}<br />
{{FeatureInProgress|KStars|Better designed object database|akarshsimha@gmail.com|Victor Carbune, Akarsh Simha}}<br />
{{FeatureInProgress|KStars|Star Hop Generator|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureDone|Kig|LaTeX/TikZ exporter|miha.cancula@gmail.com|Miha Čančula}}<br />
|}<br />
<br />
<br><br />
<br />
= kdemultimedia =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|JuK|Remove Qt/KDE3 support lib requirements|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Allow setting covers directly from URLs supported by KIO - drag/drop already allows this however|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Add MPRIS support to JuK so that the NowPlaying applet doesn't need to special-case JuK.|mpyne@kde.org|Michael Pyne}}<br />
{{FeatureTodo|JuK|Update JuK's MusicBrainz support to a modern version of MusicBrainz.|mpyne@kde.org|Michael Pyne}}<br />
<br />
|}<br />
<br />
<br/><br />
<br />
= kdegames =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|libkdegames|Import KGameRenderer framework and [[Projects/Games/Porting|port games]] to this unified rendering infrastructure.|majewsky@gmx.net|Stefan Majewsky}}<br />
{{FeatureInProgress|Kigo|Fix KNewStuff provider issues|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureDone|Palapeli|Import Goldberg slicer as the new default slicer plugin.|loehnert.kde@gmx.de|Johannes Loehnert}}<br />
{{FeatureDone|Palapeli|Update libpala API. Improve usability of "Create new puzzle" dialog.|majewsky@gmx.net|Stefan Majewsky}}<br />
{{FeatureDone|Kajongg|Docbook: Describe the basic game, until now I supposed the player already knows how to play Mah Jong.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Tiles can be discarded with drag&drop.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make robot player AI more intelligent.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make tiles in the hand larger and the wall tiles smaller for better playability on small screens.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|Kajongg|Make games suspendable/resumable.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureInProgress|Kajongg|Animate moving tiles.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureTodo|Kajongg|Add more rulesets like other Classical Chinese variants and the international tournament rules.|wolfgang@rohdewald.de|Wolfgang Rohdewald}}<br />
{{FeatureDone|KGoldrunner|Save and restore the current control-mode, keyboard-control option and game-speed settings.|iandw.au@gmail.com|Ian Wadham}}<br />
{{FeatureDone|KGoldrunner|Add a keyboard-mode option to start moving when a direction-key is pressed and stop when it is released. Support multiple keys being pressed.|iandw.au@gmail.com|Ian Wadham}}<br />
{{FeatureDone|Klickety|An adaptation of the "clickomania" game.Rewrite the kde3 version.|shuizhuyuanluo@126.com|Ni Hui}}<br />
{{FeatureInProgress|Klickety|IMerge KSame into Klickety.|shuizhuyuanluo@126.com|Ni Hui}}<br />
{{FeatureInProgress|Kolf|Port to KGameRenderer, cleanup all QGraphicsView- and physics-related code (and physics engine), incorporate ideas from Kolf-NG.|majewsky@gmx.net|Stefan Majewsky}}<br />
|}<br />
<br />
<br/><br />
<br />
= kdesdk =<br />
<br />
{| cellspa/cing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Lokalize|Integrate snowball stemmer for glossary|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Continue implementing XLIFF spec|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Segmentation [editing] functionality|shafff@NOSPAMukr.net |Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Remote translation memories|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|Integrate with nepomuk (fast stats retrieval, tag cloud - incl sharing!)|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Lokalize|loading compressed files and then saving them back in the original compression format (bug 65518)|shafff@NOSPAMukr.net|Nick Shaforostoff}} <br />
{{FeatureTodo|Nepomukshell|New Nepomukshell development tool allowing to browse and debug Nepomuk data|trueg@kde.org|Sebastian Trueg}} <br />
{{FeatureInProgress|Dolphin|Git plugin|sebastian@sebastian-doerner.de|Sebastian Doerner}} <br />
|}<br />
<br />
<br><br />
<br />
= kdeutils =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureTodo|Ark|Add a "Preview with..." context menu item|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Add an options dialog (maybe)|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|Ark|Add feedback for the latest operation in the status bar|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Get rid of the Observer code in Kerfuffle|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make error reporting work as expected in Kerfuffle|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make Kerfuffle really thread-safe (and use threads in less places)|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Make the internal previewer optional|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Simplify Kerfuffle's API (jobs, interfaces etc) and try to make it stable|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Ark|Support for custom options from the compression interface (eg. a slider for selecting compression level for rar files)|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|Ark|Try multiple plugins for each archive type before failing|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|Okteta|Add a general KPart adapter to Kasten, than finish port of Okteta KPart to Okteta Kasten|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add global toggle option for the offset display, hex or decimal|kossebau@kde.org|Friedrich W. H. Kossebau}} <br />
{{FeatureTodo|Okteta|Add Kate-like combined dialogs to query for actions on files|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add Kate-like search tool|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add Okular like embedded notifications|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for import by drop, both url and data|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for memory mapping of files and 64-bit addressing|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add support for jobs like io, printing, string search or filter|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Add view profiles, incl. editor/manager|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|copy again puts also a value or char variant of the data to clipboard|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Improve the titels of the changes to the bytearray to be more descriptive, best using ids to avoid text string|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Make all user interaction in the KastenCore managers plugin-based|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Merge row and column widgets into one|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Store bookmarks|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Store bookmarks and other view settings for next load|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|printer-applet|Restore feature parity with KDEPrint3 where possible.||Jonathon Riddell, John Layt}} <br />
{{FeatureTodo|Okteta|Add view profiles|kossebau@kde.org|Friedrich W. H. Kossebau}} <br />
|}<br />
<br />
<br><br />
<br />
= kdepim =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|Kontact|Plasma-based Summary Page|ry@n.rix.si|Ryan Rix}}<br />
|}<br />
<br />
<br/><br />
<br />
<br />
= kdeaccessibility =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|KAccessible|Added a dbus-service and a QAccessibleBridgePlugin for focus tracking (used in KMagnifier and the KWin zoom plugin).|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KMagnifier|Follow Focus Mode for Focus Tracking (uses kaccessible).|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|KAccessible|Added Screenreader (uses speech-dispatcher)|mail@dipe.org|Sebastian Sauer}}<br />
|}<br />
<br />
<br><br />
= kdeartwork =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|KDE Asciiquarium|Added a new ASCII sprite (a submarine). Contributed by Ryan Meldrum.|mpyne@kde.org.|Michael Pyne}}<br />
|}<br />
<br />
<br><br />
= kdeplasma-addons =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureDone|Shelf|Automatic sizing of the popup|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Setting a custom popup icon|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|Shelf|Cascading popup menus for folders|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Keyboard navigation|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureDone|Shelf|Search completion|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureInProgress|libLancelot-datamodels|Akonadi integration|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureTodo|libLancelot-datamodels|Folder contents sorting|ivan.cukic@kde.org|Ivan Čukić}}<br />
{{FeatureInProgress|Lancelot|Theme improvements, animations|ivan.cukic@kde.org|Ivan Čukić}}<br />
|}<br />
<br />
<br><br />
= kdenetwork =<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" style="border: 1px solid gray; border-collapse: collapse; text-align: left; width: 100%;" class="sortable"<br />
|- style="background: rgb(236, 236, 236) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; white-space: nowrap;"<br />
! Status <br />
! Project <br />
! Description <br />
! Contact <br />
{{FeatureInProgress|krfb|Refactor Core to make it more maintainable/extensible|grundleborg@googlemail.com.|George Goldberg}}<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KDE_e.V./Sprints/Telepathy-2010-09&diff=5146KDE e.V./Sprints/Telepathy-2010-092010-09-21T14:56:55Z<p>Grundleborg: /* Blogs */</p>
<hr />
<div>KDE-Telepathy Sprint at Cambridge (UK) 18th to 20th September 2010 <br />
<br />
== Pictures ==<br />
<br />
== Press ==<br />
<br />
== Blogs ==<br />
*[http://blogs.fsfe.org/drdanz/?p=325 Telepathy-KDE: Questions and Answers] by Daniele Domenichelli<br />
<br />
*[http://blogs.fsfe.org/drdanz/?p=311 Telepathy KDE Sprint: Day 1] by Daniele Domenichelli<br />
<br />
*[http://blogs.fsfe.org/drdanz/?p=310 Telepathy KDE Sprint: Release Roadmap] by Daniele Domenichelli<br />
<br />
*[http://blogs.fsfe.org/drdanz/?p=322 Telepathy KDE Sprint: Group Photo] by Daniele Domenichelli<br />
<br />
*[http://trueg.wordpress.com/2010/09/20/what-happens-if-mr-nepomuk-meets-a-bunch-of-telepathyans/ What happens if Mr. Nepomuk meets a bunch of Telepathyans?] by Sebastian Trueg<br />
<br />
*[http://gkiagia.wordpress.com/2010/09/20/what-is-telepathy-kde/ What is Telepathy-KDE] by George Kiagiadakis<br />
<br />
*[http://gkiagia.wordpress.com/2010/09/20/telepathy-kde-sprint/ Telepathy KDE Sprint] by George Kiagiadakis<br />
<br />
*[http://grundleborg.wordpress.com/2010/09/16/telepathy-kde-sprint-day-1/ Telepathy KDE Sprint: Day -1] by George Goldberg<br />
<br />
== Sponsors ==<br />
Travel and Accommodation sponsorship by [http://ev.kde.org/ KDE e.V.], [http://www.collabora.co.uk Collabora] and [http://www.novell.com Novell].<br />
<br />
Venue, Pizza and Beer provided by [http://www.collabora.co.uk Collabora]</div>Grundleborghttps://community.kde.org/index.php?title=KDE_e.V./Sprints/Telepathy-2010-09&diff=5145KDE e.V./Sprints/Telepathy-2010-092010-09-21T14:56:20Z<p>Grundleborg: Created page with 'KDE-Telepathy Sprint at Cambridge (UK) 18th to 20th September 2010 == Pictures == == Press == == Blogs == *[http://blogs.fsfe.org/drdanz/?p=325 Telepathy-KDE: Questions and ...'</p>
<hr />
<div>KDE-Telepathy Sprint at Cambridge (UK) 18th to 20th September 2010 <br />
<br />
== Pictures ==<br />
<br />
== Press ==<br />
<br />
== Blogs ==<br />
*[http://blogs.fsfe.org/drdanz/?p=325 <br />
Telepathy-KDE: Questions and Answers<br />
] by Daniele Domenichelli<br />
<br />
*[http://blogs.fsfe.org/drdanz/?p=311 <br />
Telepathy KDE Sprint: Day 1<br />
] by Daniele Domenichelli<br />
<br />
*[http://blogs.fsfe.org/drdanz/?p=310 <br />
Telepathy KDE Sprint: Release Roadmap] by Daniele Domenichelli<br />
<br />
*[http://blogs.fsfe.org/drdanz/?p=322 <br />
Telepathy KDE Sprint: Group Photo] by Daniele Domenichelli<br />
<br />
*[http://trueg.wordpress.com/2010/09/20/what-happens-if-mr-nepomuk-meets-a-bunch-of-telepathyans/ What happens if Mr. Nepomuk meets a bunch of Telepathyans?] by Sebastian Trueg<br />
<br />
*[http://gkiagia.wordpress.com/2010/09/20/what-is-telepathy-kde/ What is Telepathy-KDE] by George Kiagiadakis<br />
<br />
*[http://gkiagia.wordpress.com/2010/09/20/telepathy-kde-sprint/ Telepathy KDE Sprint] by George Kiagiadakis<br />
<br />
*[http://grundleborg.wordpress.com/2010/09/16/telepathy-kde-sprint-day-1/ Telepathy KDE Sprint: Day -1] by George Goldberg<br />
<br />
== Sponsors ==<br />
Travel and Accommodation sponsorship by [http://ev.kde.org/ KDE e.V.], [http://www.collabora.co.uk Collabora] and [http://www.novell.com Novell].<br />
<br />
Venue, Pizza and Beer provided by [http://www.collabora.co.uk Collabora]</div>Grundleborghttps://community.kde.org/index.php?title=Sprints&diff=5144Sprints2010-09-21T14:46:40Z<p>Grundleborg: add 2010 telepathy sprint</p>
<hr />
<div>KDE Developer Sprints are focused gatherings of KDE developers to work on a specific part of KDE. They are supported by KDE e.V. financially and organizationally.<br />
<br />
See the [[KDE_e.V./Sprints/Howto|KDE developer sprint HOWTO]] for information about how to organize a sprint.<br />
<br />
== Upcoming Sprints ==<br />
<br />
Add planned sprints here.<br />
<br />
* [[KDE_e.V./Sprints/KDEMobile-2010]], KDE Mobile Meeting, November 2010, To be defined<br />
<br />
== Past Sprints ==<br />
<br />
=== 2010 ===<br />
*[[KDE_e.V./Sprints/Telepathy-2010-09|KDE Telepathy Sprint, September 2010, Cambridge]]<br />
* [http://www.digikam.org/drupal/node/538 KDE Imaging sprint, Aix-en-Provence, August 2010]<br />
* [http://dot.kde.org/2010/06/25/koffice-2010-summer-sprint-report KOffice sprint, Essen, June 2010]<br />
* KDE Windows meeting, Osnabrueck, June 2010<br />
* [http://dot.kde.org/2010/06/03/kde-pim-stabilization-sprint Akonadi meeting, Berlin, May 2010]<br />
* [[KDE_e.V./Sprints/Multimedia-2010-05|Multimedia sprint, Randa, Switzerland, May 2010]]<br />
* [[KDE_e.V./Sprints/Amarok-2010-05|Amarok sprint, Randa, Switzerland, May 2010]]<br />
* [[KDE_e.V./Sprints/KdeEdu-2010|KDE-Edu 2010]], KDE-Edu Meeting in Randa, Switzerland, 20th to 25th May 2010 ([http://dot.kde.org/2010/06/19/report-successful-multimedia-and-edu-sprint-randa joint meeting with KDE multimedia])<br />
* [http://dot.kde.org/2010/07/09/successful-kde-finances-sprint-held KDE Finance Apps Meeting, Frankfurt, April/May 2010]<br />
* [http://br.kde.org/Akademy-BR_2010 Akademy-br, Praia do Forte, April 2010]<br />
* [http://dot.kde.org/2010/03/15/second-krita-sprint-ends-tea Krita sprint, Deventer, February 2010]<br />
* [http://www.valdyas.org/fading/index.cgi/2010/02/22 KPresenter sprint, February 2010]<br />
* [http://dot.kde.org/2010/03/08/kate-kdevelop-and-okteta-developers-meet-berlin KWrite/Kate & KDevelop Meeting, Berlin, February 2010]<br />
* [[KDE_e.V./Sprints/Tokamak4|Tokamak 4]], Plasma, KWin and Oxygen Meeting, February 2010, Nürnberg, Germany<br />
* [http://dot.kde.org/2010/01/14/annual-osnabr%C3%BCck-pim-meeting-brings-exciting-announcements-and-ambitious-plans KDE PIM Meeting, Osnabrück, January 2010]<br />
** [http://www.linux-magazine.com/Online/News/Cold-War-at-the-Eighth-KDE-PIM-Gathering Linux Magazine article about the KDE PIM Meeting]<br />
<br />
=== 2009 ===<br />
<br />
* [http://dot.kde.org/2009/11/22/digikam-and-kipi-sprint KDE Imaging Sprint, Essen, November 2009]<br />
* [http://dot.kde.org/2009/11/20/booth-web-and-marketing-sprint KDE Marketing & Promo Meeting, Stuttgart, November 2009]<br />
* [http://dot.kde.org/2009/11/29/second-koffice-developer-sprint-2009-kickoff KOffice Meeting, Oslo, November 2009]<br />
* KDE Coherence Meeting, Barcelona, October 2009<br />
* [http://dot.kde.org/2009/10/28/gluon-sprint-wrap KDE Games Meeting, Munich, October 2009]<br />
* [http://dot.kde.org/2009/11/06/second-akonadi-sprint-re-factors-communication Akonadi Meeting, Berlin, October 2009]<br />
* [http://dot.kde.org/2009/09/08/third-plasma-summit-lifts-kde-desktop-higher-grounds Plasma Meeting, Tokamak 3, Randa, September 2009]<br />
* KDE Wiki Meeting, Berlin, July 2009<br />
* [http://dot.kde.org/2009/06/13/koffice-2009-sprint-berlin KOffice Meeting, Berlin, June 2009]<br />
* Nepomuk Meeting, Freiburg, June 2009<br />
* [http://dot.kde.org/2009/06/10/network-manager-sprint-oslo Network Manager Meeting, Oslo, June 2009]<br />
* GSoC Meeting, Boston, May 2009<br />
* [http://dot.kde.org/2009/05/07/amarok-developer-sprint-looking-back-rocking-weekend Amarok Meeting, Berlin, May 2009]<br />
* KDE Coherence Meeting, Paris, May 2009<br />
* KDevelop Meeting, Mykolayiv, April 2009<br />
* [http://dot.kde.org/2009/04/06/pim-hackers-boost-akonadi-future Akonadi Meeting, Berlin, April 2009]<br />
* [http://dot.kde.org/2009/02/11/plasma-team-looks-future Plasma Meeting, Tokamak 2, Oporto, February 2009]<br />
* KDE PIM Meeting, Osnabrück, January 2009<br />
* [http://camp.kde.org Camp KDE Jamaica, January 2009]<br />
<br />
=== 2008 ===<br />
<br />
* [http://dot.kde.org/2008/11/11/koffice-sprint-2008 KOffice Meeting, Berlin, November 2008]<br />
* Akonadi Halloween Sprint, Essen, November 2008<br />
* KDE Graphics, Genoa, October 2008<br />
* KPhotoalbum Sprint, Aalborg, September 2008<br />
* Syncing Meeting, Berlin, August 2008<br />
* [http://dot.kde.org/2008/07/21/kde-bindings-kross-meeting KDE Bindings / Kross Meeting, Berlin, July 2008]<br />
* [http://dot.kde.org/2008/04/10/kdevelop-team-meeting-agenda KDevelop Team Meeting, Munich, April 2008]<br />
* [http://dot.kde.org/2008/04/21/tokamak-sprint-turns-plasma-upside-down Tokamak Plasma Sprint, Milan, April 2008]<br />
* [http://dot.kde.org/2008/04/15/kate-developers-meeting Kate Developer Meeting, Darmstadt, April 2008]<br />
* [http://dot.kde.org/2008/03/27/akonadi-sprint-readies-kde-41 Akonadi Developer Meeting, Berlin, March 2008]<br />
* [http://dot.kde.org/2008/02/21/kde-pim-team-meets-talk-akonadi-and-kde-41 KDE PIM Meeting in Osnabrück, February 2008]<br />
* [http://dot.kde.org/2008/01/20/second-day-kde-40-release-event KDE 4.0 Release Event, Mountain View, Janury 2008]<br />
<br />
<br />
=== 2007 ===<br />
<br />
* [http://dot.kde.org/2007/12/05/first-kde-education-meeting-great-success KDE EDU Meeting, Paris, December 2007]<br />
* [http://dot.kde.org/2007/10/30/second-koffice-sprint-berlin-focuses-release-polish KOffice Spit'n'Polish meeting, Berlin, October 2007]<br />
* [http://dot.kde.org/2007/09/18/windows-developers-meet-berlin KDE on Windows Meeting, Berlin, September 2007]<br />
* Amarok meeting at aKademy, Glasgow, July 2007<br />
* Oxygen meeting in Milan, June 2007<br />
* [http://dot.kde.org/2007/05/14/koffice-odf-sprint-report ODF meeting in Berlin, May 2007]<br />
* [http://dot.kde.org/2007/04/25/akonadi-hacking-meeting Akonadi meeting in Berlin, April 2007]<br />
* [http://dot.kde.org/2007/01/29/kde-pim-annual-meeting-pushes-advanced-design-enterprise-stability KDE PIM Meeting at Osnabrück, January 2007]<br />
<br />
=== 2006 ===<br />
* [http://dot.kde.org/1151271635/ KDE 4 Core, Trysil, July 2006]</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Components/Account_Management_GUI&diff=4796KTp/Components/Account Management GUI2010-08-27T11:50:24Z<p>Grundleborg: /* The problem of multiple CM's for each protocol */</p>
<hr />
<div>'''''WARNING: Brain-dump on this page. Please take with a liberal pinch of salt'''''<br />
<br />
==Design Notes/Features==<br />
* KCM Module - can be reused in config dialog of any Telepathy using App to give a "configure accounts" option.<br />
<br />
* Built in default auto-generated UI as a fallback for configuring any Connection manager.<br />
<br />
* Plugin interface to provide prettier UI's for particular connection managers.<br />
<br />
* Plugins for most important connection managers asap:<br />
** Gabble<br />
** Butterfly<br />
** Salut<br />
** Haze (mainly the more common protocols in Haze)<br />
<br />
==Current Status==<br />
<br />
Written, with a gabble plugin. HOWEVER, the design turns out to be a bit crap, and quite limited, so we need to refactor quite a lot.<br />
<br />
TODO: Explain what's crap about the current design ([[User:Grundleborg|Grundleborg]] 15:37, 12 January 2010 (UTC))<br />
<br />
==Contact==<br />
<br />
Developed mainly by George Goldberg (Find me on IRC in #kde-telepathy as 'grundleborg' or email me: 'grundleborg googlemail com'.<br />
<br />
==Redesign==<br />
<br />
===Use Cases===<br />
<br />
====Add an Account====<br />
Imhotep has a Yahoo Messenger account which he wants to use to text chat with his friends. He's not particularly computer savvy, but knows his username and password. However, he tends to get confused when presented with too many unfamiliar form fields.<br />
<br />
Pretzel, on the other hand, is at school. He wants to be able to use his netbook to chat to his MSN buddies during classes on the school network. However, the school uses a proxy server and blocks the default MSN port. Pretzel is pretty good with computers so wants to change the advanced network and proxy settings of his MSN account to get round the school network limitations.<br />
<br />
Fred has been having trouble getting his MSN account to work. He doesn't know this, but it is due to a bug in the telepathy-butterfly version his distribution ships. He asks on the KDE forums for help, and someone recommends he tries connecting to the account with another MSN connection manager, such as telepathy-haze. Fred doesn't know what a "Connection Manager" is, but the other user gives him step by step instructions for how to use telepathy-haze.<br />
<br />
=====Conclusions=====<br />
<br />
* Adding accounts needs to be as simple as possible by default, only presenting the minimum necessary fields.<br />
<br />
* Advanced options need to be accessible but not threatening to less tech-savvy users.<br />
<br />
* A appropriate default choice of CM for a given protocol should be made where more than one is installed without bothering the user. However, it should be possible for users to manually specify a non-default CM for an account if they want.<br />
<br />
====Edit Account====<br />
<br />
Charlie wants to change the display name of his Jabber account.<br />
<br />
Danni is having problems with network connectivity for her MSN account behind a corporate firewall. She's quite good with computers so she wants to play around with the account network and proxy settings to try and get it working.<br />
<br />
Bob also wants to edit his Jabber account - he has changed the password from his home computer, and needs to update the stored one on his work computer.<br />
<br />
Alice typed in her AIM screen name slightly wrong when creating the account. She wants to edit it without having to recreate the account and enter all the other details again too.<br />
<br />
=====Conclusions=====<br />
<br />
* All properties of accounts should be editable, including the username/screenname property.<br />
<br />
* UI should display the basic properties only on the first page displayed to the user, but should still allow editing all advanced properties with the minimum of clicking.<br />
<br />
====Delete Account====<br />
<br />
Alice no longer wants to log into her AIM account on her work computer, but she still intends to use it on her home one.<br />
<br />
Bob has decided he doesn't trust jabber.org any more, so he wants to remove his jabber account both from his computer and from jabber.org altogether.<br />
<br />
=====Conclusions=====<br />
<br />
* Deleting account should be easily possible from the UI.<br />
<br />
* It should, if possible either support optionally deleting the account altogether (if the IM network allows this), or possibly point the user to web-based ways of doing this if it is not possible programmatically?<br />
<br />
<br />
===Technical Requirements===<br />
<br />
====Properties that must be configurable====<br />
<br />
Basic Properties include:<br />
* Some of '''Account.Parameters''' - the required ones e.g. ''username'' and ''password''.<br />
* '''Account.Displayname''' - the name to give this account in the accounts list locally, e.g. ''Jabber: me@example.com'' or something.<br />
* '''Account.Nickname''' - my name to be displayed in other people's buddy list.<br />
* '''Account.Enabled''' - whether this account is enabled or disabled.<br />
* '''Account.ConnectAutomatically''' - whether to connect the account automatically on startup.<br />
* '''Account.Avatar''' - my personal avatar image for this account. Should there be some ''global avatar'' applied to all accounts unless you set one here, which would except it from the global one.<br />
<br />
Advanced Properties include:<br />
* The rest of '''Account.Parameters''' - network settings and other advanced protocol/cm specific misc.<br />
<br />
Other Properties:<br />
* Do we support '''creation of accounts''' as supported by some Jabber servers? ** The old way of doing that seems to be mostly disused now, but I definitely heard mention of a new less spammy way of registering accounts automatically although I don't think gabble supports it yet. Definitely worth asking upstream Telepathy about this a bit. [[User:Grundleborg|Grundleborg]] 12:39, 19 January 2010 (UTC)<br />
<br />
====The problem of multiple CM's for each protocol====<br />
<br />
'''''This section is somewhat out of date and should be revised once profile support lands in telepathy-qt4 upstream'''''<br />
<br />
One feature of Telepathy from a technical point of view, is however, quite a substantial problem from a user-interaction point of view. Telepathy allows you to have multiple Connection Managers (CM's) installed for a given protocol. For instance, I may have both ''telepathy-butterfly'' and ''telepathy-haze'' installed which will both support MSN accounts.<br />
<br />
This is a useful feature because:<br />
* CM's can support different feature sets - I may want to use MSN over HTTPS, which is only supported by haze (afaik, but this is just an example).<br />
* CM's may support multiple protocols (e.g. haze) which means I might want one for one protocol, or another for another one<br />
* CM's may fall unmaintained and a better one may be found for a certain protocol (or just bugs in certain ones).<br />
<br />
This is a problem because:<br />
* We don't want to have to bother users with the technical detail of which CM they are using (what the hell is a CM anyway, and why should they care). However, we do want to make it easily possible for more technical users who do care about what CM they use to choose.<br />
<br />
We need a UI that does not confuse non-technical users with the CM choice, but on the other hand it must allow selection.<br />
<br />
Accounts cannot be sensibly transferred from one CM to another, because the parameters used by them are not standardised. We will choose to accept this limitation for now, since trying to work round it in the UI to allow changing the CM of an account is not reliably possible (too many different versions of CM's and the set of all possible CM's (past and future) not being knowable by us).</div>Grundleborghttps://community.kde.org/index.php?title=UCOSP/2010/Ideas&diff=4706UCOSP/2010/Ideas2010-08-19T21:30:28Z<p>Grundleborg: some basic detail about the gluon project</p>
<hr />
<div>This page is for collecting ideas for UCOSP 2010 students. More information at http://ucosp.ca/about<br />
<br />
<br />
= KOffice =<br />
possible mentor: Boud<br />
<br />
<br />
= KWin =<br />
possible mentor: Martin (not sure he can go to Toronto yet)<br />
<br />
== Mobile port to OpenGL ES ==<br />
KDE's window and compositing manger KWin currently uses OpenGL 1.x for compositing effects. In order to get KWin to mobile devices the rendering has to be ported to OpenGL ES 1.1 and/or ES 2.0. OpenGL ES is a subset of OpenGL, so the code has to be streamlined to use a set of method calls which are both supported on regular hardware as well as on embedded devices. Furthermore the window compositing needs to be reimplemented using EGL instead of GLX. In a second step some of the effects need to be ported to ES. Most of the effects like for example Present Windows will work out of the box, if the rendering system is ported.<br />
<br />
This is a very intersting project as it requires to interact with low level painting on both the desktop and mobile system. While in general it is possible to work with emulators, it might be useful to have access to mobile hardware capable of running KDE software.<br />
<br />
== New Effects ==<br />
KDE's window manager KWin is currently missing a set of unique and coherent effects for standard window interaction like open, close, minimize, maximize. KDE's design team Oxygen has proposed some ideas to address this issue. As part of the project it would be required to work together with the designers to elaborate the effects and implement them in the way the designers want them to be. The effects will require the use of OpenGL shaders, so knowledge of OpenGL Shading Language is a plus, but the language is easy to learn, C-like and very nice to work with.<br />
<br />
= Gluon =<br />
<br />
Gluon is a framework for making games. The project is to add multiplayer infrastructure to Gluon using the [http://telepathy.freedesktop.org Telepathy Framework] - a framework for real-time communication and collaboration.<br />
<br />
Mentors: George and Leinir<br />
<br />
= a11y =<br />
together with Novell/openSuse<br />
possible mentors: Will and Jeremy<br />
<br />
= Edu =<br />
== Application for creating tests ==<br />
We need an application to create tests, the application would have two parts, a server that provides the questions to the students it has attached and every terminal that will receive the questions, show them and send the results to the server. It should use some specific standard protocols also. If that's not enough workload it would be good to have an editor for that too.<br />
<br />
== kvtml editor ==<br />
We have a file format to store information to be consumed by applications that help to learn languages. It would be good to have an editor to be able to easily create such files instead of editing them inside the testing applications.<br />
<br />
== Edu application ==<br />
Create any education application any student can think about, like all these applications that you would have liked to have in class but never had the occasion :).<br />
<br />
= KDevelop =<br />
== Working on a language support ==<br />
It can go from creating the language support from scratch to providing debugging facilities or documentation providers.<br />
<br />
== Visualizations ==<br />
Create visualizations to better understand the code based on the representations provided by KDevelop infrastructure (Project Manager, Language Support and Version Control System).<br />
<br />
== HTML+JS code navigator ==<br />
Use KDevelop infrastructure to create something like what we can find in http://websvn.kde.org/ but adding additional information like the ones we can find in KDevelop itself.</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint1&diff=4625KTp/Events/TelepathySprint12010-08-16T09:55:18Z<p>Grundleborg: confirmed on IRC</p>
<hr />
<div>==Details==<br />
*'''When''': Friday 17th September to Monday 20th September 2010<br />
*'''Where''': Cambridge, UK<br />
(Recommend travel to either London Stansted airport or by train (Eurostar from Europe)).<br />
<br />
More precise details will follow shortly.<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
==Travel and Accommodation==<br />
* If you are definitely intending to come, you should go ahead and book your own travel.<br />
* We will book accommodation as a group once the final list of participants is confirmed. You should indicate in the table below if you want accommodation booking as part of the group or not (you will be emailed with price/location and asked to confirm before we actually make any booking if you indicate that you do want accommodation).<br />
<br />
==Agenda==<br />
<br />
The purpose of this sprint is to allow all of those involved in Telepathy/KDE to meet up and have some productive face to face discussions/work at the time when the project is getting ready to make a release. This sprint will *not* cover integrating Telepathy in other applications, but is focused on getting the Telepathy infrastructure in KDE sorted out.<br />
<br />
We will:<br />
* Take stock of what's going on<br />
* Final plans for the preview release<br />
* Complete API review of all public APIs<br />
* Thorough review of all Nepomuk usage<br />
* Complete review of each and every component in Telepathy/KDE<br />
<br />
If you are involved in KDE/Telepathy, do come along!<br />
<br />
==Time Plan==<br />
* Friday: arrive, social stuff<br />
* Saturday: the serious stuff begins<br />
* Sunday: more serious stuff<br />
* Monday: depart<br />
<br />
==Participants==<br />
<br />
If you plan to attend, please add yourself to the table below.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Travel sponsoring<br />
!Accommodation sponsoring<br />
!Need accommodation booking?<br />
!Arrival date<br />
!Departure date<br />
|-<br />
|George Goldberg<br />
|grundleborg@googlemail.com<br />
|by Collabora<br />
|by Collabora<br />
|yes<br />
| Friday<br />
| Tuesday<br />
|-<br />
|George Kiagiadakis<br />
|kiagiadakis.george@gmail.com<br />
|none<br />
|none<br />
|yes<br />
| Friday<br />
| Tuesday<br />
|-<br />
|Dario Freddi<br />
|drf@kde.org<br />
|by Collabora<br />
|by Collabora<br />
|yes<br />
| Friday<br />
| Monday<br />
|-<br />
|David Edmundson<br />
|kde@davidedmundson.co.uk<br />
|none<br />
|none<br />
|yes<br />
| Friday<br />
| Monday<br />
|-<br />
|Daniele E. Domenichelli<br />
|daniele DOT domenichelli AT gmail DOT com<br />
|none<br />
|none<br />
|yes<br />
| Friday<br />
| Monday<br />
|-<br />
|Andre Moreira Magalhaes<br />
|andre DOT magalhaes AT collabora DOT co DOT uk<br />
|by Collabora<br />
|by Collabora<br />
|?<br />
| Friday<br />
| Monday<br />
|-<br />
|Olli Salli<br />
|olli DOT salli AT collabora DOT co DOT uk<br />
|by Collabora<br />
|by Collabora<br />
|yes<br />
| Friday<br />
| Monday<br />
|-<br />
|Dominik Schmidt<br />
|$firstname dot $lastname at udo dot edu<br />
|none<br />
|none<br />
|yes<br />
| Friday<br />
| Monday<br />
|-<br />
|Will Stephenson<br />
|wstephenson@kde.org<br />
|none<br />
|none<br />
|yes<br />
| Friday<br />
| Sunday<br />
|-|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint1&diff=4518KTp/Events/TelepathySprint12010-08-07T09:35:26Z<p>Grundleborg: </p>
<hr />
<div>==Details==<br />
*'''When''': Friday 17th September to Monday 20th September 2010<br />
*'''Where''': Cambridge, UK<br />
(Recommend travel to either London Stansted airport or by train (Eurostar from Europe)).<br />
<br />
More precise details will follow shortly.<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
==Travel and Accommodation==<br />
* If you are definitely intending to come, you should go ahead and book your own travel.<br />
* We will book accommodation as a group once the final list of participants is confirmed. You should indicate in the table below if you want accommodation booking as part of the group or not (you will be emailed with price/location and asked to confirm before we actually make any booking if you indicate that you do want accommodation).<br />
<br />
==Agenda==<br />
<br />
The purpose of this sprint is to allow all of those involved in Telepathy/KDE to meet up and have some productive face to face discussions/work at the time when the project is getting ready to make a release. This sprint will *not* cover integrating Telepathy in other applications, but is focused on getting the Telepathy infrastructure in KDE sorted out.<br />
<br />
We will:<br />
* Take stock of what's going on<br />
* Final plans for the preview release<br />
* Complete API review of all public APIs<br />
* Thorough review of all Nepomuk usage<br />
* Complete review of each and every component in Telepathy/KDE<br />
<br />
If you are involved in KDE/Telepathy, do come along!<br />
<br />
==Time Plan==<br />
* Friday: arrive, social stuff<br />
* Saturday: the serious stuff begins<br />
* Sunday: more serious stuff<br />
* Monday: depart<br />
<br />
==Participants==<br />
<br />
If you plan to attend, please add yourself to the table below.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Travel sponsoring<br />
!Accommodation sponsoring<br />
!Need accommodation booking?<br />
!Arrival date<br />
!Departure date<br />
|-<br />
|George Goldberg<br />
|grundleborg@googlemail.com<br />
|by Collabora<br />
|by Collabora<br />
|yes<br />
| Friday<br />
| Tuesday<br />
|-<br />
|George Kiagiadakis<br />
|kiagiadakis.george@gmail.com<br />
|none<br />
|none<br />
|?<br />
| Friday<br />
| Tuesday<br />
|-<br />
|Dario Freddi<br />
|drf@kde.org<br />
|by Collabora<br />
|by Collabora<br />
|?<br />
| Friday<br />
| Monday<br />
|-<br />
|David Edmundson<br />
|kde@davidedmundson.co.uk<br />
|none<br />
|none<br />
|?<br />
| Friday<br />
| Monday<br />
|-<br />
|Daniele E. Domenichelli<br />
|daniele DOT domenichelli AT gmail DOT com<br />
|none<br />
|none<br />
|?<br />
| Friday<br />
| Monday<br />
|-<br />
|Andre Moreira Magalhaes<br />
|andre DOT magalhaes AT collabora DOT co DOT uk<br />
|by Collabora<br />
|by Collabora<br />
|?<br />
| Friday<br />
| Monday<br />
|-<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint1&diff=4387KTp/Events/TelepathySprint12010-08-02T21:27:57Z<p>Grundleborg: oooh spelling fail</p>
<hr />
<div>==Details==<br />
*'''When''': Friday 17th September to Monday 20th September 2010<br />
*'''Where''': Cambridge, UK<br />
(Recommend travel to either London Stansted airport or by train (Eurostar from Europe)).<br />
<br />
More precise details will follow shortly.<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
==Agenda==<br />
<br />
The purpose of this sprint is to allow all of those involved in Telepathy/KDE to meet up and have some productive face to face discussions/work at the time when the project is getting ready to make a release. This sprint will *not* cover integrating Telepathy in other applications, but is focused on getting the Telepathy infrastructure in KDE sorted out.<br />
<br />
We will:<br />
* Take stock of what's going on<br />
* Final plans for the preview release<br />
* Complete API review of all public APIs<br />
* Thorough review of all Nepomuk usage<br />
* Complete review of each and every component in Telepathy/KDE<br />
<br />
If you are involved in KDE/Telepathy, do come along!<br />
<br />
==Time Plan==<br />
* Friday: arrive, social stuff<br />
* Saturday: the serious stuff begins<br />
* Sunday: more serious stuff<br />
* Monday: depart<br />
<br />
==Participants==<br />
<br />
If you plan to attend, please add yourself to the table below.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Travel sponsoring<br />
!Accommodation sponsoring<br />
!Arrival date<br />
!Departure date<br />
|-<br />
|George Goldberg<br />
|grundleborg@googlemail.com<br />
|by Collabora<br />
|by Collabora<br />
| Friday<br />
| Tuesday<br />
|-<br />
|George Kiagiadakis<br />
|kiagiadakis.george@gmail.com<br />
|none<br />
|none<br />
| Friday<br />
| Tuesday<br />
|-<br />
|Dario Freddi<br />
|drf@kde.org<br />
|by Collabora<br />
|by Collabora<br />
| Friday<br />
| Monday<br />
|-<br />
|David Edmundson<br />
|kde@davidedmundson.co.uk<br />
|none<br />
|none<br />
| Friday<br />
| Monday<br />
|-<br />
|Daniele E. Domenichelli<br />
|daniele DOT domenichelli AT gmail DOT com<br />
|none<br />
|none<br />
| Friday<br />
| Monday<br />
|-<br />
|Andre Moreira Magalhaes<br />
|andre DOT magalhaes AT collabora DOT co DOT uk<br />
|by Collabora<br />
|by Collabora<br />
| Friday<br />
| Monday<br />
|-<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint1&diff=4374KTp/Events/TelepathySprint12010-08-02T18:31:37Z<p>Grundleborg: time plan</p>
<hr />
<div>==Details==<br />
*'''When''': Friday 17th September to Monday 20th September 2010<br />
*'''Where''': Cambridge, UK<br />
(Recommend travel to either London Stanstead airport or by train (Eurostar from Europe)).<br />
<br />
More precise details will follow shortly.<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
==Agenda==<br />
<br />
The purpose of this sprint is to allow all of those involved in Telepathy/KDE to meet up and have some productive face to face discussions/work at the time when the project is getting ready to make a release. This sprint will *not* cover integrating Telepathy in other applications, but is focused on getting the Telepathy infrastructure in KDE sorted out.<br />
<br />
We will:<br />
* Take stock of what's going on<br />
* Final plans for the preview release<br />
* Complete API review of all public APIs<br />
* Thorough review of all Nepomuk usage<br />
* Complete review of each and every component in Telepathy/KDE<br />
<br />
If you are involved in KDE/Telepathy, do come along!<br />
<br />
==Time Plan==<br />
* Friday: arrive, social stuff<br />
* Saturday: the serious stuff begins<br />
* Sunday: more serious stuff<br />
* Monday: depart<br />
<br />
==Participants==<br />
<br />
If you plan to attend, please add yourself to the table below.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Travel sponsoring<br />
!Accommodation sponsoring<br />
!Arrival date<br />
!Departure date<br />
|-<br />
|George Goldberg<br />
|grundleborg@googlemail.com<br />
|by Collabora<br />
|by Collabora<br />
| Friday<br />
| Tuesday<br />
|-<br />
|George Kiagiadakis<br />
|kiagiadakis.george@gmail.com<br />
|none<br />
|none<br />
| Friday<br />
| Tuesday<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp&diff=4372KTp2010-08-02T18:16:25Z<p>Grundleborg: /* Events */</p>
<hr />
<div>==Introduction==<br />
<br />
Real time Communication has traditionally been a detatched feature of Desktop Computing, provided via stand-alone Instant Messaging clients with poor integration into the desktop experience. One of the primary goals of the KDE 4 series is to tighten integration between different components of the environment. The Realtime Communication and Collaboration (RTCC) project aims to tackle just this.<br />
<br />
Our aims are:<br />
* To integrate Real Time Communication deeply into the KDE Workspaces and Applications<br />
* To provide a infrastructure to aid development of Collaborative features for KDE applications.<br />
<br />
If you find these goals appealing, why not consider [[#Getting_Involved|getting involved]]. C++ programming is *not* a necessity.<br />
<br />
==Technical Information==<br />
<br />
* The RTCC project uses the cross-desktop [http://telepathy.freedesktop.org Telepathy Framework] as the basis for our work.<br />
* We should try and reuse code from Kopete/other already existing code wherever possibly. However, this should be balanced with the need to refactor/rewrite where appropriate to keep the new code true to Telepathy idioms.<br />
<br />
==Getting Involved==<br />
At this stage, the best way to get involved is to contact the existing team, either on IRC (#kde-telepathy channel on irc.freenode.net) or on our [https://mail.kde.org/mailman/listinfo/kde-telepathy mailing list].<br />
<br />
==Events==<br />
* [[Telepathy/Events/TelepathySprint1|Telepathy sprint - September 2010]]<br />
<br />
==Getting Started==<br />
Before you start playing with/hacking on the Telepathy integration stuff, you need to get it all compiled: [[Real-Time_Communication_and_Collaboration/Getting_Set_Up|Instructions]]<br />
<br />
==The Plan==<br />
1) Build components equivalent to a traditional IM application, using Kopete code as much as possible, and integrating with other Pillars of KDE where appropriate.<br />
<br />
2) Add advanced Telepathy features such as voice/video.<br />
<br />
3) Build components and Convenience classes to enable real-time communication and collaboration features in any KDE SC app that wants them.<br />
<br />
==The Work==<br />
<br />
What we need to get done. This is divided into two sections:<br />
* [[#Phase_1|Phase 1]] contains the tasks which *must* be completed in order for us to make a first release.<br />
* [[#Phase_2|Phase 2]] contains other speculative major features that we will probably implement once [[#Phase_1|Phase 1]] is complete.<br />
<br />
=== Phase 1 ===<br />
<br />
These are the essential tasks which must be completed before we can make a first release. Adding or removing tasks from this list requires a consensus on the kde-telepathy mailing list first. Click on a task title for further information about that task.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Account_Management_GUI|Account Management GUI]] || George Goldberg <grundleborg googlemail com> || [http://websvn.kde.org/trunk/playground/network/telepathy-accounts-kcm Web SVN Link]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Chat_Window|Chat Window App/Lib]] || Matt Rogers <> David Edmundson <kde davidedmundson co uk> || |<br />
|-<br />
| NOT STARTED || [[Real-Time_Communication_and_Collaboration/Components/Logger|Logger Application]] || || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Buddy_List|Buddy List App]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [http://websvn.kde.org/trunk/playground/network/telepathy-contactlist Web SVN Link]<br />
|-<br />
| NOT STARTED || [[Real-Time_Communication_and_Collaboration/Components/Desktop-wide_Approver|Desktop Wide Tp::Approver]] || || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Integration_Daemon|Telepathy Integration Daemon]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [http://websvn.kde.org/trunk/playground/network/telepathy-integration-daemon Web SVN Link]<br />
|-<br />
| DONE || [[Real-Time_Communication_and_Collaboration/Components/Presence_Plasmoid|Presence Plasmoid]] || Abner <> || Web svn<br />
|-<br />
|}<br />
<br />
=== Phase 2 ===<br />
<br />
This section contains features that will *probably* be implemented once the first release has been made.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| NOT STARTED || Port Kopete plugins to Telepathy infrastructure || ||<br />
|-<br />
| NOT STARTED || Add voice/video call support to Chat UI || ||<br />
|-<br />
| SPECULATIVE || Add a internal Tp::Approver to Kopete || ||<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Events/TelepathySprint1&diff=4371Events/TelepathySprint12010-08-02T18:15:45Z<p>Grundleborg: moved Events/TelepathySprint1 to Telepathy/Events/TelepathySprint1:&#32;because I'm a complete bloody idiot</p>
<hr />
<div>#REDIRECT [[Telepathy/Events/TelepathySprint1]]</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint1&diff=4370KTp/Events/TelepathySprint12010-08-02T18:15:45Z<p>Grundleborg: moved Events/TelepathySprint1 to Telepathy/Events/TelepathySprint1:&#32;because I'm a complete bloody idiot</p>
<hr />
<div>==Details==<br />
*'''When''': Friday 17th September to Monday 20th September 2010<br />
*'''Where''': Cambridge, UK<br />
(Recommend travel to either London Stanstead airport or by train (Eurostar from Europe)).<br />
<br />
More precise details will follow shortly.<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
==Agenda==<br />
<br />
The purpose of this sprint is to allow all of those involved in Telepathy/KDE to meet up and have some productive face to face discussions/work at the time when the project is getting ready to make a release. This sprint will *not* cover integrating Telepathy in other applications, but is focused on getting the Telepathy infrastructure in KDE sorted out.<br />
<br />
We will:<br />
* Take stock of what's going on<br />
* Final plans for the preview release<br />
* Complete API review of all public APIs<br />
* Thorough review of all Nepomuk usage<br />
* Complete review of each and every component in Telepathy/KDE<br />
<br />
If you are involved in KDE/Telepathy, do come along!<br />
<br />
==Participants==<br />
<br />
If you plan to attend, please add yourself to the table below.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Travel sponsoring<br />
!Accommodation sponsoring<br />
!Arrival date<br />
!Departure date<br />
|-<br />
|George Goldberg<br />
|grundleborg@googlemail.com<br />
|by Collabora<br />
|by Collabora<br />
| Friday<br />
| Tuesday<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Events/TelepathySprint1&diff=4369KTp/Events/TelepathySprint12010-08-02T18:13:52Z<p>Grundleborg: add the page for the sprint</p>
<hr />
<div>==Details==<br />
*'''When''': Friday 17th September to Monday 20th September 2010<br />
*'''Where''': Cambridge, UK<br />
(Recommend travel to either London Stanstead airport or by train (Eurostar from Europe)).<br />
<br />
More precise details will follow shortly.<br />
<br />
Sprint venue/internet connection/pizza/drinks sponsored by [http://www.collabora.co.uk Collabora]<br />
<br />
==Agenda==<br />
<br />
The purpose of this sprint is to allow all of those involved in Telepathy/KDE to meet up and have some productive face to face discussions/work at the time when the project is getting ready to make a release. This sprint will *not* cover integrating Telepathy in other applications, but is focused on getting the Telepathy infrastructure in KDE sorted out.<br />
<br />
We will:<br />
* Take stock of what's going on<br />
* Final plans for the preview release<br />
* Complete API review of all public APIs<br />
* Thorough review of all Nepomuk usage<br />
* Complete review of each and every component in Telepathy/KDE<br />
<br />
If you are involved in KDE/Telepathy, do come along!<br />
<br />
==Participants==<br />
<br />
If you plan to attend, please add yourself to the table below.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Travel sponsoring<br />
!Accommodation sponsoring<br />
!Arrival date<br />
!Departure date<br />
|-<br />
|George Goldberg<br />
|grundleborg@googlemail.com<br />
|by Collabora<br />
|by Collabora<br />
| Friday<br />
| Tuesday<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=KTp&diff=4368KTp2010-08-02T18:01:51Z<p>Grundleborg: add events section</p>
<hr />
<div>==Introduction==<br />
<br />
Real time Communication has traditionally been a detatched feature of Desktop Computing, provided via stand-alone Instant Messaging clients with poor integration into the desktop experience. One of the primary goals of the KDE 4 series is to tighten integration between different components of the environment. The Realtime Communication and Collaboration (RTCC) project aims to tackle just this.<br />
<br />
Our aims are:<br />
* To integrate Real Time Communication deeply into the KDE Workspaces and Applications<br />
* To provide a infrastructure to aid development of Collaborative features for KDE applications.<br />
<br />
If you find these goals appealing, why not consider [[#Getting_Involved|getting involved]]. C++ programming is *not* a necessity.<br />
<br />
==Technical Information==<br />
<br />
* The RTCC project uses the cross-desktop [http://telepathy.freedesktop.org Telepathy Framework] as the basis for our work.<br />
* We should try and reuse code from Kopete/other already existing code wherever possibly. However, this should be balanced with the need to refactor/rewrite where appropriate to keep the new code true to Telepathy idioms.<br />
<br />
==Getting Involved==<br />
At this stage, the best way to get involved is to contact the existing team, either on IRC (#kde-telepathy channel on irc.freenode.net) or on our [https://mail.kde.org/mailman/listinfo/kde-telepathy mailing list].<br />
<br />
==Events==<br />
* [[Events/TelepathySprint1|Telepathy sprint - September 2010]]<br />
<br />
==Getting Started==<br />
Before you start playing with/hacking on the Telepathy integration stuff, you need to get it all compiled: [[Real-Time_Communication_and_Collaboration/Getting_Set_Up|Instructions]]<br />
<br />
==The Plan==<br />
1) Build components equivalent to a traditional IM application, using Kopete code as much as possible, and integrating with other Pillars of KDE where appropriate.<br />
<br />
2) Add advanced Telepathy features such as voice/video.<br />
<br />
3) Build components and Convenience classes to enable real-time communication and collaboration features in any KDE SC app that wants them.<br />
<br />
==The Work==<br />
<br />
What we need to get done. This is divided into two sections:<br />
* [[#Phase_1|Phase 1]] contains the tasks which *must* be completed in order for us to make a first release.<br />
* [[#Phase_2|Phase 2]] contains other speculative major features that we will probably implement once [[#Phase_1|Phase 1]] is complete.<br />
<br />
=== Phase 1 ===<br />
<br />
These are the essential tasks which must be completed before we can make a first release. Adding or removing tasks from this list requires a consensus on the kde-telepathy mailing list first. Click on a task title for further information about that task.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Account_Management_GUI|Account Management GUI]] || George Goldberg <grundleborg googlemail com> || [http://websvn.kde.org/trunk/playground/network/telepathy-accounts-kcm Web SVN Link]<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Chat_Window|Chat Window App/Lib]] || Matt Rogers <> David Edmundson <kde davidedmundson co uk> || |<br />
|-<br />
| NOT STARTED || [[Real-Time_Communication_and_Collaboration/Components/Logger|Logger Application]] || || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Buddy_List|Buddy List App]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [http://websvn.kde.org/trunk/playground/network/telepathy-contactlist Web SVN Link]<br />
|-<br />
| NOT STARTED || [[Real-Time_Communication_and_Collaboration/Components/Desktop-wide_Approver|Desktop Wide Tp::Approver]] || || |<br />
|-<br />
| IN PROGRESS || [[Real-Time_Communication_and_Collaboration/Components/Integration_Daemon|Telepathy Integration Daemon]] || George Goldberg <grundleborg googlemail com> Dario Freddi <drf kde org> Help much appreciated || [http://websvn.kde.org/trunk/playground/network/telepathy-integration-daemon Web SVN Link]<br />
|-<br />
| DONE || [[Real-Time_Communication_and_Collaboration/Components/Presence_Plasmoid|Presence Plasmoid]] || Abner <> || Web svn<br />
|-<br />
|}<br />
<br />
=== Phase 2 ===<br />
<br />
This section contains features that will *probably* be implemented once the first release has been made.<br />
<br />
{| border="1"<br />
! Status !! Task!! Developers !! Source Code<br />
|-<br />
| NOT STARTED || Port Kopete plugins to Telepathy infrastructure || ||<br />
|-<br />
| NOT STARTED || Add voice/video call support to Chat UI || ||<br />
|-<br />
| SPECULATIVE || Add a internal Tp::Approver to Kopete || ||<br />
|}</div>Grundleborghttps://community.kde.org/index.php?title=Events/Akademy/2010/TaxiCallingService&diff=3999Events/Akademy/2010/TaxiCallingService2010-07-09T13:01:45Z<p>Grundleborg: add 14:35 on saturday</p>
<hr />
<div>If your flight from Tampere-Pirkkala Airport leaves at early hours when there are no bus connections, or you otherwise wish to share a taxi with other people, please write below: <br />
<br />
*Date and departure time of your flight <br />
**Your name, e-mail, IRC nick<br />
<br />
The locals will order taxis according to this list '''to Student House TOAS City, address Tuomiokirkonkatu 19''' ([http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Tuomiokirkonkatu+19,+Tampere,+Suomi&sll=37.0625,-95.677068&sspn=34.396866,79.013672&ie=UTF8&hq=&hnear=Tuomiokirkonkatu+19,+33100+Tampere,+Finland&ll=61.498069,23.770466&spn=0.010116,0.038581&z=15 Google Maps]). We will add information to this page when a taxi has been ordered and at what time it'll be in front of TOAS Student House. <br />
<br />
Tampere taxi information can be found at http://www.taksitampere.fi/in-english/services/. <br />
<br />
'''Taxi list''' <br />
<br />
*July 9 6:15 am (Taxi for 4 people ordered '''4:30 am from TOAS''' by smoinen)<br />
** Jaroslaw Staniek staniek@kde.org jstaniek<br />
** Joseph Wenninger jowenn@kde.org <br />
** Torsten Thelke thelke@kde.org<br />
<br />
*July 9 13:35 (Taxi for 4 people ordered '''11:30 am from Demola''' by smoinen)<br />
** Marco Martin notmart@gmail.com notmart<br />
** Alessandro Diaferia alediaferia@gmail.com alediaferia<br />
** Davide bettio bettio@kde.org uninstall<br />
** Valerio Pilo valerio@kmess.org vpilo<br />
<br />
*July 10 6:15 am (Taxi for 8 people (minivan) ordered '''4:30 am from TOAS''' by smoinen)<br />
**Jonas Vejlin, jonas.vejlin@gmail.com, beer <br />
**Troy Unrau, troy.unrau@gmail.com, troy<br />
**Volker Krause, vkrause@kde.org, vkrause<br />
**Peter Grasch, grasch@simon-listens.org, bedahr<br />
**Tobias Koenig, tokoe@kde.org, tokoe<br />
**Leo Franchi, lfranchi@kde.org<br />
<br />
*July 10 14:35<br />
** George Goldberg, grundleborg@googlemail.com, grundleborg<br />
** sjors<br />
** vdboor<br />
<br />
*July 11, 6:15 am (Taxi for 4 people ordered '''4:30 am from TOAS''' by smoinen)<br />
**Jure Repinc, jlp@holodeck1.com, JLP<br />
**Neja Repinc, rene@holodeck1.com, SmrtSkoso</div>Grundleborghttps://community.kde.org/index.php?title=KTp/Getting_Set_Up&diff=2421KTp/Getting Set Up2010-03-27T16:49:35Z<p>Grundleborg: Linky fix</p>
<hr />
<div>These instructions assume that you already know how to build KDE stuff from source. It just provides a list of what you need to checkout and build, and how to run it.<br />
<br />
==Prerequisites==<br />
<br />
You will need a working Nepomuk on your system (strigi indexer not required to be on, but Nepomuk must be enabled), with the virtuoso backend.<br />
<br />
You will also need to install several cross-desktop Telepathy components. Packages of the following from your distribution should do fine.<br />
* telepathy-mission-control-5<br />
* telepathy-gabble (for Jabber support)<br />
* other Telepathy connection managers if you want to try out other protocols<br />
<br />
==TelepathyQt4==<br />
<br />
The prerequisite for all the Telepathy stuff to build is the TelepathyQt4 library. The source code for this is available [http://git.collabora.co.uk/?p=telepathy-qt4.git;a=summary here]. Your distribution may package it, in which case you need version >= 0.2.2. Be careful not to confuse it with the telepathy-qt library which used to be in kdesupport SVN. This is *completely* different and in no way compatible.<br />
<br />
If you are building your own copy of TelepathyQt4, clone the git repository linked above, and use the usual autotools method to build and install it.<br />
<br />
==Telepathy Accounts KCM==<br />
<br />
The next thing to get set up is the Telepathy Accounts KCM. This is the UI for account management.<br />
<br />
Source code is [http://websvn.kde.org/trunk/playground/network/telepathy-accounts-kcm/ here].<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-accounts-kcm</code><br />
<br />
This can be compiled and installed by the usual KDE build procedure.<br />
<br />
You will also want the plugins for this app, found in svn [http://websvn.kde.org/trunk/playground/network/telepathy-accounts-kcm-plugins/ here].<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-accounts-kcm-plugins</code><br />
<br />
==Presence Plasmoid and Dataengine==<br />
<br />
In order to bring accounts on/offline you will need the Presence Plasmoid and its data engine. These are in svn [http://websvn.kde.org/trunk/playground/base/plasma/applets/presence/ here] and [http://websvn.kde.org/trunk/playground/base/plasma/dataengines/presence/ here].<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/applets/presence<br />
svn co svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/dataengines/presence</code><br />
<br />
==Integration Daemon==<br />
<br />
This daemon integrates Telepathy with Nepomuk, which is required by the Contact List application. Code is in svn [http://websvn.kde.org/trunk/playground/network/telepathy-integration-daemon/ here]<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon</code><br />
<br />
==Contact List App==<br />
<br />
This application provides a traditional contact-list, similar to the one provided by Kopete. Code is in svn [http://websvn.kde.org/trunk/playground/network/telepathy-contactlist/ here]<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-contactlist</code></div>Grundleborghttps://community.kde.org/index.php?title=KTp/Getting_Set_Up&diff=2420KTp/Getting Set Up2010-03-27T16:49:13Z<p>Grundleborg: first rough sketch of a "how to build this stuff" page</p>
<hr />
<div>These instructions assume that you already know how to build KDE stuff from source. It just provides a list of what you need to checkout and build, and how to run it.<br />
<br />
==Prerequisites==<br />
<br />
You will need a working Nepomuk on your system (strigi indexer not required to be on, but Nepomuk must be enabled), with the virtuoso backend.<br />
<br />
You will also need to install several cross-desktop Telepathy components. Packages of the following from your distribution should do fine.<br />
* telepathy-mission-control-5<br />
* telepathy-gabble (for Jabber support)<br />
* other Telepathy connection managers if you want to try out other protocols<br />
<br />
==TelepathyQt4==<br />
<br />
The prerequisite for all the Telepathy stuff to build is the TelepathyQt4 library. The source code for this is available [http://git.collabora.co.uk/?p=telepathy-qt4.git;a=summary here]. Your distribution may package it, in which case you need version >= 0.2.2. Be careful not to confuse it with the telepathy-qt library which used to be in kdesupport SVN. This is *completely* different and in no way compatible.<br />
<br />
If you are building your own copy of TelepathyQt4, clone the git repository linked above, and use the usual autotools method to build and install it.<br />
<br />
==Telepathy Accounts KCM==<br />
<br />
The next thing to get set up is the Telepathy Accounts KCM. This is the UI for account management.<br />
<br />
Source code is [http://websvn.kde.org/trunk/playground/network/telepathy-accounts-kcm/ here].<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-accounts-kcm</code><br />
<br />
This can be compiled and installed by the usual KDE build procedure.<br />
<br />
You will also want the plugins for this app, found in svn [http://websvn.kde.org/trunk/playground/network/telepathy-accounts-kcm-plugins/ here].<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-accounts-kcm-plugins</code><br />
<br />
==Presence Plasmoid and Dataengine==<br />
<br />
In order to bring accounts on/offline you will need the Presence Plasmoid and its data engine. These are in svn [http://websvn.kde.org/trunk/playground/base/plasma/applets/presence/ here] and [http://websvn.kde.org/trunk/playground/base/plasma/dataengines/presence/ here].<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/applets/presence<br />
svn co svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/dataengines/presence</code><br />
<br />
==Integration Daemon==<br />
<br />
This daemon integrates Telepathy with Nepomuk, which is required by the Contact List application. Code is in svn [http://websvn.kde.org/trunk/playground/network/telepathy-integration-daemon/ here]<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon</code><br />
<br />
==Contact List App==<br />
<br />
This application provides a traditional contact-list, similar to the one provided by Kopete. Code is in svn [http://websvn.kde.org/trunk/playground/network/telepathy-contactlist/]<br />
<br />
<code>svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-contactlist</code></div>Grundleborg