https://techbase.kde.org/api.php?action=feedcontributions&user=Zwabel&feedformat=atomKDE TechBase - User contributions [en]2024-03-28T18:33:40ZUser contributionsMediaWiki 1.40.2https://techbase.kde.org/index.php?title=Schedules/KDE4/4.3_Feature_Plan&diff=40866Schedules/KDE4/4.3 Feature Plan2009-04-15T09:54:41Z<p>Zwabel: </p>
<hr />
<div>This is a list of planned features for the 4.3 release.<br />
<br />
See also:<br />
* [[Schedules/KDE4/4.3 Release Schedule]]<br />
* [[Schedules/KDE4/4.3 Release Goals]]<br />
* [[Schedules/KDE4/4.2 Feature Plan]]<br />
<br />
<br />
Legend:<br />
* todo => not started yet<br />
* in-progress => started, but not completed yet<br />
* done => completed<br />
__TOC__<br />
<br />
= Other =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|Akonadi|Various Akonadi related items can be found here http://techbase.kde.org/Projects/PIM/Akonadi#Scheduled_for_KDE_4.3_.2F_Akonadi_1.2|kde-pim@kde.org|Akonadi Developers}}<br />
{{FeatureInProgress|KPackageKit|Pushing in KPackageKit (dependant on PolicyKit integration)|dantti85-dev@yahoo.com.br|Daniel}}<br />
|}<br />
<br />
= kdelibs =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|KLocale|Investigate adding Currency Code and currency minor units support based on ISO 4217 (http://en.wikipedia.org/wiki/ISO_4217).|john@layt.net|John Layt}}<br />
{{FeatureDone|kdecore|Thread safety in ksycoca (KService, KMimeType etc.)|faure:AT:kde.org|David Faure}}<br />
{{FeatureTodo|kdecore|Dynamic allocation of KDebug areas|faure:AT:kde.org|David Faure}}<br />
{{FeatureInProgress|Sonnet|Implement language detection|qbast@go2.pl|Jakub Stachowski}}<br />
{{FeatureInProgress|Sonnet|Integrate language detection with spellchecking|qbast@go2.pl|Jakub Stachowski}}<br />
{{FeatureTodo|Sonnet|Integrate language detection with strigi|qbast@go2.pl|Jakub Stachowski}}<br />
{{FeatureTodo|Sonnet|Grammar checking (at least for English)|qbast@go2.pl|Jakub Stachowski}}<br />
{{FeatureInProgress|kio|Move KTcpSocket to kio and make it public; some cleanup required|ahartmetz@gmail.com|Andreas Hartmetz}}<br />
{{FeatureTodo|KCalendarSystem|Add new astronomical calculation support classes to be used in kdelibs to build new astronomically based calendar systems, and in kdepim to build new version of libkholiday.|john@layt.net|John Layt}}<br />
{{FeatureTodo|KCalendarSystem|Add new calendar systems: Indian Civil (Saka), Ethiopean, Chinese, Pure Julian, Pure Gregorian, etc.|john@layt.net|John Layt}}<br />
{{FeatureTodo|KDEPrint|If no file printing support in Qt4.5, migrate FilePrinter class from Okular to enable file printing for all apps via QPrinter. To be discussed on k-c-d first.|john@layt.net|John Layt}}<br />
{{FeatureTodo|KDEPrint|Add framework for standard actions for 'Send to...' for e-mail, fax, etc by printing to PDF/PS.|john@layt.net|John Layt}}<br />
{{FeatureTodo|kdeui|entries to help menu and aboutdata pointing to UserBase entry and forum.kde.org|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|kdesu|Classes to help kde-apps open ports in the local firewall (via IPTables/IPFW, etc...)|tejas@gja.in|Tejas Dinkar}}<br />
{{FeatureInProgress|katepart|Key mapping support for the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}<br />
{{FeatureInProgress|katepart|Blockwise visual mode for the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}<br />
{{FeatureInProgress|katepart|Improve text objects in the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}<br />
{{FeatureTodo|katepart|Save registers and marks from the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}<br />
{{FeatureInProgress|kio|Fix D-Bus timeout in SlaveBase when calling kpasswdserver|lemma@confuego.org|Michael Leupold}}<br />
{{FeatureInProgress|kdeui|Provide a class for detecting modifier keystrokes and locked key states|lemma@confuego.org|Michael Leupold}}<br />
{{FeatureTodo|khtml|CSS3 Web Fonts|germain@ebooksfrance.org|Germain Garand}}<br />
{{FeatureTodo|khtml|support more properties from CSS3 Backgrounds and Borders module|germain@ebooksfrance.org|Fredrik Höglund and/or Germain Garand}}<br />
{{FeatureInProgress|khtml|support more properties from CSS3 Text module|germain@ebooksfrance.org|Germain Garand}}<br />
{{FeatureInProgress|solid|Smart card reader support|cblauvelt@gmail.com|Christopher Blauvelt}}<br />
{{FeatureTodo|KEmoticons|emit a signal when the emoticon theme is changed|brandon.ml@gmail.com|Carlo Segato}}<br />
{{FeatureTodo|KLocale|Per-language number formats, and exposing them to modification by user.|caslav.ilic@gmx.net|Chusslove Illich}}<br />
{{FeatureTodo|KLocale|Extension of date formats to cover many resolutions (month-year, day-month, etc.)|caslav.ilic@gmx.net|Chusslove Illich}}<br />
{{FeatureInProgress|kfile|KDirSortFilterProxyModel: make it possible to not always sort folders first|frank78ac@googlemail.com|Frank Reininghaus}}<br />
{{FeatureTodo|buildsystem|Add support for crosscompiling|neundorf@kde.org|Alexander Neundorf}}<br />
{{FeatureInProgress|buildsystem|Add support for building parts of modules separately|neundorf@kde.org|Alexander Neundorf}}<br />
|}<br />
<br />
= kdebase-workspace =<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 !! Project !! Description !! Contact<br />
<br />
|- border="1" cellpadding="5" cellspacing="0" style="border<br />
! colspan="4" style="text-align: center" |Non-Plasma, Non-KWin<br />
{{FeatureTodo|Kxkb|Support for languages in keyboard layout descriptions|rysin:AT:kde.org|Andriy Rysin}}<br />
{{FeatureDone|PolicyKit integration|Import PolicyKit-KDE from extragear|drf54321@gmail.com|Dario Freddi}}<br />
{{FeatureDone|Solid Actions KCM|Import Solid actions KControl module from playground|ben@eclipse.endoftheinternet.org|Ben Cooksley}}<br />
{{FeatureTodo|KControl4|Import refactor of systemsettings with Tree and Icon view support|ben(at)eclipse(dot)endoftheinternet(dot)org|Ben Cooksley and Mathias Soeken}}<br />
{{FeatureDone|KSysguard|Added GetHotNewStuff support|a@b.com|name}}<br />
{{FeatureInProgress|KActiveEdges|Split active screen edges from KWin|lmurray@undefinedfire.com|Lucas Murray}}<br />
{{FeatureInProgress|Solid Wicd Engine|Import Solid Wicd engine from github/playground|drf54321@gmail.com|Dario Freddi}}<br />
{{FeatureDone|Klipper|Made klipper automatically find possible actions based on filename copied to clipboard|dimsuz@gmail.com|Dmitry Suzdalev}}<br />
{{FeatureDone|Klipper|Improved action adding/editing workflow by implementing a special dialog for editing a certain action|dimsuz@gmail.com|Dmitry Suzdalev}}<br />
{{FeatureTodo|Klipper|Make action popup unobtrusive by showing menu only when user clicks an icon in systray. Icon itself should change to indicate availability of some actions on current clipboard|dimsuz@gmail.com|Dmitry Suzdalev}}<br />
{{FeatureTodo|Font Installer KCM |Use PolicyKit for installtion of system-wide fonts.|craig@kde.org|Craig Drummond}}<br />
{{FeatureInProgress|Font Settings KCM|Improved GUI for configuring anti-aliasing settings|fredrik@kde.org|Fredrik Höglund}}<br />
<br />
|- border="1" cellpadding="5" cellspacing="0" style="border<br />
! colspan="4" style="text-align: center" |KRunner<br />
{{FeatureInProgress|Nepomuk/Location Runners|Open with and service menu actions|ryan.bitanga@gmail.com|Ryan Bitanga}}<br />
{{FeatureTodo|KRunner|Simple adaptive search|ryan.bitanga@gmail.com|Ryan Bitanga}}<br />
<br />
|- border="1" cellpadding="5" cellspacing="0" style="border<br />
! colspan="4" style="text-align: center" |Plasma - Priority Features<br />
<br />
|- border="1" cellpadding="5" cellspacing="0" style="border<br />
! colspan="4" style="text-align: center" |Plasma<br />
{{FeatureTodo|Now Playing data engine|Support for MPD|kde:AT:randomguy3.me.uk|Alex Merry}}<br />
{{FeatureTodo|Now Playing applet|Better design in panels|kde:AT:randomguy3.me.uk|Alex Merry}}<br />
{{FeatureDone|Classic Menu Launcher|Optional recently used applications and System Settings menu|mail:AT:dipe.org|Sebastian Sauer}}<br />
{{FeatureDone|Classic Menu Launcher|KDE3-like menu titles|mail:AT:dipe.org|Christian Loose}}<br />
{{FeatureDone|Classic Menu Launcher|Context menu for menu items|mail:AT:dipe.org|Christian Loose}}<br />
{{FeatureInProgress|Reusable video widget|A widget in libplasma that can play video and audio|notmart@gmail.com|Marco Martin}}<br />
{{FeatureInProgress|Message box|A message box shown as an overlay over plasmoids|notmart@gmail.com|Marco Martin}}<br />
{{FeatureTodo|Panel spacers|A way to add/manage spacers directly from the panel controller|notmart@gmail.com|Marco Martin}}<br />
{{FeatureInProgress|Systemtray protocol|New systemtray protocol beginnings: daemon and systemtray widget part|notmart@gmail.com|Marco Martin}}<br />
{{FeatureInProgress|Default theme|Air: new default Plasma theme|notmart@gmail.com|Marco Martin and Nuno Pinheiro}}<br />
{{FeatureInProgress|screensaver|security constraints|chanika@gmail.com|Chani}}<br />
{{FeatureInProgress|keyboard shortcuts|configuration|chanika@gmail.com|Chani}}<br />
{{FeatureTodo|icon plasmoid|make it suck less|chanika@gmail.com|Chani}}<br />
{{FeatureTodo|desktop|make a plasmoid when I paste stuff|chanika@gmail.com|Chani}}<br />
{{FeatureInProgress|extenders|Add grouping support to extenders|r.scheepmaker@student.utwente.nl|Rob Scheepmaker}}<br />
{{FeatureInProgress|systemtray|Group multiple jobs and notifications|r.scheepmaker@student.utwente.nl|Rob Scheepmaker}}<br />
{{FeatureTodo|systemtray|Job completed notifications, providing an sensible action ('open file' etc)|r.scheepmaker@student.utwente.nl|Rob Scheepmaker}}<br />
{{FeatureInProgress|Kickoff|Add multiple columns support to Kickoff|talvik@gmail.com|Luiz Felipe Talvik}}<br />
{{FeatureDone|folderview|Show tooltips with large previews and file metadata when hovering icons|fredrik@kde.org|Fredrik Höglund}}<br />
{{FeatureDone|folderview|Show a popup view with the folder contents when hovering a folder in the icon view|fredrik@kde.org|Fredrik Höglund}}<br />
{{FeatureDone|folderview|Add menu items to the context menu for showing the applet browser, adding panels, locking the screen, logging out etc.|fredrik@kde.org|Fredrik Höglund}}<br />
{{FeatureInProgress|folderview|Add menu items to the drop menu for creating applets and setting the wallpaper|fredrik@kde.org|Fredrik Höglund}}<br />
{{FeatureTodo|folderview|Accessing sub folders as sub menus in the popup view when the applet is on the panel|fredrik@kde.org|Fredrik Höglund}}<br />
{{FeatureTodo|folderview|Optionally show the window list menu when middle clicking the containment|fredrik@kde.org|Fredrik Höglund}}<br />
{{FeatureTodo|folderview|Offer to create applets based on the mimetype when pasting URL's in the containment|fredrik@kde.org|Fredrik Höglund}}<br />
{{FeatureInProgress|folderview|Implement support for keyboard navigation|jhahoneyk@gmail.com|Shantanu Tushar Jha}}<br />
{{FeatureDone|virus wallpaper|Move from playground to kdeplasma-addons and port to the new plasma::wallpaper|asraniel@fryx.ch|Beat Wolf}}<br />
{{FeatureInProgress|Plasma|Add press-down feedback to folderview|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureDone|Time DataEngine|Integrate solar position dataengine to time dataengine|damu@iki.fi|Petri Damstén}}<br />
{{FeatureTodo|Time DataEngine|Moon position/phase data|damu@iki.fi|Petri Damstén}}<br />
{{FeatureInProgress|Akonadi DataEngine|Move Akonadi dataengine to kdeplasma-addons|sebas@kde.org|Sebastian Kügler}}<br />
{{FeatureInProgress|Social Desktop Plasmoid|Plasmoid displaying contacts via OpenDesktop|sebas@kde.org|Sebastian Kügler}}<br />
{{FeatureTodo|Knowledge base Plasmoid|Plasmoid for searching and dispaying results from Open Collaboration Services / OpenDesktop|sebas@kde.org|Sebastian Kügler}}<br />
{{FeatureTodo|Tool tips|Extend tool tips API|emdeck@gmail.com|Michał Dutkiewicz}}<br />
{{FeatureInProgress|Theme System|Better fallback mechanisms for transparent panels/dialogs without composition|david.nolden.kdevelop@art-master.de|David Nolden}}<br />
{{FeatureInProgress|Plasmaclock library|Context menu for fast copying date and time strings to clipboard|emdeck@gmail.com|Michał Dutkiewicz}}<br />
{{FeatureInProgress|Plasmaclock/Calendar|Display various information on the calendar using kholiday/akonadi|?|?}}<br />
<br />
|- border="1" cellpadding="5" cellspacing="0" style="border<br />
! colspan="4" style="text-align: center" |KWin - Core<br />
{{FeatureTodo|KWin|Redesign KWin system settings GUI|lmurray@undefinedfire.com|Lucas Murray}}<br />
{{FeatureTodo|KWin|ARGB support for decorations|lmurray@undefinedfire.com|Lucas Murray}}<br />
{{FeatureInProgress|KWin|Window docking/quick tiling|lmurray@undefinedfire.com|Lucas Murray}}<br />
{{FeatureTodo|KWin|Internal desktop layout/pager support|lmurray@undefinedfire.com|Lucas Murray}}<br />
{{FeatureInProgress|KWin|Non-composited Present Windows|kde@martin-graesslin.com|Martin Gräßlin}}<br />
{{FeatureInProgress|KWin|Tabbox improvements|kde@martin-graesslin.com|Martin Gräßlin}}<br />
{{FeatureTodo|KWin/Plasma|Toggle Compositing Plasmoid|kde@martin-graesslin.com|Martin Gräßlin}}<br />
|- border="1" cellpadding="5" cellspacing="0" style="border<br />
! colspan="4" style="text-align: center" |KWin - Desktop Effects<br />
{{FeatureTodo|KWin|Expand present windows into other effects (E.g. Desktop Grid)|kde@martin-graesslin.com|Martin Gräßlin}}<br />
{{FeatureTodo|KWin|OpenGL 3 compatible Shaders|kde@martin-graesslin.com|Martin Gräßlin}}<br />
{{FeatureTodo|KWin|Improved cube reflection|kde@martin-graesslin.com|Martin Gräßlin}}<br />
{{FeatureInProgress|KWin|Add and remove desktops in grid effect|kde@martin-graesslin.com|Martin Gräßlin}}<br />
{{FeatureTodo|KWin|Desktop Thumnails in Pager Tooltips|kde@martin-graesslin.com|Martin Gräßlin}}<br />
{{FeatureTodo|KWin|Slide In/Out effect|hein@kde.org|Eike Hein}}<br />
{{FeatureDone|KWin|Fade desktop effect (Desktop switcher)|lmurray@undefinedfire.com|Lucas Murray}}<br />
{{FeatureInProgress|KWin|Highlight window effect|lmurray@undefinedfire.com|Lucas Murray}}<br />
{{FeatureInProgress|KWin|SlideBack effect|michael_zanetti@gmx.net|Michael Zanetti}}<br />
|- border="1" cellpadding="5" cellspacing="0" style="border<br />
! colspan="4" style="text-align: center" |KDM<br />
{{FeatureTodo|KDM|Plasma wallpaper|davide.bettio@kdemail.net|Davide Bettio}}<br />
|}<br />
<br />
= kdepimlibs =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|Buildsystem|Require OpenLDAP (coordinate with the Windows team)|winter@kde.org|Allen Winter}}<br />
{{FeatureTodo|Buildsystem|Require Cyrus-SASL (coordinate with the Windows team)|winter@kde.org|Allen Winter}}<br />
{{FeatureTodo|libkleopatraclient|New interface library for kleopatra uiserver clients|marc@kdab.net|Marc Mutz}}<br />
{{FeatureTodo|pimtextedit|New library around text edits, to provide support for inline images in the signature editor, among others|mcguire@kde.org|Thomas McGuire}}<br />
|}<br />
<br />
= kdenetwork =<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 !! Project !! Description !! Contact<br />
{{FeatureInProgress|Kopete|UPnp Support|mattr@kde.org|Matt Rogers}}<br />
{{FeatureDone|Kopete|Updated contact list interface (uses Qt 4 rather than Qt 3)|mattr@kde.org|Matt Rogers}}<br />
{{FeatureTodo|Kopete|Update Kopete to better support Decibel|kopete-devel@kde.org|Kopete Developers}}<br />
{{FeatureTodo|Kopete|Jabber Jingle video support|detlev.casanova@gmail.com|Detlev Casanova}}<br />
{{FeatureTodo|Kopete|Jabber Jingle ICE support|detlev.casanova@gmail.com|Detlev Casanova}}<br />
{{FeatureInProgress|Kopete|Contacts plasmoid|earthwings@gentoo.org|Dennis Nienhüser}}<br />
{{FeatureTodo|Kopete|Rich text support for ICQ|kedgedev@gmail.com|Roman Jarosz}}<br />
{{FeatureTodo|Kopete|Add support for urls to Bonjour plugin|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureInProgress|KGet|MultiSource-Downloading|l.appelhans@gmx.de|Lukas Appelhans}}<br />
{{FeatureTodo|KGet|Support mms://-protocol, see https://launchpad.net/libmms|l.appelhans@gmx.de|Lukas Appelhans}}<br />
{{FeatureTodo|KGet|MLDonkey-Plugin based on libkmldonkey|l.appelhans@gmx.de|Lukas Appelhans}}<br />
{{FeatureTodo|KGet|Advanced Details|l.appelhans@gmx.de|Lukas Appelhans}}<br />
{{FeatureInProgress|KRDC|NX support|gdavid.devel@gmail.com|David Gross}}<br />
{{FeatureTodo|KRDC|Minimal-clutter mode to optimize screen real estate usage|gpothier@gmail.com|Guillaume Pothier}}<br />
{{FeatureInProgress|Telepathy|Telepathy-specification compliant Account Manager using KWallet to store account data|grundleborg@googlemail.com|George Goldberg}}<br />
{{FeatureInProgress|Telepathy|Account Editing UI for Telepathy|grundleborg@googlemail.com|George Goldberg}}<br />
{{FeatureInProgress|Plasma|Network Manager Applet|wstephenson@kde.org|Will Stephenson}}<br />
{{FeatureTodo|network:/ KIOSlave|Move into kdenetwork module|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
|}<br />
<br />
= kdepim =<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 !! Project !! Description !! Contact<br />
{{FeatureInProgress|Akonadi|Migration of contacts and calendar data from KResource to Akonadi ([http://techbase.kde.org/Projects/PIM/Akonadi#Scheduled_for_4.3 Details])|kde-pim@kde.org|Volker Krause, Kevin Krammer, Tobias Koenig}}<br />
{{FeatureInProgress|Akregator|Support for syncing the feed list with Google Reader |osterfeld@kde.org|Frank Osterfeld}}<br />
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Add export of alarms to a new calendar file|djarvie@kde.org|David Jarvie}}<br />
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Allow configuration of default deferral time interval|djarvie@kde.org|David Jarvie}}<br />
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Accept drag-and-drop of Todo entries to create a new alarm|djarvie@kde.org|David Jarvie}}<br />
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Show command execution error indication in alarm list|djarvie@kde.org|David Jarvie}}<br />
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Add option to spread alarm windows across screen|djarvie@kde.org|David Jarvie}}<br />
{{FeatureTodo|[http://www.astrojar.org.uk/kalarm KAlarm]|Port to Akonadi|djarvie@kde.org|David Jarvie}}<br />
{{FeatureTodo|[http://kblogger.pwsp.net KBlogger]|KBlogger, a blogging application|christian_weilbach@.web.de|Christian Weilbach}}<br />
{{FeatureTodo|KBlogger|Port to use KRichTextEdit (Or KMEditor)|steveire@gmail.com|Stephen Kelly}}<br />
{{FeatureInProgress|KContactManager|A new Akonadi-based address book to replace KAddressbook|tokoe@kde.org|Tobias Koenig}}<br />
{{FeatureInProgress|Kjots| Create and port to akonadi model. |steveire@gmail.com|Stephen Kelly}}<br />
{{FeatureTodo|Kjots| Add support for nepomuk including tagging, possibly storage, and linking. Also a nepomuk tag proxy model for representing the structure as tagged.|steveire@gmail.com|Stephen Kelly}}<br />
{{FeatureInProgress|Kjots| Create plasmoid capable of showing the entire tree, or a single book.|steveire@gmail.com|Stephen Kelly}}<br />
{{FeatureTodo|Kjots| Email KJots pages using default mail client ({{bug|124509}}. |steveire@gmail.com|Stephen Kelly}}<br />
{{FeatureInProgress|Kleopatra|OpenPGP support|marc@kdab.net|Marc Mutz (Gpg4win)}}<br />
{{FeatureDone|KMail|Add support for HTML images|yez@familieschepers.nl|Edwin Schepers}}<br />
{{FeatureTodo|KMail|Use asynchronous Kleo|marc@kdab.net|Marc Mutz}}<br />
{{FeatureTodo|KMail|Save metadata about attachments to Nepomuk when saving them|onurf@su.sabanciuniv.edu|Ismail Onur Filiz}}<br />
{{FeatureTodo|KNode|Port to use KRichTextEdit (Or KMEditor)|steveire@gmail.com|Stephen Kelly}}<br />
{{FeatureTodo|Kontact|Support for Kontact wide profiles|kdepim@kdab.net|Kolab Konsortium}}<br />
{{FeatureTodo|Kontact|Tip-of-the-Day summary|molkentin@kde.org|Daniel Molkentin}}<br />
{{FeatureTodo|KOrganizer|Support for extended free-busy lists|kdepim@kdab.net|Kolab Konsortium}}<br />
{{FeatureInProgress|KPilot|Port old conduits to new base conduit architecture and KDE4/Qt4|jkasper@kde.org|Jason 'vanRijn' Kasper}}<br />
{{FeatureInProgress|KPilot|Finish Keyring conduit, base conduit code and test cases, category syncing|jkasper@kde.org|Jason 'vanRijn' Kasper}}<br />
|}<br />
<br />
= kdeutils =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|printer-applet|Restore feature parity with KDEPrint3 where possible.|john@layt.net|John Layt}}<br />
{{FeatureTodo|Okteta|add editing capability to Decoding table |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 support for import by drop, both url and data|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|add support for memory mapping of files|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|add further export formats like s-record and intel 16|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|Make dialogs for Goto, Search & Replace embedded|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 hash calculator tool|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|Okteta|Show tooltip over bookmarks|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureInProgress|Okteta|Add filesystem browser tool|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureInProgress|Okteta|Add loaded documents tool|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|Okteta|Show selection range in status bar|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|Make the Okteta KPart use libkakao, and rename libkakao|kossebau@kde.org|Friedrich W. H. Kossebau}}<br />
{{FeatureTodo|kwalletmanager|Move kwalletmanager to the Model/View architecture and redesign the UI.|lemma@confuego.org|Michael Leupold}}<br />
{{FeatureInProgress|kdelirc|Bring back kdelirc|michael_zanetti@gmx.net|Michael Zanetti}}<br />
{{FeatureTodo|ark|Improve support for pure gzip and bzip2 files|kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureInProgress|ark| Finish the cliinterface |haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|ark| Add lots of more meaningful error messages |haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|ark| Add support for ACE archives |haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|ark| Add support for zip archives (cli-based, ie. info-zip) |haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureTodo|ark| Make the mimetype selection dialog more user-friendly |kubito@gmail.com|Raphael Kubo da Costa}}<br />
{{FeatureTodo|KGpg| Port to new systray framework |kde@opensource.sf-tec.de|Rolf Eike Beer}}<br />
{{FeatureTodo|KGpg| Clean up editor GUI and classes |kde@opensource.sf-tec.de|Rolf Eike Beer}}<br />
{{FeatureTodo|KGpg| Make keyserver operations more flexible |kde@opensource.sf-tec.de|Rolf Eike Beer}}<br />
{{FeatureInProgress|KGpg| Port key importing to be a transaction |kde@opensource.sf-tec.de|Rolf Eike Beer}}<br />
{{FeatureTodo|KGpg| Port keyserver query to be a transaction |kde@opensource.sf-tec.de|Rolf Eike Beer}}<br />
{{FeatureTodo|KGpg| Make "import key" also work with keyservers |kde@opensource.sf-tec.de|Rolf Eike Beer}}<br />
{{FeatureTodo|KGpg| Integrate solid to know when a online action (e.g. keyserver query) does not make sense |kde@opensource.sf-tec.de|Rolf Eike Beer}}<br />
{{FeatureInProgress|KTimer| Redesign UI |zahl@transbay.net|A. L. Spehr}}<br />
{{FeatureTodo|KTimer| Add hours and seconds to counter |zahl@transbay.net|A. L. Spehr}}<br />
|}<br />
<br />
= kdebindings =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|krossjava|Integrate into e.g. SuperKaramba and fix issues that show up.|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureTodo|krossjava|Documentation++|mail@dipe.org|Sebastian Sauer}}<br />
{{FeatureTodo|krossfalcon|Documentation++|mail@dipe.org|Sebastian Sauer}}<br />
|}<br />
<br />
= kdegames =<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 !! Project !! Description !! Contact<br />
{{FeatureDone|KGoldrunner|Add Curse of the Mummy game (20 levels), contributed by Steve Mann.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureInProgress|KGoldrunner|Major rewrite, mainly of the game engine and editor.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureInProgress|KGoldrunner|More accurate and reliable pause and resume.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureTodo|KGoldrunner|Save and reload at any instant in a game.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureTodo|KGoldrunner|Record and replay games.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureTodo|KGoldrunner|Run demos ... especially at startup or as hints for difficult levels.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureTodo|KGoldrunner|Hot-new-stuff support for themes and game sets.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureTodo|KGoldrunner|Integration of the Scavenger game (180 new levels) and its rule-set. This would also involve allowing different grid dimensions for different games, as a feature of the new game engine.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureTodo|KGoldrunner|Better support for beginners, such as graphical cues for false bricks and hidden ladders, extra messages with "don't tell me this again", etc.|ianw2@optusnet.com.au|Ian Wadham}}<br />
{{FeatureInProgress|Killbots|Add "sonic screwdriver" functionality.|parker.coates@gmail.com|Parker Coates}}<br />
{{FeatureTodo|Killbots|Add a tutorial for beginners.|parker.coates@gmail.com|Parker Coates}}<br />
{{FeatureTodo|Kolf|Replace with Kolf 2 (please help!)|majewsky@gmx.net|Stefan Majewsky}}<br />
{{FeatureDone|KPatience|Add a command line switch to manually launch a game of a certain type.|parker.coates@gmail.com|Parker Coates}}<br />
{{FeatureDone|KPatience|Add an option to save the game state at shutdown to be automatically be restored on next run.|parker.coates@gmail.com|Parker Coates}}<br />
{{FeatureDone|KPatience|Add the ability to return to the game selection screen after selecting a game.|parker.coates@gmail.com|Parker Coates}}<br />
{{FeatureTodo|KsirK|rewrite AI code or at least correct most problems related in bug #170777. Volunteers wanted!|kleag@free.fr|Gaël de Chalendar}}<br />
{{FeatureTodo|KsirK|Previous/Next in start new game as described in bug #170774|kleag@free.fr|Gaël de Chalendar}}<br />
{{FeatureTodo|KsirK|Polish the skin editor (doc, contextual help, ...)|kleag@free.fr|Gaël de Chalendar}}<br />
{{FeatureTodo|KsirK|Boost playing over Jabber|kleag@free.fr|Gaël de Chalendar}}<br />
{{FeatureTodo|KSpaceDuel|rewrite AI code|dirkrathlev@gmx.de|Dirk Rathlev}}<br />
{{FeatureDone|ktron|Port and remake the KTron game for KDE 4.3|legolas@legolasweb.nl|Stas Verberkt}}<br />
{{FeatureTodo|KSudoku|Import the new logic engine as a library|joselb@gmx.net|Johannes Bergmeier}}<br />
{{FeatureTodo|KSudoku|Port KSudoku to the new engine|joselb@gmx.net|Johannes Bergmeier}}<br />
{{FeatureTodo|KSudoku|Add interactive help|joselb@gmx.net|Johannes Bergmeier}}<br />
{{FeatureDone|Bovo|Add new AI|pelladigabor@gmail.com|Pelladi Gabor}}<br />
{{FeatureDone|Bovo|Computer thinking doesn't block the GUI|pelladigabor@gmail.com|Pelladi Gabor}}<br />
{{FeatureTodo|libkdegames|Import KGGZ libraries from GGZ SVN|spillner@kde.org|Josef Spillner}}<br />
{{FeatureInProgress|libkmahjongg|Introduce new tileset, Bamboo.|mw_triad@users.sourceforge.net|Matthew Woehlke}}<br />
{{FeatureDone|KMahjongg|Add 70 additional levels contributed by users|piacentini at kde.org|Mauricio Piacentini}}<br />
{{FeatureTodo|KMahjongg|Add start page with level selection|piacentini at kde.org|Mauricio Piacentini}}<br />
|}<br />
<br />
= kdeadmin =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|KGrubEditor|Integrate KGrubEditor into KDE Admin http://sourceforge.net/projects/kgrubeditor. Approved by Nicolas Ternisien <nicolas.ternisien@gmail.com> |artemis_dot_fowl_dot_2007@gmail_dot_com|Konstantinos Smanis}}<br />
{{FeatureTodo|Guidance|Port Guidance to KDE 4, and move it to KDE Admin http://www.simonzone.com/software/guidance/.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}<br />
{{FeatureTodo|system-config-printer-kde|Restore feature parity with KDEPrint3 where possible.|john@layt.net|john Layt, Jonathan Riddell}}<br />
|}<br />
<br />
= kdesdk =<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 !! Project !! Description !! Contact<br />
{{FeatureInProgress|Lokalize|XLIFF support|shafff-at-ukr.net|Nick Shaforostoff}}<br />
{{FeatureInProgress|Lokalize|various Translation Memory enhancements|shafff-at-ukr.net|Nick Shaforostoff}}<br />
{{FeatureInProgress|Lokalize|Kross-based scripting|shafff-at-ukr.net|Nick Shaforostoff}}<br />
{{FeatureTodo|Lokalize|QA: glossary checklists|shafff-at-ukr.net|Nick Shaforostoff}}<br />
{{FeatureTodo|KAppTemplate|Add DBUS support in templates|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureDone|Umbrello|Replace all q3 widgets in the refactoring assistant|andi.fischer@hispeed.ch|Andi Fischer}}<br />
{{FeatureInProgress|Umbrello|Merge in SoC qgraphicsview port branch|krishna.ggk@gmail.com|Gopala Krishna A}}<br />
|}<br />
<br />
= kdeedu =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|KAlgebra|Export to MathML Presentation Markup|aleixpol@gmail.com|Aleix Pol}}<br />
{{FeatureTodo|KAlgebra|Some integration with the new KFormula widget|aleixpol@gmail.com|Aleix Pol}}<br />
{{FeatureInProgress|KAlgebra|Add ability to draw 3D plots in cylindrical and spherical coordinates.|orgyforever@gmail.com|Percy Camilo Triveño Aucahuasi}}<br />
{{FeatureTodo|Kalzium|Port Kalzium's periodic table to use new QGraphicsView.|marcus@cryos.org|Marcus D. Hanwell}}<br />
{{FeatureTodo|Kalzium|Separate compound viewer/editor application from Kalzium.|marcus@cryos.org|Marcus D. Hanwell}}<br />
{{FeatureTodo|Kalzium|Remove the libavogadro snapshot, depend on libavogadro directly.|jacob@math.jussieu.fr|Benoit Jacob}}<br />
{{FeatureTodo|Kalzium|Plasmoid to access Kalzium database|cniehaus@kde.org|Carsten Niehaus}}<br />
{{FeatureTodo|KEduca|Rewrite of the classic test writing/taking application|matt@milliams.com|Matt Williams}}<br />
{{FeatureTodo|KHangMan|Integrate an editor|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|KHangMan|Plasmoid|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|KHangMan|Theme manager|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|Kig|Properties dialog for objects.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Kig|Improve construction of bisect lines.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Kig|Improve feedback when constructing objects.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Kig|More geometric objects.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Kig|Script objects as macros (to be reused more than once).|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Kig|Improve the Cabri import filter.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Kig|Improve the new/edit script wizard.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|KLettres|Visual Indicator when letter is wrong|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|KLettres|Number support|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|KLettres|Theme manager|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|KStars|Marble widget for Geolocation tool|mboquien@free.fr|Médéric Boquien}}<br />
{{FeatureTodo|KStars|Better printed star charts|kstars@30doradus.org|Jason Harris}}<br />
{{FeatureTodo|KStars|Sync KStars time from device|mutlaqja@ikarustech.com|Jasem Mutlaq}}<br />
{{FeatureTodo|KStars|Better rendering of comets/asteroids|kstars@30doradus.org|Jason Harris}}<br />
{{FeatureTodo|KStars|Texture mapping of the skymap???|kstars@30doradus.org|Jason Harris}}<br />
{{FeatureTodo|KStars|Improve Observing List Wizard|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Display Comet Magnitudes whenever possible|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Information links in-place for each technical term|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Tool to suggest star-hopping techniques???|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Extend conjunction tool to have one object unspecified, but have a genre of objects specified instead|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Extend conjunction tool to predict oppositions and occultations|prak902000@gmail.com|Prakash Mohan}}<br />
{{FeatureTodo|KStars|Simulate Lunar Eclipses|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Simulate Satellites and Iridium Flares|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Social and Geographical Integration for KStars|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KStars|Merge SAC with NGC / IC as default catalog|akarshsimha@gmail.com|Akarsh Simha}}<br />
{{FeatureTodo|KTurtle|Optional rulers/grid for canvas units|piacentini@kde.org|Mauricio Piacentini}}<br />
{{FeatureTodo|Marble|Export map to MxN pixel bitmap|inge@lysator.liu.se|Inge Wallin}}<br />
{{FeatureTodo|Marble|Bookmarks|inge@lysator.liu.se|Inge Wallin}}<br />
{{FeatureTodo|Marble|Support for MarbleWidget::setEnabled( bool )|inge@lysator.liu.se|Inge Wallin}}<br />
{{FeatureTodo|Marble|Map Contents translation|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureTodo|Marble|Editing GeoDataFeatures|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureTodo|Marble|Update Map ("F5")|jensmh@gmx.de|Jens-Michael Hoffmann}}<br />
{{FeatureInProgress|Marble|Layer Management Class|rahn@kde.org|Torsten Rahn}}<br />
{{FeatureInProgress|Marble|Plugin architecture for map layers|rahn@kde.org|Torsten Rahn}}<br />
{{FeatureInProgress|Marble|Extending GeoPainter|rahn@kde.org|Torsten Rahn}}<br />
{{FeatureInProgress|Marble|Marble Runners|hdevalence@gmail.com|Henry de Valence}}<br />
{{FeatureInProgress|Marble|GeoClue Integration |jensmh@gmx.de|Jens-Michael Hoffmann}}<br />
{{FeatureInProgress|Marble|Routing |jensmh@gmx.de|Jens-Michael Hoffmann}}<br />
{{FeatureInProgress|Marble|More map providers (WMS?) |jensmh@gmx.de|Jens-Michael Hoffmann}}<br />
{{FeatureInProgress|Marble|Winkel Triple projection / equivalent |hdevalence@gmail.com|Henry de Valence}}<br />
{{FeatureInProgress|Marble|Marble WorldClock Plasmoid|hdevalence@gmail.com|Henry de Valence}}<br />
{{FeatureDone|Marble|Qt-Version settings dialog|hdevalence@gmail.com|Henry de Valence}}<br />
{{FeatureInProgress|Marble|Panoramio Support||Shashank Singh}}<br />
{{FeatureInProgress|Marble|Twitter Plugin||Shashank Singh}}<br />
{{FeatureInProgress|Marble|TimeZone Support|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureDone|Marble|Support for other planets and the moon|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureDone|Marble|DGML2 Support|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureDone|Marble|Support for imperial units|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureInProgress|Marble|Graticule plugin|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureInProgress|Marble|MeasureTool plugin|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureDone|Marble|Port authors list from the Qt-About dialog to the KDE-About dialog|tackat@kde.org|Torsten Rahn}}<br />
{{FeatureInProgress|Marble|Basic KML support|ps_ml@gmx.de|Patrick Spendrin}}<br />
{{FeatureInProgress|Marble|GeoData Model/View Visualization|ps_ml@gmx.de|Patrick Spendrin}}<br />
{{FeatureInProgress|Marble|More generic projection support|inge@lysator.liu.se|Inge Wallin}}<br />
{{FeatureInProgress|Marble|Network plugins|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Marble|Geolocation plugins|ewoerner@kde.org|Eckhart Wörner}}<br />
{{FeatureInProgress|Parley|Declensions|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}<br />
{{FeatureTodo|Step|Improve GUI for creating softbody|ksvladimir@gmail.com|Vladimir Kuznetsov}}<br />
{{FeatureTodo|Step|Use common constraints handling code for collisions|ksvladimir@gmail.com|Vladimir Kuznetsov}}<br />
|}<br />
<br />
= kdemultimedia =<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 !! Project !! Description !! Contact<br />
{{FeatureTodo|JuK|Remove Qt/KDE3 support lib requirements|michael.pyne@kdemail.net|Michael Pyne}}<br />
{{FeatureTodo|JuK|Allow setting covers directly from URLs supported by KIO - drag/drop already allows this however|michael.pyne@kdemail.net|Michael Pyne}}<br />
{{FeatureDone|JuK|Use XCOMPOSITE real transparency when available for the track announcement popup|michael.pyne@kdemail.net|Michael Pyne}}<br />
{{FeatureTodo|JuK|Allow disabling crossfade|michael.pyne@kdemail.net|Michael Pyne}}<br />
|}<br />
<br />
= kdeaccessibility =<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 !! Project !! Description !! Contact<br />
|}<br />
<br />
= kdegraphics =<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 !! Project !! Description !! Contact<br />
{{FeatureDone|Okular|Generator for Mobipocket format|qbast@go2.pl|Jakub Stachowski}}<br />
{{FeatureDone|strigi|Thumbnailer and analyzer for Mobipocket format|qbast@go2.pl|Jakub Stachowski}}<br />
{{FeatureDone|strigi|Analyzer for epub format|qbast@go2.pl|Jakub Stachowski}}<br />
{{FeatureTodo|Okular|Sound annotations.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Okular|Link annotations.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Okular|Caret annotations.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Okular|Support .snp and .emf file formats|bradh@kde.org|Brad Hards}}<br />
{{FeatureTodo|Okular|Synctex support.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Okular|Rich-text for annotations text.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|kruler|More ruler shapes.|msoeken_at_tzi_dot_de|Mathias Soeken}}<br />
{{FeatureDone|kruler|Configurable shortcuts.|msoeken_at_tzi_dot_de|Mathias Soeken}}<br />
{{FeatureTodo|kruler|DBUS Interface.|msoeken_at_tzi_dot_de|Mathias Soeken}}<br />
{{FeatureDone|kruler|Transparent background and opaque drawing of the lines and numbers (Qt 4.5).|msoeken_at_tzi_dot_de|Mathias Soeken}}<br />
{{FeatureInProgress|gwenview|Folder view.|agateau@kde.org|Aurélien Gâteau}}<br />
{{FeatureInProgress|gwenview|Make thumbnail bar more customizable (orientation, number of rows/columns).|agateau@kde.org|Aurélien Gâteau}}<br />
{{FeatureInProgress|gwenview|Add back video support.|agateau@kde.org|Aurélien Gâteau}}<br />
{{FeatureInProgress|gwenview|Improve history handling.|agateau@kde.org|Aurélien Gâteau}}<br />
{{FeatureDone|libksane|Add "Auto selection" after preview.|kare.sars@iki.fi|Kåre Särs}}<br />
{{FeatureInProgress|Okular|Less intrusive search with find bar.|pino@kde.org|Pino Toscano}}<br />
{{FeatureTodo|Okular|Better detection of where the Okular KPart is embedded into, and adapt the UI accordingly (sidebar, actions, etc).|pino@kde.org|Pino Toscano}}<br />
|}<br />
<br />
= kdebase-runtime =<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 !! Project !! Description !! Contact<br />
{{FeatureInProgress|drkonqi|DrKonqi new dialog UI + Guided crash reporting tool|andresbajotierra@gmail.com|Dario Andres|}}<br />
{{FeatureInProgress|drkonqi|Backtrace parsing and rating|gkiagiad@csd.uoc.gr|George Kiagiadakis|}}<br />
{{FeatureTodo|drkonqi|DrKonqi native english texts + guide|andresbajotierra@gmail.com|Dario Andres|}}<br />
{{FeatureInProgress|kpasswdserver|Fix D-Bus timeout in kpasswdserver using an async API|lemma@confuego.org|Michael Leupold}}<br />
|}<br />
<br />
= kdebase-apps =<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 !! Project !! Description !! Contact<br />
{{FeatureInProgress|konq_thumbnails|Basic thumbnail support for KHTMLPart views(almost finished, now cleanup code)|yinshuiboy@gmail.com|Siyuan Cao}}<br />
{{FeatureTodo|konq_thumbnails|thumbnail support for all KonqFrame|yinshuiboy@gmail.com|Siyuan Cao}}<br />
{{FeatureTodo|konq_thumbnails|more thumbnail page styles and customization|yinshuiboy@gmail.com|Siyuan Cao}}<br />
{{FeatureTodo|konqueror|"Places" sidebar to replace KDE3's "media:/"|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}<br />
{{FeatureTodo|konqueror|Move Dolphin's Treeview to libkonq so that it can be used in Konqueror|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}<br />
{{FeatureTodo|konqueror|Move Dolphin's Information panel to libkonq so that it can be used in Konqueror|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}<br />
{{FeatureInProgress|dolphin|Matthias's Audio/ Video preview in Information panel|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}<br />
{{FeatureTodo|dolphin|Allow to configure and download service menus|peter.penz@gmx.at|Peter Penz}}<br />
{{FeatureInProgress|dolphin|Nepomuk search integration|peter.penz@gmx.at|Peter Penz}}<br />
{{FeatureInProgress|dolphin|Use Nepomuk to receive the meta data for the Information panel|peter.penz@gmx.at|Peter Penz}}<br />
{{FeatureInProgress|dolphin|Let user choose if folders are always shown first or not|frank78ac@googlemail.com|Frank Reininghaus}}<br />
{{FeatureInProgress|konsole|Get a working DBus interface|kurt.hindenburg@gmail.com|Kurt Hindenburg}}<br />
{{FeatureTodo|konsole|Redesign manage profile dialog to allow users to sort profiles|kurt.hindenburg@gmail.com|Kurt Hindenburg}}<br />
{{FeatureTodo|konsole|Allow window/terminal size to be set in profiles|kurt.hindenburg@gmail.com|Kurt Hindenburg}}<br />
{{FeatureInProgress|libkonq|Add support in for pluginbased Drag'n'drop popup menus (and in my case, an "extract here" menu on dragged archives)|haraldhv@stud.ntnu.no|Harald Hvaal}}<br />
{{FeatureInProgress|konqueror|History browser as independent from sidebar, and improved (different grouping style, sorting, etc).|pino@kde.org|Pino Toscano}}<br />
|}<br />
<br />
= kdeplasma-addons =<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 !! Project !! Description !! Contact<br />
<br />
{{FeatureInProgress|Video Plasmoid|a media player widget complete with a basic dbus interface|notmart@gmail.com|Marco Martin}}<br />
{{FeatureDone|System Load Viewer|A tiny monitor for CPU, RAM and swap usage (known as System Monitor in KDE3)|dhaumann@kde.org|Dominik Haumann}}<br />
{{FeatureInProgress|Comic Plasmoid|Clean up the config-dialog|mat69@gmx.net|Matthias Fuchs}}<br />
{{FeatureTodo|Comic Plasmoid|Port to popup applet|mat69@gmx.net|Matthias Fuchs}}<br />
{{FeatureTodo|PoTD Engine|Import PoTD engine|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|Metadata Engine|Import Metadata engine|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|Frame Plasmoid|Display Picture Metadata|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|Frame Plasmoid|Add url as setting|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureTodo|Frame Plasmoid|Add buttons Next/Previous/pause in slideshow mode|annma@kde.org|Anne-Marie Mahfouf}}<br />
{{FeatureDone|wallpapers|Mandelbrot fractal wallpaper plugin|jacob.benoit.1@gmail.com|Benoît Jacob}}<br />
{{FeatureInProgress|Weather Wallpaper|Add user-defined wallpapers|echidnaman@kubuntu.org|Jonathan Thomas}}<br />
{{FeatureInProgress|wallpapers|Marble desktop globe wallpaper|sasch.pe@gmx.de|Sascha Peilicke}}<br />
{{FeatureTodo|FileWatcher|Highlighting support|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureTodo|Now Playing|New widget UI|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureTodo|Life|Colors|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureTodo|Life|Fading|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureInProgress|Timer|Restore countdown after a shutdown|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureInProgress|Timer|Improved notifications|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureInProgress|Timer|Hide seconds|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureTodo|Unit converter|Improved widget UI|davide.bettio@kdemail.net|Davide Bettio}}<br />
{{FeatureInProgress|plasmaweather lib|Make plasmaweather library and use it in lcd weather, weather and weather wallpaper|damu@iki.fi|Petri Damstén}}<br />
{{FeatureDone|LCD Weather|Tooltip|damu@iki.fi|Petri Damstén}}<br />
|}<br />
<br />
= kdeartwork =<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 !! Project !! Description !! Contact<br />
<br />
{{FeatureInProgress|screensavers|port to wallpaper packages|davide.bettio@kdemail.net|Davide Bettio}}<br />
|}</div>Zwabelhttps://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas&diff=22420Projects/Summer of Code/2008/Ideas2008-03-23T15:21:20Z<p>Zwabel: Add kio-fuse idea</p>
<hr />
<div>This page is an open list for ideas for the 2008 edition of [http://code.google.com/soc Google Summer of Code]. This page is open for new ideas from anyone - you do need to log in to the wiki to edit this page though (see below for why).<br />
<br />
This list is not exhaustive. It is just a collection of some ideas. To get further ideas, please feel free to use any resources and [[#Past_ideas|past ideas]].<br />
<br />
Before proceeding, '''read''' the [[Projects/Summer of Code/2008/Participation|participation instructions]] and [[#Notes_on_editing_this_page|the notes on editing this page]]. They are useful for students and developers alike.<br />
<br />
== Past ideas ==<br />
<br />
You may want to take a look at the ideas page for [http://wiki.kde.org/tiki-index.php?page=KDE%20Google%20SoC%202006%20ideas 2006] and [[Projects/Summer_of_Code/2007/Ideas|2007]]. Many of the ideas there are still valid today.<br />
<br />
== Notes on editing this page ==<br />
<br />
Before making any modifications, please '''log in''' to Techbase. This will help us track who is contributing to the ideas. This page is protected, so you can't modify it without logging in anyways.<br />
<br />
When adding a new idea, please bear in mind the question: can a student with very little knowledge of KDE code complete this work in three months? If you can't answer "yes", your idea is probably not for this page. Please remember that this is '''not''' a generic wishlist page for KDE developers.<br />
<br />
When making modifications to existing ideas, please consider whether you're changing it more fundamentally or just superficially. If your changes are substantial, you probably have an entirely new idea. Similarly, if your idea is modified and you feel it no longer reflects your original thought, please split the idea in two, restoring yours.<br />
<br />
Please use the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] if you want to discuss an idea.<br />
<br />
Finally, do '''not''' delete ideas without a reason for doing so (like, for instance, being contrary to KDE ideals, being completely unrelated to KDE, being unfeasible, etc.) -- you may want to state in the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] why you removed the idea.<br />
<br />
Do '''not''' re-add ideas that were removed without discussing first with the developers of the target application.<br />
<br />
== Project ideas ==<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 />
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 />
When adding an idea to this section, please try to include the following data:<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 />
=== KDE Libs ===<br />
<br />
==== KDE Core libraries ====<br />
<br />
The KDE core libraries (kdecore, kdeui, kio, kparts) are the most basic libraries that all KDE applications depend upon.<br />
<br />
----<br />
'''Project:''' ODF writer<br />
<br />
'''Brief explanation:'''<br />
The ODF file format could be used for a wide range of applications, not just traditional office tools such as a word processor or spreadsheet.<br />
<br />
As an example, consider a tool like ksnapshot (which does screenshot captures). When writing documentation on how to perform some task with an application, you might work through the application taking many screenshots. If we had a class in kdelibs that could write ODF files, and the right application integration, perhaps the tool could create a file full of screenshots, which could then be annotated with some explanation to create a "visual guide" for that task.<br />
<br />
ODF is a pretty simple format to write (much less simple to read, because of the many options), and there is significant expertise in the KOffice community on that format.<br />
<br />
'''Expected results:'''<br />
* Properly designed, implemented, documented and tested class(es) for ODF writing.<br />
* Two usages of the class in different KDE applications (e.g. Okular and ksnapshot).<br />
<br />
'''Hints for proposal:'''<br />
* Explain what design and coding principles you will apply (goal: convince us that the code will be suitable for kdelibs)<br />
* Identify schedule for each element (goal: demonstrate that the task can be completed in the time you have available)<br />
* State your understanding of ODF (goal: demonstrate commitment to the task outcomes)<br />
<br />
'''Knowledge prerequisites:''' Sound C++ and Qt knowledge. Some familiarity with other ODF tools would be useful. <br />
<br />
'''Mentor:''' TBA<br />
<br />
----<br />
'''Project:''' Diskspace Service<br />
<br />
'''Brief explanation:'''<br />
<br />
Applications that write large amounts of data to partitions must nor fill them up completely. As an example there is strigi/soprano which can have a large index and will fill your ~ until 0 bytes remain. Other applications are e.g. those that write data to .thumbnails.<br />
<br />
To prevent this there is the need for a service that can be queried by applications, whether the user-set limit of remaining MB is already reached or not.<br />
<br />
As an extra the user could be notified if the set limit is reached.<br />
<br />
Mentor: Sebastian Trueg<br />
<br />
----<br />
'''Project:''' Support for fingerprint authentication<br />
<br />
'''Brief explanation:'''<br />
Many laptops come with a simple fingerprint scanner that can be used to authenticate users. It would be nice if KDE had support for these fingerprint scanner integrated. This way you could use them to log into KDE, unlock KWallet, maybe even use it to enter nickname in highscores for games... It would probably be a good idea to work with [http://reactivated.net/fprint/wiki/Main_Page fprint] project when integrating the support.<br />
<br />
----<br />
'''Project:''' Smart toolbars<br />
<br />
'''Brief explanation:'''<br />
Currently the policy is to have as few buttons in toolbar as possible by default. Only the ones that have a very high chance of being used by almost all users of an application. Maybe there could be an option added to toolbars so that it would monitor which actions (from menus) the user uses. When the new smart toolbar notices that the user has used some action very frequently and which doesn't have a button in the toolbar yet, it could suggest to the user to automatically add it to the toolbar. Buttons could also be removed after not using toolbar buttons for a long time. Off course there should be 3 options for this feature: 1. to automatically add and remove toolbar buttons without asking, 2. to ask before adding or removing, and 3. to disable this feature so that toolbars are the same as now.<br />
<br />
----<br />
<br />
'''Project:''' Beautify KNotify / Support Growl themes<br />
<br />
'''Brief explanation:''' In its current form KDE notifications are quite "basic" -- one might even say ugly. With WebKit as part of Qt 4.4, implement "CSS-able" notifications similar to (and ideally compatible to) [http://growl.info/about.php Growl]. Growl is a framework for Mac OS X and its free software under the 3-clause BSD License. Adopting the same license for KNotify's theming code may ensure future code exchange between both projects and theme compatibility.<br />
<br />
'''Expected results:''' Similar capabilities to what's shown in the video on http://growl.info/about.php and in the screenshots on http://growl.info/screenshots.php<br />
<br />
'''Project:''' KIO-fuse UI integration<br />
<br />
'''Brief explanation:''' Fuse is a technology that allows mounting in user-space. There is already the kio-fuse application that allows using kio in any application, but it is incomplete and not well integrated. It should be made a more general integrated solution.<br />
<br />
'''Expected result:'''<br />
There should be something like an additional folder "~/$KDEDIR/remote_places", in which all opened kio connections are mounted with a nice directory-name like "myuser@ftp.somepage.com". Dolphin and the kde file-open dialog should replace the directory on the fly with something like "Remote Places", and sub-folders with the correct address like in this case ftp://myuser@ftp.somepage.com. That way the only difference between kio-aware and un-aware applications would be that the ones show nicer urls. All applications could transarently work with any remote files.<br />
<br />
==== Solid ====<br />
<br />
Solid is the KDE hardware abstraction layer, that enables KDE programs to get consistent results when running on different platforms.<br />
<br />
==== Phonon ====<br />
<br />
Phonon is the KDE audio abstraction layer, that enables KDE programs to produce basic and medium-level multimedia functionality in any platform without platform-specific code.<br />
<br />
==== KHTML ====<br />
<br />
KHTML is the current KDE HTML engine, used by the Konqueror web-browser and other applications to display HTML in their interfaces.<br />
<br />
'''Project:''' Implement HTML 5 features<br />
<br />
'''Brief explanation:''' HTML 5 will bring many new features. The student gets to pick and propose one or several of those features from the draft. Projects could encompass implementation of DOM Storage or SQL interfaces for example.<br />
<br />
'''Project:''' Web-based desktop<br />
<br />
'''Brief explanation:''' The advancement of Web technology (DHTML, XMLHTTPRequest, CSS, Canvas) nowadays allows for the implementation of complex GUIs that can compete with native programing toolkits. This project would involve the implementation of a KDE desktop including icons and menus that is solely based on HTML, JavaScript and CSS. An examplaric feature: render the content of .desktop files in HTML. This could either be served through a backend server or a custom KHTML part that provides such code and offers extensions to load from and store data on the hard disk.<br />
<br />
==== KJS ====<br />
<br />
KJS is the JavaScript engine used by KHTML and Kross to run JavaScript programs.<br />
<br />
'''Project:''' ECMAScript 4 classes<br />
<br />
The draft for ECMAScript 4 on www.ecmascript.org mentions several new built-in types like Vector and Map. Existing implementations that already cover part of the future standard (like ActionScript) also feature classes like ByteArray. Other ideas are KDE specific likes like KIO bindings. Students are invited to select and implement a subset of these classes.<br />
<br />
'''Project:''' Pre-compiled JavaScript programs<br />
<br />
As announced [http://www.kdedevelopers.org/node/3323 recently] the [http://websvn.kde.org/branches/work/kjs-frostbyte/kjs/ kjs-frostbyte] branch now features a byte-code version of KJS. From there the step to pre-compiled executables, i.e. binary blobs that contain code as well as data and can be executed from the shell like normal executables is not very big.<br />
<br />
==== Sonnet ====<br />
<br />
Sonnet is the KDE grammar, spell-checker and language-detection engine.<br />
<br />
==== Kross ====<br />
<br />
Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and KDE JavaScript transparently into native applications to bridge the static and dynamic worlds together.<br />
<br />
==== Oxygen ====<br />
<br />
Oxygen is the KDE 4's default look-and-feel. It comprises of the Oxygen icon set (including the palette and guidelines for icons), the Oxygen sound theme, the Oxygen wallpaper collection, the Oxygen window decoration and the Oxygen widget style. Note that for Summer of Code, you must produce code, so the window decoration and widget styles are your more likely candidates.<br />
<br />
==== KDE-Print ====<br />
<br />
* Implement an easy usable [http://www.fineprint.com/products/fineprint/index.html fineprint-like] solution for collecting pages from different printing sources (browser, kword, krita...) and allow it to rearrange single pages (not printing jobs), delete pages, add blank pages. Information also in wish-list-item: [https://bugs.kde.org/show_bug.cgi?id=90989 90989]. I am the reporter of this wish, you can contact me there. I do not have the abilities to program, but I am willing to help testing an implementation and discuss how it should look like.<br />
* WARNING! i'm doing exactly this for my semester project at school (we are two students, so we can't apply for SoC with this). We are probably developing it in pure QT (the other student is a gnome user).You can get in contact with me: asranie@fryx.ch<br />
<br />
=== KDE Base applications ===<br />
<br />
==== Konqueror ====<br />
<br />
Konqueror is KDE's powerful web browser and file manager.<br />
<br />
'''Project: Bookmark Wallet'''<br />
<br />
'''Description:''' This isn't actually a project to be a part of Konqueror itself, but rather a separate application similar to KWallet. The application should provide a database for the storage of URL bookmarks. The database should be able to connect to remote storage, such as the Google bookmarks service, for synchronization and backup. The URLs should be easily manageable, and include a concept of ratings for the URLs. A plugin should be written to allow Konqueror to easily interface into the system, or preferably Konqueror itself should be modified to use the storage system when it is available. The application should provide an interface which is easy to connect to from a browser plugin, so that plugins could be written for other browsers, such as Firefox, as well. There should also be a plugin interface into the database, to allow support for other remote storage backends, such as foxmarks, to be created. The application should handle multiple concurrent connections to the database without issues. Additionally, the application should provide an event interface to notify all connected browsers whenever a bookmark is added, changed or removed.<br />
<br />
Comment: Rather than developing a separate application, interested students should have a look at the [http://websvn.kde.org/trunk/KDE/kdepim/akonadi/resources/localbookmarks/ Akonadi resource localbookmarks]<br />
<br />
Comment: Would be great if this would include saving RSS-Feeds in as well, synchronising them with webbased feedreaders<br />
<br />
Comment: a database of feeds would indeed be great. If implemented with a "feedtype" field, it would solve the problem of feeds containing news that's best read in a traditional aggregator, audio that's best heard in a music player, video that's best seen in a video player, etc. Apps could just open the query the feed DB for suitable feeds. Or perhaps they could query for feeds with particular enclosure mimetypes? Hmm. That raises the issue of pre-loading the feed, and integration with libsyndication.<br />
<br />
Comment: Here is a somewhat related mockup for a bookmark tagging GUI : [http://www.kde-look.org/content/show.php/Taged+bookmarks?content=43765 KDE-look link]<br />
<br />
==== Dolphin ====<br />
<br />
Dolphin is KDE 4's default file manager application.<br />
<br />
'''Project: Support Windows' "Previous Versions"'''<br />
<br />
'''Description:''' Shadow Copy (also called Volume Snapshot Service or VSS) is a feature introduced with Windows XP with SP1, Windows Server 2003, and available in all releases of Microsoft Windows thereafter, that allows taking manual or automatic backup copies or snapshots of a file or folder on a specific volume at a specific point in time. It is used by NTBackup and the Volume Shadow Copy service to backup files. In Windows Vista, it is used by Windows Vista's backup utility, System Restore and the Previous Versions feature. Samba supports Shadow Copy since version 3.0.3.<br />
<br />
==== Konsole ====<br />
<br />
Konsole is KDE's terminal application.<br />
<br />
==== Kate and KWrite ====<br />
<br />
Kate is KDE's Advanced Text Editor, both a full-featured text editor application and a KPart engine ready for embedding into other applications (like KDevelop, Quanta and Kile). KWrite is a simple text editor based on the KatePart engine and is KDE's default text editor.<br />
<br />
----<br />
<br />
'''Project:''' vi mode for the Kate editor<br />
<br />
'''Project overview:''' Create a vi-like modal editing mode for the Kate editor part and improve the kate command line to a point where it can be used efficiently for vi commands in this mode.<br />
<br />
'''Expected results:''' This project should implement a vi-like, modal editing mode for kate. This mode will be selectable by the user.<br />
<br />
'''Mentor:''' Christoph Cullmann has agreed to mentor this project.<br />
<br />
==== System Settings ====<br />
<br />
'''Project: A system settings module for creating backups'''<br />
<br />
'''Project Information''':<br />
The idea is twofold:<br />
<br />
Create a System Settings control module for scheduling backups. Rather than pick a specific backup technology, it would support multiple backends, such as tar, dar, rdiff-backup and rsync-backup. By making it backend agnostic, it could be used with any file-based backup tool. It would therefore be more robust and easier to adopt than previous backup GUIs.<br />
<br />
To benefit the most users, the control module would be based on a non-KDE library so the technology could be reused in Gnome and other desktop environments. Therefore ideally, the implementation would take the form of a Freedesktop.org project that focuses on the functionality most backup programs share: selecting a root directory to backup and a destination directory, inclusion and exclusion rules, a choice between full or incremental backup, and whether to use compression and/or encryption. The goal would be to develop a descriptive backup file format that is not tied to any specific implementation, and a library that can read such files and generate the appropriate command line flags to create the backup with a given backup tool. A secondary goal would to create a sensible set of defaults for creating backups. That would involve collecting a list of common directories that can be excluded (such as trash directories, common web browser caches, and mount points) so that users do not have to waste time tweaking their exclusion rules.<br />
<br />
Usage cases:<br />
<br />
Average Joe is new to Linux, and wants to make a backup of his computer. He sees "Backup Settings" in KDE4's System Settings (or Gnome's Administration menu). Since the module is part of the upstream desktop environment, it doesn't matter which distribution he's using.<br />
<br />
Joe has been making backups to writable DVDs using the DAR backend of the backup control module for several weeks, when he gets an external hard drive. Now he wants to make the same backup to his external hard drive instead. He does not have to learn how to use a new program; he simply selects the rsync-backup backend and specifies the new destination.<br />
<br />
'''Expected Result:'''<br />
* A library that maps standard backup options (like include/exclude rules) to the command line options for several popular backup tools.<br />
* A working KControlModule for KDE4 that allows users customize and schedule backups.<br />
<br />
'''Currrent Knowledge''': <br />
* I have a little experience with C++, and have dabbled a bit in PyKDE<br />
<br />
'''Contact''': <br />
<br />
If you think the idea is interesting and would like to mentor such a project, my email is (wmhilton+gsoc@gmail.com)<br />
<br />
<br />
=== KDE Workspace ===<br />
<br />
==== Plasma ====<br />
<br />
Plasma is KDE 4's desktop and panel tool, replacing KDE 3's kicker and kdesktop. It's an advanced and powerful application with revolutionary ideas.<br />
<br />
* '''Plasma Packages'''<br />
** Plasma provides a simple packaging system for widget (plasmoids), SVG themes, wallpaper sets and indeed any type of application add-on data. It is not a replacement for apt, rpm, klick, etc. but rather is designed to help with the challenge of creating, sharing, installing and managing run time add-ons as have been made popular with KDE's Get Hot New Stuff framework.<br />
*** ''Project I: A GUI Creator For Packages'': This project involves taking the already started user application "plasmagik" and refining it to be ready for production use. The application must take a plasma package description, display it in a user friendly way in the UI and allow the user of the application to add files to the various nodes in the structure (e.g. graphics to an "images" entry). In particular this project would consist of:<br />
**** Removing assumptions based on the plasmoid package structure and instead using the generic Plasma::PackageStructure class.<br />
**** Making the UI more user friendly<br />
**** Streamlining the upload support<br />
**** Writing a tutorial on KDE's TechBase on how to employ the application as an add-on creator.<br />
**** As the plasmagik application already has had a fair amount of work done it and an active community of developers interested in its future, the scope and support for this project should be within the limits and expectations of the SoC.<br />
*** ''Project II: Package Management'': This project involves creating a small utility application consisting of a dialog and a control panel that uses it which allows the user to list, share and remove installed Plasma packages. As there are no dependencies, binary compatibility, etc issues usually associated with full package management applications, this would be well suited to a SoC project. <br />
* '''Zeroconf Integration''': This project would involved adding a zeroconf announce and discovery feature to libplasma that would provide a Plasma::Applet with a simple API to find other Applets of the same type on the local network. A test plasmoid would be created to prove the working status of the zeroconf support. Remaining time would be spent adding zeroconf features to applicable existing plasmoids.<br />
* '''DataEngine + Plasmoid for zeroconf services''': Browser for zeroconf services available (perhaps doable with above project as well?)<br />
* <s>'''Physics Engine''': Take an existing 2D physics engine and experiment with using it within a containment to emulate "natural" object interactions.</s> taken<br />
* '''Setting a video as desktop background'''<br />
* '''Dynamic desktop background''': A desktop background which displays different wallpapers according to information like time of the day, season, weather etc.<br />
* '''Mobile device containment''': Implement a Plasma::Containment that is appropriate in form factor and UI layout for a UMPC/tablet style device.<br />
* '''Touchscreen profile''': The use of UMPC form factors with a touch screen is increasing -- certainly in some business areas. Plasma is prepared for handling different form factors and for providing a user interface experience that adjusts to device characteristics. The touchscreen profile SoC project (touchscreen hardware will probably be arranged through the mentors) aims to identify where Plasma / KDE works well and where it doesn't on small (VGA or SXGA) screen sizes; then it will fix the bits where it doesn't work well and introduce a general mechanism for handling small screens. In addition, UMPC on-screen keyboards introduce new UI challenges; integrating these in a meaningful way with plasma is an extra part of this project (or possibly an extra project). Dialog and menu handling on small screens, with pagination of menus and (re)pagination of tabbed dialogs is another topic. '''Mentors:''' Adriaan de Groot and Armijn Hemel.<br />
* '''Phase''': improving the Phase/Animator system by:<br />
** implementing animation curves (already in the API and used by plasmoids, but not actually implemented)<br />
** optional keys for individual animations, allowing them to be turned off or otherwise tweaked individually / in groups<br />
** chaining animations<br />
** going through uses of customAnimation in libplasma using code and reimplementing generally useful ones within Animator itself<br />
<br />
==== KRunner ====<br />
<br />
KRunner manages the screen locking, run command dialog and provides a general natural language interface to applications, desktop services, network locations, files and data (e.g. math calculations, spell checking, word definitions, etc). It replaced the Run Command dialog in kdesktop from KDE3, is multithreaded and shares code with Plasma.<br />
<br />
Some of the items below may take an entire SoC project, others may be better combined to flesh out an entire summer's worth of work.<br />
<br />
* '''Ranking''': Results are returned to KRunner by individual runners. These result must then be ordered for the user prior to display. This project would consist of improving the ranking of returned results by working on two related fronts:<br />
** Tweaking individual runners to more accurately rate their own results.<br />
** Improving the final ranking system employed by the host application.<br />
* '''Abstracting runner management out of KRunner''': The main pieces of using runners (SearchContext, SearchMatch and AbstractRunner) exist in a shared library (libplasma). However, much of the code for managing the actual runners at runtime is contained within the krunner application itself. Abstracting this code out would make it easier for other components and applications to user runners as well.<br />
* '''Using runners in Kickoff''': The kickoff menu has a search tab. Currently it does it's own internal search. It should, instead, be using AbstractRunners for this. This task would go well with the runner management task above.<br />
* '''Xesam search runner''': Write an AbstractRunner plugin that uses the Xesam query spec to forward user queries to a search store. The trick will be in making it performant as well as providing support for paging through requests.<br />
* '''Write as many runners of your choice''': one might call this a "marathon" (get it? runners? as many as you can? ahaha! *sigh*). I wrote [[http://aseigo.blogspot.com/2007/10/what-runners-do-we-need-want-dream-of.html this blog entry]] looking for ideas for runners and got many, many suggestions. I think it reasonable to expect that over the course of a summer's work one might be able to write 5-10 runners depending which ones were selected.<br />
<br />
==== KWin ====<br />
<br />
KWin is KDE's X11 Window Manager program, greatly improved when compared to its older brother in KDE 3.<br />
*'''Compiz-like Effects in KWin''': Effects like Desktop Cube often greatly improve the usability, especially when it comes to multiple desktops, and they are just cool.<br />
<br />
*'''Make KWin multi-pointer ready''': Mpx is an extension of the X-Server currently living in a branch, that is planned to be merged in one of the next versions(see http://wearables.unisa.edu.au/mpx/). Once it's merged, the x-server will support an arbitrary count of simultaneous active pointers/cursors(A mouse and a keyboard paired together) and multiple active windows, allowing input from multiple users at the same time. The window-manager needs to be aware of the multiple cursors, and needs to dynamically assign pointers to applications that are not mpx-aware(Which will be all, in the beginning). Also it might be nice having a plasma-applet that allows easy spawning/removing of additional cursors.<br />
<br />
==== KDM ====<br />
<br />
KDM is KDE's Display Manager and login application.<br />
*'''More Ways of entering login data''': Currently, KDM only supports logging in with Username and Password in two fields on the one login mask. Entering first Username and then Password in two separate masks (Yeah, just like GDM) or searching for users while typing in the letters of a username would be really handy and cool. Another interesting thing to investigate would be "log in by finger-print".<br />
<br />
==== KScreenSaver ====<br />
<br />
*'''Plasma Dashboard Screensaver''': There could be a new default screensaver added. When started it would show the Plasma Dashboard with all the plasmoids on it. The Dashboard could be the default one (the one that shows up when you press Ctrl+F12) or the user could create a custom one just for this screensaver. These two options should be in the screensaver's properties. For creating custom layout there should be some tool to set background and add plasmoids.<br />
<br />
=== KDE Runtime ===<br />
<br />
''' Project''': KHelpcenter: What's this explosion<br />
<br />
'''Description''': A lot of help about elements of the user interface is available in the form of "What's This?" texts. Unfortunately it's pretty cumbersome to get to this information for a user as it needs clicking on the "question mark button" in the title bar of the window/dialog and then clicking on the user interface element. This project is about making this information more conveniently available by providing an "exploded" view of the "What's This?" help as part of the application's manual in KHelpcenter.<br />
<br />
All "What's This?" texts of a given window could get displayed in a view at once, e.g. by using some bubble views and connecting lines to the interface elements. These views could be extracted from the run-time instances of the windows by inspecting the widget hierarchy. This could either be done as a special offline run to pre-generate help pages or dynamically at run-time of the application. Investigations of what method would be the best would be part of the project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': KHelpcenter: Cheat sheets<br />
<br />
'''Description''': Task based documentation of applications can often be presented best as step-by-step instructions how to achieve certain user goals. With the help of application's D-Bus interfaces KHelpcenter could be extended to provide interactive versions of these step-by-step instructions. Users would be provided with explanations and instructions how to accomplish tasks together with links that would open corresponding dialogs, execute described actions, etc. In the Eclipse project this kind of help is called cheat sheets.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KOffice ===<br />
<br />
==== KWord ====<br />
'''Project:''' Improve ISO OpenDocument support<br />
<br />
'''Explanation:''' Improve loading and saving of the ISO OpenDocument format what includes 1) extend the current saving code, 2) extend the current loading code and 3) probably also extend the rendering engine aka the text flake-shape.<br />
<br />
'''Expected results:''' be sure everything we are able to load, display and edit is also saved back correctly using the default file format.<br />
<br />
'''Mentor:''' Sebastian Sauer <mail@dipe.org><br />
<br />
-----<br />
<br />
'''Project:''' Collaborative editing of documents over a network.<br />
<br />
'''Explanation:''' Make it possible for two or more users to work at the same document in KWord at the same time over a network. Both users would open the same document, and changes made by each user are synchronized to the other user's editing session.<br />
<br />
----<br />
<br />
'''Project:''' Version control integration.<br />
<br />
'''Explanation:''' Integrate version control system support with KWord to allow easy control over revisions of documents. It should be possible to connect with remote revision control systems, to allow collaborative work on projects, similarly to how software is developed. It should be easy for the user to browse through the history of document versions in the version control system, to see what has changed. CVS, Subversion and git should be supported.<br />
<br />
----<br />
<br />
'''Project:''' Improve legacy MS Office (2003) documents support<br />
<br />
'''Explanation:''' Current MS Office formats support is kinda limited (especially write support). To decrease the barrier for adoption, better MS Office support is a way to do that.<br />
<br />
==== KSpread ====<br />
==== Kexi ====<br />
Kexi is an integrated data management application for desktop users like Microsoft Access.<br />
<br />
-------<br />
'''Project:''' Improve Kexi Data Import/Export<br />
<br />
'''Brief explanation:''' Currently Kexi allows importing CSV files into an existing database, and converting MySQL/PostgreSQL/MS Access databases into Kexi databases.<br />
<br />
The aim of this project is to provide plugin(s) that import from more database backends/formats.<br />
<br />
You can select backend you want to implement migration for:<br />
<br />
* HSQLDB - the OpenOffice.org Base's DB backend (ODB file format, very important to have)<br />
* ODBC<br />
* Paradox<br />
* DBase (e.g. using [http://linux.techass.com/projects/xdb Xbase])<br />
* Firebird (note: pending licence checks if we want GPL-compliance)<br />
<br />
For the ODBC driver, a migration plugin and a backend plugin should be provided. For Paradox, only a migration plugin is required, although this will require modifying the migration framework to allow more than one file to be selected as the source database (i.e. the database to be imported).<br />
<br />
Both a migration plugin and a backend plugin could be provided for HSQLDB, which should be implemented using JNI to invoke JDBC methods in the HSQLDB library. To avoid Java and OO.org dependencies, a small tool could be developed in Java to export/import to/from a intermediate format, and then used from within a Kexi migration plugin.<br />
<br />
In any case, migration plugins are simpler to implement than direct access plugins (drivers), so these can be developed first.<br />
<br />
'''Expected results:''' HSQL support would enable OpenOffice.org Base format for KDE and KOffice itself, a good companion to already existing OpenDocument support. ODBC connectivity would add many new possibilities directly to KDE.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:'''<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_DBaseMigrationPlugin "DBase Migration Plugin for Kexi" proposed by Jonathon Manning in 2006]<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_ParadoxAndHSQLAccess "Paradox & HSQL access for Kexi" proposed by Joseph Wenninger in 2006]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl>, Sebastian Sauer <mail@dipe.org><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Kexi Web Forms<br />
<br />
'''Brief explanation:''' Web Forms allow to read-only or read-write access to database projects created with Kexi. It is optional feature for uses where client has no Kexi installed for any reason. The fact that the Web Forms will use Web standards, adds another advantage over competitors like MS Access (which uses proprietary Windows-only ActiveX bindings).<br />
<br />
Proposed solution is to develop a small standalone web server. It is probably already written in C++ or C by FOSS community. Good examples are lighttpd - http://www.lighttpd.net/ <br />
and (being already in KDEnetwork module) KPF - http://rikkus.info/kpf.html.<br />
<br />
The web server would be dynamically linked to kexidb and thus can access Kexi databases via universal KexiDB API, and create HTML content on demand as an answer to HTTP requests.<br />
<br />
For alternative solution see "Alternative solution for Kexi forms using PHP" below.<br />
<br />
'''Expected results:''' Shortly, it is internet-enabler for KOffice/KDE data management.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++ and HTTP/web standards, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:''' [http://jacek.migdal.pl/gsoc/ Solution proposed by Jacek Migdal last year]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Alternative Solution for Kexi Forms Using PHP<br />
<br />
'''Brief explanation:''' Create a Kexi plugin generating PHP code saving it directy to the filesystem. This will require Apache (or other PHP-compatible web server) to be present and configured, and also will require the plugin to be packaged with a script that will install appropriate tools that allow r/w accessing the Apache/php subdirs.<br />
<br />
'''Expected results:''' The generated code could directly access MySQL or PostgreSQL servers at the backend, so users could immediately have a robust server-side solution without complex requirements.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of PHP, web standards and C++, (knowledge of Qt is recommended)<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
==== Krita ====<br />
<br />
'''Project:''' Sumi-e brush engine<br />
<br />
'''Project Information:''' While there is already an attempt at a sumi-e brush engine in Krita, the current code is limited and uses an old-fashioned way of simulating brushes. <br />
<br />
'''Expected results:''' This project should implement an anti-aliased, bidirectional ink-transfer simulation of a sumi-e brush, together with a user interface to define brushes. The brushes should react to pressure, tilt and rotation of the a tablet stylus. The results should be realistic. Loan hardware for use during the development phase is available.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic knowledge of basic 2d graphics principles. A list of relevant papers and books is available.<br />
<br />
'''Mentor:''' Boudewijn Rempt <boud@valdyas.org> The mentor can help preparing the project proposal for submission to Google.<br />
<br />
-----<br />
<br />
'''Project:''' Sketch-pad interface for Krita<br />
<br />
'''Project Information:''' Krita is a large and complex application built around a sophisticated painting engine. The goal of this project is to create a new interface around the Krita engine, specialized for quick sketching.<br />
<br />
'''Expected results:''' This project should implement a new interface around Krita, presenting the user a single-layer plus tracing paper interface with a single freehand sketching tool. Easy to use and graphic color and paint operation (brush, pencil, eraser etc.) interface elements must be designed and implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:''' <br />
<br />
-----<br />
<br />
'''Project:''' Shader filters and generators for Krita<br />
<br />
'''Project Information:''' Some initial work has already been done to make it possible to write filters in the OpenGL shading language. This project should take that initial code as a basis and implement a fully functioning plugin for Krita that allows filters and shaders to be executed on images in any colorspace.<br />
<br />
'''Expected results:''' The plugin should have a finished user interface and make it possible to experiment with shader filters in an interactive way. Example filters must be implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, OpenGL.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Animation support<br />
<br />
'''Project Information:''' There is no support at all in Krita for animated images such as GIF or MNG or for working with images in an animation context, such as textures or backgrounds in applications like Blender. The applicant should first investigate user needs and use cases and then implement support in the user interface and in the import/export filters.<br />
<br />
'''Expected results:''' A user-friendly way of working with animated images (i.e., not by making each frame a layer), but e.g. a docker that shows the the animation running in thumbnail format. Import/export filters for relevant file formats.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' RAW plugin<br />
<br />
'''Project Information:''' Krita's current raw plugin is based on a shell exit to dcraw. This is not sufficient and needs to be re-implemented.<br />
<br />
'''Expected results:''' A next generation plugin should implement loading of raw images either through libopenraw or libkdcraw; preferably designed in such a way that we can switch libraries when opportune. The plugin should allow the user to set conversion parameters in a way that is useful to photographers. An extension to this project could be the implementation of a bayer colorspace model: that is, a colormodel that allows us to load the raw images and edit them in the native raw format, without conversion.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' PSD and Gimp plugins<br />
<br />
'''Project Information:''' Krita is powerful enough to handle nearly all that the Gimp and Photoshop are capable of saving. This project is about creating dedicated file import/export filters that can handle as much of these file formats as possible, possibly through the use of existing libraries.<br />
<br />
'''Expected results:''' 4 plugins: psd import/export and xcf import/export. These plugins should be able to handle complex files in all supported colorspaces.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Photoshop-compatible brush engine<br />
<br />
'''Project Information:''' A paintop plugin that can load and handle current photoshop brushes. This entails reverse engineering of the Photoshop brush file format and implementing a procedural brush engine that matches the Photoshop brush engine.<br />
<br />
'''Expected results:''' A procedural brush engine with settings dialog that can load and save current photoshop brush files.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Workspaces<br />
<br />
'''Project Information:''' A workspace is a loadable package of settings that finetune Krita for a particular purpose. A workspace could contain additional plugins (like an image browser plugin for batch operations) and a subset of resources. Example workspaces could be batch-editing of images, editing of animation sequences or painting or sketching.<br />
<br />
'''Expected results:''' the user interface and framework to make packages of plugins and resources that users can switch between. Also extra plugins to extend krita in areas like batch processing that do not exist yet.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:''' <br />
<br />
<br />
-----<br />
<br />
'''Project:''' Kipi and digikam plugins compatibility<br />
<br />
'''Project Information:''' Kipi and digikam provide lots of interesting plugins for working with 8 and 16 bit RGBA images. It would be great to be able to re-use those plugins from within Krita.<br />
<br />
'''Expected results:''' Two plugins that load kipi and digikam filters into two new menus in the filter menu. Code to convert Krita layers to the digikam image representation and back, taking care of icc profiles and other niceties.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:'''<br />
<br />
=== KDE SDK ===<br />
<br />
==== Umbrello ====<br />
<br />
Umbrello is the UML drawing and design tool in KDE.<br />
<br />
----<br />
<br />
'''Project:''' Add the capability to draw SysML diagrams (http://www.omg.org).<br />
<br />
----<br />
<br />
'''Project:''' Port Umbrello to QGraphicsView<br />
<br />
----<br />
<br />
==== Kobby ====<br />
<br />
<br />
'''Project:''' Kobby. A text editor which allows multiple users modify a set of documents at the same time. This is called a collaborative text editor.<br />
<br />
'''Brief explanation:'''<br />
* The idea is to create a KDE based application that depends on the [http://gobby.0x539.de/trac/wiki/InfinoteProtocol infinote] library which is the successor of the obby library.<br />
* It would be really nice to have integration with already existing editing and coding solutions: as KDevelop, or Kate for instance.<br />
* It would be even better if it was a katepart plugin so it can be used everywhere kateparts are used. The plugin integration can probably be done by extending KTextEditor to use the infinote API.<br />
<br />
You can find the [http://gobby.0x539.de/trac/ Gobby page here], where you can [http://gobby.0x539.de/trac/wiki/InfinoteProtocol also check out the infinote] library code. Svn repository: svn://svn.0x539.de/infinote/trunk<br />
<br />
'''Mentor:''' Andreas Ramm <psychobrain@gmx.net><br />
<br />
COMMENT: I had filed my vision of collaborative editing in KDE applications as wishlist item [http://bugs.kde.org/show_bug.cgi?id=149498 149498].<br />
Also see bugs [http://bugs.kde.org/show_bug.cgi?id=79721 79721] and [http://bugs.kde.org/show_bug.cgi?id=145011 145011]<br />
<br />
COMMENT: Infinote is under heavy development, and both the protocol and the library API have gaps and are subject to change. Whether you view this as a drawback or a chance to help shape and be on the cutting edge of open-source collaborative editing is down to you.<br />
<br />
COMMENT: Notes and Ideas can be found at the [http://mateedit.wiki.sourceforge.net/MateEdit Mateedit Wiki page]<br />
----<br />
<br />
=== KDE Edu ===<br />
<br />
==== Marble ====<br />
<br />
'''Project:''' Vector-Tiles for Marble <br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/marble Marble] is a generic geographical map widget and framework that is meant to be used by KDE4 applications. It is also distributed as a standalone application in KDE4.<br />
<br />
'''Brief explanation:'''<br />
* Marble can download and texture map texture tiles ( see http://www.kdedevelopers.org/node/3269 )<br />
* For implementing stuff like routing etc. properly we need a vector representation of streets and other features. One strategy to add those would be in terms of tiles similar to texture tiles.<br />
* Source data could either be VMap0 ( http://en.wikipedia.org/wiki/Vector_Map ) or OpenStreetMap data. You'd first need to find a way to create some vector tiles from this data stored in a suitable efficient format. These would need to get put onto the server. <br />
<br />
* Based on the Marble Layer Management architecture (which is currently in the works) you'd need to create a vector layer plugin which maps the vector tiles in the given projection. The vector layer data would internally use Marble's given data structure which is similar to the KML format ones. You'd need to extend that structure by vector features which are in the spirit of those provided by KML.<br />
<br />
* Ideally you'd also provide ways to select features using the mouse.<br />
<br />
'''Expected results:'''<br />
Getting OSM data or VMap0 data downloaded as tiles and rendered as vectors in the projection currently used. Being able to select features using the mouse.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, Qt, Recommended: knowledge of OpenStreetMap / VMap0.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Marble - OSM Annotation<br />
<br />
'''Brief exmplanation:'''<br />
* With a UMPC (possibly with built-in GPS receiver), it is possible to go into the field and hold a "verification party" to check the accuracy of OSM data. However, making notes when the OSM data is inaccurate is somehow annoying.<br />
* This project will implement on-screen annotation for OSM data overlaid on Marble, including mark and circle (i.e. drawing stuff on the map) and text annotation (taken together, it means you can draw a circle on the map and add a note saying what's wrong there).<br />
* Integration with UMPC stylus and on-screen keyboard input methods is needed.<br />
* Aggressive caching of Marble / OSM data in order to display it in the field is needed as well (compare Google Earth on an iPod).<br />
* Bonus points for optimizing for battery life.<br />
<br />
'''Mentor:''' Adriaan de Groot and Armijn Hemel. Touchscreen hardware might be provided on loan through the mentors.<br />
<br />
----<br />
<br />
'''Project:''' Marble - Routing<br />
<br />
Note from Marble author Torsten Rahn: I don't think that this project as a whole is feasible at this point. But choosing aspects as a GSoC project that are needed to get routing implemented in the future would be appreciated.<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/marble Marble] is a generic geographical map widget and framework that is meant to be used by KDE4 applications. It is also distributed as a standalone application in KDE4.<br />
<br />
'''Brief explanation:'''<br />
* Build on the inclusion of OpenStreetMap data in Marble.<br />
* Implement routing algorithms, ex. A*<br />
* implement a display of the route on the globe.<br />
* Optionally, show a list of roads and turns to get to destination.<br />
<br />
'''Expected results:'''<br />
Ability to chose start point, end point and type of transport (car, bike, foot <br />
etc.) and get a display of a route on the globe.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, knowledge of OpenStreetMap.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
<br />
==== Parley ====<br />
<br />
'''Project:''' Parley - Practice<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/parley Parley] is the vocabulary trainer that comes with KDE4. It is based on KVocTrain but has a much improved GUI. It allows to manage and exchange vocabulary collections that are stored in XML and provides advanced features, such as different practice modes.<br />
<br />
'''Brief explanation:''' The library and the GUI for editing vocabulary have been rewritten to a great extent. Now the thing that is still lacking is the most important part, the actual vocabulary practice. Based on QGraphicsView a nice practice dialog can be implemented, learning does not have to look boring.<br />
<br />
'''Expected results:''' A working practice which supports different modes of practice, ranging from multiple choice and written tests to conjugation and other grammar practices. Support for themeing is desireable.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, QGraphicsView, basic SVG knowledge.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
-----<br />
<br />
'''Project:''' Printing in Parley<br />
<br />
'''Brief explanation:''' Parley and some other KDE-Edu apps use a simple xml file format to store vocabulary data.<br />
This includes quite a bit of context information such as example sentences, word types, verb conjugations etc.<br />
The only way to print any of this information was so far to have a direct printout of the vocabulary list, containing only the words.<br />
Starting from xml it is reasonable to realize printing and even more by exporting to different formats.<br />
Using XSL to transform to html is one of the easiest way to achieve a good and flexible layout. More export formats could be added.<br />
Using this as a way to get multiple printing options would be a nice project.<br />
A flash card view (one vocabulary + optional context info per card), a list and more should be created at the users wish.<br />
<br />
'''Expected results:''' Configureable xsl/xslt transformation of the vocabulary data to at least html(+css) and maybe another format (pdf for example).<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, XSL(T). I can imaging learning XML/XSLT could be done during the project. A very basic example xsl file exists.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
-----<br />
'''Project:''' Parley - Advanced correction and grading<br />
<br />
'''Brief explanation:''' A bit of linguistic research is involved in this project.<br />
Evaluating language in a computer environment is close to impossible, so let's try what we can do anyways.<br />
I would like Parley to not only give feedback of the binary kind (your answer is right/wrong) but try to be a little more differenciated.<br />
How about offering the user to simply place the missing coma, wrong word order, add the accent he left out or hint at two mxied up letters?<br />
It would be possible to look at spell checking programs and other ways to know about the user input.<br />
Maybe the Levenshtein Distance algorithm is of help here? It would be interesting to have more research and an improved correction mechanism.<br />
<br />
'''Expected results:''' Design and implementation of a correction mechanism, that gives good feedback.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: some Qt, knowledge about languages, interest in research in that area.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
<br />
-----<br />
<br />
==== KStars ====<br />
<br />
'''Project:''' KStars: Millions of stars<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. Its display includes 130,000 stars down to 9th magnitude, which is well below the naked-eye limit, but inadequate for advanced purposes. <br />
<br />
'''Brief explanation:''' We would like to see KStars displaying millions of stars, without adversely affecting the program's responsiveness. Much of the infrastructure needed to accomplish this was implemented as part of the KDE-4.0 port, but the remaining work to make millions of stars a reality would be a nice SoC project.<br />
<br />
'''Expected results:''' Expanding the KStars database to include at least a million stars, while maintaining the current level of responsiveness. This will likely require asynchronous disk i/o to read in regionalized chunks of stars data, so that only the onscreen portion of the sky is loaded into memory.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, and probably Qt. Threaded programming a plus.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Prettyfication<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. The display is interactive, but it could be made more beautiful. <br />
<br />
'''Brief explanation:''' We often get good suggestions for making KStars look better. Choose any of the following ideas: realistic rendering of asteroids and comets (including tails!); texture-mapping of the sky (this would mostly allow a photorealistic Milky Way); texture-mapping of planets; realistic sky-lighting effects (i.e., sky is blue in the daytime, gets gradually darker and colorful at sunset).<br />
<br />
'''Expected results:''' Successful implementation of any of these ideas to make KStars more beautiful.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Printable star charts<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It already has a print feature, but the printed chart could be much better. <br />
<br />
'''Brief explanation:''' A printed star chart should at least include a legend explaining the symbols, and provide some information <br />
on the location of the user, the time and date, etc. The user would ideally be able to annotate the chart in various ways.<br />
<br />
'''Expected results:''' Significant improvements to the printed star charts in KStars.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic programming skills, ability to quickly learn QPainter API.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Many Moons<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It currently includes Earth's moon and 4 of Jupiter's moons. <br />
<br />
'''Brief explanation:''' Generalize the JupiterMoons class to encapsulate any planet's Moons. The project will require some research to identify a public source of orbital data for planetary moons, most likely from a NASA webpage. <br />
<br />
'''Expected results:''' Implement moons for at least Mars, Jupiter, Saturn, and Pluto with the new system.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. The project doesn't require much contact with Qt/KDE APIs, and the existing JupiterMoons class can be used as a template.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
==== Step ====<br />
<br />
'''Project:''' Step: 3d mode<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Implement physical simulation in 3d. This involves:<br />
* convert all classes in StepCore to templates with dimension as a template parameter, implement specialized versions where required, modify meta-object system to handle it<br />
* implement 3d mode in GUI: viewing and editing<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view 3d simulations in Step with the same set of objects as in 2d.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, basic OpenGL, basic physics (mechanics). Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: a game<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
The idea is to create a game based on physical simulation where the player have <br />
a fixed list of equipment (like springs, balls, cat and mice, teapot, etc.) and should use it to build a machine to achieve a given goal (for example put the ball in a basket, capture the mice, prepare a tea, etc.). The user places the equipment, than press Start button which starts physical simulation and if (in certain time limit) the goal is achieved the game is won. In the other case the user could try again. Similar projects: old game named "The Incredible Machine" and newer (but commercial) one named "Crazy Machines".<br />
<br />
The game can be implemented as standalone application using StepCore or as special restricted 'game' mode for Step (probably with tweaked graphics).<br />
<br />
'''Expected results:'''<br />
Playable game and several levels to test it.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, basic physics (mechanics).<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: simulation of chemical reactions<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1. This project also relates to [http://edu.kde.org/kalzium Kalzium].<br />
<br />
'''Brief explanation:'''<br />
Simulate some basic chemical reactions using classical molecular dynamics methods with empirical potentials. At first initial settings for simulation should be prepared by hand (as XML file), if there will be enough time an editor could be implemented too. This project involves:<br />
* convert required classes from StepCore to handle 3d simulations (you will need only several classes which are trivial to convert)<br />
* implement required objects and potentials in StepCore<br />
* implement GUI for observing the simulation (investigate the possibility to use avogadro library for visualization), GUI should also allow altering of some properties like masses and charges<br />
* prepare demonstrations of several common reactions<br />
<br />
'''Expected results:'''<br />
Chemical reaction viewer which could load predefined experiment, modify some basic properties and run the simulation. Prepared simulation for several common reactions.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, basic chemistry. Could be useful: Qt, basic quantum mechanics, knowledge of common molecular dynamics simulation techniques and numerical methods.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: fast water and gas simulation<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Currently Step has molecular dynamics based simulation of gas and water (that is a gas is simulated as a collection of particles). This is very usefull for demonstrating microscopical properties of the gas as well as its connection with macroscopical quantities like temperature. But this is far from optimal to demonstrate things like a boat floating in the water, water flowing from a glass, etc. This project involves:<br />
* investigate fast methods of simulating water and gas: ranging from molecular dynamics but with simplified potentials, various optimizations, coarse graining methods, to lattice Boltzmann methods; investigate existing libraries for water simulation (for example take a look at [http://elbeem.sourceforge.net/ elbeem] library from Blender)<br />
* implement selected method of simulation or incorporate selected library in StepCore<br />
* implement GUI in Step for creating and modifying macroscopical quantities of gas and watter<br />
<br />
'''Expected results:'''<br />
Ability to easily simulate in Step experiments like a boat floating in the water, water flowing from a glass, etc.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, numerical methods. Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: other ideas<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
These are smaller ideas related to Step. You can combine several of them to compose you project.<br />
* use KAlgebra library for parsing user-supplied expressions in PropertiesBrowser; allow value in Meter, x- and y-values in Graph to be arbitrary expression; implement ParametricForce object that will apply a force given by user-supplied expression; implement a series of ParametricJoint objects that will allow creation of various parametric constraints (like fixed particle trajectory)<br />
* scripting for Step using either QtScript or Kross<br />
* multi-threaded calculations in StepCore (knowledge pre-requisite: multi-threaded programming)<br />
* correctly handle stiff problems in StepCore (knowledge pre-requisite: numerical methods)<br />
* calculation of gravitational and electromagnetic force between non-point objects by integrating (knowledge pre-requisite: numerical methods)<br />
* make StepCore compilable without Qt<br />
* improve soft-body support: implement automatic creation of arbitrary-shaped soft bodies, better soft-body border handling, investigate better (more accurate) methods of modeling soft bodies (knowledge pre-requisite: physics)<br />
* support for non-convex polygons (probably by implementing triangulation)<br />
* optimize collision detection (AABB trees, etc.)<br />
* framework for dynamic object creation/destruction in order to allow implementing particle emitters<br />
* statistical models (for example prey/predator model)<br />
If you have other ideas please feel free to propose them !<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
==== RoxGT ====<br />
<br />
'''Project:''' RoxGT <br />
<br />
'''Project Information:'''<br />
RoxGT is a OSS done by Ugo Sangiori for building Graph-based applications. It aims essentially for academic jobs, such as graph algorithm execution and theorem proofs. <br />
<br />
'''Brief explanation:'''<br />
Rewrite the RoxGT, today it's written in Java as a Eclipse Plugin. This project aims to transform RoxGT into a full featured KDE4-Application, with all the benefits that Kross can give for the implementation of the algorithm execution in every language suported by Kross, and not only Java.<br />
<br />
Possibly integration of RoxGT in Marble, as a kparts to do things like 'shortest path between 2 points' when marble is used as GPS mode.<br />
Possibly integration of RoxGT in Umbrello, examining the UML and searching for design flaws into the Graph-generated UML.<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view simulations in graphical mode of Graph-Theory algorithm execution.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, Could be useful: Qt.<br />
<br />
'''Mentor:''' Looking for One.<br />
<br />
'''Student''' Tomaz Canabrava - tomaz <dot> canabrava <at> gmail <dot> com<br />
<br />
----<br />
<br />
=== KDE PIM (Personal Information Management) ===<br />
<br />
==== Kontact ====<br />
<br />
==== KOrganizer ====<br />
<br />
'''Project''': Beautiful month view<br />
<br />
'''Description''': The month view of KOrganizer has a long history, which is beginning to show, especially in terms of visually attractivity and performance. With KDE 4 and especially the latest versions of Qt 4 there is an unprecedented opportunity to add some beauty to this view. The goal of this project would be to create a new version of the month view which is able to display a month's worth of events in a beautiful, efficient and user-friendly way. This would include appointments, todos, multi-day events. In addition of a good display of events one could also think about advanced ideas like dynamical zooming of days, 3D indicators of categories or calendar associations, and more. There is a lot of room for creativity in this project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
==== KPilot ====<br />
<br />
==== KMail ====<br />
----<br />
'''Project:''' Message-View: Use more than one line per message<br />
<br />
'''Project Information:'''<br />
As known from other email-apps there is a use-case for having three panes next to each other. However the message-list is currently restricted to one line per message which makes it quite unuseable for that purpose. Thus a new view is needed.<br />
<br />
'''Knowledge Prerequisite:''' Qt Interview Framework<br />
<br />
==== Kleopatra ====<br />
<br />
Kleopatra is the KDE Certificate Manager. In KDE 4.1, it will have gained OpenPGP support (it originally comes from the X.509 world). It is currently being prepared to be integrated into the [[http://www.gpg4win.org GnuPG For Windows]] installer, too, and therefore needs to work in a size-reduced KDE environment (basically, kdecore and kdeui only).<br />
<br />
All of the Kleopatra projects naturally require familiarity with Qt, C++, and GnuPG/OpenPGP concepts.<br />
<br />
----<br />
'''Project:''' OpenPGP web-of-trust visualization<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement a mechanism to visualize the user's personal OpenPGP web of trust.<br />
<br />
'''Detailed Description:'''<br />
For a long time now, Kleopatra has had the ability to show a ''hierarchical view'' of the user's X.509 (aka. S/MIME, aka. CMS) keyring. Such a view lends itself naturally to X.509 certificates, whose trust model ''is'' hierarchical. Here, ''subjects'' (signees) are children of their respective issuers (signers) in a standard tree view, so that root certificates end up being top-level items.<br />
<br />
Naturally, this simplistic hierarchical view is hard to generalize to OpenPGP's Web-of-Trust (WoT) model where everyone may certify everyone else. It is the goal of this task to identify and implement such a generalized ''hierarchical view'' that fits this extended trust model.<br />
<br />
At least two views are obvious candidates (but this task is not restricted to only these):<br />
<br />
Extend the current X.509-type hierarchical view around the idea that my own key can be seen as my own personal ''root certificate'': Keys signed by me would be first-level children of my top-level key, and keys signed by those people would be second-level children, etc. The depth of a key in the item would be the same as that reported as <tt>depth</tt> in the output of <tt>gpg --check-trustdb</tt>. Problems with this approach include mapping a directed cyclic graph onto a tree for putting it into a tree view. Some people also have the opinion that the reverse of what is described here would be what users expect (rationale: <tt>gpg</tt> lists the signers below the signee in an <tt>--list-signatures</tt> operation).<br />
<br />
The second option is to use a graph visualization widget (to be found somewhere or written) that would allow to browse the WoT interactively. This ''might'' break the timeframe, but could be made into a more general component that can be used elsewhere if the project progresses exceptionally well.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a visualization tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* It should contain the X.509 case as a special subset.<br />
* It is easy to find the people I have signed.<br />
* It is easy to see the trust path between two certificates.<br />
* It is easy to see when such a trust path does not exist.<br />
With regard to Gpg4Win, the solution should fail gracefully in the absence of either the external tool, or KMail/Akonadi.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra. Graph visualization knowledge would help, too.<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
----<br />
'''Project:''' Keysigning Party Support<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement functionality to automate the challenge-response mail algorithm used after OpenPGP keysigning parties<br />
<br />
'''Detailed Description:'''<br />
Everyone that has been to a keysigning party has probably gotten a challenge mail to decrypt and send back afterwards. This is done in order to verify that the owner of the email address is also the owner of the (secret) key. This procedure is the basis for most OpenPGP Keysigning Policies, including the one from [http://www.math.uni-bielefeld.de/~mmutz/sign-policy.html#act your mentor].<br />
<br />
There are two ways to do this:<br />
* Interface with an already existing robot that is hooked into the local mail server, or<br />
* Interface with KMail/Kontact (or, if ready by then Akonadi).<br />
<br />
The second option is preferable, as it allows users with a normal desktop system to participate in the system. The first option would have to do a lot of user handholding for being usable enough for the target audience.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a OpenPGP challenge/response tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* Track sent challenges<br />
* Validate responses.<br />
* Alert the user when all responses necessary for a signing have been received.<br />
* Optionally, do this without user interaction.<br />
* Optionally, do this per user-id.<br />
* Deal gracefully with responses that are not forthcoming.<br />
With regard to Gpg4Win, the solution should also have no further external dependencies (mainly Qt, boost, kdelibs, kdeui, gpgme), but this is no hard requirement.<br />
<br />
Optionally, a MIME message format that facilitates the automatic handling of these challenge/response mail could be created and publicized.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
----<br />
'''Project:''' SSL CA Control Center<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an S/MIME Certificate Authority (CA) frontend for one or more free CA solutions.<br />
<br />
'''Detailed Description:'''<br />
While there is CA software available (e.g. OpenSSL and [http://www.mozilla.org/projects/security/pki/nss/ Mozilla NSS]), the command line tools are hard to integrate to get even a small CA running. This project is all about changing that.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented frontend for one or more X.509 CA software packages, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* Set up a new X.509 root certificate. Optionally: allow more than one root to be adminstered.<br />
* Allow to define any number of child CAs.<br />
* Allow to create new client certificates either ad-hoc, or from a PKCS#10 request.<br />
* Allow web- as well as mail certificates (or be flexible enough for doing both).<br />
* Allow to revoke and extend client certificates, and publish CRLs.<br />
* Be useable without much prior knowledge, prevent useless certificates.<br />
* Optional: KIOSK-enable the processes, so an admin can lock down certain aspects of them.<br />
With regard to Gpg4Win, the solution should also have no further external dependencies (mainly Qt, boost, kdelibs, kdeui, gpgme), but this is no hard requirement. It should use the command line tools instead of linking to the respective libraries (for stability, security, and licensing reasons).<br />
<br />
From a UI point of view, the operations shouldn't look much different from the respective OpenPGP ones.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra. Knowledge about CA software helps.<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
==== Akonadi ====<br />
<br />
Akonadi (http://kdepim.kde.org/akonadi/) is the framework for groupware and other PIM applications for KDE4.1 and later. <br />
<br />
----<br />
'''Project:''' Akonadi backend for Microsoft Exchange Groupware server<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an Akonadi backend to allow users to work with Microsoft Exchange servers and applications using compatible protocols (e.g. Outlook).<br />
<br />
'''Brief explanation:'''<br />
The implementation will almost certainly need to use the OpenChange (http://www.openchange.org) libraries. A proof-of-concept implementation has been done (available in KDE's SVN archive), but has bit-rotted as the OpenChange libraries have evolved. <br />
<br />
'''Expected results:'''<br />
A completed, and tested, backend that can operate with a current Microsoft Exchange server. Important capabilities include:<br />
* ability to receive mail,<br />
* ability to create and receive appointments, and to view the calendar,<br />
* ability to access the address book, and<br />
* ability to create and receive tasks.<br />
<br />
Sending mail is outside the scope of Akonadi, and is a "growth" potential if the project is proceeding particularly well.<br />
<br />
'''Knowledge Prerequisite:''' You need to have some familiarity with groupware applications (e.g. knowledge of how appointments and address books are used). C and C++ is pretty much essential, and at least passing knowledge of Qt. <br />
It would be useful (but not absolutely essential) if you had access to a Microsoft Exchange server you can use for testing - we may be able to arrange access.<br />
<br />
'''Mentor:''' Optional, possibly Brad Hards <bradh@kde.org><br />
<br />
----<br />
<br />
'''Project:''' Akonadi testing framework<br />
<br />
'''Project Information:''' Akonadi uses helper processes, called Agents, to do the actual processing of PIM data, e.g. transfer from/to an external storage.<br />
Agent functionality can depend on operations on the Akonadi store performed by other participating processes (Agents and/or clients), e.g. updating an external storage when a user application applies changes to PIM data.<br />
<br />
'''Brief explanation:''' In order to test such a setup automatically or semi-automatically, a testing framework needs to provide the following items:<br />
* means to launch Akonadi in a defined state, e.g. by restoring a data base dump<br />
* means to start a certain set of Agents<br />
* means to trigger changes on Akonadi's data<br />
* means to check the resulting state of Akonadi<br />
<br />
'''Expected results:'''<br />
* tools or test templates for developers to create and run test scenarios, probably using a scripting language like Python or Ruby.<br />
* example test scenarios for at least one agent and one resource<br />
<br />
'''Knowledge Pre-Requisite:''' An understanding of the concept of collaborating services, knowledge how to setup shell environments<br />
<br />
'''Mentor:''' Kevin Krammer <kevin.krammer@gmx.at><br />
<br />
----<br />
<br />
'''Project''': Akonadi Resouce: GroupDAV<br />
<br />
'''Description''': [http://www.groupdav.org/ GroupDAV] is a standard protocol to access groupware servers. It's for example implemented by [http://www.opengroupware.org OpenGroupware.org] or [http://www.citadel.org Citadel]. The task of this project is to create a native [http://pim.kde.org/akonadi Akonadi] resource to provide access to GroupDAV enabled servers to all KDE applications, in particular the KDE PIM suite. There is an existing KDE 3 based KResource supporting GroupDAV which could be used as a starting point.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Calendar<br />
<br />
'''Description''': Googgle Calendar provides an API to access the calendar data on the server. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource, so that any accessible Google calendar can be displayed and edited in Akonadi enabled applications, e.g. in KOrganizer.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Contacts<br />
<br />
'''Description''': Googgle recently has opened their [http://code.google.com/apis/contacts/ Google Contacts Data API]. This makes it possible to access the contacts data which is stored at Google, e.g. for GMail. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource to access contact data stored at Google, so that it can be displayed in Akonadi enabled applications, e.g. in KAddressbook.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Facebook friends and events<br />
<br />
'''Description''': Facebook has an [http://wiki.developers.facebook.com/index.php/API API] that can be used to query a user's friends and information about these. The API also gives access to a user's events. The aim of this project is to implement an Akonadi resource to access contact data stored on Facebook for a user's friends, and also give access to a user's events in Akonadi so that this information can be used in KOrganizer and KAddressbook.<br />
<br />
'''Mentor''': <br />
<br />
Note that there already is [http://websvn.kde.org/trunk/playground/pim/kfacebook/akonadi/ an implementation].<br />
<br />
----<br />
<br />
'''Project''': Akonadi Agent: PIM Data Mining<br />
<br />
'''Description''': PIM data usually contains a lot of related PIM data in some explicit or implicit form. Emails contain contact data as sender or recipients or as part of the signature. Emails also can contain calendar data, e.g. when sending groupware invitations or just by mentioning a date as part of an informal mail about getting together for a beer. The goal of this project is to implement an [http://pim.kde.org/akonadi Akonadi] agent which transparently collects all this information in the background and makes it available to the user e.g. as a special address book ("Email addresses of people to whose emails I answered on a mailing list", etc.). There are many interesting options what and how to implement this and part of the project would be to investigate, what makes sense to be collected and which methods are best suited to get the most useful information from the available raw data.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
'''Project:''' Akonadi backend for .pst files<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an Akonadi backend to allow users to at least read, and possibly write, information from personal storage (.pst) format files.<br />
<br />
'''Brief explanation:'''<br />
Users migrating from Microsoft Outlook often have a lot of information embedded in .pst files - archived mails, calendars, journal entries, and sometimes contacts.<br />
<br />
There are existing libraries to work with this format (e.g. libpst) but I'm not aware of any that do writing. Also note that the .pst format changed - there are two different versions. <br />
<br />
'''Expected results:'''<br />
A completed, and tested, backend that can operate with a both of the .pst formats. Important capabilities include ability to retrieve mail, calendar entries and contact entries. It would be useful to be able to write as well.<br />
<br />
'''Knowledge Prerequisite:''' You need to have some familiarity with groupware applications (e.g. knowledge of how appointments and address books are used). C and C++ is pretty much essential, and at least passing knowledge of Qt. <br />
You would need some way to create test files - almost certainly some version of Outlook, and it would be useful if you had real-world experience with creating and using .pst files.<br />
<br />
'''Mentor:'''<br />
<br />
----<br />
<br />
=== KDE Games ===<br />
<br />
'''Project''': Polytris clone<br />
<br />
'''Description''': Polytris is an old DOS game based on the Tetris concept. Its unique feature is that the number of blocks a piece is build from isn't fixed to four as in the original Tetris, but that it's variable. There are the simple one block pieces which fit everywhere, but there are also the challenging ten block pieces, which provide a complex setting which then has to be filled with other pieces. Difficulty of the game increases over time not by letting pieces fall faster, but by increasing the average number of blocks the pieces are constructed of.<br />
<br />
The task of this project is to create a KDE 4 version of this game. In addition of implementation of the basic game functionality extra credits are given for great playability, beautiful appearance, and a creative and motivating scoring scheme.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KDE Development & Web Development ===<br />
<br />
==== Kompare ====<br />
<br />
'''Project Information:'''<br />
[http://www.caffeinated.me.uk/kompare/ Kompare] is a graphical difference viewer.<br />
<br />
-----<br />
'''Project:''' Semantic diff<br />
<br />
'''Brief explanation:'''<br />
Implement a plugin-based approach for different (potentially incomplete) diff-algorithms. Documents are not just lines of text, but have semantics, and these plugins should help to see changes made to the document.<br />
<br />
Possible plugins are:<br />
* File information diff: show date, size, last-modification, ...<br />
* Programming language diff: detect changes like renamed variables, reindentation, namespace-changes, changes in comments, other refactorings ... (the more the better)<br />
* XML-diff<br />
* Latex-diff: whitespace is ignored.<br />
* config-file diff: in many config-files the order does not matter.<br />
* Image diff: at least show both images next to each other.<br />
* Video diff: show both videos next to each other and link their time. Should be interesting for diffs after reencoding.<br />
<br />
'''Expected Result:'''<br />
A native and Kross (for scripting) plugin-support for Kompare. Some of the above mentioned plugins.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Knowledge of C++.<br />
<br />
Comment: I think one of the most obvious applications of this is in SVG: it would be possible to graphically show the original image + new_rect merged as new_image fairly easily. You could even make elements transparent, and show them in steps, with onion-skinning, almost animating from previous version to new version. I'd also really like to see this "semantic-diff" for ODF documents.<br />
<br />
----<br />
<br />
==== KLinkStatus ====<br />
<br />
'''Project Information:'''<br />
[http://klinkstatus.kdewebdev.org/ KLinkStatus] is a link checker, part of the kdewebdev module.<br />
<br />
-----<br />
'''Project:''' Aided correction of broken links<br />
<br />
'''Brief explanation:'''<br />
Currently, it is possible to find out broken links but it is not possible to fix them. It would be great if those links could also be corrected within KLinkStatus. The corrector should present the user with sugestions, like a spell checker does (it might be possible to reuse some of the KSpell heuristics). Possible errors are typos in domain and paths, absolute vs relative path, and wrong directories.<br />
<br />
'''Expected results:'''<br />
Ability to fix broken links, being effectively assisted with suggestions.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' Site check automation<br />
<br />
'''Brief explanation:'''<br />
KLinkStatus already provide a D-Bus interface that allows to check sites in the background based on a configuration file and then export the results to HTML. A system administrator can already automate check using cron jobs. However it would be nice to offer a nice frontend inside KLinkStatus (without the need of super user permissions). The results could then be exported into files and/or emailed to the site administrator.<br />
<br />
'''Expected results:'''<br />
Easy site check automation and notification system.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' HTML validation<br />
<br />
'''Brief explanation:'''<br />
HTML validation is a very requested feature by users. KLinkStatus already have the infrastructure for this, using libtidy, but some work is still missing in order to actually correct the HTML documents. <br />
<br />
'''Expected results:'''<br />
- Visual indication of which document have HTML validation problems<br />
- Ability to fix individual documents or several documents at a time <br />
- Ability to efectively preview, compare (perhaps using the Kompare kpart) and edit partial parts of a document<br />
- Configurable HTML validation parameters<br />
<br />
'''Knowledge Pre-Requisite:''' HTML, some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ and, for some parts of it, a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
==== KDevelop ====<br />
'''Project Information:'''<br />
[http://www.kdevelop.org/ KDevelop] is the Integrated Development Environment from KDE. If you have something you'd like to see in KDevelop4 don't hesitate to write up your proposal or come to our developer list and discuss it with us.<br />
<br />
'''Project:''' Distribution integration<br />
<br />
'''Brief explanation:'''<br />
Integration of the build-system of one specific distribution into KDevelop. Usually it is quite easy to get the source-code of a package and build it, for example using "apt-get source" and "dpkg-build" under debian, or "osc" under openSUSE.<br />
<br />
'''Expected results:'''<br />
A user can start KDevelop, and choose a package from a list that should be retrieved from some distribution repository. Then KDevelop would download the source-package and create a project-directory+file into which all the necessary information is extracted, inluding a copy of the original project source that can be edited from within KDevelop. The developer can edit the source with code-completion, -navigation, and all the nice extras out of the box. Then the developer can build the package using the distribution-specific mechanisms, with the own changes to the source-tree are included as a patch.<br />
One of the most tricky things here would be providing KDevelop with correct include-path information for all the source-files. A simple hack to retrieve include-paths from existing makefiles is already implemented within KDevelop, and can be re-used. An additional bonus could be management of multiple separate patches on top of the source-tree, that can easily be submitted upstream.<br />
It would be nice if all the stuff could be implemented in a way that it's easy to add support for other Distributions.<br />
<br />
'''Knowledge Pre-Requisite:'''<br />
C++, package-building experience for a popular distribution(Maybe openSUSE or Ubuntu/Debian)<br />
<br />
==== Quanta ====<br />
<br />
=== KDE Network ===<br />
<br />
==== KRDC ====<br />
<br />
Add NX support to KRDC.<br />
<br />
-----<br />
'''Project:''' NX support in KRDC.<br />
<br />
'''Brief explanation:'''<br />
KRDC lacks NX support, which is gaining momentum in the free software world. Build upon the work done by George Wright in the 2006 SoC and the work done by Urs Wolfer in the 2007 SoC to create a top quality NX client for KDE.<br />
<br />
'''Expected results:'''<br />
Fully working NX integration for KRDC, including support for advanced NX features such as sound, VNC/RDP tunnelling etc. Feature parity with the commercial NX client shouldn't be necessary, but aiming for that isn't a bad idea. All NX connection handling code should be in the cross-platform client library nxcl (C++/STL/autotools), and all GUI specific code should be in KRDC.<br />
<br />
'''Knowledge Prerequisites:''' Knowledge of the NX protocol (see http://www.gwright.org.uk/protocol.pdf for an older version of the protocol), C++/STL/Qt/KDE coding and cross platform coding.<br />
<br />
'''Resources:''' http://freenx.berlios.de , http://blog.gwright.org.uk/articles/category/nx , http://nomachine.com/ , http://svn.berlios.de/wsvn/freenx<br />
<br />
'''Mentor:''' George Wright <gwright at kde dot org><br />
<br />
==== Decibel ====<br />
<br />
Decibel is a realtime communication framework for KDE 4.x.<br />
<br />
----<br />
<br />
'''Project:''' KDE4 integration<br />
<br />
'''Brief Explanation:''' Decibel should integrate well with the KDE 4 environment. This includes getting contact data from Akonadi and storing contact state there, storing account data in KWallet as well as integration with Nepomuk to store semantic information on connections made.<br />
<br />
'''Expected Results:''' A working and tested implementation of integration components.<br />
<br />
'''Knowledge Prerequisites:''' A good overview of the involved KDE 4 technologies is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/, Akonadi documentation<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Filtering framework for text messaging<br />
<br />
'''Brief Explanation:''' Text message that are passed to applications using the Decibel framework should get filtered. This includes processing steps (like processing of Off the record messages) as well as logging, etc. This filtering framework needs to be made more flexible as it currently is and some basic filters need to be written.<br />
<br />
'''Expected Results:''' The filtering API of Decibel is improved and sample filters are developed and tested.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Improve Telephony features<br />
<br />
'''Brief Explanation:''' Decibel currently has limited support for telephony features required for VoIP integration. This support needs to be improved and missing features (call forwarding, conferencing, etc.) should be implemented.<br />
<br />
'''Expected Results:''' A VoIP backend based on the existing telepathy backend with the additional telephony features implemented.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required. Familiarity with the telepathy spec and VoIP is helpful.<br />
<br />
'''Resources:''' http://decibel.kde.org/, http://telepathy.freedesktop.org/spec.html<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
==== Kopete ====<br />
'''Project:''' Integrate Decibel and Kopete<br />
<br />
'''Brief explanation'''<br />
Add support for Decibel to Kopete. This will involve some a lot of work within the Kopete core library (libkopete) in addition to making all the current protocol implementations into Telepathy Connection Managers. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
'''Note:''' This is an advanced project. The proposal will need to be very detailed and very complete. Basically, you need to show that you've done your homework, so to speak. The student will also need to be able to work closely with his/her mentor and the rest of the Kopete developer community by being available on IRC and being subscribed to the Kopete mailing list. <br />
<br />
'''Mentor:''' Matt Rogers<br />
<br />
'''Project:''' Jabber voice- and video-chat support<br />
<br />
'''Brief explanation'''<br />
Add suport for Jabber/Google Talk video chat to Kopete and Decibel.<br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
'''Project:''' Advanced custom media support<br />
<br />
'''Brief explanation'''<br />
In MSN, it's great fun for many people to collect individual animated emoticons and use them during the chat, and to trigger funny animations over the whole chat window. Also it is confusing for newbies when they send a message with an own emoticon, and it apears on the other side with no or another one. So at least the custom emoticon feature would be very nice. What probably needs to be done:<br />
- Implement simple management of a custom set of emoticons that can be added one by one. When someone else uses an emoticon, it should be possible to right-click it, and save it to the own collection.<br />
- Implement support for sending custom emoticons through jabber, and as many other protocols as possible that support this feature. For MSN, I think it's already implemented.<br />
- If time allows, implement sending of custom flash animations, that are played back using gnash, and allow downloading new animations through GetHotNewStuff.<br />
These features would make Kopete even more interesting to a wider less-purist audience.<br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
----<br />
<br />
=== Amarok ===<br />
Consider these suggestions a starting point to create your own proposal. Some need more detail. Please contact us and let us help you with the proposal before submitting. Find us on IRC on [irc://irc.freenode.net/amarok irc.freenode.net #amarok] or email the public mailing list [mailto:amarok@kde.org amarok@kde.org].<br />
<br />
-----<br />
'''Project:''' CD Stack collection view<br />
<br />
'''Brief Explanation:'''<br />
In iTunes you might have seen the very fancy view with albums flying by very prettily and not very usefully. Now, imaging instead that you have a stack of CDs in a tower. You scroll up and down through it, take one out, and open it to see what tracks are on it. A mockup of this idea can be found here: [http://leinir.dk/temp/gallery/mockups.php?gallery=mockups&image=mockups/cd-stack-in-glorious-pen-o-vision.jpg CD Stack]. Qt has a Model/View system that allows multiple views to the same data. This project would be a new view on the current collection browser. It could be implemented in 3D using OpenGL or using the pseudo-3D techniques that projects like Marble use.<br />
<br />
'''Expected Results:'''<br />
A working (not necessarily polished) implementation of such a CD stack interface, most preferably Model/View based.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, and while experience with Qt (and QGV) is nice it is by no means required, as it can be learned relatively easily. OpenGL and/or 3D programming helpful.<br />
<br />
-----<br />
<br />
'''Project:''' Context View development and Applet writing<br />
<br />
'''Brief Explanation:'''<br />
The Context View is one of the most visually evident features of the new Amarok 2. It takes up the middle part of the Amarok window and provides a view into the information about the song that a user is playing. As such, it is essential to Amarok that the Context View be functionally pleasing, polished, and pretty.<br />
<br />
A project focused on the Context View would consist of mainly continuing development on the CV itself, completing features that are planned but have not yet been implemented, as well as writing new Applets and DataEngines to display further data.<br />
<br />
'''Expected Results:'''<br />
A Context View that uses libplasma to provide an Amarok-specific way of viewing current data in a beautiful and innovative form. The basic structure and architecture is already there, but it needs substantial work to complete.<br />
<br />
Also, time permitting, the development of new applets and data engines for Amarok's CV.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, but this is probably a less KDE project as others. Experience with Qt is nice but by no means required, as it can be learned relatively easily.<br />
<br />
'''Mentor:'''<br />
Leo Franchi (lfranchi) is the original author of the Context View (in Soc 2007) and is willing to mentor any interested student. He can be contacted on #amarok at irc.freenode.net or (better) at lfranchi AT gmail DOT com.<br />
<br />
-----<br />
<br />
'''Project:''' Nepomuk collection<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a plug-in system that allows it to access music metadata from various backends. A plug-in to read and write data to and from Nepomuk should be written in this project. Additionally, Amarok should be extended to make real use of Nepomuk's capabilities by re-adding labels support.<br />
<br />
'''Expected results:'''<br />
A plugin to use Nepomuk as a metadata store from Amarok. Additionally, support for labels should be added to Amarok 2.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE would be helpful<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
-----<br />
<br />
'''Project:''' UPnP Support<br />
<br />
'''Brief explanation:'''<br />
Using the UPnP protocol users can, for example, share music from their Vista computer to a PS3. Amarok lacks any sort of UPnP support. Being able to act as a client (the PS3) or possibly a UPnP media server (Vista) would be useful. See [http://pupnp.sourceforge.net/ libupnp] for more information about UPnP's implementation in open source. The nature of how UPnP works would need to be researched a bit more, as the creator of this idea (Ian Monroe) has only seen it in use on friends computers. :)<br />
<br />
'''Expected results:'''<br />
*Using either Amarok's Internet Service framework or the straight Amarok collection framework, create a plugin which allows Amarok to browse and play music off of a UPnP share. Playing music may require the creation of a KIO for UPnP.<br />
*Allow Amarok to share it's collection with other devices via UPnP. This is secondary priority and may not be feasible to accomplish during Summer of Code.<br />
<br />
'''Material Prerequisite:''' Some UPnP devices or computers to test with.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and networking would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
-----<br />
<br />
'''Project:''' Amarok Scripting<br />
<br />
'''Brief explanation:'''<br />
Starting with Amarok 1.2, Amarok has enabled scripting through a script manager and its DCOP interface. For Amarok 2 we have a straight port of the old DCOP API to DBus. The old API was created over time, and perhaps could be thought out better. Additionally KDE 4 has introduced technology like Kross that could allow true integration of scripts into Amarok, including GUIs. In-process scripting has its own issues though!<br />
<br />
'''Expected results:'''<br />
*This is a more open-ended idea. Contact the Amarok mailing list or on IRC to get help working out the proposal.<br />
:*Perhaps redesign the Amarok DBus API <br />
:*..and/or add a Kross interface and then <br />
:*Create a script showcasing the technology.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and Ruby would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
<br />
-----<br />
<br />
'''Project:''' CD Ripping<br />
<br />
'''Brief explanation:'''<br />
Amarok has never really felt a need for good CD ripping support. We always felt there were better programs suited for this task. This hasn't stopped folks from finding ways to use Amarok to rip their CDs though. ;) <br />
<br />
'''Expected results:'''<br />
*An excellent CD ripping solution integrated into Amarok. <br />
*Cross-platform (Linux, Mac, Windows)<br />
*This task is not too large, so there would be higher standards of polish.<br />
<br />
-----<br />
<br />
'''Project:''' Mass-tagging<br />
<br />
'''Brief explanation:'''<br />
Users sometimes have poorly tagged tracks. Amarok has always lacked an easy way to download information about tracks from FreeDB or Musicbrainz and then tag multiple tracks at once.<br />
<br />
'''Expected Results:'''<br />
*To bring the functionality of programs like EasyTag or [http://musicbrainz.org/doc/PicardQt PicardQt] into Amarok.<br />
*A creative UI to accomplish the goal<br />
<br />
-----<br />
<br />
'''Project:''' Playlist and Playlist browser<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a snazzy new playlist, though its code could use some refactoring to take advantage of Qt 4.4 features. Also it is missing features from 1.4.<br />
<br />
'''Expected Results:'''<br />
*Mass inline tag-editing in the playlist (like in Amarok 1.4)<br />
*Allow users to pick which fields are shown<br />
*Dynamic playlist and smart playlist support<br />
*Improve memory management for large playlists<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential and knowledge of Qt is nice, experience with Model/Views in Qt is a bonus<br />
<br />
'''Mentor:'''<br />
Ian Monroe and other Amarok developers. <br />
<br />
----- <br />
'''Project:''' Media Devices as Collection Provider<br />
<br />
'''Brief explanation:'''<br />
Media device support is very important in a modern media player due to their widespread popularity. Media devices haven't found much love in Amarok 2 development. Amarok 2 has a flexible collection system, that was designed in part with media devices in mind. Whereas in Amarok 1.4 the collection was solely local files so the Collection Browser could only show local files. In Amarok 2 collections have been abstracted, allowing sources from the Internet and ''with this project'' media devices as well.<br />
<br />
'''Expected Results:'''<br />
*Integrate the media device framework into Amarok 2.<br />
*Support at least one kind of media device, while having the framework available for others.<br />
<br />
'''Material Requirements:'''<br />
A media device to test with.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, KDE.<br />
-----<br />
<br />
'''Project:''' Mp3tunes.com service synchronization<br />
<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an mp3tunes locker. This will allow us to use Amarok 2 for managing the mp3tunes locker as well as provide a framework for backing up all local content.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an mp3tunes locker as well as downloading content from the lock er to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the basic mp3tunes service . He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Ampache service synchronization<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an Ampache server. This will allow us to use Amarok 2 for managing the collection on the Ampache server. This will be a cross project task as the Ampache API used by Amarok 2 does currently not support uploading of content. There is great communication between the 2 projects, and the original Ampache API was developed in collaboration with Amarok developers.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an Ampache server as well as download content from the server to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the Ampache service. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Add new service<br />
<br />
'''Brief explanation:'''<br />
Add support for a new online service to the Amarok 2 service framework. This is a project that requires a student that already has a good idea or contacts with an interested service. Getting added to Amarok will mean that the service will have itself and its contents made available to a potentially huge new audience, and Amarok user will enjoy having access to even more great content. Ideas for services ( just to throw something out there ) could be the internet archives collection of live recordings, remixes from ccmixter.org, or something similar<br />
<br />
'''Expected results:'''<br />
Being able to play content from the service directly within Amarok. Depending on the type of service, downloads or purchasing of content might also be possible, as might other features unique to the service.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and many of the services. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----<br />
<br />
=== Digikam ===<br />
<br />
'' Project:'' Nepomuk integration<br />
<br />
''' Project Information:'''<br />
Integration between Digikam and Nepomuk could allow the user to better organize his/her pictures and access them easily from other apps, or even from other computers as Nepomuk is a networked system.<br />
<br />
'''Brief explanation:'''<br />
Nepomuk could allow the user to organize the pictures in a finer way : Nepomuk allows the user to define properties on his picture, extending the usecases of standard metadata (XML/IPTC/XMP...). The user can add any property under the form subject - predicate - object. Think of it as finer grained tags. You could for example define the predicate "is on the picture" to list all the people present on it (facebook does that). In a larger scope, the user can link picture to any resource known by Nepomuk (project, meetings...).<br />
<br />
The other advantage is that Nepomuk stores the information in a central index, which means that it can easily be accessed by other apps (I think of Akonadi). This allows tighter integration, as OS X does in its latest version with the iPhoto library.<br />
<br />
----<br />
<br />
=== Okular ===<br />
<br />
''Project:'' Okular backend<br />
<br />
'''Project Information:'''<br />
Okular has plug-in system that allow it read different documentation formats. It currently reads a range of formats, but there are several that might be able to be improved (e.g. XPS) or implemented.<br />
<br />
'''Brief explanation:'''<br />
The project would need to identify a format that requires improvement (or implementation). Candidates that have been requested in the past include the Microsoft Word (.doc) format and the .lit e-book format. Given a suitable library, potentially any format could be considered. Consider:<br />
* Microsoft Visio<br />
* Microsoft Access snapshot (would require implementing a .emf file renderer - not simple, but could be useful in many other places in KDE).<br />
<br />
Note that improving PDF requires changes to the poppler library, and you would need significant previous experience with PDF (and ideally with poppler) to make much progress.<br />
<br />
'''Expected results:'''<br />
A working backend, capable of rendering most documents to a readable level. <br />
<br />
'''Knowledge Prerequisite:''' C++ is pretty much essential, and at least passing knowledge of Qt. C programming experience may be useful for some libraries.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the okular mailing list.<br />
<br />
=== K3b ===<br />
<br />
'''Project:''' Port K3b to libburnia libraries<br />
<br />
'''Project Information:''' K3b currently uses cdrtools/cdrkit. This project should rewrite k3b to take advantage of three libburnia libraries - libburn, libisofs, libisoburn.<br />
<br />
'''Expected results:''' Experimental K3b branch with dropped support for cdrtools/cdrkit, and k3b features provided on top of libburnia libs backends.<br />
<br />
''trueg: I do not support the idea of dropping cdrecord integration. K3b already supports different backends. This architecture should be extended.''<br />
<br />
'''Contact for more information:''' mario AT libburnia-project DOT org<br />
<br />
'''Mentor (volounteer): Sebastian Trueg <trueg@k3b.org>'''<br />
<br />
=== Other applications ===<br />
<br />
==== Application User Interface Test System ====<br />
<br />
There are a couple of tools available for Qt / KDE that allow testing of applications - squish and kdexecutor. Both are binary only, and are specific to the systems that they are built on. <br />
<br />
It would be useful to have an open source tool that allowed us to test applications in a scripted way. Similar open source tools include Dogtail and LDTP, which use the accessibility interfaces in Gnome. <br />
<br />
There are arguments for and against using accessibility - it might be a lot more useful to implement a separate system, using some of the Qt4 specific features including QMetaObject. Qt4 has a nice set of hooks, and QTestLib shows how they can be implemented. However instead of requiring specific code in the application (as done by QTestLib), it would be more flexible to use LD_PRELOAD and a small interface library. <br />
<br />
More discussion: Brad Hards <bradh@kde.org><br />
<br />
==== (Multiple) image printing application ====<br />
<br />
This idea comes from my father, who is missing this kind of feature he was using in Paint Shop Pro. He says that there it was possible to open many images and when you selected them for printing the application would present you with a paper page, onto which you could drag the images, which were presented on a panel on the left side of screen. You could then interactively position and resize images on the paper and so see how the page look like when printed. There were also special functions available which would automatically resize and position the images.<br />
<br />
This application could also have a feature added to make it easier to print one image onto multiple pages (think posters). Here you could select how many pages of what size there should be and how many space on each page would overlap so you could glue the pages together after printing.<br />
<br />
I think it would be nice to also find a way to integrate such an application with imageviewer like Gwenview and photo management app like DigiKam.<br />
<br />
=== Usability ===<br />
<br />
The KDE Usability Project is willing to offer support mentoring to one or two projects (more if additional design mentors are available) which involve heavy UI development or UI redesign activities.<br />
<br />
=== Infrastructure ===<br />
<br />
KDE infrastructure tools, like Bugzilla, the Review Board, etc.<br />
<br />
=== KDE dependencies and non-KDE projects ===<br />
<br />
Depending on the relevance of the proposal, the KDE Project will accept student proposals on projects that are not part of KDE, but which are either KDE dependencies or relevant to KDE or the Free Software Desktop.<br />
<br />
==== Qt Cryptographic Architecture ====<br />
<br />
The Qt Cryptographic Architecture (QCA) isn't strictly part of KDE, however it is used in a range of KDE applications (and other applications). <br />
A range of projects are possible, in terms of adding security features to applications (e.g. SASL, encrypted content, client side puzzles). <br />
<br />
A specific need is the provision of alternative backends, which are typically the interface between QCA and some underlying crypto library. We already have several, but only the OpenSSL one is fairly complete, and OpenSSL is pretty ugly. A new backend would require some previous crypto knowledge, and ability to program in C++ and C. No GUI experience required! We probably only need one good alternative on each platform.<br />
<br />
- '''Alternative backend - GNU crypto libraries''': We have a basic backend using libgcrypt, which is mostly working. However a lot of the more interesting capabilities are present in gsasl and GNUtls. <br />
Mentor: Brad Hards <br />
<br />
- '''Alternative backend - Mozilla Network Security Services''': The Mozilla project has a library that is separately packaged on most Linux systems. It offers a fairly complete alternative to OpenSSL. We have a basic skeleton for NSS, but it only offers a couple of basic crypto primitives.<br />
Mentor: Brad Hards<br />
<br />
==== Strigi ====<br />
<br />
Strigi [1] and Pinot [2] are desktop search tools for the Linux and<br />
free Unix desktop. While targeted at different desktop environments,<br />
they have a history of collaboration, for instance on parsers for the<br />
Xesam query languages [3].<br />
<br />
Their features list overlap significantly as both projects offer most<br />
of the functionality users expect of desktop search systems.<br />
<br />
Both projects are written in C++ and feature an abstraction layer that<br />
makes them backend independent, though both only have one fully<br />
functional backend. Strigi's backend of choice is based on CLucene [4]<br />
while Pinot's is based on Xapian [5].<br />
<br />
This proposal is to bring this collaboration one step further by<br />
allowing them to use each other's indexing and search backends.<br />
<br />
Benefits include :<br />
* better abstraction layer for each project<br />
* wider testing of the respective back-ends<br />
* more choice to these projects' users<br />
* ease of evaluating and comparing CLucene and Xapian strengths and weaknesses<br />
<br />
The goal of project is to let Strigi use Pinot as a backend and vice<br />
versa so that both can query each others interfaces using<br />
the Xesam query language, and whatever query language is native<br />
to the backend.<br />
<br />
The emphasis is on completeness of querying. Performance optimizations<br />
and support for writing are secondary.<br />
<br />
[1] http://strigi.sf.net/<br />
[2] http://pinot.berlios.de/<br />
[3] http://www.xesam.org/<br />
[4] http://clucene.sourceforge.net/<br />
[5] http://www.xapian.org/<br />
<br />
==== Soprano & Nepomuk ====<br />
<br />
'''Project: Full Featured Query API'''<br />
<br />
'''Description''':<br />
For powerful semantic queries on the desktop we need a powerful query API. At the moment we are restricted to SPARQL queries which are then parsed by the Soprano backend. It would be much more efficient and easy to use if we had a query API that allowed to represent queries (independent of any query language) using a class structure. Queries could then easily be created, manipulated, and translated. Application developers would not have to learn a specific query language but would create a query object and have Nepomuk/Soprano evaluate that.<br />
<br />
This query API would become part of the official Soprano API and replace the simple Soprano::Model::executeQuery interface we have now.<br />
<br />
'''References:'''<br />
* Implementation of something similar in Java: http://sparql.sourceforge.net/<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
<br />
==== D-Bus ====<br />
<br />
* a named pipe or shared memory transport implementation for win32<br />
<br />
* can QLocalSocket and QSharedMemory (in 4.4) be used?<br />
<br />
==== APOC ====<br />
<br />
'''Project: KDE (KConfig) integration with APOC'''<br />
<br />
'''Project Information''':<br />
<br />
APOC (http://apoc.freedesktop.org) is a framework for centralized (e.g. in LDAP) storage and management of application and desktop configuration. It has integrations with the GNOME configuration system (gconf) and various desktop-independent applications (OpenOffice.org, firefox, Java). <br />
<br />
This project is to integrate APOC with KConfig so that KDE application preferences can be managed as well.<br />
<br />
APOC is also proposing another, different GSOC project using [http://live.gnome.org/SummerOfCode2008/Ideas GNOME as mentoring organisation].<br />
<br />
'''Knowledge Prerequisites''': <br />
* C++ coding <br />
* XML knowledge <br />
* KDE coding and configuration experience helpful<br />
<br />
'''Expected Result:'''<br />
* A documented mapping of KConfig preference structure onto the APOC file format.<br />
* A working KConfig backend that reads data from APOC<br />
<br />
'''Contact''': <br />
<br />
APOC is discussed on the [http://lists.freedesktop.org/mailman/listinfo/apoc apoc mailing list] (apoc@lists.freedesktop.org) and on the #apoc channel at irc.freenode.net.<br />
<br />
'''Mentor''': <br />
[mailto:joerg.barfurth@sun.com J&ouml;rg Barfurth]<br />
<br />
==== PolicyKit ====<br />
<br />
'''Project: PolicyKit Integration for KDE'''<br />
<br />
'''Description''':<br />
PolicyKit is a toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems.<br />
<br />
'''Expected results:'''<br />
* Provide a D-Bus session bus service that is used to bring up Qt/KDE authentication dialogs used for obtaining privileges.<br />
* Exemplary integration of PolicyKit within KDE (eg changing system clock from System Settings/clock plasmoid)<br />
* Write a Qt/KDE frontend to manage privileges<br />
<br />
'''References:'''<br />
* Specification: http://people.freedesktop.org/~david/polkit-spec.html<br />
* http://hal.freedesktop.org/docs/PolicyKit-gnome/<br />
<br />
'''Mentor:'''<br />
<br />
==== Other Freedesktop.org initiatives ====<br />
<br />
Both KDE and Gnome have previously acted as mentor organisations for projects that are under the Freedesktop.org umbrella. If you want to do a cross-desktop project, you can consider submitting it to one (or more) organisations. This is one case where you almost certainly want to have a mentor identified before you submit.<br />
<br />
If you submit to more than one organisation, please note which organisations you have submitted it to (since KDE has to coordinate with the other mentoring organisations).</div>Zwabelhttps://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas&diff=22417Projects/Summer of Code/2008/Ideas2008-03-23T12:21:09Z<p>Zwabel: Add 2 Kopete ideas</p>
<hr />
<div>This page is an open list for ideas for the 2008 edition of [http://code.google.com/soc Google Summer of Code]. This page is open for new ideas from anyone - you do need to log in to the wiki to edit this page though (see below for why).<br />
<br />
This list is not exhaustive. It is just a collection of some ideas. To get further ideas, please feel free to use any resources and [[#Past_ideas|past ideas]].<br />
<br />
Before proceeding, '''read''' the [[Projects/Summer of Code/2008/Participation|participation instructions]] and [[#Notes_on_editing_this_page|the notes on editing this page]]. They are useful for students and developers alike.<br />
<br />
== Past ideas ==<br />
<br />
You may want to take a look at the ideas page for [http://wiki.kde.org/tiki-index.php?page=KDE%20Google%20SoC%202006%20ideas 2006] and [[Projects/Summer_of_Code/2007/Ideas|2007]]. Many of the ideas there are still valid today.<br />
<br />
== Notes on editing this page ==<br />
<br />
Before making any modifications, please '''log in''' to Techbase. This will help us track who is contributing to the ideas. This page is protected, so you can't modify it without logging in anyways.<br />
<br />
When adding a new idea, please bear in mind the question: can a student with very little knowledge of KDE code complete this work in three months? If you can't answer "yes", your idea is probably not for this page. Please remember that this is '''not''' a generic wishlist page for KDE developers.<br />
<br />
When making modifications to existing ideas, please consider whether you're changing it more fundamentally or just superficially. If your changes are substantial, you probably have an entirely new idea. Similarly, if your idea is modified and you feel it no longer reflects your original thought, please split the idea in two, restoring yours.<br />
<br />
Please use the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] if you want to discuss an idea.<br />
<br />
Finally, do '''not''' delete ideas without a reason for doing so (like, for instance, being contrary to KDE ideals, being completely unrelated to KDE, being unfeasible, etc.) -- you may want to state in the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] why you removed the idea.<br />
<br />
Do '''not''' re-add ideas that were removed without discussing first with the developers of the target application.<br />
<br />
== Project ideas ==<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 />
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 />
When adding an idea to this section, please try to include the following data:<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 />
=== KDE Libs ===<br />
<br />
==== KDE Core libraries ====<br />
<br />
The KDE core libraries (kdecore, kdeui, kio, kparts) are the most basic libraries that all KDE applications depend upon.<br />
<br />
----<br />
'''Project:''' ODF writer<br />
<br />
'''Brief explanation:'''<br />
The ODF file format could be used for a wide range of applications, not just traditional office tools such as a word processor or spreadsheet.<br />
<br />
As an example, consider a tool like ksnapshot (which does screenshot captures). When writing documentation on how to perform some task with an application, you might work through the application taking many screenshots. If we had a class in kdelibs that could write ODF files, and the right application integration, perhaps the tool could create a file full of screenshots, which could then be annotated with some explanation to create a "visual guide" for that task.<br />
<br />
ODF is a pretty simple format to write (much less simple to read, because of the many options), and there is significant expertise in the KOffice community on that format.<br />
<br />
'''Expected results:'''<br />
* Properly designed, implemented, documented and tested class(es) for ODF writing.<br />
* Two usages of the class in different KDE applications (e.g. Okular and ksnapshot).<br />
<br />
'''Hints for proposal:'''<br />
* Explain what design and coding principles you will apply (goal: convince us that the code will be suitable for kdelibs)<br />
* Identify schedule for each element (goal: demonstrate that the task can be completed in the time you have available)<br />
* State your understanding of ODF (goal: demonstrate commitment to the task outcomes)<br />
<br />
'''Knowledge prerequisites:''' Sound C++ and Qt knowledge. Some familiarity with other ODF tools would be useful. <br />
<br />
'''Mentor:''' TBA<br />
<br />
----<br />
'''Project:''' Diskspace Service<br />
<br />
'''Brief explanation:'''<br />
<br />
Applications that write large amounts of data to partitions must nor fill them up completely. As an example there is strigi/soprano which can have a large index and will fill your ~ until 0 bytes remain. Other applications are e.g. those that write data to .thumbnails.<br />
<br />
To prevent this there is the need for a service that can be queried by applications, whether the user-set limit of remaining MB is already reached or not.<br />
<br />
As an extra the user could be notified if the set limit is reached.<br />
<br />
Mentor: Sebastian Trueg<br />
<br />
----<br />
'''Project:''' Support for fingerprint authentication<br />
<br />
'''Brief explanation:'''<br />
Many laptops come with a simple fingerprint scanner that can be used to authenticate users. It would be nice if KDE had support for these fingerprint scanner integrated. This way you could use them to log into KDE, unlock KWallet, maybe even use it to enter nickname in highscores for games... It would probably be a good idea to work with [http://reactivated.net/fprint/wiki/Main_Page fprint] project when integrating the support.<br />
<br />
----<br />
'''Project:''' Smart toolbars<br />
<br />
'''Brief explanation:'''<br />
Currently the policy is to have as few buttons in toolbar as possible by default. Only the ones that have a very high chance of being used by almost all users of an application. Maybe there could be an option added to toolbars so that it would monitor which actions (from menus) the user uses. When the new smart toolbar notices that the user has used some action very frequently and which doesn't have a button in the toolbar yet, it could suggest to the user to automatically add it to the toolbar. Buttons could also be removed after not using toolbar buttons for a long time. Off course there should be 3 options for this feature: 1. to automatically add and remove toolbar buttons without asking, 2. to ask before adding or removing, and 3. to disable this feature so that toolbars are the same as now.<br />
<br />
----<br />
<br />
'''Project:''' Beautify KNotify / Support Growl themes<br />
<br />
'''Brief explanation:''' In its current form KDE notifications are quite "basic" -- one might even say ugly. With WebKit as part of Qt 4.4, implement "CSS-able" notifications similar to (and ideally compatible to) [http://growl.info/about.php Growl]. Growl is a framework for Mac OS X and its free software under the 3-clause BSD License. Adopting the same license for KNotify's theming code may ensure future code exchange between both projects and theme compatibility.<br />
<br />
'''Expected results:''' Similar capabilities to what's shown in the video on http://growl.info/about.php and in the screenshots on http://growl.info/screenshots.php<br />
<br />
==== Solid ====<br />
<br />
Solid is the KDE hardware abstraction layer, that enables KDE programs to get consistent results when running on different platforms.<br />
<br />
==== Phonon ====<br />
<br />
Phonon is the KDE audio abstraction layer, that enables KDE programs to produce basic and medium-level multimedia functionality in any platform without platform-specific code.<br />
<br />
==== KHTML ====<br />
<br />
KHTML is the current KDE HTML engine, used by the Konqueror web-browser and other applications to display HTML in their interfaces.<br />
<br />
'''Project:''' Implement HTML 5 features<br />
<br />
'''Brief explanation:''' HTML 5 will bring many new features. The student gets to pick and propose one or several of those features from the draft. Projects could encompass implementation of DOM Storage or SQL interfaces for example.<br />
<br />
'''Project:''' Web-based desktop<br />
<br />
'''Brief explanation:''' The advancement of Web technology (DHTML, XMLHTTPRequest, CSS, Canvas) nowadays allows for the implementation of complex GUIs that can compete with native programing toolkits. This project would involve the implementation of a KDE desktop including icons and menus that is solely based on HTML, JavaScript and CSS. An examplaric feature: render the content of .desktop files in HTML. This could either be served through a backend server or a custom KHTML part that provides such code and offers extensions to load from and store data on the hard disk.<br />
<br />
==== KJS ====<br />
<br />
KJS is the JavaScript engine used by KHTML and Kross to run JavaScript programs.<br />
<br />
'''Project:''' ECMAScript 4 classes<br />
<br />
The draft for ECMAScript 4 on www.ecmascript.org mentions several new built-in types like Vector and Map. Existing implementations that already cover part of the future standard (like ActionScript) also feature classes like ByteArray. Other ideas are KDE specific likes like KIO bindings. Students are invited to select and implement a subset of these classes.<br />
<br />
'''Project:''' Pre-compiled JavaScript programs<br />
<br />
As announced [http://www.kdedevelopers.org/node/3323 recently] the [http://websvn.kde.org/branches/work/kjs-frostbyte/kjs/ kjs-frostbyte] branch now features a byte-code version of KJS. From there the step to pre-compiled executables, i.e. binary blobs that contain code as well as data and can be executed from the shell like normal executables is not very big.<br />
<br />
==== Sonnet ====<br />
<br />
Sonnet is the KDE grammar, spell-checker and language-detection engine.<br />
<br />
==== Kross ====<br />
<br />
Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and KDE JavaScript transparently into native applications to bridge the static and dynamic worlds together.<br />
<br />
==== Oxygen ====<br />
<br />
Oxygen is the KDE 4's default look-and-feel. It comprises of the Oxygen icon set (including the palette and guidelines for icons), the Oxygen sound theme, the Oxygen wallpaper collection, the Oxygen window decoration and the Oxygen widget style. Note that for Summer of Code, you must produce code, so the window decoration and widget styles are your more likely candidates.<br />
<br />
==== KDE-Print ====<br />
<br />
* Implement an easy usable [http://www.fineprint.com/products/fineprint/index.html fineprint-like] solution for collecting pages from different printing sources (browser, kword, krita...) and allow it to rearrange single pages (not printing jobs), delete pages, add blank pages. Information also in wish-list-item: [https://bugs.kde.org/show_bug.cgi?id=90989 90989]. I am the reporter of this wish, you can contact me there. I do not have the abilities to program, but I am willing to help testing an implementation and discuss how it should look like.<br />
* WARNING! i'm doing exactly this for my semester project at school (we are two students, so we can't apply for SoC with this). We are probably developing it in pure QT (the other student is a gnome user).You can get in contact with me: asranie@fryx.ch<br />
<br />
=== KDE Base applications ===<br />
<br />
==== Konqueror ====<br />
<br />
Konqueror is KDE's powerful web browser and file manager.<br />
<br />
'''Project: Bookmark Wallet'''<br />
<br />
'''Description:''' This isn't actually a project to be a part of Konqueror itself, but rather a separate application similar to KWallet. The application should provide a database for the storage of URL bookmarks. The database should be able to connect to remote storage, such as the Google bookmarks service, for synchronization and backup. The URLs should be easily manageable, and include a concept of ratings for the URLs. A plugin should be written to allow Konqueror to easily interface into the system, or preferably Konqueror itself should be modified to use the storage system when it is available. The application should provide an interface which is easy to connect to from a browser plugin, so that plugins could be written for other browsers, such as Firefox, as well. There should also be a plugin interface into the database, to allow support for other remote storage backends, such as foxmarks, to be created. The application should handle multiple concurrent connections to the database without issues. Additionally, the application should provide an event interface to notify all connected browsers whenever a bookmark is added, changed or removed.<br />
<br />
Comment: Rather than developing a separate application, interested students should have a look at the [http://websvn.kde.org/trunk/KDE/kdepim/akonadi/resources/localbookmarks/ Akonadi resource localbookmarks]<br />
<br />
Comment: Would be great if this would include saving RSS-Feeds in as well, synchronising them with webbased feedreaders<br />
<br />
Comment: a database of feeds would indeed be great. If implemented with a "feedtype" field, it would solve the problem of feeds containing news that's best read in a traditional aggregator, audio that's best heard in a music player, video that's best seen in a video player, etc. Apps could just open the query the feed DB for suitable feeds. Or perhaps they could query for feeds with particular enclosure mimetypes? Hmm. That raises the issue of pre-loading the feed, and integration with libsyndication.<br />
<br />
==== Dolphin ====<br />
<br />
Dolphin is KDE 4's default file manager application.<br />
<br />
'''Project: Support Windows' "Previous Versions"'''<br />
<br />
'''Description:''' Shadow Copy (also called Volume Snapshot Service or VSS) is a feature introduced with Windows XP with SP1, Windows Server 2003, and available in all releases of Microsoft Windows thereafter, that allows taking manual or automatic backup copies or snapshots of a file or folder on a specific volume at a specific point in time. It is used by NTBackup and the Volume Shadow Copy service to backup files. In Windows Vista, it is used by Windows Vista's backup utility, System Restore and the Previous Versions feature. Samba supports Shadow Copy since version 3.0.3.<br />
<br />
==== Konsole ====<br />
<br />
Konsole is KDE's terminal application.<br />
<br />
==== Kate and KWrite ====<br />
<br />
Kate is KDE's Advanced Text Editor, both a full-featured text editor application and a KPart engine ready for embedding into other applications (like KDevelop, Quanta and Kile). KWrite is a simple text editor based on the KatePart engine and is KDE's default text editor.<br />
<br />
----<br />
<br />
'''Project:''' vi mode for the Kate editor<br />
<br />
'''Project overview:''' Create a vi-like modal editing mode for the Kate editor part and improve the kate command line to a point where it can be used efficiently for vi commands in this mode.<br />
<br />
'''Expected results:''' This project should implement a vi-like, modal editing mode for kate. This mode will be selectable by the user.<br />
<br />
'''Mentor:''' Christoph Cullmann has agreed to mentor this project.<br />
<br />
==== System Settings ====<br />
<br />
'''Project: A system settings module for creating backups'''<br />
<br />
'''Project Information''':<br />
The idea is twofold:<br />
<br />
Create a System Settings control module for scheduling backups. Rather than pick a specific backup technology, it would support multiple backends, such as tar, dar, rdiff-backup and rsync-backup. By making it backend agnostic, it could be used with any file-based backup tool. It would therefore be more robust and easier to adopt than previous backup GUIs.<br />
<br />
To benefit the most users, the control module would be based on a non-KDE library so the technology could be reused in Gnome and other desktop environments. Therefore ideally, the implementation would take the form of a Freedesktop.org project that focuses on the functionality most backup programs share: selecting a root directory to backup and a destination directory, inclusion and exclusion rules, a choice between full or incremental backup, and whether to use compression and/or encryption. The goal would be to develop a descriptive backup file format that is not tied to any specific implementation, and a library that can read such files and generate the appropriate command line flags to create the backup with a given backup tool. A secondary goal would to create a sensible set of defaults for creating backups. That would involve collecting a list of common directories that can be excluded (such as trash directories, common web browser caches, and mount points) so that users do not have to waste time tweaking their exclusion rules.<br />
<br />
Usage cases:<br />
<br />
Average Joe is new to Linux, and wants to make a backup of his computer. He sees "Backup Settings" in KDE4's System Settings (or Gnome's Administration menu). Since the module is part of the upstream desktop environment, it doesn't matter which distribution he's using.<br />
<br />
Joe has been making backups to writable DVDs using the DAR backend of the backup control module for several weeks, when he gets an external hard drive. Now he wants to make the same backup to his external hard drive instead. He does not have to learn how to use a new program; he simply selects the rsync-backup backend and specifies the new destination.<br />
<br />
'''Expected Result:'''<br />
* A library that maps standard backup options (like include/exclude rules) to the command line options for several popular backup tools.<br />
* A working KControlModule for KDE4 that allows users customize and schedule backups.<br />
<br />
'''Currrent Knowledge''': <br />
* I have a little experience with C++, and have dabbled a bit in PyKDE<br />
<br />
'''Contact''': <br />
<br />
If you think the idea is interesting and would like to mentor such a project, my email is (wmhilton+gsoc@gmail.com)<br />
<br />
<br />
=== KDE Workspace ===<br />
<br />
==== Plasma ====<br />
<br />
Plasma is KDE 4's desktop and panel tool, replacing KDE 3's kicker and kdesktop. It's an advanced and powerful application with revolutionary ideas.<br />
<br />
* '''Plasma Packages'''<br />
** Plasma provides a simple packaging system for widget (plasmoids), SVG themes, wallpaper sets and indeed any type of application add-on data. It is not a replacement for apt, rpm, klick, etc. but rather is designed to help with the challenge of creating, sharing, installing and managing run time add-ons as have been made popular with KDE's Get Hot New Stuff framework.<br />
*** ''Project I: A GUI Creator For Packages'': This project involves taking the already started user application "plasmagik" and refining it to be ready for production use. The application must take a plasma package description, display it in a user friendly way in the UI and allow the user of the application to add files to the various nodes in the structure (e.g. graphics to an "images" entry). In particular this project would consist of:<br />
**** Removing assumptions based on the plasmoid package structure and instead using the generic Plasma::PackageStructure class.<br />
**** Making the UI more user friendly<br />
**** Streamlining the upload support<br />
**** Writing a tutorial on KDE's TechBase on how to employ the application as an add-on creator.<br />
**** As the plasmagik application already has had a fair amount of work done it and an active community of developers interested in its future, the scope and support for this project should be within the limits and expectations of the SoC.<br />
*** ''Project II: Package Management'': This project involves creating a small utility application consisting of a dialog and a control panel that uses it which allows the user to list, share and remove installed Plasma packages. As there are no dependencies, binary compatibility, etc issues usually associated with full package management applications, this would be well suited to a SoC project. <br />
* '''Zeroconf Integration''': This project would involved adding a zeroconf announce and discovery feature to libplasma that would provide a Plasma::Applet with a simple API to find other Applets of the same type on the local network. A test plasmoid would be created to prove the working status of the zeroconf support. Remaining time would be spent adding zeroconf features to applicable existing plasmoids.<br />
* '''DataEngine + Plasmoid for zeroconf services''': Browser for zeroconf services available (perhaps doable with above project as well?)<br />
* <s>'''Physics Engine''': Take an existing 2D physics engine and experiment with using it within a containment to emulate "natural" object interactions.</s> taken<br />
* '''Setting a video as desktop background'''<br />
* '''Dynamic desktop background''': A desktop background which displays different wallpapers according to information like time of the day, season, weather etc.<br />
* '''Mobile device containment''': Implement a Plasma::Containment that is appropriate in form factor and UI layout for a UMPC/tablet style device.<br />
* '''Touchscreen profile''': The use of UMPC form factors with a touch screen is increasing -- certainly in some business areas. Plasma is prepared for handling different form factors and for providing a user interface experience that adjusts to device characteristics. The touchscreen profile SoC project (touchscreen hardware will probably be arranged through the mentors) aims to identify where Plasma / KDE works well and where it doesn't on small (VGA or SXGA) screen sizes; then it will fix the bits where it doesn't work well and introduce a general mechanism for handling small screens. In addition, UMPC on-screen keyboards introduce new UI challenges; integrating these in a meaningful way with plasma is an extra part of this project (or possibly an extra project). Dialog and menu handling on small screens, with pagination of menus and (re)pagination of tabbed dialogs is another topic. '''Mentors:''' Adriaan de Groot and Armijn Hemel.<br />
* '''Phase''': improving the Phase/Animator system by:<br />
** implementing animation curves (already in the API and used by plasmoids, but not actually implemented)<br />
** optional keys for individual animations, allowing them to be turned off or otherwise tweaked individually / in groups<br />
** chaining animations<br />
** going through uses of customAnimation in libplasma using code and reimplementing generally useful ones within Animator itself<br />
<br />
==== KRunner ====<br />
<br />
KRunner manages the screen locking, run command dialog and provides a general natural language interface to applications, desktop services, network locations, files and data (e.g. math calculations, spell checking, word definitions, etc). It replaced the Run Command dialog in kdesktop from KDE3, is multithreaded and shares code with Plasma.<br />
<br />
Some of the items below may take an entire SoC project, others may be better combined to flesh out an entire summer's worth of work.<br />
<br />
* '''Ranking''': Results are returned to KRunner by individual runners. These result must then be ordered for the user prior to display. This project would consist of improving the ranking of returned results by working on two related fronts:<br />
** Tweaking individual runners to more accurately rate their own results.<br />
** Improving the final ranking system employed by the host application.<br />
* '''Abstracting runner management out of KRunner''': The main pieces of using runners (SearchContext, SearchMatch and AbstractRunner) exist in a shared library (libplasma). However, much of the code for managing the actual runners at runtime is contained within the krunner application itself. Abstracting this code out would make it easier for other components and applications to user runners as well.<br />
* '''Using runners in Kickoff''': The kickoff menu has a search tab. Currently it does it's own internal search. It should, instead, be using AbstractRunners for this. This task would go well with the runner management task above.<br />
* '''Xesam search runner''': Write an AbstractRunner plugin that uses the Xesam query spec to forward user queries to a search store. The trick will be in making it performant as well as providing support for paging through requests.<br />
* '''Write as many runners of your choice''': one might call this a "marathon" (get it? runners? as many as you can? ahaha! *sigh*). I wrote [[http://aseigo.blogspot.com/2007/10/what-runners-do-we-need-want-dream-of.html this blog entry]] looking for ideas for runners and got many, many suggestions. I think it reasonable to expect that over the course of a summer's work one might be able to write 5-10 runners depending which ones were selected.<br />
<br />
==== KWin ====<br />
<br />
KWin is KDE's X11 Window Manager program, greatly improved when compared to its older brother in KDE 3.<br />
*'''Compiz-like Effects in KWin''': Effects like Desktop Cube often greatly improve the usability, especially when it comes to multiple desktops, and they are just cool.<br />
<br />
*'''Make KWin multi-pointer ready''': Mpx is an extension of the X-Server currently living in a branch, that is planned to be merged in one of the next versions(see http://wearables.unisa.edu.au/mpx/). Once it's merged, the x-server will support an arbitrary count of simultaneous active pointers/cursors(A mouse and a keyboard paired together) and multiple active windows, allowing input from multiple users at the same time. The window-manager needs to be aware of the multiple cursors, and needs to dynamically assign pointers to applications that are not mpx-aware(Which will be all, in the beginning). Also it might be nice having a plasma-applet that allows easy spawning/removing of additional cursors.<br />
<br />
==== KDM ====<br />
<br />
KDM is KDE's Display Manager and login application.<br />
*'''More Ways of entering login data''': Currently, KDM only supports logging in with Username and Password in two fields on the one login mask. Entering first Username and then Password in two separate masks (Yeah, just like GDM) or searching for users while typing in the letters of a username would be really handy and cool. Another interesting thing to investigate would be "log in by finger-print".<br />
<br />
==== KScreenSaver ====<br />
<br />
*'''Plasma Dashboard Screensaver''': There could be a new default screensaver added. When started it would show the Plasma Dashboard with all the plasmoids on it. The Dashboard could be the default one (the one that shows up when you press Ctrl+F12) or the user could create a custom one just for this screensaver. These two options should be in the screensaver's properties. For creating custom layout there should be some tool to set background and add plasmoids.<br />
<br />
=== KDE Runtime ===<br />
<br />
''' Project''': KHelpcenter: What's this explosion<br />
<br />
'''Description''': A lot of help about elements of the user interface is available in the form of "What's This?" texts. Unfortunately it's pretty cumbersome to get to this information for a user as it needs clicking on the "question mark button" in the title bar of the window/dialog and then clicking on the user interface element. This project is about making this information more conveniently available by providing an "exploded" view of the "What's This?" help as part of the application's manual in KHelpcenter.<br />
<br />
All "What's This?" texts of a given window could get displayed in a view at once, e.g. by using some bubble views and connecting lines to the interface elements. These views could be extracted from the run-time instances of the windows by inspecting the widget hierarchy. This could either be done as a special offline run to pre-generate help pages or dynamically at run-time of the application. Investigations of what method would be the best would be part of the project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': KHelpcenter: Cheat sheets<br />
<br />
'''Description''': Task based documentation of applications can often be presented best as step-by-step instructions how to achieve certain user goals. With the help of application's D-Bus interfaces KHelpcenter could be extended to provide interactive versions of these step-by-step instructions. Users would be provided with explanations and instructions how to accomplish tasks together with links that would open corresponding dialogs, execute described actions, etc. In the Eclipse project this kind of help is called cheat sheets.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KOffice ===<br />
<br />
==== KWord ====<br />
'''Project:''' Improve ISO OpenDocument support<br />
<br />
'''Explanation:''' Improve loading and saving of the ISO OpenDocument format what includes 1) extend the current saving code, 2) extend the current loading code and 3) probably also extend the rendering engine aka the text flake-shape.<br />
<br />
'''Expected results:''' be sure everything we are able to load, display and edit is also saved back correctly using the default file format.<br />
<br />
'''Mentor:''' Sebastian Sauer <mail@dipe.org><br />
<br />
-----<br />
<br />
'''Project:''' Collaborative editing of documents over a network.<br />
<br />
'''Explanation:''' Make it possible for two or more users to work at the same document in KWord at the same time over a network. Both users would open the same document, and changes made by each user are synchronized to the other user's editing session.<br />
<br />
----<br />
<br />
'''Project:''' Version control integration.<br />
<br />
'''Explanation:''' Integrate version control system support with KWord to allow easy control over revisions of documents. It should be possible to connect with remote revision control systems, to allow collaborative work on projects, similarly to how software is developed. It should be easy for the user to browse through the history of document versions in the version control system, to see what has changed. CVS, Subversion and git should be supported.<br />
<br />
----<br />
<br />
'''Project:''' Improve legacy MS Office (2003) documents support<br />
<br />
'''Explanation:''' Current MS Office formats support is kinda limited (especially write support). To decrease the barrier for adoption, better MS Office support is a way to do that.<br />
<br />
==== KSpread ====<br />
==== Kexi ====<br />
Kexi is an integrated data management application for desktop users like Microsoft Access.<br />
<br />
-------<br />
'''Project:''' Improve Kexi Data Import/Export<br />
<br />
'''Brief explanation:''' Currently Kexi allows importing CSV files into an existing database, and converting MySQL/PostgreSQL/MS Access databases into Kexi databases.<br />
<br />
The aim of this project is to provide plugin(s) that import from more database backends/formats.<br />
<br />
You can select backend you want to implement migration for:<br />
<br />
* HSQLDB - the OpenOffice.org Base's DB backend (ODB file format, very important to have)<br />
* ODBC<br />
* Paradox<br />
* DBase (e.g. using [http://linux.techass.com/projects/xdb Xbase])<br />
* Firebird (note: pending licence checks if we want GPL-compliance)<br />
<br />
For the ODBC driver, a migration plugin and a backend plugin should be provided. For Paradox, only a migration plugin is required, although this will require modifying the migration framework to allow more than one file to be selected as the source database (i.e. the database to be imported).<br />
<br />
Both a migration plugin and a backend plugin could be provided for HSQLDB, which should be implemented using JNI to invoke JDBC methods in the HSQLDB library. To avoid Java and OO.org dependencies, a small tool could be developed in Java to export/import to/from a intermediate format, and then used from within a Kexi migration plugin.<br />
<br />
In any case, migration plugins are simpler to implement than direct access plugins (drivers), so these can be developed first.<br />
<br />
'''Expected results:''' HSQL support would enable OpenOffice.org Base format for KDE and KOffice itself, a good companion to already existing OpenDocument support. ODBC connectivity would add many new possibilities directly to KDE.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:'''<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_DBaseMigrationPlugin "DBase Migration Plugin for Kexi" proposed by Jonathon Manning in 2006]<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_ParadoxAndHSQLAccess "Paradox & HSQL access for Kexi" proposed by Joseph Wenninger in 2006]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl>, Sebastian Sauer <mail@dipe.org><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Kexi Web Forms<br />
<br />
'''Brief explanation:''' Web Forms allow to read-only or read-write access to database projects created with Kexi. It is optional feature for uses where client has no Kexi installed for any reason. The fact that the Web Forms will use Web standards, adds another advantage over competitors like MS Access (which uses proprietary Windows-only ActiveX bindings).<br />
<br />
Proposed solution is to develop a small standalone web server. It is probably already written in C++ or C by FOSS community. Good examples are lighttpd - http://www.lighttpd.net/ <br />
and (being already in KDEnetwork module) KPF - http://rikkus.info/kpf.html.<br />
<br />
The web server would be dynamically linked to kexidb and thus can access Kexi databases via universal KexiDB API, and create HTML content on demand as an answer to HTTP requests.<br />
<br />
For alternative solution see "Alternative solution for Kexi forms using PHP" below.<br />
<br />
'''Expected results:''' Shortly, it is internet-enabler for KOffice/KDE data management.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++ and HTTP/web standards, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:''' [http://jacek.migdal.pl/gsoc/ Solution proposed by Jacek Migdal last year]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Alternative Solution for Kexi Forms Using PHP<br />
<br />
'''Brief explanation:''' Create a Kexi plugin generating PHP code saving it directy to the filesystem. This will require Apache (or other PHP-compatible web server) to be present and configured, and also will require the plugin to be packaged with a script that will install appropriate tools that allow r/w accessing the Apache/php subdirs.<br />
<br />
'''Expected results:''' The generated code could directly access MySQL or PostgreSQL servers at the backend, so users could immediately have a robust server-side solution without complex requirements.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of PHP, web standards and C++, (knowledge of Qt is recommended)<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
==== Krita ====<br />
<br />
'''Project:''' Sumi-e brush engine<br />
<br />
'''Project Information:''' While there is already an attempt at a sumi-e brush engine in Krita, the current code is limited and uses an old-fashioned way of simulating brushes. <br />
<br />
'''Expected results:''' This project should implement an anti-aliased, bidirectional ink-transfer simulation of a sumi-e brush, together with a user interface to define brushes. The brushes should react to pressure, tilt and rotation of the a tablet stylus. The results should be realistic. Loan hardware for use during the development phase is available.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic knowledge of basic 2d graphics principles. A list of relevant papers and books is available.<br />
<br />
'''Mentor:''' Boudewijn Rempt <boud@valdyas.org> The mentor can help preparing the project proposal for submission to Google.<br />
<br />
-----<br />
<br />
'''Project:''' Sketch-pad interface for Krita<br />
<br />
'''Project Information:''' Krita is a large and complex application built around a sophisticated painting engine. The goal of this project is to create a new interface around the Krita engine, specialized for quick sketching.<br />
<br />
'''Expected results:''' This project should implement a new interface around Krita, presenting the user a single-layer plus tracing paper interface with a single freehand sketching tool. Easy to use and graphic color and paint operation (brush, pencil, eraser etc.) interface elements must be designed and implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:''' <br />
<br />
-----<br />
<br />
'''Project:''' Shader filters and generators for Krita<br />
<br />
'''Project Information:''' Some initial work has already been done to make it possible to write filters in the OpenGL shading language. This project should take that initial code as a basis and implement a fully functioning plugin for Krita that allows filters and shaders to be executed on images in any colorspace.<br />
<br />
'''Expected results:''' The plugin should have a finished user interface and make it possible to experiment with shader filters in an interactive way. Example filters must be implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, OpenGL.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Animation support<br />
<br />
'''Project Information:''' There is no support at all in Krita for animated images such as GIF or MNG or for working with images in an animation context, such as textures or backgrounds in applications like Blender. The applicant should first investigate user needs and use cases and then implement support in the user interface and in the import/export filters.<br />
<br />
'''Expected results:''' A user-friendly way of working with animated images (i.e., not by making each frame a layer), but e.g. a docker that shows the the animation running in thumbnail format. Import/export filters for relevant file formats.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' RAW plugin<br />
<br />
'''Project Information:''' Krita's current raw plugin is based on a shell exit to dcraw. This is not sufficient and needs to be re-implemented.<br />
<br />
'''Expected results:''' A next generation plugin should implement loading of raw images either through libopenraw or libkdcraw; preferably designed in such a way that we can switch libraries when opportune. The plugin should allow the user to set conversion parameters in a way that is useful to photographers. An extension to this project could be the implementation of a bayer colorspace model: that is, a colormodel that allows us to load the raw images and edit them in the native raw format, without conversion.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' PSD and Gimp plugins<br />
<br />
'''Project Information:''' Krita is powerful enough to handle nearly all that the Gimp and Photoshop are capable of saving. This project is about creating dedicated file import/export filters that can handle as much of these file formats as possible, possibly through the use of existing libraries.<br />
<br />
'''Expected results:''' 4 plugins: psd import/export and xcf import/export. These plugins should be able to handle complex files in all supported colorspaces.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Photoshop-compatible brush engine<br />
<br />
'''Project Information:''' A paintop plugin that can load and handle current photoshop brushes. This entails reverse engineering of the Photoshop brush file format and implementing a procedural brush engine that matches the Photoshop brush engine.<br />
<br />
'''Expected results:''' A procedural brush engine with settings dialog that can load and save current photoshop brush files.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Workspaces<br />
<br />
'''Project Information:''' A workspace is a loadable package of settings that finetune Krita for a particular purpose. A workspace could contain additional plugins (like an image browser plugin for batch operations) and a subset of resources. Example workspaces could be batch-editing of images, editing of animation sequences or painting or sketching.<br />
<br />
'''Expected results:''' the user interface and framework to make packages of plugins and resources that users can switch between. Also extra plugins to extend krita in areas like batch processing that do not exist yet.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:''' <br />
<br />
<br />
-----<br />
<br />
'''Project:''' Kipi and digikam plugins compatibility<br />
<br />
'''Project Information:''' Kipi and digikam provide lots of interesting plugins for working with 8 and 16 bit RGBA images. It would be great to be able to re-use those plugins from within Krita.<br />
<br />
'''Expected results:''' Two plugins that load kipi and digikam filters into two new menus in the filter menu. Code to convert Krita layers to the digikam image representation and back, taking care of icc profiles and other niceties.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:'''<br />
<br />
=== KDE SDK ===<br />
<br />
==== Umbrello ====<br />
<br />
Umbrello is the UML drawing and design tool in KDE.<br />
<br />
----<br />
<br />
'''Project:''' Add the capability to draw SysML diagrams (http://www.omg.org).<br />
<br />
----<br />
<br />
'''Project:''' Port Umbrello to QGraphicsView<br />
<br />
----<br />
<br />
==== Kobby ====<br />
<br />
<br />
'''Project:''' Kobby. A text editor which allows multiple users modify a set of documents at the same time. This is called a collaborative text editor.<br />
<br />
'''Brief explanation:'''<br />
* The idea is to create a KDE based application that depends on the [http://gobby.0x539.de/trac/wiki/InfinoteProtocol infinote] library which is the successor of the obby library.<br />
* It would be really nice to have integration with already existing editing and coding solutions: as KDevelop, or Kate for instance.<br />
* It would be even better if it was a katepart plugin so it can be used everywhere kateparts are used. The plugin integration can probably be done by extending KTextEditor to use the infinote API.<br />
<br />
You can find the [http://gobby.0x539.de/trac/ Gobby page here], where you can [http://gobby.0x539.de/trac/wiki/InfinoteProtocol also check out the infinote] library code. Svn repository: svn://svn.0x539.de/infinote/trunk<br />
<br />
'''Mentor:''' Andreas Ramm <psychobrain@gmx.net><br />
<br />
COMMENT: I had filed my vision of collaborative editing in KDE applications as wishlist item [http://bugs.kde.org/show_bug.cgi?id=149498 149498].<br />
Also see bugs [http://bugs.kde.org/show_bug.cgi?id=79721 79721] and [http://bugs.kde.org/show_bug.cgi?id=145011 145011]<br />
<br />
COMMENT: Infinote is under heavy development, and both the protocol and the library API have gaps and are subject to change. Whether you view this as a drawback or a chance to help shape and be on the cutting edge of open-source collaborative editing is down to you.<br />
<br />
COMMENT: Notes and Ideas can be found at the [http://mateedit.wiki.sourceforge.net/MateEdit Mateedit Wiki page]<br />
----<br />
<br />
=== KDE Edu ===<br />
<br />
==== Marble ====<br />
<br />
'''Project:''' Vector-Tiles for Marble <br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/marble Marble] is a generic geographical map widget and framework that is meant to be used by KDE4 applications. It is also distributed as a standalone application in KDE4.<br />
<br />
'''Brief explanation:'''<br />
* Marble can download and texture map texture tiles ( see http://www.kdedevelopers.org/node/3269 )<br />
* For implementing stuff like routing etc. properly we need a vector representation of streets and other features. One strategy to add those would be in terms of tiles similar to texture tiles.<br />
* Source data could either be VMap0 ( http://en.wikipedia.org/wiki/Vector_Map ) or OpenStreetMap data. You'd first need to find a way to create some vector tiles from this data stored in a suitable efficient format. These would need to get put onto the server. <br />
<br />
* Based on the Marble Layer Management architecture (which is currently in the works) you'd need to create a vector layer plugin which maps the vector tiles in the given projection. The vector layer data would internally use Marble's given data structure which is similar to the KML format ones. You'd need to extend that structure by vector features which are in the spirit of those provided by KML.<br />
<br />
* Ideally you'd also provide ways to select features using the mouse.<br />
<br />
'''Expected results:'''<br />
Getting OSM data or VMap0 data downloaded as tiles and rendered as vectors in the projection currently used. Being able to select features using the mouse.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, Qt, Recommended: knowledge of OpenStreetMap / VMap0.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Marble - OSM Annotation<br />
<br />
'''Brief exmplanation:'''<br />
* With a UMPC (possibly with built-in GPS receiver), it is possible to go into the field and hold a "verification party" to check the accuracy of OSM data. However, making notes when the OSM data is inaccurate is somehow annoying.<br />
* This project will implement on-screen annotation for OSM data overlaid on Marble, including mark and circle (i.e. drawing stuff on the map) and text annotation (taken together, it means you can draw a circle on the map and add a note saying what's wrong there).<br />
* Integration with UMPC stylus and on-screen keyboard input methods is needed.<br />
* Aggressive caching of Marble / OSM data in order to display it in the field is needed as well (compare Google Earth on an iPod).<br />
* Bonus points for optimizing for battery life.<br />
<br />
'''Mentor:''' Adriaan de Groot and Armijn Hemel. Touchscreen hardware might be provided on loan through the mentors.<br />
<br />
----<br />
<br />
'''Project:''' Marble - Routing<br />
<br />
Note from Marble author Torsten Rahn: I don't think that this project as a whole is feasible at this point. But choosing aspects as a GSoC project that are needed to get routing implemented in the future would be appreciated.<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/marble Marble] is a generic geographical map widget and framework that is meant to be used by KDE4 applications. It is also distributed as a standalone application in KDE4.<br />
<br />
'''Brief explanation:'''<br />
* Build on the inclusion of OpenStreetMap data in Marble.<br />
* Implement routing algorithms, ex. A*<br />
* implement a display of the route on the globe.<br />
* Optionally, show a list of roads and turns to get to destination.<br />
<br />
'''Expected results:'''<br />
Ability to chose start point, end point and type of transport (car, bike, foot <br />
etc.) and get a display of a route on the globe.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, knowledge of OpenStreetMap.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
<br />
==== Parley ====<br />
<br />
'''Project:''' Parley - Practice<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/parley Parley] is the vocabulary trainer that comes with KDE4. It is based on KVocTrain but has a much improved GUI. It allows to manage and exchange vocabulary collections that are stored in XML and provides advanced features, such as different practice modes.<br />
<br />
'''Brief explanation:''' The library and the GUI for editing vocabulary have been rewritten to a great extent. Now the thing that is still lacking is the most important part, the actual vocabulary practice. Based on QGraphicsView a nice practice dialog can be implemented, learning does not have to look boring.<br />
<br />
'''Expected results:''' A working practice which supports different modes of practice, ranging from multiple choice and written tests to conjugation and other grammar practices. Support for themeing is desireable.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, QGraphicsView, basic SVG knowledge.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
-----<br />
<br />
'''Project:''' Printing in Parley<br />
<br />
'''Brief explanation:''' Parley and some other KDE-Edu apps use a simple xml file format to store vocabulary data.<br />
This includes quite a bit of context information such as example sentences, word types, verb conjugations etc.<br />
The only way to print any of this information was so far to have a direct printout of the vocabulary list, containing only the words.<br />
Starting from xml it is reasonable to realize printing and even more by exporting to different formats.<br />
Using XSL to transform to html is one of the easiest way to achieve a good and flexible layout. More export formats could be added.<br />
Using this as a way to get multiple printing options would be a nice project.<br />
A flash card view (one vocabulary + optional context info per card), a list and more should be created at the users wish.<br />
<br />
'''Expected results:''' Configureable xsl/xslt transformation of the vocabulary data to at least html(+css) and maybe another format (pdf for example).<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, XSL(T). I can imaging learning XML/XSLT could be done during the project. A very basic example xsl file exists.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
-----<br />
'''Project:''' Parley - Advanced correction and grading<br />
<br />
'''Brief explanation:''' A bit of linguistic research is involved in this project.<br />
Evaluating language in a computer environment is close to impossible, so let's try what we can do anyways.<br />
I would like Parley to not only give feedback of the binary kind (your answer is right/wrong) but try to be a little more differenciated.<br />
How about offering the user to simply place the missing coma, wrong word order, add the accent he left out or hint at two mxied up letters?<br />
It would be possible to look at spell checking programs and other ways to know about the user input.<br />
Maybe the Levenshtein Distance algorithm is of help here? It would be interesting to have more research and an improved correction mechanism.<br />
<br />
'''Expected results:''' Design and implementation of a correction mechanism, that gives good feedback.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: some Qt, knowledge about languages, interest in research in that area.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
<br />
-----<br />
<br />
==== KStars ====<br />
<br />
'''Project:''' KStars: Millions of stars<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. Its display includes 130,000 stars down to 9th magnitude, which is well below the naked-eye limit, but inadequate for advanced purposes. <br />
<br />
'''Brief explanation:''' We would like to see KStars displaying millions of stars, without adversely affecting the program's responsiveness. Much of the infrastructure needed to accomplish this was implemented as part of the KDE-4.0 port, but the remaining work to make millions of stars a reality would be a nice SoC project.<br />
<br />
'''Expected results:''' Expanding the KStars database to include at least a million stars, while maintaining the current level of responsiveness. This will likely require asynchronous disk i/o to read in regionalized chunks of stars data, so that only the onscreen portion of the sky is loaded into memory.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, and probably Qt. Threaded programming a plus.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Prettyfication<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. The display is interactive, but it could be made more beautiful. <br />
<br />
'''Brief explanation:''' We often get good suggestions for making KStars look better. Choose any of the following ideas: realistic rendering of asteroids and comets (including tails!); texture-mapping of the sky (this would mostly allow a photorealistic Milky Way); texture-mapping of planets; realistic sky-lighting effects (i.e., sky is blue in the daytime, gets gradually darker and colorful at sunset).<br />
<br />
'''Expected results:''' Successful implementation of any of these ideas to make KStars more beautiful.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Printable star charts<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It already has a print feature, but the printed chart could be much better. <br />
<br />
'''Brief explanation:''' A printed star chart should at least include a legend explaining the symbols, and provide some information <br />
on the location of the user, the time and date, etc. The user would ideally be able to annotate the chart in various ways.<br />
<br />
'''Expected results:''' Significant improvements to the printed star charts in KStars.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic programming skills, ability to quickly learn QPainter API.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Many Moons<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It currently includes Earth's moon and 4 of Jupiter's moons. <br />
<br />
'''Brief explanation:''' Generalize the JupiterMoons class to encapsulate any planet's Moons. The project will require some research to identify a public source of orbital data for planetary moons, most likely from a NASA webpage. <br />
<br />
'''Expected results:''' Implement moons for at least Mars, Jupiter, Saturn, and Pluto with the new system.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. The project doesn't require much contact with Qt/KDE APIs, and the existing JupiterMoons class can be used as a template.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
==== Step ====<br />
<br />
'''Project:''' Step: 3d mode<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Implement physical simulation in 3d. This involves:<br />
* convert all classes in StepCore to templates with dimension as a template parameter, implement specialized versions where required, modify meta-object system to handle it<br />
* implement 3d mode in GUI: viewing and editing<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view 3d simulations in Step with the same set of objects as in 2d.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, basic OpenGL, basic physics (mechanics). Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: a game<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
The idea is to create a game based on physical simulation where the player have <br />
a fixed list of equipment (like springs, balls, cat and mice, teapot, etc.) and should use it to build a machine to achieve a given goal (for example put the ball in a basket, capture the mice, prepare a tea, etc.). The user places the equipment, than press Start button which starts physical simulation and if (in certain time limit) the goal is achieved the game is won. In the other case the user could try again. Similar projects: old game named "The Incredible Machine" and newer (but commercial) one named "Crazy Machines".<br />
<br />
The game can be implemented as standalone application using StepCore or as special restricted 'game' mode for Step (probably with tweaked graphics).<br />
<br />
'''Expected results:'''<br />
Playable game and several levels to test it.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, basic physics (mechanics).<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: simulation of chemical reactions<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1. This project also relates to [http://edu.kde.org/kalzium Kalzium].<br />
<br />
'''Brief explanation:'''<br />
Simulate some basic chemical reactions using classical molecular dynamics methods with empirical potentials. At first initial settings for simulation should be prepared by hand (as XML file), if there will be enough time an editor could be implemented too. This project involves:<br />
* convert required classes from StepCore to handle 3d simulations (you will need only several classes which are trivial to convert)<br />
* implement required objects and potentials in StepCore<br />
* implement GUI for observing the simulation (investigate the possibility to use avogadro library for visualization), GUI should also allow altering of some properties like masses and charges<br />
* prepare demonstrations of several common reactions<br />
<br />
'''Expected results:'''<br />
Chemical reaction viewer which could load predefined experiment, modify some basic properties and run the simulation. Prepared simulation for several common reactions.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, basic chemistry. Could be useful: Qt, basic quantum mechanics, knowledge of common molecular dynamics simulation techniques and numerical methods.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: fast water and gas simulation<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Currently Step has molecular dynamics based simulation of gas and water (that is a gas is simulated as a collection of particles). This is very usefull for demonstrating microscopical properties of the gas as well as its connection with macroscopical quantities like temperature. But this is far from optimal to demonstrate things like a boat floating in the water, water flowing from a glass, etc. This project involves:<br />
* investigate fast methods of simulating water and gas: ranging from molecular dynamics but with simplified potentials, various optimizations, coarse graining methods, to lattice Boltzmann methods; investigate existing libraries for water simulation (for example take a look at [http://elbeem.sourceforge.net/ elbeem] library from Blender)<br />
* implement selected method of simulation or incorporate selected library in StepCore<br />
* implement GUI in Step for creating and modifying macroscopical quantities of gas and watter<br />
<br />
'''Expected results:'''<br />
Ability to easily simulate in Step experiments like a boat floating in the water, water flowing from a glass, etc.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, numerical methods. Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: other ideas<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
These are smaller ideas related to Step. You can combine several of them to compose you project.<br />
* use KAlgebra library for parsing user-supplied expressions in PropertiesBrowser; allow value in Meter, x- and y-values in Graph to be arbitrary expression; implement ParametricForce object that will apply a force given by user-supplied expression; implement a series of ParametricJoint objects that will allow creation of various parametric constraints (like fixed particle trajectory)<br />
* scripting for Step using either QtScript or Kross<br />
* multi-threaded calculations in StepCore (knowledge pre-requisite: multi-threaded programming)<br />
* correctly handle stiff problems in StepCore (knowledge pre-requisite: numerical methods)<br />
* calculation of gravitational and electromagnetic force between non-point objects by integrating (knowledge pre-requisite: numerical methods)<br />
* make StepCore compilable without Qt<br />
* improve soft-body support: implement automatic creation of arbitrary-shaped soft bodies, better soft-body border handling, investigate better (more accurate) methods of modeling soft bodies (knowledge pre-requisite: physics)<br />
* support for non-convex polygons (probably by implementing triangulation)<br />
* optimize collision detection (AABB trees, etc.)<br />
* framework for dynamic object creation/destruction in order to allow implementing particle emitters<br />
* statistical models (for example prey/predator model)<br />
If you have other ideas please feel free to propose them !<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
==== RoxGT ====<br />
<br />
'''Project:''' RoxGT <br />
<br />
'''Project Information:'''<br />
RoxGT is a OSS done by Ugo Sangiori for building Graph-based applications. It aims essentially for academic jobs, such as graph algorithm execution and theorem proofs. <br />
<br />
'''Brief explanation:'''<br />
Rewrite the RoxGT, today it's written in Java as a Eclipse Plugin. This project aims to transform RoxGT into a full featured KDE4-Application, with all the benefits that Kross can give for the implementation of the algorithm execution in every language suported by Kross, and not only Java.<br />
<br />
Possibly integration of RoxGT in Marble, as a kparts to do things like 'shortest path between 2 points' when marble is used as GPS mode.<br />
Possibly integration of RoxGT in Umbrello, examining the UML and searching for design flaws into the Graph-generated UML.<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view simulations in graphical mode of Graph-Theory algorithm execution.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, Could be useful: Qt.<br />
<br />
'''Mentor:''' Looking for One.<br />
<br />
'''Student''' Tomaz Canabrava - tomaz <dot> canabrava <at> gmail <dot> com<br />
<br />
----<br />
<br />
=== KDE PIM (Personal Information Management) ===<br />
<br />
==== Kontact ====<br />
<br />
==== KOrganizer ====<br />
<br />
'''Project''': Beautiful month view<br />
<br />
'''Description''': The month view of KOrganizer has a long history, which is beginning to show, especially in terms of visually attractivity and performance. With KDE 4 and especially the latest versions of Qt 4 there is an unprecedented opportunity to add some beauty to this view. The goal of this project would be to create a new version of the month view which is able to display a month's worth of events in a beautiful, efficient and user-friendly way. This would include appointments, todos, multi-day events. In addition of a good display of events one could also think about advanced ideas like dynamical zooming of days, 3D indicators of categories or calendar associations, and more. There is a lot of room for creativity in this project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
==== KPilot ====<br />
<br />
==== KMail ====<br />
----<br />
'''Project:''' Message-View: Use more than one line per message<br />
<br />
'''Project Information:'''<br />
As known from other email-apps there is a use-case for having three panes next to each other. However the message-list is currently restricted to one line per message which makes it quite unuseable for that purpose. Thus a new view is needed.<br />
<br />
'''Knowledge Prerequisite:''' Qt Interview Framework<br />
<br />
==== Kleopatra ====<br />
<br />
Kleopatra is the KDE Certificate Manager. In KDE 4.1, it will have gained OpenPGP support (it originally comes from the X.509 world). It is currently being prepared to be integrated into the [[http://www.gpg4win.org GnuPG For Windows]] installer, too, and therefore needs to work in a size-reduced KDE environment (basically, kdecore and kdeui only).<br />
<br />
All of the Kleopatra projects naturally require familiarity with Qt, C++, and GnuPG/OpenPGP concepts.<br />
<br />
----<br />
'''Project:''' OpenPGP web-of-trust visualization<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement a mechanism to visualize the user's personal OpenPGP web of trust.<br />
<br />
'''Detailed Description:'''<br />
For a long time now, Kleopatra has had the ability to show a ''hierarchical view'' of the user's X.509 (aka. S/MIME, aka. CMS) keyring. Such a view lends itself naturally to X.509 certificates, whose trust model ''is'' hierarchical. Here, ''subjects'' (signees) are children of their respective issuers (signers) in a standard tree view, so that root certificates end up being top-level items.<br />
<br />
Naturally, this simplistic hierarchical view is hard to generalize to OpenPGP's Web-of-Trust (WoT) model where everyone may certify everyone else. It is the goal of this task to identify and implement such a generalized ''hierarchical view'' that fits this extended trust model.<br />
<br />
At least two views are obvious candidates (but this task is not restricted to only these):<br />
<br />
Extend the current X.509-type hierarchical view around the idea that my own key can be seen as my own personal ''root certificate'': Keys signed by me would be first-level children of my top-level key, and keys signed by those people would be second-level children, etc. The depth of a key in the item would be the same as that reported as <tt>depth</tt> in the output of <tt>gpg --check-trustdb</tt>. Problems with this approach include mapping a directed cyclic graph onto a tree for putting it into a tree view. Some people also have the opinion that the reverse of what is described here would be what users expect (rationale: <tt>gpg</tt> lists the signers below the signee in an <tt>--list-signatures</tt> operation).<br />
<br />
The second option is to use a graph visualization widget (to be found somewhere or written) that would allow to browse the WoT interactively. This ''might'' break the timeframe, but could be made into a more general component that can be used elsewhere if the project progresses exceptionally well.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a visualization tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* It should contain the X.509 case as a special subset.<br />
* It is easy to find the people I have signed.<br />
* It is easy to see the trust path between two certificates.<br />
* It is easy to see when such a trust path does not exist.<br />
With regard to Gpg4Win, the solution should fail gracefully in the absence of either the external tool, or KMail/Akonadi.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra. Graph visualization knowledge would help, too.<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
----<br />
'''Project:''' Keysigning Party Support<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement functionality to automate the challenge-response mail algorithm used after OpenPGP keysigning parties<br />
<br />
'''Detailed Description:'''<br />
Everyone that has been to a keysigning party has probably gotten a challenge mail to decrypt and send back afterwards. This is done in order to verify that the owner of the email address is also the owner of the (secret) key. This procedure is the basis for most OpenPGP Keysigning Policies, including the one from [http://www.math.uni-bielefeld.de/~mmutz/sign-policy.html#act your mentor].<br />
<br />
There are two ways to do this:<br />
* Interface with an already existing robot that is hooked into the local mail server, or<br />
* Interface with KMail/Kontact (or, if ready by then Akonadi).<br />
<br />
The second option is preferable, as it allows users with a normal desktop system to participate in the system. The first option would have to do a lot of user handholding for being usable enough for the target audience.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a OpenPGP challenge/response tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* Track sent challenges<br />
* Validate responses.<br />
* Alert the user when all responses necessary for a signing have been received.<br />
* Optionally, do this without user interaction.<br />
* Optionally, do this per user-id.<br />
* Deal gracefully with responses that are not forthcoming.<br />
With regard to Gpg4Win, the solution should also have no further external dependencies (mainly Qt, boost, kdelibs, kdeui, gpgme), but this is no hard requirement.<br />
<br />
Optionally, a MIME message format that facilitates the automatic handling of these challenge/response mail could be created and publicized.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
----<br />
'''Project:''' SSL CA Control Center<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an S/MIME Certificate Authority (CA) frontend for one or more free CA solutions.<br />
<br />
'''Detailed Description:'''<br />
While there is CA software available (e.g. OpenSSL and [http://www.mozilla.org/projects/security/pki/nss/ Mozilla NSS]), the command line tools are hard to integrate to get even a small CA running. This project is all about changing that.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented frontend for one or more X.509 CA software packages, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* Set up a new X.509 root certificate. Optionally: allow more than one root to be adminstered.<br />
* Allow to define any number of child CAs.<br />
* Allow to create new client certificates either ad-hoc, or from a PKCS#10 request.<br />
* Allow web- as well as mail certificates (or be flexible enough for doing both).<br />
* Allow to revoke and extend client certificates, and publish CRLs.<br />
* Be useable without much prior knowledge, prevent useless certificates.<br />
* Optional: KIOSK-enable the processes, so an admin can lock down certain aspects of them.<br />
With regard to Gpg4Win, the solution should also have no further external dependencies (mainly Qt, boost, kdelibs, kdeui, gpgme), but this is no hard requirement. It should use the command line tools instead of linking to the respective libraries (for stability, security, and licensing reasons).<br />
<br />
From a UI point of view, the operations shouldn't look much different from the respective OpenPGP ones.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra. Knowledge about CA software helps.<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
==== Akonadi ====<br />
<br />
Akonadi (http://kdepim.kde.org/akonadi/) is the framework for groupware and other PIM applications for KDE4.1 and later. <br />
<br />
----<br />
'''Project:''' Akonadi backend for Microsoft Exchange Groupware server<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an Akonadi backend to allow users to work with Microsoft Exchange servers and applications using compatible protocols (e.g. Outlook).<br />
<br />
'''Brief explanation:'''<br />
The implementation will almost certainly need to use the OpenChange (http://www.openchange.org) libraries. A proof-of-concept implementation has been done (available in KDE's SVN archive), but has bit-rotted as the OpenChange libraries have evolved. <br />
<br />
'''Expected results:'''<br />
A completed, and tested, backend that can operate with a current Microsoft Exchange server. Important capabilities include:<br />
* ability to receive mail,<br />
* ability to create and receive appointments, and to view the calendar,<br />
* ability to access the address book, and<br />
* ability to create and receive tasks.<br />
<br />
Sending mail is outside the scope of Akonadi, and is a "growth" potential if the project is proceeding particularly well.<br />
<br />
'''Knowledge Prerequisite:''' You need to have some familiarity with groupware applications (e.g. knowledge of how appointments and address books are used). C and C++ is pretty much essential, and at least passing knowledge of Qt. <br />
It would be useful (but not absolutely essential) if you had access to a Microsoft Exchange server you can use for testing - we may be able to arrange access.<br />
<br />
'''Mentor:''' Optional, possibly Brad Hards <bradh@kde.org><br />
<br />
----<br />
<br />
'''Project:''' Akonadi testing framework<br />
<br />
'''Project Information:''' Akonadi uses helper processes, called Agents, to do the actual processing of PIM data, e.g. transfer from/to an external storage.<br />
Agent functionality can depend on operations on the Akonadi store performed by other participating processes (Agents and/or clients), e.g. updating an external storage when a user application applies changes to PIM data.<br />
<br />
'''Brief explanation:''' In order to test such a setup automatically or semi-automatically, a testing framework needs to provide the following items:<br />
* means to launch Akonadi in a defined state, e.g. by restoring a data base dump<br />
* means to start a certain set of Agents<br />
* means to trigger changes on Akonadi's data<br />
* means to check the resulting state of Akonadi<br />
<br />
'''Expected results:'''<br />
* tools or test templates for developers to create and run test scenarios, probably using a scripting language like Python or Ruby.<br />
* example test scenarios for at least one agent and one resource<br />
<br />
'''Knowledge Pre-Requisite:''' An understanding of the concept of collaborating services, knowledge how to setup shell environments<br />
<br />
'''Mentor:''' Kevin Krammer <kevin.krammer@gmx.at><br />
<br />
----<br />
<br />
'''Project''': Akonadi Resouce: GroupDAV<br />
<br />
'''Description''': [http://www.groupdav.org/ GroupDAV] is a standard protocol to access groupware servers. It's for example implemented by [http://www.opengroupware.org OpenGroupware.org] or [http://www.citadel.org Citadel]. The task of this project is to create a native [http://pim.kde.org/akonadi Akonadi] resource to provide access to GroupDAV enabled servers to all KDE applications, in particular the KDE PIM suite. There is an existing KDE 3 based KResource supporting GroupDAV which could be used as a starting point.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Calendar<br />
<br />
'''Description''': Googgle Calendar provides an API to access the calendar data on the server. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource, so that any accessible Google calendar can be displayed and edited in Akonadi enabled applications, e.g. in KOrganizer.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Contacts<br />
<br />
'''Description''': Googgle recently has opened their [http://code.google.com/apis/contacts/ Google Contacts Data API]. This makes it possible to access the contacts data which is stored at Google, e.g. for GMail. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource to access contact data stored at Google, so that it can be displayed in Akonadi enabled applications, e.g. in KAddressbook.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Facebook friends and events<br />
<br />
'''Description''': Facebook has an [http://wiki.developers.facebook.com/index.php/API API] that can be used to query a user's friends and information about these. The API also gives access to a user's events. The aim of this project is to implement an Akonadi resource to access contact data stored on Facebook for a user's friends, and also give access to a user's events in Akonadi so that this information can be used in KOrganizer and KAddressbook.<br />
<br />
'''Mentor''': <br />
<br />
Note that there already is [http://websvn.kde.org/trunk/playground/pim/kfacebook/akonadi/ an implementation].<br />
<br />
----<br />
<br />
'''Project''': Akonadi Agent: PIM Data Mining<br />
<br />
'''Description''': PIM data usually contains a lot of related PIM data in some explicit or implicit form. Emails contain contact data as sender or recipients or as part of the signature. Emails also can contain calendar data, e.g. when sending groupware invitations or just by mentioning a date as part of an informal mail about getting together for a beer. The goal of this project is to implement an [http://pim.kde.org/akonadi Akonadi] agent which transparently collects all this information in the background and makes it available to the user e.g. as a special address book ("Email addresses of people to whose emails I answered on a mailing list", etc.). There are many interesting options what and how to implement this and part of the project would be to investigate, what makes sense to be collected and which methods are best suited to get the most useful information from the available raw data.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
'''Project:''' Akonadi backend for .pst files<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an Akonadi backend to allow users to at least read, and possibly write, information from personal storage (.pst) format files.<br />
<br />
'''Brief explanation:'''<br />
Users migrating from Microsoft Outlook often have a lot of information embedded in .pst files - archived mails, calendars, journal entries, and sometimes contacts.<br />
<br />
There are existing libraries to work with this format (e.g. libpst) but I'm not aware of any that do writing. Also note that the .pst format changed - there are two different versions. <br />
<br />
'''Expected results:'''<br />
A completed, and tested, backend that can operate with a both of the .pst formats. Important capabilities include ability to retrieve mail, calendar entries and contact entries. It would be useful to be able to write as well.<br />
<br />
'''Knowledge Prerequisite:''' You need to have some familiarity with groupware applications (e.g. knowledge of how appointments and address books are used). C and C++ is pretty much essential, and at least passing knowledge of Qt. <br />
You would need some way to create test files - almost certainly some version of Outlook, and it would be useful if you had real-world experience with creating and using .pst files.<br />
<br />
'''Mentor:'''<br />
<br />
----<br />
<br />
=== KDE Games ===<br />
<br />
'''Project''': Polytris clone<br />
<br />
'''Description''': Polytris is an old DOS game based on the Tetris concept. Its unique feature is that the number of blocks a piece is build from isn't fixed to four as in the original Tetris, but that it's variable. There are the simple one block pieces which fit everywhere, but there are also the challenging ten block pieces, which provide a complex setting which then has to be filled with other pieces. Difficulty of the game increases over time not by letting pieces fall faster, but by increasing the average number of blocks the pieces are constructed of.<br />
<br />
The task of this project is to create a KDE 4 version of this game. In addition of implementation of the basic game functionality extra credits are given for great playability, beautiful appearance, and a creative and motivating scoring scheme.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KDE Development & Web Development ===<br />
<br />
==== Kompare ====<br />
<br />
'''Project Information:'''<br />
[http://www.caffeinated.me.uk/kompare/ Kompare] is a graphical difference viewer.<br />
<br />
-----<br />
'''Project:''' Semantic diff<br />
<br />
'''Brief explanation:'''<br />
Implement a plugin-based approach for different (potentially incomplete) diff-algorithms. Documents are not just lines of text, but have semantics, and these plugins should help to see changes made to the document.<br />
<br />
Possible plugins are:<br />
* File information diff: show date, size, last-modification, ...<br />
* Programming language diff: detect changes like renamed variables, reindentation, namespace-changes, changes in comments, other refactorings ... (the more the better)<br />
* XML-diff<br />
* Latex-diff: whitespace is ignored.<br />
* config-file diff: in many config-files the order does not matter.<br />
* Image diff: at least show both images next to each other.<br />
* Video diff: show both videos next to each other and link their time. Should be interesting for diffs after reencoding.<br />
<br />
'''Expected Result:'''<br />
A native and Kross (for scripting) plugin-support for Kompare. Some of the above mentioned plugins.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Knowledge of C++.<br />
<br />
Comment: I think one of the most obvious applications of this is in SVG: it would be possible to graphically show the original image + new_rect merged as new_image fairly easily. You could even make elements transparent, and show them in steps, with onion-skinning, almost animating from previous version to new version. I'd also really like to see this "semantic-diff" for ODF documents.<br />
<br />
----<br />
<br />
==== KLinkStatus ====<br />
<br />
'''Project Information:'''<br />
[http://klinkstatus.kdewebdev.org/ KLinkStatus] is a link checker, part of the kdewebdev module.<br />
<br />
-----<br />
'''Project:''' Aided correction of broken links<br />
<br />
'''Brief explanation:'''<br />
Currently, it is possible to find out broken links but it is not possible to fix them. It would be great if those links could also be corrected within KLinkStatus. The corrector should present the user with sugestions, like a spell checker does (it might be possible to reuse some of the KSpell heuristics). Possible errors are typos in domain and paths, absolute vs relative path, and wrong directories.<br />
<br />
'''Expected results:'''<br />
Ability to fix broken links, being effectively assisted with suggestions.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' Site check automation<br />
<br />
'''Brief explanation:'''<br />
KLinkStatus already provide a D-Bus interface that allows to check sites in the background based on a configuration file and then export the results to HTML. A system administrator can already automate check using cron jobs. However it would be nice to offer a nice frontend inside KLinkStatus (without the need of super user permissions). The results could then be exported into files and/or emailed to the site administrator.<br />
<br />
'''Expected results:'''<br />
Easy site check automation and notification system.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' HTML validation<br />
<br />
'''Brief explanation:'''<br />
HTML validation is a very requested feature by users. KLinkStatus already have the infrastructure for this, using libtidy, but some work is still missing in order to actually correct the HTML documents. <br />
<br />
'''Expected results:'''<br />
- Visual indication of which document have HTML validation problems<br />
- Ability to fix individual documents or several documents at a time <br />
- Ability to efectively preview, compare (perhaps using the Kompare kpart) and edit partial parts of a document<br />
- Configurable HTML validation parameters<br />
<br />
'''Knowledge Pre-Requisite:''' HTML, some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ and, for some parts of it, a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
==== KDevelop ====<br />
'''Project Information:'''<br />
[http://www.kdevelop.org/ KDevelop] is the Integrated Development Environment from KDE. If you have something you'd like to see in KDevelop4 don't hesitate to write up your proposal or come to our developer list and discuss it with us.<br />
<br />
'''Project:''' Distribution integration<br />
<br />
'''Brief explanation:'''<br />
Integration of the build-system of one specific distribution into KDevelop. Usually it is quite easy to get the source-code of a package and build it, for example using "apt-get source" and "dpkg-build" under debian, or "osc" under openSUSE.<br />
<br />
'''Expected results:'''<br />
A user can start KDevelop, and choose a package from a list that should be retrieved from some distribution repository. Then KDevelop would download the source-package and create a project-directory+file into which all the necessary information is extracted, inluding a copy of the original project source that can be edited from within KDevelop. The developer can edit the source with code-completion, -navigation, and all the nice extras out of the box. Then the developer can build the package using the distribution-specific mechanisms, with the own changes to the source-tree are included as a patch.<br />
One of the most tricky things here would be providing KDevelop with correct include-path information for all the source-files. A simple hack to retrieve include-paths from existing makefiles is already implemented within KDevelop, and can be re-used. An additional bonus could be management of multiple separate patches on top of the source-tree, that can easily be submitted upstream.<br />
It would be nice if all the stuff could be implemented in a way that it's easy to add support for other Distributions.<br />
<br />
'''Knowledge Pre-Requisite:'''<br />
C++, package-building experience for a popular distribution(Maybe openSUSE or Ubuntu/Debian)<br />
<br />
==== Quanta ====<br />
<br />
=== KDE Network ===<br />
<br />
==== KRDC ====<br />
<br />
Add NX support to KRDC.<br />
<br />
-----<br />
'''Project:''' NX support in KRDC.<br />
<br />
'''Brief explanation:'''<br />
KRDC lacks NX support, which is gaining momentum in the free software world. Build upon the work done by George Wright in the 2006 SoC and the work done by Urs Wolfer in the 2007 SoC to create a top quality NX client for KDE.<br />
<br />
'''Expected results:'''<br />
Fully working NX integration for KRDC, including support for advanced NX features such as sound, VNC/RDP tunnelling etc. Feature parity with the commercial NX client shouldn't be necessary, but aiming for that isn't a bad idea. All NX connection handling code should be in the cross-platform client library nxcl (C++/STL/autotools), and all GUI specific code should be in KRDC.<br />
<br />
'''Knowledge Prerequisites:''' Knowledge of the NX protocol (see http://www.gwright.org.uk/protocol.pdf for an older version of the protocol), C++/STL/Qt/KDE coding and cross platform coding.<br />
<br />
'''Resources:''' http://freenx.berlios.de , http://blog.gwright.org.uk/articles/category/nx , http://nomachine.com/ , http://svn.berlios.de/wsvn/freenx<br />
<br />
'''Mentor:''' George Wright <gwright at kde dot org><br />
<br />
==== Decibel ====<br />
<br />
Decibel is a realtime communication framework for KDE 4.x.<br />
<br />
----<br />
<br />
'''Project:''' KDE4 integration<br />
<br />
'''Brief Explanation:''' Decibel should integrate well with the KDE 4 environment. This includes getting contact data from Akonadi and storing contact state there, storing account data in KWallet as well as integration with Nepomuk to store semantic information on connections made.<br />
<br />
'''Expected Results:''' A working and tested implementation of integration components.<br />
<br />
'''Knowledge Prerequisites:''' A good overview of the involved KDE 4 technologies is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/, Akonadi documentation<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Filtering framework for text messaging<br />
<br />
'''Brief Explanation:''' Text message that are passed to applications using the Decibel framework should get filtered. This includes processing steps (like processing of Off the record messages) as well as logging, etc. This filtering framework needs to be made more flexible as it currently is and some basic filters need to be written.<br />
<br />
'''Expected Results:''' The filtering API of Decibel is improved and sample filters are developed and tested.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Improve Telephony features<br />
<br />
'''Brief Explanation:''' Decibel currently has limited support for telephony features required for VoIP integration. This support needs to be improved and missing features (call forwarding, conferencing, etc.) should be implemented.<br />
<br />
'''Expected Results:''' A VoIP backend based on the existing telepathy backend with the additional telephony features implemented.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required. Familiarity with the telepathy spec and VoIP is helpful.<br />
<br />
'''Resources:''' http://decibel.kde.org/, http://telepathy.freedesktop.org/spec.html<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
==== Kopete ====<br />
'''Project:''' Integrate Decibel and Kopete<br />
<br />
'''Brief explanation'''<br />
Add support for Decibel to Kopete. This will involve some a lot of work within the Kopete core library (libkopete) in addition to making all the current protocol implementations into Telepathy Connection Managers. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
'''Note:''' This is an advanced project. The proposal will need to be very detailed and very complete. Basically, you need to show that you've done your homework, so to speak. The student will also need to be able to work closely with his/her mentor and the rest of the Kopete developer community by being available on IRC and being subscribed to the Kopete mailing list. <br />
<br />
'''Mentor:''' Matt Rogers<br />
<br />
'''Project:''' Jabber voice- and video-chat support<br />
<br />
'''Brief explanation'''<br />
Add suport for Jabber/Google Talk video chat to Kopete and Decibel.<br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
'''Project:''' Advanced custom media support<br />
<br />
'''Brief explanation'''<br />
In MSN, it's great fun for many people to collect individual animated emoticons and use them during the chat, and to trigger funny animations over the whole chat window. Also it is confusing for newbies when they send a message with an own emoticon, and it apears on the other side with no or another one. So at least the custom emoticon feature would be very nice. What probably needs to be done:<br />
- Implement simple management of a custom set of emoticons that can be added one by one. When someone else uses an emoticon, it should be possible to right-click it, and save it to the own collection.<br />
- Implement support for sending custom emoticons through jabber, and as many other protocols as possible that support this feature. For MSN, I think it's already implemented.<br />
- If time allows, implement sending of custom flash animations, that are played back using gnash, and allow downloading new animations through GetHotNewStuff.<br />
These features would make Kopete even more interesting to a wider less-purist audience.<br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
----<br />
<br />
=== Amarok ===<br />
Consider these suggestions a starting point to create your own proposal. Some need more detail. Please contact us and let us help you with the proposal before submitting. Find us on IRC on [irc://irc.freenode.net/amarok irc.freenode.net #amarok] or email the public mailing list [mailto:amarok@kde.org amarok@kde.org].<br />
<br />
-----<br />
'''Project:''' CD Stack collection view<br />
<br />
'''Brief Explanation:'''<br />
In iTunes you might have seen the very fancy view with albums flying by very prettily and not very usefully. Now, imaging instead that you have a stack of CDs in a tower. You scroll up and down through it, take one out, and open it to see what tracks are on it. A mockup of this idea can be found here: [http://leinir.dk/temp/gallery/mockups.php?gallery=mockups&image=mockups/cd-stack-in-glorious-pen-o-vision.jpg CD Stack]. Qt has a Model/View system that allows multiple views to the same data. This project would be a new view on the current collection browser. It could be implemented in 3D using OpenGL or using the pseudo-3D techniques that projects like Marble use.<br />
<br />
'''Expected Results:'''<br />
A working (not necessarily polished) implementation of such a CD stack interface, most preferably Model/View based.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, and while experience with Qt (and QGV) is nice it is by no means required, as it can be learned relatively easily. OpenGL and/or 3D programming helpful.<br />
<br />
-----<br />
<br />
'''Project:''' Context View development and Applet writing<br />
<br />
'''Brief Explanation:'''<br />
The Context View is one of the most visually evident features of the new Amarok 2. It takes up the middle part of the Amarok window and provides a view into the information about the song that a user is playing. As such, it is essential to Amarok that the Context View be functionally pleasing, polished, and pretty.<br />
<br />
A project focused on the Context View would consist of mainly continuing development on the CV itself, completing features that are planned but have not yet been implemented, as well as writing new Applets and DataEngines to display further data.<br />
<br />
'''Expected Results:'''<br />
A Context View that uses libplasma to provide an Amarok-specific way of viewing current data in a beautiful and innovative form. The basic structure and architecture is already there, but it needs substantial work to complete.<br />
<br />
Also, time permitting, the development of new applets and data engines for Amarok's CV.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, but this is probably a less KDE project as others. Experience with Qt is nice but by no means required, as it can be learned relatively easily.<br />
<br />
'''Mentor:'''<br />
Leo Franchi (lfranchi) is the original author of the Context View (in Soc 2007) and is willing to mentor any interested student. He can be contacted on #amarok at irc.freenode.net or (better) at lfranchi AT gmail DOT com.<br />
<br />
-----<br />
<br />
'''Project:''' Nepomuk collection<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a plug-in system that allows it to access music metadata from various backends. A plug-in to read and write data to and from Nepomuk should be written in this project. Additionally, Amarok should be extended to make real use of Nepomuk's capabilities by re-adding labels support.<br />
<br />
'''Expected results:'''<br />
A plugin to use Nepomuk as a metadata store from Amarok. Additionally, support for labels should be added to Amarok 2.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE would be helpful<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
-----<br />
<br />
'''Project:''' UPnP Support<br />
<br />
'''Brief explanation:'''<br />
Using the UPnP protocol users can, for example, share music from their Vista computer to a PS3. Amarok lacks any sort of UPnP support. Being able to act as a client (the PS3) or possibly a UPnP media server (Vista) would be useful. See [http://pupnp.sourceforge.net/ libupnp] for more information about UPnP's implementation in open source. The nature of how UPnP works would need to be researched a bit more, as the creator of this idea (Ian Monroe) has only seen it in use on friends computers. :)<br />
<br />
'''Expected results:'''<br />
*Using either Amarok's Internet Service framework or the straight Amarok collection framework, create a plugin which allows Amarok to browse and play music off of a UPnP share. Playing music may require the creation of a KIO for UPnP.<br />
*Allow Amarok to share it's collection with other devices via UPnP. This is secondary priority and may not be feasible to accomplish during Summer of Code.<br />
<br />
'''Material Prerequisite:''' Some UPnP devices or computers to test with.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and networking would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
-----<br />
<br />
'''Project:''' Amarok Scripting<br />
<br />
'''Brief explanation:'''<br />
Starting with Amarok 1.2, Amarok has enabled scripting through a script manager and its DCOP interface. For Amarok 2 we have a straight port of the old DCOP API to DBus. The old API was created over time, and perhaps could be thought out better. Additionally KDE 4 has introduced technology like Kross that could allow true integration of scripts into Amarok, including GUIs. In-process scripting has its own issues though!<br />
<br />
'''Expected results:'''<br />
*This is a more open-ended idea. Contact the Amarok mailing list or on IRC to get help working out the proposal.<br />
:*Perhaps redesign the Amarok DBus API <br />
:*..and/or add a Kross interface and then <br />
:*Create a script showcasing the technology.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and Ruby would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
<br />
-----<br />
<br />
'''Project:''' CD Ripping<br />
<br />
'''Brief explanation:'''<br />
Amarok has never really felt a need for good CD ripping support. We always felt there were better programs suited for this task. This hasn't stopped folks from finding ways to use Amarok to rip their CDs though. ;) <br />
<br />
'''Expected results:'''<br />
*An excellent CD ripping solution integrated into Amarok. <br />
*Cross-platform (Linux, Mac, Windows)<br />
*This task is not too large, so there would be higher standards of polish.<br />
<br />
-----<br />
<br />
'''Project:''' Mass-tagging<br />
<br />
'''Brief explanation:'''<br />
Users sometimes have poorly tagged tracks. Amarok has always lacked an easy way to download information about tracks from FreeDB or Musicbrainz and then tag multiple tracks at once.<br />
<br />
'''Expected Results:'''<br />
*To bring the functionality of programs like EasyTag or [http://musicbrainz.org/doc/PicardQt PicardQt] into Amarok.<br />
*A creative UI to accomplish the goal<br />
<br />
-----<br />
<br />
'''Project:''' Playlist and Playlist browser<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a snazzy new playlist, though its code could use some refactoring to take advantage of Qt 4.4 features. Also it is missing features from 1.4.<br />
<br />
'''Expected Results:'''<br />
*Mass inline tag-editing in the playlist (like in Amarok 1.4)<br />
*Allow users to pick which fields are shown<br />
*Dynamic playlist and smart playlist support<br />
*Improve memory management for large playlists<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential and knowledge of Qt is nice, experience with Model/Views in Qt is a bonus<br />
<br />
'''Mentor:'''<br />
Ian Monroe and other Amarok developers. <br />
<br />
----- <br />
'''Project:''' Media Devices as Collection Provider<br />
<br />
'''Brief explanation:'''<br />
Media device support is very important in a modern media player due to their widespread popularity. Media devices haven't found much love in Amarok 2 development. Amarok 2 has a flexible collection system, that was designed in part with media devices in mind. Whereas in Amarok 1.4 the collection was solely local files so the Collection Browser could only show local files. In Amarok 2 collections have been abstracted, allowing sources from the Internet and ''with this project'' media devices as well.<br />
<br />
'''Expected Results:'''<br />
*Integrate the media device framework into Amarok 2.<br />
*Support at least one kind of media device, while having the framework available for others.<br />
<br />
'''Material Requirements:'''<br />
A media device to test with.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, KDE.<br />
-----<br />
<br />
'''Project:''' Mp3tunes.com service synchronization<br />
<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an mp3tunes locker. This will allow us to use Amarok 2 for managing the mp3tunes locker as well as provide a framework for backing up all local content.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an mp3tunes locker as well as downloading content from the lock er to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the basic mp3tunes service . He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Ampache service synchronization<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an Ampache server. This will allow us to use Amarok 2 for managing the collection on the Ampache server. This will be a cross project task as the Ampache API used by Amarok 2 does currently not support uploading of content. There is great communication between the 2 projects, and the original Ampache API was developed in collaboration with Amarok developers.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an Ampache server as well as download content from the server to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the Ampache service. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Add new service<br />
<br />
'''Brief explanation:'''<br />
Add support for a new online service to the Amarok 2 service framework. This is a project that requires a student that already has a good idea or contacts with an interested service. Getting added to Amarok will mean that the service will have itself and its contents made available to a potentially huge new audience, and Amarok user will enjoy having access to even more great content. Ideas for services ( just to throw something out there ) could be the internet archives collection of live recordings, remixes from ccmixter.org, or something similar<br />
<br />
'''Expected results:'''<br />
Being able to play content from the service directly within Amarok. Depending on the type of service, downloads or purchasing of content might also be possible, as might other features unique to the service.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and many of the services. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----<br />
<br />
=== Digikam ===<br />
<br />
'' Project:'' Nepomuk integration<br />
<br />
''' Project Information:'''<br />
Integration between Digikam and Nepomuk could allow the user to better organize his/her pictures and access them easily from other apps, or even from other computers as Nepomuk is a networked system.<br />
<br />
'''Brief explanation:'''<br />
Nepomuk could allow the user to organize the pictures in a finer way : Nepomuk allows the user to define properties on his picture, extending the usecases of standard metadata (XML/IPTC/XMP...). The user can add any property under the form subject - predicate - object. Think of it as finer grained tags. You could for example define the predicate "is on the picture" to list all the people present on it (facebook does that). In a larger scope, the user can link picture to any resource known by Nepomuk (project, meetings...).<br />
<br />
The other advantage is that Nepomuk stores the information in a central index, which means that it can easily be accessed by other apps (I think of Akonadi). This allows tighter integration, as OS X does in its latest version with the iPhoto library.<br />
<br />
----<br />
<br />
=== Okular ===<br />
<br />
''Project:'' Okular backend<br />
<br />
'''Project Information:'''<br />
Okular has plug-in system that allow it read different documentation formats. It currently reads a range of formats, but there are several that might be able to be improved (e.g. XPS) or implemented.<br />
<br />
'''Brief explanation:'''<br />
The project would need to identify a format that requires improvement (or implementation). Candidates that have been requested in the past include the Microsoft Word (.doc) format and the .lit e-book format. Given a suitable library, potentially any format could be considered. Consider:<br />
* Microsoft Visio<br />
* Microsoft Access snapshot (would require implementing a .emf file renderer - not simple, but could be useful in many other places in KDE).<br />
<br />
Note that improving PDF requires changes to the poppler library, and you would need significant previous experience with PDF (and ideally with poppler) to make much progress.<br />
<br />
'''Expected results:'''<br />
A working backend, capable of rendering most documents to a readable level. <br />
<br />
'''Knowledge Prerequisite:''' C++ is pretty much essential, and at least passing knowledge of Qt. C programming experience may be useful for some libraries.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the okular mailing list.<br />
<br />
=== K3b ===<br />
<br />
'''Project:''' Port K3b to libburnia libraries<br />
<br />
'''Project Information:''' K3b currently uses cdrtools/cdrkit. This project should rewrite k3b to take advantage of three libburnia libraries - libburn, libisofs, libisoburn.<br />
<br />
'''Expected results:''' Experimental K3b branch with dropped support for cdrtools/cdrkit, and k3b features provided on top of libburnia libs backends.<br />
<br />
''trueg: I do not support the idea of dropping cdrecord integration. K3b already supports different backends. This architecture should be extended.''<br />
<br />
'''Contact for more information:''' mario AT libburnia-project DOT org<br />
<br />
'''Mentor (volounteer): Sebastian Trueg <trueg@k3b.org>'''<br />
<br />
=== Other applications ===<br />
<br />
==== Application User Interface Test System ====<br />
<br />
There are a couple of tools available for Qt / KDE that allow testing of applications - squish and kdexecutor. Both are binary only, and are specific to the systems that they are built on. <br />
<br />
It would be useful to have an open source tool that allowed us to test applications in a scripted way. Similar open source tools include Dogtail and LDTP, which use the accessibility interfaces in Gnome. <br />
<br />
There are arguments for and against using accessibility - it might be a lot more useful to implement a separate system, using some of the Qt4 specific features including QMetaObject. Qt4 has a nice set of hooks, and QTestLib shows how they can be implemented. However instead of requiring specific code in the application (as done by QTestLib), it would be more flexible to use LD_PRELOAD and a small interface library. <br />
<br />
More discussion: Brad Hards <bradh@kde.org><br />
<br />
==== (Multiple) image printing application ====<br />
<br />
This idea comes from my father, who is missing this kind of feature he was using in Paint Shop Pro. He says that there it was possible to open many images and when you selected them for printing the application would present you with a paper page, onto which you could drag the images, which were presented on a panel on the left side of screen. You could then interactively position and resize images on the paper and so see how the page look like when printed. There were also special functions available which would automatically resize and position the images.<br />
<br />
This application could also have a feature added to make it easier to print one image onto multiple pages (think posters). Here you could select how many pages of what size there should be and how many space on each page would overlap so you could glue the pages together after printing.<br />
<br />
I think it would be nice to also find a way to integrate such an application with imageviewer like Gwenview and photo management app like DigiKam.<br />
<br />
=== Usability ===<br />
<br />
The KDE Usability Project is willing to offer support mentoring to one or two projects (more if additional design mentors are available) which involve heavy UI development or UI redesign activities.<br />
<br />
=== Infrastructure ===<br />
<br />
KDE infrastructure tools, like Bugzilla, the Review Board, etc.<br />
<br />
=== KDE dependencies and non-KDE projects ===<br />
<br />
Depending on the relevance of the proposal, the KDE Project will accept student proposals on projects that are not part of KDE, but which are either KDE dependencies or relevant to KDE or the Free Software Desktop.<br />
<br />
==== Qt Cryptographic Architecture ====<br />
<br />
The Qt Cryptographic Architecture (QCA) isn't strictly part of KDE, however it is used in a range of KDE applications (and other applications). <br />
A range of projects are possible, in terms of adding security features to applications (e.g. SASL, encrypted content, client side puzzles). <br />
<br />
A specific need is the provision of alternative backends, which are typically the interface between QCA and some underlying crypto library. We already have several, but only the OpenSSL one is fairly complete, and OpenSSL is pretty ugly. A new backend would require some previous crypto knowledge, and ability to program in C++ and C. No GUI experience required! We probably only need one good alternative on each platform.<br />
<br />
- '''Alternative backend - GNU crypto libraries''': We have a basic backend using libgcrypt, which is mostly working. However a lot of the more interesting capabilities are present in gsasl and GNUtls. <br />
Mentor: Brad Hards <br />
<br />
- '''Alternative backend - Mozilla Network Security Services''': The Mozilla project has a library that is separately packaged on most Linux systems. It offers a fairly complete alternative to OpenSSL. We have a basic skeleton for NSS, but it only offers a couple of basic crypto primitives.<br />
Mentor: Brad Hards<br />
<br />
==== Strigi ====<br />
<br />
Strigi [1] and Pinot [2] are desktop search tools for the Linux and<br />
free Unix desktop. While targeted at different desktop environments,<br />
they have a history of collaboration, for instance on parsers for the<br />
Xesam query languages [3].<br />
<br />
Their features list overlap significantly as both projects offer most<br />
of the functionality users expect of desktop search systems.<br />
<br />
Both projects are written in C++ and feature an abstraction layer that<br />
makes them backend independent, though both only have one fully<br />
functional backend. Strigi's backend of choice is based on CLucene [4]<br />
while Pinot's is based on Xapian [5].<br />
<br />
This proposal is to bring this collaboration one step further by<br />
allowing them to use each other's indexing and search backends.<br />
<br />
Benefits include :<br />
* better abstraction layer for each project<br />
* wider testing of the respective back-ends<br />
* more choice to these projects' users<br />
* ease of evaluating and comparing CLucene and Xapian strengths and weaknesses<br />
<br />
The goal of project is to let Strigi use Pinot as a backend and vice<br />
versa so that both can query each others interfaces using<br />
the Xesam query language, and whatever query language is native<br />
to the backend.<br />
<br />
The emphasis is on completeness of querying. Performance optimizations<br />
and support for writing are secondary.<br />
<br />
[1] http://strigi.sf.net/<br />
[2] http://pinot.berlios.de/<br />
[3] http://www.xesam.org/<br />
[4] http://clucene.sourceforge.net/<br />
[5] http://www.xapian.org/<br />
<br />
==== Soprano & Nepomuk ====<br />
<br />
'''Project: Full Featured Query API'''<br />
<br />
'''Description''':<br />
For powerful semantic queries on the desktop we need a powerful query API. At the moment we are restricted to SPARQL queries which are then parsed by the Soprano backend. It would be much more efficient and easy to use if we had a query API that allowed to represent queries (independent of any query language) using a class structure. Queries could then easily be created, manipulated, and translated. Application developers would not have to learn a specific query language but would create a query object and have Nepomuk/Soprano evaluate that.<br />
<br />
This query API would become part of the official Soprano API and replace the simple Soprano::Model::executeQuery interface we have now.<br />
<br />
'''References:'''<br />
* Implementation of something similar in Java: http://sparql.sourceforge.net/<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
<br />
==== D-Bus ====<br />
<br />
* a named pipe or shared memory transport implementation for win32<br />
<br />
* can QLocalSocket and QSharedMemory (in 4.4) be used?<br />
<br />
==== APOC ====<br />
<br />
'''Project: KDE (KConfig) integration with APOC'''<br />
<br />
'''Project Information''':<br />
<br />
APOC (http://apoc.freedesktop.org) is a framework for centralized (e.g. in LDAP) storage and management of application and desktop configuration. It has integrations with the GNOME configuration system (gconf) and various desktop-independent applications (OpenOffice.org, firefox, Java). <br />
<br />
This project is to integrate APOC with KConfig so that KDE application preferences can be managed as well.<br />
<br />
APOC is also proposing another, different GSOC project using [http://live.gnome.org/SummerOfCode2008/Ideas GNOME as mentoring organisation].<br />
<br />
'''Knowledge Prerequisites''': <br />
* C++ coding <br />
* XML knowledge <br />
* KDE coding and configuration experience helpful<br />
<br />
'''Expected Result:'''<br />
* A documented mapping of KConfig preference structure onto the APOC file format.<br />
* A working KConfig backend that reads data from APOC<br />
<br />
'''Contact''': <br />
<br />
APOC is discussed on the [http://lists.freedesktop.org/mailman/listinfo/apoc apoc mailing list] (apoc@lists.freedesktop.org) and on the #apoc channel at irc.freenode.net.<br />
<br />
'''Mentor''': <br />
[mailto:joerg.barfurth@sun.com J&ouml;rg Barfurth]<br />
<br />
==== PolicyKit ====<br />
<br />
'''Project: PolicyKit Integration for KDE'''<br />
<br />
'''Description''':<br />
PolicyKit is a toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems.<br />
<br />
'''Expected results:'''<br />
* Provide a D-Bus session bus service that is used to bring up Qt/KDE authentication dialogs used for obtaining privileges.<br />
* Exemplary integration of PolicyKit within KDE (eg changing system clock from System Settings/clock plasmoid)<br />
* Write a Qt/KDE frontend to manage privileges<br />
<br />
'''References:'''<br />
* Specification: http://people.freedesktop.org/~david/polkit-spec.html<br />
* http://hal.freedesktop.org/docs/PolicyKit-gnome/<br />
<br />
'''Mentor:'''<br />
<br />
==== Other Freedesktop.org initiatives ====<br />
<br />
Both KDE and Gnome have previously acted as mentor organisations for projects that are under the Freedesktop.org umbrella. If you want to do a cross-desktop project, you can consider submitting it to one (or more) organisations. This is one case where you almost certainly want to have a mentor identified before you submit.<br />
<br />
If you submit to more than one organisation, please note which organisations you have submitted it to (since KDE has to coordinate with the other mentoring organisations).</div>Zwabelhttps://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas&diff=22367Projects/Summer of Code/2008/Ideas2008-03-21T12:24:40Z<p>Zwabel: Add proposal "mpx support for kwin", and add a comment to the kdm proposal.</p>
<hr />
<div>This page is an open list for ideas for the 2008 edition of [http://code.google.com/soc Google Summer of Code]. This page is open for new ideas from anyone - you do need to log in to the wiki to edit this page though (see below for why).<br />
<br />
This list is not exhaustive. It is just a collection of some ideas. To get further ideas, please feel free to use any resources and [[#Past_ideas|past ideas]].<br />
<br />
Before proceeding, '''read''' the [[Projects/Summer of Code/2008/Participation|participation instructions]] and [[#Notes_on_editing_this_page|the notes on editing this page]]. They are useful for students and developers alike.<br />
<br />
== Past ideas ==<br />
<br />
You may want to take a look at the ideas page for [http://wiki.kde.org/tiki-index.php?page=KDE%20Google%20SoC%202006%20ideas 2006] and [[Projects/Summer_of_Code/2007/Ideas|2007]]. Many of the ideas there are still valid today.<br />
<br />
== Notes on editing this page ==<br />
<br />
Before making any modifications, please '''log in''' to Techbase. This will help us track who is contributing to the ideas. This page is protected, so you can't modify it without logging in anyways.<br />
<br />
When adding a new idea, please bear in mind the question: can a student with very little knowledge of KDE code complete this work in three months? If you can't answer "yes", your idea is probably not for this page. Please remember that this is '''not''' a generic wishlist page for KDE developers.<br />
<br />
When making modifications to existing ideas, please consider whether you're changing it more fundamentally or just superficially. If your changes are substantial, you probably have an entirely new idea. Similarly, if your idea is modified and you feel it no longer reflects your original thought, please split the idea in two, restoring yours.<br />
<br />
Please use the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] if you want to discuss an idea.<br />
<br />
Finally, do '''not''' delete ideas without a reason for doing so (like, for instance, being contrary to KDE ideals, being completely unrelated to KDE, being unfeasible, etc.) -- you may want to state in the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] why you removed the idea.<br />
<br />
Do '''not''' re-add ideas that were removed without discussing first with the developers of the target application.<br />
<br />
== Project ideas ==<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 />
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 />
When adding an idea to this section, please try to include the following data:<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 />
=== KDE Libs ===<br />
<br />
==== KDE Core libraries ====<br />
<br />
The KDE core libraries (kdecore, kdeui, kio, kparts) are the most basic libraries that all KDE applications depend upon.<br />
<br />
----<br />
'''Project:''' ODF writer<br />
<br />
'''Brief explanation:'''<br />
The ODF file format could be used for a wide range of applications, not just traditional office tools such as a word processor or spreadsheet.<br />
<br />
As an example, consider a tool like ksnapshot (which does screenshot captures). When writing documentation on how to perform some task with an application, you might work through the application taking many screenshots. If we had a class in kdelibs that could write ODF files, and the right application integration, perhaps the tool could create a file full of screenshots, which could then be annotated with some explanation to create a "visual guide" for that task.<br />
<br />
ODF is a pretty simple format to write (much less simple to read, because of the many options), and there is significant expertise in the KOffice community on that format.<br />
<br />
'''Expected results:'''<br />
* Properly designed, implemented, documented and tested class(es) for ODF writing.<br />
* Two usages of the class in different KDE applications (e.g. Okular and ksnapshot).<br />
<br />
'''Hints for proposal:'''<br />
* Explain what design and coding principles you will apply (goal: convince us that the code will be suitable for kdelibs)<br />
* Identify schedule for each element (goal: demonstrate that the task can be completed in the time you have available)<br />
* State your understanding of ODF (goal: demonstrate commitment to the task outcomes)<br />
<br />
'''Knowledge prerequisites:''' Sound C++ and Qt knowledge. Some familiarity with other ODF tools would be useful. <br />
<br />
'''Mentor:''' TBA<br />
<br />
----<br />
'''Project:''' Diskspace Service<br />
<br />
'''Brief explanation:'''<br />
<br />
Applications that write large amounts of data to partitions must nor fill them up completely. As an example there is strigi/soprano which can have a large index and will fill your ~ until 0 bytes remain. Other applications are e.g. those that write data to .thumbnails.<br />
<br />
To prevent this there is the need for a service that can be queried by applications, whether the user-set limit of remaining MB is already reached or not.<br />
<br />
As an extra the user could be notified if the set limit is reached.<br />
<br />
Mentor: Sebastian Trueg<br />
<br />
----<br />
'''Project:''' Support for fingerprint authentication<br />
<br />
'''Brief explanation:'''<br />
Many laptops come with a simple fingerprint scanner that can be used to authenticate users. It would be nice if KDE had support for these fingerprint scanner integrated. This way you could use them to log into KDE, unlock KWallet, maybe even use it to enter nickname in highscores for games... It would probably be a good idea to work with [http://reactivated.net/fprint/wiki/Main_Page fprint] project when integrating the support.<br />
<br />
----<br />
'''Project:''' Smart toolbars<br />
<br />
'''Brief explanation:'''<br />
Currently the policy is to have as few buttons in toolbar as possible by default. Only the ones that have a very high chance of being used by almost all users of an application. Maybe there could be an option added to toolbars so that it would monitor which actions (from menus) the user uses. When the new smart toolbar notices that the user has used some action very frequently and which doesn't have a button in the toolbar yet, it could suggest to the user to automatically add it to the toolbar. Buttons could also be removed after not using toolbar buttons for a long time. Off course there should be 3 options for this feature: 1. to automatically add and remove toolbar buttons without asking, 2. to ask before adding or removing, and 3. to disable this feature so that toolbars are the same as now.<br />
<br />
----<br />
<br />
'''Project:''' Beautify KNotify / Support Growl themes<br />
<br />
'''Brief explanation:''' In its current form KDE notifications are quite "basic" -- one might even say ugly. With WebKit as part of Qt 4.4, implement "CSS-able" notifications similar to (and ideally compatible to) [http://growl.info/about.php Growl]. Growl is a framework for Mac OS X and its free software under the 3-clause BSD License. Adopting the same license for KNotify's theming code may ensure future code exchange between both projects and theme compatibility.<br />
<br />
'''Expected results:''' Similar capabilities to what's shown in the video on http://growl.info/about.php and in the screenshots on http://growl.info/screenshots.php<br />
<br />
==== Solid ====<br />
<br />
Solid is the KDE hardware abstraction layer, that enables KDE programs to get consistent results when running on different platforms.<br />
<br />
==== Phonon ====<br />
<br />
Phonon is the KDE audio abstraction layer, that enables KDE programs to produce basic and medium-level multimedia functionality in any platform without platform-specific code.<br />
<br />
==== KHTML ====<br />
<br />
KHTML is the current KDE HTML engine, used by the Konqueror web-browser and other applications to display HTML in their interfaces.<br />
<br />
'''Project:''' Implement HTML 5 features<br />
<br />
'''Brief explanation:''' HTML 5 will bring many new features. The student gets to pick and propose one or several of those features from the draft. Projects could encompass implementation of DOM Storage or SQL interfaces for example.<br />
<br />
'''Project:''' Web-based desktop<br />
<br />
'''Brief explanation:''' The advancement of Web technology (DHTML, XMLHTTPRequest, CSS, Canvas) nowadays allows for the implementation of complex GUIs that can compete with native programing toolkits. This project would involve the implementation of a KDE desktop including icons and menus that is solely based on HTML, JavaScript and CSS. An examplaric feature: render the content of .desktop files in HTML. This could either be served through a backend server or a custom KHTML part that provides such code and offers extensions to load from and store data on the hard disk.<br />
<br />
==== KJS ====<br />
<br />
KJS is the JavaScript engine used by KHTML and Kross to run JavaScript programs.<br />
<br />
'''Project:''' ECMAScript 4 classes<br />
<br />
The draft for ECMAScript 4 on www.ecmascript.org mentions several new built-in types like Vector and Map. Existing implementations that already cover part of the future standard (like ActionScript) also feature classes like ByteArray. Other ideas are KDE specific likes like KIO bindings. Students are invited to select and implement a subset of these classes.<br />
<br />
'''Project:''' Pre-compiled JavaScript programs<br />
<br />
As announced [http://www.kdedevelopers.org/node/3323 recently] the [http://websvn.kde.org/branches/work/kjs-frostbyte/kjs/ kjs-frostbyte] branch now features a byte-code version of KJS. From there the step to pre-compiled executables, i.e. binary blobs that contain code as well as data and can be executed from the shell like normal executables is not very big.<br />
<br />
==== Sonnet ====<br />
<br />
Sonnet is the KDE grammar, spell-checker and language-detection engine.<br />
<br />
==== Kross ====<br />
<br />
Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and KDE JavaScript transparently into native applications to bridge the static and dynamic worlds together.<br />
<br />
==== Oxygen ====<br />
<br />
Oxygen is the KDE 4's default look-and-feel. It comprises of the Oxygen icon set (including the palette and guidelines for icons), the Oxygen sound theme, the Oxygen wallpaper collection, the Oxygen window decoration and the Oxygen widget style. Note that for Summer of Code, you must produce code, so the window decoration and widget styles are your more likely candidates.<br />
<br />
==== KDE-Print ====<br />
<br />
* Implement an easy usable [http://www.fineprint.com/products/fineprint/index.html fineprint-like] solution for collecting pages from different printing sources (browser, kword, krita...) and allow it to rearrange single pages (not printing jobs), delete pages, add blank pages. Information also in wish-list-item: [https://bugs.kde.org/show_bug.cgi?id=90989 90989]. I am the reporter of this wish, you can contact me there. I do not have the abilities to program, but I am willing to help testing an implementation and discuss how it should look like.<br />
* WARNING! i'm doing exactly this for my semester project at school (we are two students, so we can't apply for SoC with this). We are probably developing it in pure QT (the other student is a gnome user).You can get in contact with me: asranie@fryx.ch<br />
<br />
=== KDE Base applications ===<br />
<br />
==== Konqueror ====<br />
<br />
Konqueror is KDE's powerful web browser and file manager.<br />
<br />
'''Project: Bookmark Wallet'''<br />
<br />
'''Description:''' This isn't actually a project to be a part of Konqueror itself, but rather a separate application similar to KWallet. The application should provide a database for the storage of URL bookmarks. The database should be able to connect to remote storage, such as the Google bookmarks service, for synchronization and backup. The URLs should be easily manageable, and include a concept of ratings for the URLs. A plugin should be written to allow Konqueror to easily interface into the system, or preferably Konqueror itself should be modified to use the storage system when it is available. The application should provide an interface which is easy to connect to from a browser plugin, so that plugins could be written for other browsers, such as Firefox, as well. There should also be a plugin interface into the database, to allow support for other remote storage backends, such as foxmarks, to be created. The application should handle multiple concurrent connections to the database without issues. Additionally, the application should provide an event interface to notify all connected browsers whenever a bookmark is added, changed or removed.<br />
<br />
Comment: Rather than developing a separate application, interested students should have a look at the [http://websvn.kde.org/trunk/KDE/kdepim/akonadi/resources/localbookmarks/ Akonadi resource localbookmarks]<br />
<br />
Comment: Would be great if this would include saving RSS-Feeds in as well, synchronising them with webbased feedreaders<br />
<br />
Comment: a database of feeds would indeed be great. If implemented with a "feedtype" field, it would solve the problem of feeds containing news that's best read in a traditional aggregator, audio that's best heard in a music player, video that's best seen in a video player, etc. Apps could just open the query the feed DB for suitable feeds. Or perhaps they could query for feeds with particular enclosure mimetypes? Hmm. That raises the issue of pre-loading the feed, and integration with libsyndication.<br />
<br />
==== Dolphin ====<br />
<br />
Dolphin is KDE 4's default file manager application.<br />
<br />
'''Project: Support Windows' "Previous Versions"'''<br />
<br />
'''Description:''' Shadow Copy (also called Volume Snapshot Service or VSS) is a feature introduced with Windows XP with SP1, Windows Server 2003, and available in all releases of Microsoft Windows thereafter, that allows taking manual or automatic backup copies or snapshots of a file or folder on a specific volume at a specific point in time. It is used by NTBackup and the Volume Shadow Copy service to backup files. In Windows Vista, it is used by Windows Vista's backup utility, System Restore and the Previous Versions feature. Samba supports Shadow Copy since version 3.0.3.<br />
<br />
==== Konsole ====<br />
<br />
Konsole is KDE's terminal application.<br />
<br />
==== Kate and KWrite ====<br />
<br />
Kate is KDE's Advanced Text Editor, both a full-featured text editor application and a KPart engine ready for embedding into other applications (like KDevelop, Quanta and Kile). KWrite is a simple text editor based on the KatePart engine and is KDE's default text editor.<br />
<br />
----<br />
<br />
'''Project:''' vi mode for the Kate editor<br />
<br />
'''Project overview:''' Create a vi-like modal editing mode for the Kate editor part and improve the kate command line to a point where it can be used efficiently for vi commands in this mode.<br />
<br />
'''Expected results:''' This project should implement a vi-like, modal editing mode for kate. This mode will be selectable by the user.<br />
<br />
'''Mentor:''' Christoph Cullmann has agreed to mentor this project.<br />
<br />
==== System Settings ====<br />
<br />
'''Project: A system settings module for creating backups'''<br />
<br />
'''Project Information''':<br />
The idea is twofold:<br />
<br />
Create a System Settings control module for scheduling backups. Rather than pick a specific backup technology, it would support multiple backends, such as tar, dar, rdiff-backup and rsync-backup. By making it backend agnostic, it could be used with any file-based backup tool. It would therefore be more robust and easier to adopt than previous backup GUIs.<br />
<br />
To benefit the most users, the control module would be based on a non-KDE library so the technology could be reused in Gnome and other desktop environments. Therefore ideally, the implementation would take the form of a Freedesktop.org project that focuses on the functionality most backup programs share: selecting a root directory to backup and a destination directory, inclusion and exclusion rules, a choice between full or incremental backup, and whether to use compression and/or encryption. The goal would be to develop a descriptive backup file format that is not tied to any specific implementation, and a library that can read such files and generate the appropriate command line flags to create the backup with a given backup tool. A secondary goal would to create a sensible set of defaults for creating backups. That would involve collecting a list of common directories that can be excluded (such as trash directories, common web browser caches, and mount points) so that users do not have to waste time tweaking their exclusion rules.<br />
<br />
Usage cases:<br />
<br />
Average Joe is new to Linux, and wants to make a backup of his computer. He sees "Backup Settings" in KDE4's System Settings (or Gnome's Administration menu). Since the module is part of the upstream desktop environment, it doesn't matter which distribution he's using.<br />
<br />
Joe has been making backups to writable DVDs using the DAR backend of the backup control module for several weeks, when he gets an external hard drive. Now he wants to make the same backup to his external hard drive instead. He does not have to learn how to use a new program; he simply selects the rsync-backup backend and specifies the new destination.<br />
<br />
'''Expected Result:'''<br />
* A library that maps standard backup options (like include/exclude rules) to the command line options for several popular backup tools.<br />
* A working KControlModule for KDE4 that allows users customize and schedule backups.<br />
<br />
'''Currrent Knowledge''': <br />
* I have a little experience with C++, and have dabbled a bit in PyKDE<br />
<br />
'''Contact''': <br />
<br />
If you think the idea is interesting and would like to mentor such a project, my email is (wmhilton+gsoc@gmail.com)<br />
<br />
<br />
=== KDE Workspace ===<br />
<br />
==== Plasma ====<br />
<br />
Plasma is KDE 4's desktop and panel tool, replacing KDE 3's kicker and kdesktop. It's an advanced and powerful application with revolutionary ideas.<br />
<br />
* '''Plasma Packages'''<br />
** Plasma provides a simple packaging system for widget (plasmoids), SVG themes, wallpaper sets and indeed any type of application add-on data. It is not a replacement for apt, rpm, klick, etc. but rather is designed to help with the challenge of creating, sharing, installing and managing run time add-ons as have been made popular with KDE's Get Hot New Stuff framework.<br />
*** ''Project I: A GUI Creator For Packages'': This project involves taking the already started user application "plasmagik" and refining it to be ready for production use. The application must take a plasma package description, display it in a user friendly way in the UI and allow the user of the application to add files to the various nodes in the structure (e.g. graphics to an "images" entry). In particular this project would consist of:<br />
**** Removing assumptions based on the plasmoid package structure and instead using the generic Plasma::PackageStructure class.<br />
**** Making the UI more user friendly<br />
**** Streamlining the upload support<br />
**** Writing a tutorial on KDE's TechBase on how to employ the application as an add-on creator.<br />
**** As the plasmagik application already has had a fair amount of work done it and an active community of developers interested in its future, the scope and support for this project should be within the limits and expectations of the SoC.<br />
*** ''Project II: Package Management'': This project involves creating a small utility application consisting of a dialog and a control panel that uses it which allows the user to list, share and remove installed Plasma packages. As there are no dependencies, binary compatibility, etc issues usually associated with full package management applications, this would be well suited to a SoC project. <br />
* '''Zeroconf Integration''': This project would involved adding a zeroconf announce and discovery feature to libplasma that would provide a Plasma::Applet with a simple API to find other Applets of the same type on the local network. A test plasmoid would be created to prove the working status of the zeroconf support. Remaining time would be spent adding zeroconf features to applicable existing plasmoids.<br />
* '''DataEngine + Plasmoid for zeroconf services''': Browser for zeroconf services available (perhaps doable with above project as well?)<br />
* <s>'''Physics Engine''': Take an existing 2D physics engine and experiment with using it within a containment to emulate "natural" object interactions.</s> taken<br />
* '''Setting a video as desktop background'''<br />
* '''Dynamic desktop background''': A desktop background which displays different wallpapers according to information like time of the day, season, weather etc.<br />
* '''Mobile device containment''': Implement a Plasma::Containment that is appropriate in form factor and UI layout for a UMPC/tablet style device.<br />
* '''Touchscreen profile''': The use of UMPC form factors with a touch screen is increasing -- certainly in some business areas. Plasma is prepared for handling different form factors and for providing a user interface experience that adjusts to device characteristics. The touchscreen profile SoC project (touchscreen hardware will probably be arranged through the mentors) aims to identify where Plasma / KDE works well and where it doesn't on small (VGA or SXGA) screen sizes; then it will fix the bits where it doesn't work well and introduce a general mechanism for handling small screens. In addition, UMPC on-screen keyboards introduce new UI challenges; integrating these in a meaningful way with plasma is an extra part of this project (or possibly an extra project). Dialog and menu handling on small screens, with pagination of menus and (re)pagination of tabbed dialogs is another topic. '''Mentors:''' Adriaan de Groot and Armijn Hemel.<br />
* '''Phase''': improving the Phase/Animator system by:<br />
** implementing animation curves (already in the API and used by plasmoids, but not actually implemented)<br />
** optional keys for individual animations, allowing them to be turned off or otherwise tweaked individually / in groups<br />
** chaining animations<br />
** going through uses of customAnimation in libplasma using code and reimplementing generally useful ones within Animator itself<br />
<br />
==== KRunner ====<br />
<br />
KRunner manages the screen locking, run command dialog and provides a general natural language interface to applications, desktop services, network locations, files and data (e.g. math calculations, spell checking, word definitions, etc). It replaced the Run Command dialog in kdesktop from KDE3, is multithreaded and shares code with Plasma.<br />
<br />
Some of the items below may take an entire SoC project, others may be better combined to flesh out an entire summer's worth of work.<br />
<br />
* '''Ranking''': Results are returned to KRunner by individual runners. These result must then be ordered for the user prior to display. This project would consist of improving the ranking of returned results by working on two related fronts:<br />
** Tweaking individual runners to more accurately rate their own results.<br />
** Improving the final ranking system employed by the host application.<br />
* '''Abstracting runner management out of KRunner''': The main pieces of using runners (SearchContext, SearchMatch and AbstractRunner) exist in a shared library (libplasma). However, much of the code for managing the actual runners at runtime is contained within the krunner application itself. Abstracting this code out would make it easier for other components and applications to user runners as well.<br />
* '''Using runners in Kickoff''': The kickoff menu has a search tab. Currently it does it's own internal search. It should, instead, be using AbstractRunners for this. This task would go well with the runner management task above.<br />
* '''Xesam search runner''': Write an AbstractRunner plugin that uses the Xesam query spec to forward user queries to a search store. The trick will be in making it performant as well as providing support for paging through requests.<br />
* '''Write as many runners of your choice''': one might call this a "marathon" (get it? runners? as many as you can? ahaha! *sigh*). I wrote [[http://aseigo.blogspot.com/2007/10/what-runners-do-we-need-want-dream-of.html this blog entry]] looking for ideas for runners and got many, many suggestions. I think it reasonable to expect that over the course of a summer's work one might be able to write 5-10 runners depending which ones were selected.<br />
<br />
==== KWin ====<br />
<br />
KWin is KDE's X11 Window Manager program, greatly improved when compared to its older brother in KDE 3.<br />
*'''Compiz-like Effects in KWin''': Effects like Desktop Cube often greatly improve the usability, especially when it comes to multiple desktops, and they are just cool.<br />
<br />
*'''Make KWin multi-pointer ready''': Mpx is an extension of the X-Server currently living in a branch, that is planned to be merged in one of the next versions(see http://wearables.unisa.edu.au/mpx/). Once it's merged, the x-server will support an arbitrary count of simultaneous active pointers/cursors(A mouse and a keyboard paired together) and multiple active windows, allowing input from multiple users at the same time. The window-manager needs to be aware of the multiple cursors, and needs to dynamically assign pointers to applications that are not mpx-aware(Which will be all, in the beginning). Also it might be nice having a plasma-applet that allows easy spawning/removing of additional cursors.<br />
<br />
==== KDM ====<br />
<br />
KDM is KDE's Display Manager and login application.<br />
*'''More Ways of entering login data''': Currently, KDM only supports logging in with Username and Password in two fields on the one login mask. Entering first Username and then Password in two separate masks (Yeah, just like GDM) or searching for users while typing in the letters of a username would be really handy and cool. Another interesting thing to investigate would be "log in by finger-print".<br />
<br />
==== KScreenSaver ====<br />
<br />
*'''Plasma Dashboard Screensaver''': There could be a new default screensaver added. When started it would show the Plasma Dashboard with all the plasmoids on it. The Dashboard could be the default one (the one that shows up when you press Ctrl+F12) or the user could create a custom one just for this screensaver. These two options should be in the screensaver's properties. For creating custom layout there should be some tool to set background and add plasmoids.<br />
<br />
=== KDE Runtime ===<br />
<br />
''' Project''': KHelpcenter: What's this explosion<br />
<br />
'''Description''': A lot of help about elements of the user interface is available in the form of "What's This?" texts. Unfortunately it's pretty cumbersome to get to this information for a user as it needs clicking on the "question mark button" in the title bar of the window/dialog and then clicking on the user interface element. This project is about making this information more conveniently available by providing an "exploded" view of the "What's This?" help as part of the application's manual in KHelpcenter.<br />
<br />
All "What's This?" texts of a given window could get displayed in a view at once, e.g. by using some bubble views and connecting lines to the interface elements. These views could be extracted from the run-time instances of the windows by inspecting the widget hierarchy. This could either be done as a special offline run to pre-generate help pages or dynamically at run-time of the application. Investigations of what method would be the best would be part of the project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': KHelpcenter: Cheat sheets<br />
<br />
'''Description''': Task based documentation of applications can often be presented best as step-by-step instructions how to achieve certain user goals. With the help of application's D-Bus interfaces KHelpcenter could be extended to provide interactive versions of these step-by-step instructions. Users would be provided with explanations and instructions how to accomplish tasks together with links that would open corresponding dialogs, execute described actions, etc. In the Eclipse project this kind of help is called cheat sheets.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KOffice ===<br />
<br />
==== KWord ====<br />
'''Project:''' Improve ISO OpenDocument support<br />
<br />
'''Explanation:''' Improve loading and saving of the ISO OpenDocument format what includes 1) extend the current saving code, 2) extend the current loading code and 3) probably also extend the rendering engine aka the text flake-shape.<br />
<br />
'''Expected results:''' be sure everything we are able to load, display and edit is also saved back correctly using the default file format.<br />
<br />
'''Mentor:''' Sebastian Sauer <mail@dipe.org><br />
<br />
-----<br />
<br />
'''Project:''' Collaborative editing of documents over a network.<br />
<br />
'''Explanation:''' Make it possible for two or more users to work at the same document in KWord at the same time over a network. Both users would open the same document, and changes made by each user are synchronized to the other user's editing session.<br />
<br />
----<br />
<br />
'''Project:''' Version control integration.<br />
<br />
'''Explanation:''' Integrate version control system support with KWord to allow easy control over revisions of documents. It should be possible to connect with remote revision control systems, to allow collaborative work on projects, similarly to how software is developed. It should be easy for the user to browse through the history of document versions in the version control system, to see what has changed. CVS, Subversion and git should be supported.<br />
<br />
----<br />
<br />
'''Project:''' Improve legacy MS Office (2003) documents support<br />
<br />
'''Explanation:''' Current MS Office formats support is kinda limited (especially write support). To decrease the barrier for adoption, better MS Office support is a way to do that.<br />
<br />
==== KSpread ====<br />
==== Kexi ====<br />
Kexi is an integrated data management application for desktop users like Microsoft Access.<br />
<br />
-------<br />
'''Project:''' Improve Kexi Data Import/Export<br />
<br />
'''Brief explanation:''' Currently Kexi allows importing CSV files into an existing database, and converting MySQL/PostgreSQL/MS Access databases into Kexi databases.<br />
<br />
The aim of this project is to provide plugin(s) that import from more database backends/formats.<br />
<br />
You can select backend you want to implement migration for:<br />
<br />
* HSQLDB - the OpenOffice.org Base's DB backend (ODB file format, very important to have)<br />
* ODBC<br />
* Paradox<br />
* DBase (e.g. using [http://linux.techass.com/projects/xdb Xbase])<br />
* Firebird (note: pending licence checks if we want GPL-compliance)<br />
<br />
For the ODBC driver, a migration plugin and a backend plugin should be provided. For Paradox, only a migration plugin is required, although this will require modifying the migration framework to allow more than one file to be selected as the source database (i.e. the database to be imported).<br />
<br />
Both a migration plugin and a backend plugin could be provided for HSQLDB, which should be implemented using JNI to invoke JDBC methods in the HSQLDB library. To avoid Java and OO.org dependencies, a small tool could be developed in Java to export/import to/from a intermediate format, and then used from within a Kexi migration plugin.<br />
<br />
In any case, migration plugins are simpler to implement than direct access plugins (drivers), so these can be developed first.<br />
<br />
'''Expected results:''' HSQL support would enable OpenOffice.org Base format for KDE and KOffice itself, a good companion to already existing OpenDocument support. ODBC connectivity would add many new possibilities directly to KDE.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:'''<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_DBaseMigrationPlugin "DBase Migration Plugin for Kexi" proposed by Jonathon Manning in 2006]<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_ParadoxAndHSQLAccess "Paradox & HSQL access for Kexi" proposed by Joseph Wenninger in 2006]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl>, Sebastian Sauer <mail@dipe.org><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Kexi Web Forms<br />
<br />
'''Brief explanation:''' Web Forms allow to read-only or read-write access to database projects created with Kexi. It is optional feature for uses where client has no Kexi installed for any reason. The fact that the Web Forms will use Web standards, adds another advantage over competitors like MS Access (which uses proprietary Windows-only ActiveX bindings).<br />
<br />
Proposed solution is to develop a small standalone web server. It is probably already written in C++ or C by FOSS community. Good examples are lighttpd - http://www.lighttpd.net/ <br />
and (being already in KDEnetwork module) KPF - http://rikkus.info/kpf.html.<br />
<br />
The web server would be dynamically linked to kexidb and thus can access Kexi databases via universal KexiDB API, and create HTML content on demand as an answer to HTTP requests.<br />
<br />
For alternative solution see "Alternative solution for Kexi forms using PHP" below.<br />
<br />
'''Expected results:''' Shortly, it is internet-enabler for KOffice/KDE data management.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++ and HTTP/web standards, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:''' [http://jacek.migdal.pl/gsoc/ Solution proposed by Jacek Migdal last year]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Alternative Solution for Kexi Forms Using PHP<br />
<br />
'''Brief explanation:''' Create a Kexi plugin generating PHP code saving it directy to the filesystem. This will require Apache (or other PHP-compatible web server) to be present and configured, and also will require the plugin to be packaged with a script that will install appropriate tools that allow r/w accessing the Apache/php subdirs.<br />
<br />
'''Expected results:''' The generated code could directly access MySQL or PostgreSQL servers at the backend, so users could immediately have a robust server-side solution without complex requirements.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of PHP, web standards and C++, (knowledge of Qt is recommended)<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
==== Krita ====<br />
<br />
'''Project:''' Sumi-e brush engine<br />
<br />
'''Project Information:''' While there is already an attempt at a sumi-e brush engine in Krita, the current code is limited and uses an old-fashioned way of simulating brushes. <br />
<br />
'''Expected results:''' This project should implement an anti-aliased, bidirectional ink-transfer simulation of a sumi-e brush, together with a user interface to define brushes. The brushes should react to pressure, tilt and rotation of the a tablet stylus. The results should be realistic. Loan hardware for use during the development phase is available.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic knowledge of basic 2d graphics principles. A list of relevant papers and books is available.<br />
<br />
'''Mentor:''' Boudewijn Rempt <boud@valdyas.org> The mentor can help preparing the project proposal for submission to Google.<br />
<br />
-----<br />
<br />
'''Project:''' Sketch-pad interface for Krita<br />
<br />
'''Project Information:''' Krita is a large and complex application built around a sophisticated painting engine. The goal of this project is to create a new interface around the Krita engine, specialized for quick sketching.<br />
<br />
'''Expected results:''' This project should implement a new interface around Krita, presenting the user a single-layer plus tracing paper interface with a single freehand sketching tool. Easy to use and graphic color and paint operation (brush, pencil, eraser etc.) interface elements must be designed and implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:''' <br />
<br />
-----<br />
<br />
'''Project:''' Shader filters and generators for Krita<br />
<br />
'''Project Information:''' Some initial work has already been done to make it possible to write filters in the OpenGL shading language. This project should take that initial code as a basis and implement a fully functioning plugin for Krita that allows filters and shaders to be executed on images in any colorspace.<br />
<br />
'''Expected results:''' The plugin should have a finished user interface and make it possible to experiment with shader filters in an interactive way. Example filters must be implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, OpenGL.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Animation support<br />
<br />
'''Project Information:''' There is no support at all in Krita for animated images such as GIF or MNG or for working with images in an animation context, such as textures or backgrounds in applications like Blender. The applicant should first investigate user needs and use cases and then implement support in the user interface and in the import/export filters.<br />
<br />
'''Expected results:''' A user-friendly way of working with animated images (i.e., not by making each frame a layer), but e.g. a docker that shows the the animation running in thumbnail format. Import/export filters for relevant file formats.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' RAW plugin<br />
<br />
'''Project Information:''' Krita's current raw plugin is based on a shell exit to dcraw. This is not sufficient and needs to be re-implemented.<br />
<br />
'''Expected results:''' A next generation plugin should implement loading of raw images either through libopenraw or libkdcraw; preferably designed in such a way that we can switch libraries when opportune. The plugin should allow the user to set conversion parameters in a way that is useful to photographers. An extension to this project could be the implementation of a bayer colorspace model: that is, a colormodel that allows us to load the raw images and edit them in the native raw format, without conversion.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' PSD and Gimp plugins<br />
<br />
'''Project Information:''' Krita is powerful enough to handle nearly all that the Gimp and Photoshop are capable of saving. This project is about creating dedicated file import/export filters that can handle as much of these file formats as possible, possibly through the use of existing libraries.<br />
<br />
'''Expected results:''' 4 plugins: psd import/export and xcf import/export. These plugins should be able to handle complex files in all supported colorspaces.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Photoshop-compatible brush engine<br />
<br />
'''Project Information:''' A paintop plugin that can load and handle current photoshop brushes. This entails reverse engineering of the Photoshop brush file format and implementing a procedural brush engine that matches the Photoshop brush engine.<br />
<br />
'''Expected results:''' A procedural brush engine with settings dialog that can load and save current photoshop brush files.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Workspaces<br />
<br />
'''Project Information:''' A workspace is a loadable package of settings that finetune Krita for a particular purpose. A workspace could contain additional plugins (like an image browser plugin for batch operations) and a subset of resources. Example workspaces could be batch-editing of images, editing of animation sequences or painting or sketching.<br />
<br />
'''Expected results:''' the user interface and framework to make packages of plugins and resources that users can switch between. Also extra plugins to extend krita in areas like batch processing that do not exist yet.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:''' <br />
<br />
<br />
-----<br />
<br />
'''Project:''' Kipi and digikam plugins compatibility<br />
<br />
'''Project Information:''' Kipi and digikam provide lots of interesting plugins for working with 8 and 16 bit RGBA images. It would be great to be able to re-use those plugins from within Krita.<br />
<br />
'''Expected results:''' Two plugins that load kipi and digikam filters into two new menus in the filter menu. Code to convert Krita layers to the digikam image representation and back, taking care of icc profiles and other niceties.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:'''<br />
<br />
=== KDE SDK ===<br />
<br />
==== Umbrello ====<br />
<br />
Umbrello is the UML drawing and design tool in KDE.<br />
<br />
----<br />
<br />
'''Project:''' Add the capability to draw SysML diagrams (http://www.omg.org).<br />
<br />
----<br />
<br />
'''Project:''' Port Umbrello to QGraphicsView<br />
<br />
----<br />
<br />
==== Kobby ====<br />
<br />
<br />
'''Project:''' Kobby. A text editor which allows multiple users modify a set of documents at the same time. This is called a collaborative text editor.<br />
<br />
'''Brief explanation:'''<br />
* The idea is to create a KDE based application that depends on the [http://gobby.0x539.de/trac/wiki/InfinoteProtocol infinote] library which is the successor of the obby library.<br />
* It would be really nice to have integration with already existing editing and coding solutions: as KDevelop, or Kate for instance.<br />
* It would be even better if it was a katepart plugin so it can be used everywhere kateparts are used. The plugin integration can probably be done by extending KTextEditor to use the infinote API.<br />
<br />
You can find the [http://gobby.0x539.de/trac/ Gobby page here], where you can [http://gobby.0x539.de/trac/wiki/InfinoteProtocol also check out the infinote] library code. Svn repository: svn://svn.0x539.de/infinote/trunk<br />
<br />
'''Mentor:''' Andreas Ramm <psychobrain@gmx.net><br />
<br />
COMMENT: I had filed my vision of collaborative editing in KDE applications as wishlist item [http://bugs.kde.org/show_bug.cgi?id=149498 149498].<br />
Also see bugs [http://bugs.kde.org/show_bug.cgi?id=79721 79721] and [http://bugs.kde.org/show_bug.cgi?id=145011 145011]<br />
<br />
COMMENT: Infinote is under heavy development, and both the protocol and the library API have gaps and are subject to change. Whether you view this as a drawback or a chance to help shape and be on the cutting edge of open-source collaborative editing is down to you.<br />
<br />
COMMENT: Notes and Ideas can be found at the [http://mateedit.wiki.sourceforge.net/MateEdit Mateedit Wiki page]<br />
----<br />
<br />
=== KDE Edu ===<br />
<br />
==== Marble ====<br />
<br />
'''Project:''' Vector-Tiles for Marble <br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/marble Marble] is a generic geographical map widget and framework that is meant to be used by KDE4 applications. It is also distributed as a standalone application in KDE4.<br />
<br />
'''Brief explanation:'''<br />
* Marble can download and texture map texture tiles ( see http://www.kdedevelopers.org/node/3269 )<br />
* For implementing stuff like routing etc. properly we need a vector representation of streets and other features. One strategy to add those would be in terms of tiles similar to texture tiles.<br />
* Source data could either be VMap0 ( http://en.wikipedia.org/wiki/Vector_Map ) or OpenStreetMap data. You'd first need to find a way to create some vector tiles from this data stored in a suitable efficient format. These would need to get put onto the server. <br />
<br />
* Based on the Marble Layer Management architecture (which is currently in the works) you'd need to create a vector layer plugin which maps the vector tiles in the given projection. The vector layer data would internally use Marble's given data structure which is similar to the KML format ones. You'd need to extend that structure by vector features which are in the spirit of those provided by KML.<br />
<br />
* Ideally you'd also provide ways to select features using the mouse.<br />
<br />
'''Expected results:'''<br />
Getting OSM data or VMap0 data downloaded as tiles and rendered as vectors in the projection currently used. Being able to select features using the mouse.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, Qt, Recommended: knowledge of OpenStreetMap / VMap0.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Marble - OSM Annotation<br />
<br />
'''Brief exmplanation:'''<br />
* With a UMPC (possibly with built-in GPS receiver), it is possible to go into the field and hold a "verification party" to check the accuracy of OSM data. However, making notes when the OSM data is inaccurate is somehow annoying.<br />
* This project will implement on-screen annotation for OSM data overlaid on Marble, including mark and circle (i.e. drawing stuff on the map) and text annotation (taken together, it means you can draw a circle on the map and add a note saying what's wrong there).<br />
* Integration with UMPC stylus and on-screen keyboard input methods is needed.<br />
* Aggressive caching of Marble / OSM data in order to display it in the field is needed as well (compare Google Earth on an iPod).<br />
* Bonus points for optimizing for battery life.<br />
<br />
'''Mentor:''' Adriaan de Groot and Armijn Hemel. Touchscreen hardware might be provided on loan through the mentors.<br />
<br />
----<br />
<br />
'''Project:''' Marble - Routing<br />
<br />
Note from Marble author Torsten Rahn: I don't think that this project as a whole is feasible at this point. But choosing aspects as a GSoC project that are needed to get routing implemented in the future would be appreciated.<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/marble Marble] is a generic geographical map widget and framework that is meant to be used by KDE4 applications. It is also distributed as a standalone application in KDE4.<br />
<br />
'''Brief explanation:'''<br />
* Build on the inclusion of OpenStreetMap data in Marble.<br />
* Implement routing algorithms, ex. A*<br />
* implement a display of the route on the globe.<br />
* Optionally, show a list of roads and turns to get to destination.<br />
<br />
'''Expected results:'''<br />
Ability to chose start point, end point and type of transport (car, bike, foot <br />
etc.) and get a display of a route on the globe.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, knowledge of OpenStreetMap.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
<br />
==== Parley ====<br />
<br />
'''Project:''' Parley - Practice<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/parley Parley] is the vocabulary trainer that comes with KDE4. It is based on KVocTrain but has a much improved GUI. It allows to manage and exchange vocabulary collections that are stored in XML and provides advanced features, such as different practice modes.<br />
<br />
'''Brief explanation:''' The library and the GUI for editing vocabulary have been rewritten to a great extent. Now the thing that is still lacking is the most important part, the actual vocabulary practice. Based on QGraphicsView a nice practice dialog can be implemented, learning does not have to look boring.<br />
<br />
'''Expected results:''' A working practice which supports different modes of practice, ranging from multiple choice and written tests to conjugation and other grammar practices. Support for themeing is desireable.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, QGraphicsView, basic SVG knowledge.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
-----<br />
<br />
'''Project:''' Printing in Parley<br />
<br />
'''Brief explanation:''' Parley and some other KDE-Edu apps use a simple xml file format to store vocabulary data.<br />
This includes quite a bit of context information such as example sentences, word types, verb conjugations etc.<br />
The only way to print any of this information was so far to have a direct printout of the vocabulary list, containing only the words.<br />
Starting from xml it is reasonable to realize printing and even more by exporting to different formats.<br />
Using XSL to transform to html is one of the easiest way to achieve a good and flexible layout. More export formats could be added.<br />
Using this as a way to get multiple printing options would be a nice project.<br />
A flash card view (one vocabulary + optional context info per card), a list and more should be created at the users wish.<br />
<br />
'''Expected results:''' Configureable xsl/xslt transformation of the vocabulary data to at least html(+css) and maybe another format (pdf for example).<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, XSL(T). I can imaging learning XML/XSLT could be done during the project. A very basic example xsl file exists.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
-----<br />
'''Project:''' Parley - Advanced correction and grading<br />
<br />
'''Brief explanation:''' A bit of linguistic research is involved in this project.<br />
Evaluating language in a computer environment is close to impossible, so let's try what we can do anyways.<br />
I would like Parley to not only give feedback of the binary kind (your answer is right/wrong) but try to be a little more differenciated.<br />
How about offering the user to simply place the missing coma, wrong word order, add the accent he left out or hint at two mxied up letters?<br />
It would be possible to look at spell checking programs and other ways to know about the user input.<br />
Maybe the Levenshtein Distance algorithm is of help here? It would be interesting to have more research and an improved correction mechanism.<br />
<br />
'''Expected results:''' Design and implementation of a correction mechanism, that gives good feedback.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: some Qt, knowledge about languages, interest in research in that area.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
<br />
-----<br />
<br />
==== KStars ====<br />
<br />
'''Project:''' KStars: Millions of stars<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. Its display includes 130,000 stars down to 9th magnitude, which is well below the naked-eye limit, but inadequate for advanced purposes. <br />
<br />
'''Brief explanation:''' We would like to see KStars displaying millions of stars, without adversely affecting the program's responsiveness. Much of the infrastructure needed to accomplish this was implemented as part of the KDE-4.0 port, but the remaining work to make millions of stars a reality would be a nice SoC project.<br />
<br />
'''Expected results:''' Expanding the KStars database to include at least a million stars, while maintaining the current level of responsiveness. This will likely require asynchronous disk i/o to read in regionalized chunks of stars data, so that only the onscreen portion of the sky is loaded into memory.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, and probably Qt. Threaded programming a plus.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Prettyfication<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. The display is interactive, but it could be made more beautiful. <br />
<br />
'''Brief explanation:''' We often get good suggestions for making KStars look better. Choose any of the following ideas: realistic rendering of asteroids and comets (including tails!); texture-mapping of the sky (this would mostly allow a photorealistic Milky Way); texture-mapping of planets; realistic sky-lighting effects (i.e., sky is blue in the daytime, gets gradually darker and colorful at sunset).<br />
<br />
'''Expected results:''' Successful implementation of any of these ideas to make KStars more beautiful.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Printable star charts<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It already has a print feature, but the printed chart could be much better. <br />
<br />
'''Brief explanation:''' A printed star chart should at least include a legend explaining the symbols, and provide some information <br />
on the location of the user, the time and date, etc. The user would ideally be able to annotate the chart in various ways.<br />
<br />
'''Expected results:''' Significant improvements to the printed star charts in KStars.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic programming skills, ability to quickly learn QPainter API.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Many Moons<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It currently includes Earth's moon and 4 of Jupiter's moons. <br />
<br />
'''Brief explanation:''' Generalize the JupiterMoons class to encapsulate any planet's Moons. The project will require some research to identify a public source of orbital data for planetary moons, most likely from a NASA webpage. <br />
<br />
'''Expected results:''' Implement moons for at least Mars, Jupiter, Saturn, and Pluto with the new system.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. The project doesn't require much contact with Qt/KDE APIs, and the existing JupiterMoons class can be used as a template.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
==== Step ====<br />
<br />
'''Project:''' Step: 3d mode<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Implement physical simulation in 3d. This involves:<br />
* convert all classes in StepCore to templates with dimension as a template parameter, implement specialized versions where required, modify meta-object system to handle it<br />
* implement 3d mode in GUI: viewing and editing<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view 3d simulations in Step with the same set of objects as in 2d.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, basic OpenGL, basic physics (mechanics). Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: a game<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
The idea is to create a game based on physical simulation where the player have <br />
a fixed list of equipment (like springs, balls, cat and mice, teapot, etc.) and should use it to build a machine to achieve a given goal (for example put the ball in a basket, capture the mice, prepare a tea, etc.). The user places the equipment, than press Start button which starts physical simulation and if (in certain time limit) the goal is achieved the game is won. In the other case the user could try again. Similar projects: old game named "The Incredible Machine" and newer (but commercial) one named "Crazy Machines".<br />
<br />
The game can be implemented as standalone application using StepCore or as special restricted 'game' mode for Step (probably with tweaked graphics).<br />
<br />
'''Expected results:'''<br />
Playable game and several levels to test it.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, basic physics (mechanics).<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: simulation of chemical reactions<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1. This project also relates to [http://edu.kde.org/kalzium Kalzium].<br />
<br />
'''Brief explanation:'''<br />
Simulate some basic chemical reactions using classical molecular dynamics methods with empirical potentials. At first initial settings for simulation should be prepared by hand (as XML file), if there will be enough time an editor could be implemented too. This project involves:<br />
* convert required classes from StepCore to handle 3d simulations (you will need only several classes which are trivial to convert)<br />
* implement required objects and potentials in StepCore<br />
* implement GUI for observing the simulation (investigate the possibility to use avogadro library for visualization), GUI should also allow altering of some properties like masses and charges<br />
* prepare demonstrations of several common reactions<br />
<br />
'''Expected results:'''<br />
Chemical reaction viewer which could load predefined experiment, modify some basic properties and run the simulation. Prepared simulation for several common reactions.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, basic chemistry. Could be useful: Qt, basic quantum mechanics, knowledge of common molecular dynamics simulation techniques and numerical methods.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: fast water and gas simulation<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Currently Step has molecular dynamics based simulation of gas and water (that is a gas is simulated as a collection of particles). This is very usefull for demonstrating microscopical properties of the gas as well as its connection with macroscopical quantities like temperature. But this is far from optimal to demonstrate things like a boat floating in the water, water flowing from a glass, etc. This project involves:<br />
* investigate fast methods of simulating water and gas: ranging from molecular dynamics but with simplified potentials, various optimizations, coarse graining methods, to lattice Boltzmann methods; investigate existing libraries for water simulation (for example take a look at [http://elbeem.sourceforge.net/ elbeem] library from Blender)<br />
* implement selected method of simulation or incorporate selected library in StepCore<br />
* implement GUI in Step for creating and modifying macroscopical quantities of gas and watter<br />
<br />
'''Expected results:'''<br />
Ability to easily simulate in Step experiments like a boat floating in the water, water flowing from a glass, etc.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, numerical methods. Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: other ideas<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
These are smaller ideas related to Step. You can combine several of them to compose you project.<br />
* use KAlgebra library for parsing user-supplied expressions in PropertiesBrowser; allow value in Meter, x- and y-values in Graph to be arbitrary expression; implement ParametricForce object that will apply a force given by user-supplied expression; implement a series of ParametricJoint objects that will allow creation of various parametric constraints (like fixed particle trajectory)<br />
* scripting for Step using either QtScript or Kross<br />
* multi-threaded calculations in StepCore (knowledge pre-requisite: multi-threaded programming)<br />
* correctly handle stiff problems in StepCore (knowledge pre-requisite: numerical methods)<br />
* calculation of gravitational and electromagnetic force between non-point objects by integrating (knowledge pre-requisite: numerical methods)<br />
* make StepCore compilable without Qt<br />
* improve soft-body support: implement automatic creation of arbitrary-shaped soft bodies, better soft-body border handling, investigate better (more accurate) methods of modeling soft bodies (knowledge pre-requisite: physics)<br />
* support for non-convex polygons (probably by implementing triangulation)<br />
* optimize collision detection (AABB trees, etc.)<br />
* framework for dynamic object creation/destruction in order to allow implementing particle emitters<br />
* statistical models (for example prey/predator model)<br />
If you have other ideas please feel free to propose them !<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
==== RoxGT ====<br />
<br />
'''Project:''' RoxGT <br />
<br />
'''Project Information:'''<br />
RoxGT is a OSS done by Ugo Sangiori for building Graph-based applications. It aims essentially for academic jobs, such as graph algorithm execution and theorem proofs. <br />
<br />
'''Brief explanation:'''<br />
Rewrite the RoxGT, today it's written in Java as a Eclipse Plugin. This project aims to transform RoxGT into a full featured KDE4-Application, with all the benefits that Kross can give for the implementation of the algorithm execution in every language suported by Kross, and not only Java.<br />
<br />
Possibly integration of RoxGT in Marble, as a kparts to do things like 'shortest path between 2 points' when marble is used as GPS mode.<br />
Possibly integration of RoxGT in Umbrello, examining the UML and searching for design flaws into the Graph-generated UML.<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view simulations in graphical mode of Graph-Theory algorithm execution.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, Could be useful: Qt.<br />
<br />
'''Mentor:''' Looking for One.<br />
<br />
'''Student''' Tomaz Canabrava - tomaz <dot> canabrava <at> gmail <dot> com<br />
<br />
----<br />
<br />
=== KDE PIM (Personal Information Management) ===<br />
<br />
==== Kontact ====<br />
<br />
==== KOrganizer ====<br />
<br />
'''Project''': Beautiful month view<br />
<br />
'''Description''': The month view of KOrganizer has a long history, which is beginning to show, especially in terms of visually attractivity and performance. With KDE 4 and especially the latest versions of Qt 4 there is an unprecedented opportunity to add some beauty to this view. The goal of this project would be to create a new version of the month view which is able to display a month's worth of events in a beautiful, efficient and user-friendly way. This would include appointments, todos, multi-day events. In addition of a good display of events one could also think about advanced ideas like dynamical zooming of days, 3D indicators of categories or calendar associations, and more. There is a lot of room for creativity in this project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
==== KPilot ====<br />
<br />
==== KMail ====<br />
----<br />
'''Project:''' Message-View: Use more than one line per message<br />
<br />
'''Project Information:'''<br />
As known from other email-apps there is a use-case for having three panes next to each other. However the message-list is currently restricted to one line per message which makes it quite unuseable for that purpose. Thus a new view is needed.<br />
<br />
'''Knowledge Prerequisite:''' Qt Interview Framework<br />
<br />
==== Kleopatra ====<br />
<br />
Kleopatra is the KDE Certificate Manager. In KDE 4.1, it will have gained OpenPGP support (it originally comes from the X.509 world). It is currently being prepared to be integrated into the [[http://www.gpg4win.org GnuPG For Windows]] installer, too, and therefore needs to work in a size-reduced KDE environment (basically, kdecore and kdeui only).<br />
<br />
All of the Kleopatra projects naturally require familiarity with Qt, C++, and GnuPG/OpenPGP concepts.<br />
<br />
----<br />
'''Project:''' OpenPGP web-of-trust visualization<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement a mechanism to visualize the user's personal OpenPGP web of trust.<br />
<br />
'''Detailed Description:'''<br />
For a long time now, Kleopatra has had the ability to show a ''hierarchical view'' of the user's X.509 (aka. S/MIME, aka. CMS) keyring. Such a view lends itself naturally to X.509 certificates, whose trust model ''is'' hierarchical. Here, ''subjects'' (signees) are children of their respective issuers (signers) in a standard tree view, so that root certificates end up being top-level items.<br />
<br />
Naturally, this simplistic hierarchical view is hard to generalize to OpenPGP's Web-of-Trust (WoT) model where everyone may certify everyone else. It is the goal of this task to identify and implement such a generalized ''hierarchical view'' that fits this extended trust model.<br />
<br />
At least two views are obvious candidates (but this task is not restricted to only these):<br />
<br />
Extend the current X.509-type hierarchical view around the idea that my own key can be seen as my own personal ''root certificate'': Keys signed by me would be first-level children of my top-level key, and keys signed by those people would be second-level children, etc. The depth of a key in the item would be the same as that reported as <tt>depth</tt> in the output of <tt>gpg --check-trustdb</tt>. Problems with this approach include mapping a directed cyclic graph onto a tree for putting it into a tree view. Some people also have the opinion that the reverse of what is described here would be what users expect (rationale: <tt>gpg</tt> lists the signers below the signee in an <tt>--list-signatures</tt> operation).<br />
<br />
The second option is to use a graph visualization widget (to be found somewhere or written) that would allow to browse the WoT interactively. This ''might'' break the timeframe, but could be made into a more general component that can be used elsewhere if the project progresses exceptionally well.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a visualization tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* It should contain the X.509 case as a special subset.<br />
* It is easy to find the people I have signed.<br />
* It is easy to see the trust path between two certificates.<br />
* It is easy to see when such a trust path does not exist.<br />
With regard to Gpg4Win, the solution should fail gracefully in the absence of either the external tool, or KMail/Akonadi.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra. Graph visualization knowledge would help, too.<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
----<br />
'''Project:''' Keysigning Party Support<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement functionality to automate the challenge-response mail algorithm used after OpenPGP keysigning parties<br />
<br />
'''Detailed Description:'''<br />
Everyone that has been to a keysigning party has probably gotten a challenge mail to decrypt and send back afterwards. This is done in order to verify that the owner of the email address is also the owner of the (secret) key. This procedure is the basis for most OpenPGP Keysigning Policies, including the one from [http://www.math.uni-bielefeld.de/~mmutz/sign-policy.html#act your mentor].<br />
<br />
There are two ways to do this:<br />
* Interface with an already existing robot that is hooked into the local mail server, or<br />
* Interface with KMail/Kontact (or, if ready by then Akonadi).<br />
<br />
The second option is preferable, as it allows users with a normal desktop system to participate in the system. The first option would have to do a lot of user handholding for being usable enough for the target audience.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a OpenPGP challenge/response tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* Track sent challenges<br />
* Validate responses.<br />
* Alert the user when all responses necessary for a signing have been received.<br />
* Optionally, do this without user interaction.<br />
* Optionally, do this per user-id.<br />
* Deal gracefully with responses that are not forthcoming.<br />
With regard to Gpg4Win, the solution should also have no further external dependencies (mainly Qt, boost, kdelibs, kdeui, gpgme), but this is no hard requirement.<br />
<br />
Optionally, a MIME message format that facilitates the automatic handling of these challenge/response mail could be created and publicized.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
----<br />
'''Project:''' SSL CA Control Center<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an S/MIME Certificate Authority (CA) frontend for one or more free CA solutions.<br />
<br />
'''Detailed Description:'''<br />
While there is CA software available (e.g. OpenSSL and [http://www.mozilla.org/projects/security/pki/nss/ Mozilla NSS]), the command line tools are hard to integrate to get even a small CA running. This project is all about changing that.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented frontend for one or more X.509 CA software packages, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* Set up a new X.509 root certificate. Optionally: allow more than one root to be adminstered.<br />
* Allow to define any number of child CAs.<br />
* Allow to create new client certificates either ad-hoc, or from a PKCS#10 request.<br />
* Allow web- as well as mail certificates (or be flexible enough for doing both).<br />
* Allow to revoke and extend client certificates, and publish CRLs.<br />
* Be useable without much prior knowledge, prevent useless certificates.<br />
* Optional: KIOSK-enable the processes, so an admin can lock down certain aspects of them.<br />
With regard to Gpg4Win, the solution should also have no further external dependencies (mainly Qt, boost, kdelibs, kdeui, gpgme), but this is no hard requirement. It should use the command line tools instead of linking to the respective libraries (for stability, security, and licensing reasons).<br />
<br />
From a UI point of view, the operations shouldn't look much different from the respective OpenPGP ones.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra. Knowledge about CA software helps.<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
==== Akonadi ====<br />
<br />
Akonadi (http://kdepim.kde.org/akonadi/) is the framework for groupware and other PIM applications for KDE4.1 and later. <br />
<br />
----<br />
'''Project:''' Akonadi backend for Microsoft Exchange Groupware server<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an Akonadi backend to allow users to work with Microsoft Exchange servers and applications using compatible protocols (e.g. Outlook).<br />
<br />
'''Brief explanation:'''<br />
The implementation will almost certainly need to use the OpenChange (http://www.openchange.org) libraries. A proof-of-concept implementation has been done (available in KDE's SVN archive), but has bit-rotted as the OpenChange libraries have evolved. <br />
<br />
'''Expected results:'''<br />
A completed, and tested, backend that can operate with a current Microsoft Exchange server. Important capabilities include:<br />
* ability to receive mail,<br />
* ability to create and receive appointments, and to view the calendar,<br />
* ability to access the address book, and<br />
* ability to create and receive tasks.<br />
<br />
Sending mail is outside the scope of Akonadi, and is a "growth" potential if the project is proceeding particularly well.<br />
<br />
'''Knowledge Prerequisite:''' You need to have some familiarity with groupware applications (e.g. knowledge of how appointments and address books are used). C and C++ is pretty much essential, and at least passing knowledge of Qt. <br />
It would be useful (but not absolutely essential) if you had access to a Microsoft Exchange server you can use for testing - we may be able to arrange access.<br />
<br />
'''Mentor:''' Optional, possibly Brad Hards <bradh@kde.org><br />
<br />
----<br />
<br />
'''Project:''' Akonadi testing framework<br />
<br />
'''Project Information:''' Akonadi uses helper processes, called Agents, to do the actual processing of PIM data, e.g. transfer from/to an external storage.<br />
Agent functionality can depend on operations on the Akonadi store performed by other participating processes (Agents and/or clients), e.g. updating an external storage when a user application applies changes to PIM data.<br />
<br />
'''Brief explanation:''' In order to test such a setup automatically or semi-automatically, a testing framework needs to provide the following items:<br />
* means to launch Akonadi in a defined state, e.g. by restoring a data base dump<br />
* means to start a certain set of Agents<br />
* means to trigger changes on Akonadi's data<br />
* means to check the resulting state of Akonadi<br />
<br />
'''Expected results:'''<br />
* tools or test templates for developers to create and run test scenarios, probably using a scripting language like Python or Ruby.<br />
* example test scenarios for at least one agent and one resource<br />
<br />
'''Knowledge Pre-Requisite:''' An understanding of the concept of collaborating services, knowledge how to setup shell environments<br />
<br />
'''Mentor:''' Kevin Krammer <kevin.krammer@gmx.at><br />
<br />
----<br />
<br />
'''Project''': Akonadi Resouce: GroupDAV<br />
<br />
'''Description''': [http://www.groupdav.org/ GroupDAV] is a standard protocol to access groupware servers. It's for example implemented by [http://www.opengroupware.org OpenGroupware.org] or [http://www.citadel.org Citadel]. The task of this project is to create a native [http://pim.kde.org/akonadi Akonadi] resource to provide access to GroupDAV enabled servers to all KDE applications, in particular the KDE PIM suite. There is an existing KDE 3 based KResource supporting GroupDAV which could be used as a starting point.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Calendar<br />
<br />
'''Description''': Googgle Calendar provides an API to access the calendar data on the server. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource, so that any accessible Google calendar can be displayed and edited in Akonadi enabled applications, e.g. in KOrganizer.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Contacts<br />
<br />
'''Description''': Googgle recently has opened their [http://code.google.com/apis/contacts/ Google Contacts Data API]. This makes it possible to access the contacts data which is stored at Google, e.g. for GMail. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource to access contact data stored at Google, so that it can be displayed in Akonadi enabled applications, e.g. in KAddressbook.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Facebook friends and events<br />
<br />
'''Description''': Facebook has an [http://wiki.developers.facebook.com/index.php/API API] that can be used to query a user's friends and information about these. The API also gives access to a user's events. The aim of this project is to implement an Akonadi resource to access contact data stored on Facebook for a user's friends, and also give access to a user's events in Akonadi so that this information can be used in KOrganizer and KAddressbook.<br />
<br />
'''Mentor''': <br />
<br />
Note that there already is [http://websvn.kde.org/trunk/playground/pim/kfacebook/akonadi/ an implementation].<br />
<br />
----<br />
<br />
'''Project''': Akonadi Agent: PIM Data Mining<br />
<br />
'''Description''': PIM data usually contains a lot of related PIM data in some explicit or implicit form. Emails contain contact data as sender or recipients or as part of the signature. Emails also can contain calendar data, e.g. when sending groupware invitations or just by mentioning a date as part of an informal mail about getting together for a beer. The goal of this project is to implement an [http://pim.kde.org/akonadi Akonadi] agent which transparently collects all this information in the background and makes it available to the user e.g. as a special address book ("Email addresses of people to whose emails I answered on a mailing list", etc.). There are many interesting options what and how to implement this and part of the project would be to investigate, what makes sense to be collected and which methods are best suited to get the most useful information from the available raw data.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
'''Project:''' Akonadi backend for .pst files<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an Akonadi backend to allow users to at least read, and possibly write, information from personal storage (.pst) format files.<br />
<br />
'''Brief explanation:'''<br />
Users migrating from Microsoft Outlook often have a lot of information embedded in .pst files - archived mails, calendars, journal entries, and sometimes contacts.<br />
<br />
There are existing libraries to work with this format (e.g. libpst) but I'm not aware of any that do writing. Also note that the .pst format changed - there are two different versions. <br />
<br />
'''Expected results:'''<br />
A completed, and tested, backend that can operate with a both of the .pst formats. Important capabilities include ability to retrieve mail, calendar entries and contact entries. It would be useful to be able to write as well.<br />
<br />
'''Knowledge Prerequisite:''' You need to have some familiarity with groupware applications (e.g. knowledge of how appointments and address books are used). C and C++ is pretty much essential, and at least passing knowledge of Qt. <br />
You would need some way to create test files - almost certainly some version of Outlook, and it would be useful if you had real-world experience with creating and using .pst files.<br />
<br />
'''Mentor:'''<br />
<br />
----<br />
<br />
=== KDE Games ===<br />
<br />
'''Project''': Polytris clone<br />
<br />
'''Description''': Polytris is an old DOS game based on the Tetris concept. Its unique feature is that the number of blocks a piece is build from isn't fixed to four as in the original Tetris, but that it's variable. There are the simple one block pieces which fit everywhere, but there are also the challenging ten block pieces, which provide a complex setting which then has to be filled with other pieces. Difficulty of the game increases over time not by letting pieces fall faster, but by increasing the average number of blocks the pieces are constructed of.<br />
<br />
The task of this project is to create a KDE 4 version of this game. In addition of implementation of the basic game functionality extra credits are given for great playability, beautiful appearance, and a creative and motivating scoring scheme.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KDE Development & Web Development ===<br />
<br />
==== Kompare ====<br />
<br />
'''Project Information:'''<br />
[http://www.caffeinated.me.uk/kompare/ Kompare] is a graphical difference viewer.<br />
<br />
-----<br />
'''Project:''' Semantic diff<br />
<br />
'''Brief explanation:'''<br />
Implement a plugin-based approach for different (potentially incomplete) diff-algorithms. Documents are not just lines of text, but have semantics, and these plugins should help to see changes made to the document.<br />
<br />
Possible plugins are:<br />
* File information diff: show date, size, last-modification, ...<br />
* Programming language diff: detect changes like renamed variables, reindentation, namespace-changes, changes in comments, other refactorings ... (the more the better)<br />
* XML-diff<br />
* Latex-diff: whitespace is ignored.<br />
* config-file diff: in many config-files the order does not matter.<br />
* Image diff: at least show both images next to each other.<br />
* Video diff: show both videos next to each other and link their time. Should be interesting for diffs after reencoding.<br />
<br />
'''Expected Result:'''<br />
A native and Kross (for scripting) plugin-support for Kompare. Some of the above mentioned plugins.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Knowledge of C++.<br />
<br />
Comment: I think one of the most obvious applications of this is in SVG: it would be possible to graphically show the original image + new_rect merged as new_image fairly easily. You could even make elements transparent, and show them in steps, with onion-skinning, almost animating from previous version to new version. I'd also really like to see this "semantic-diff" for ODF documents.<br />
<br />
----<br />
<br />
==== KLinkStatus ====<br />
<br />
'''Project Information:'''<br />
[http://klinkstatus.kdewebdev.org/ KLinkStatus] is a link checker, part of the kdewebdev module.<br />
<br />
-----<br />
'''Project:''' Aided correction of broken links<br />
<br />
'''Brief explanation:'''<br />
Currently, it is possible to find out broken links but it is not possible to fix them. It would be great if those links could also be corrected within KLinkStatus. The corrector should present the user with sugestions, like a spell checker does (it might be possible to reuse some of the KSpell heuristics). Possible errors are typos in domain and paths, absolute vs relative path, and wrong directories.<br />
<br />
'''Expected results:'''<br />
Ability to fix broken links, being effectively assisted with suggestions.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' Site check automation<br />
<br />
'''Brief explanation:'''<br />
KLinkStatus already provide a D-Bus interface that allows to check sites in the background based on a configuration file and then export the results to HTML. A system administrator can already automate check using cron jobs. However it would be nice to offer a nice frontend inside KLinkStatus (without the need of super user permissions). The results could then be exported into files and/or emailed to the site administrator.<br />
<br />
'''Expected results:'''<br />
Easy site check automation and notification system.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' HTML validation<br />
<br />
'''Brief explanation:'''<br />
HTML validation is a very requested feature by users. KLinkStatus already have the infrastructure for this, using libtidy, but some work is still missing in order to actually correct the HTML documents. <br />
<br />
'''Expected results:'''<br />
- Visual indication of which document have HTML validation problems<br />
- Ability to fix individual documents or several documents at a time <br />
- Ability to efectively preview, compare (perhaps using the Kompare kpart) and edit partial parts of a document<br />
- Configurable HTML validation parameters<br />
<br />
'''Knowledge Pre-Requisite:''' HTML, some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ and, for some parts of it, a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
==== KDevelop ====<br />
'''Project Information:'''<br />
[http://www.kdevelop.org/ KDevelop] is the Integrated Development Environment from KDE. If you have something you'd like to see in KDevelop4 don't hesitate to write up your proposal or come to our developer list and discuss it with us.<br />
<br />
'''Project:''' Distribution integration<br />
<br />
'''Brief explanation:'''<br />
Integration of the build-system of one specific distribution into KDevelop. Usually it is quite easy to get the source-code of a package and build it, for example using "apt-get source" and "dpkg-build" under debian, or "osc" under openSUSE.<br />
<br />
'''Expected results:'''<br />
A user can start KDevelop, and choose a package from a list that should be retrieved from some distribution repository. Then KDevelop would download the source-package and create a project-directory+file into which all the necessary information is extracted, inluding a copy of the original project source that can be edited from within KDevelop. The developer can edit the source with code-completion, -navigation, and all the nice extras out of the box. Then the developer can build the package using the distribution-specific mechanisms, with the own changes to the source-tree are included as a patch.<br />
One of the most tricky things here would be providing KDevelop with correct include-path information for all the source-files. A simple hack to retrieve include-paths from existing makefiles is already implemented within KDevelop, and can be re-used. An additional bonus could be management of multiple separate patches on top of the source-tree, that can easily be submitted upstream.<br />
It would be nice if all the stuff could be implemented in a way that it's easy to add support for other Distributions.<br />
<br />
'''Knowledge Pre-Requisite:'''<br />
C++, package-building experience for a popular distribution(Maybe openSUSE or Ubuntu/Debian)<br />
<br />
==== Quanta ====<br />
<br />
=== KDE Network ===<br />
<br />
==== KRDC ====<br />
<br />
Add NX support to KRDC.<br />
<br />
-----<br />
'''Project:''' NX support in KRDC.<br />
<br />
'''Brief explanation:'''<br />
KRDC lacks NX support, which is gaining momentum in the free software world. Build upon the work done by George Wright in the 2006 SoC and the work done by Urs Wolfer in the 2007 SoC to create a top quality NX client for KDE.<br />
<br />
'''Expected results:'''<br />
Fully working NX integration for KRDC, including support for advanced NX features such as sound, VNC/RDP tunnelling etc. Feature parity with the commercial NX client shouldn't be necessary, but aiming for that isn't a bad idea. All NX connection handling code should be in the cross-platform client library nxcl (C++/STL/autotools), and all GUI specific code should be in KRDC.<br />
<br />
'''Knowledge Prerequisites:''' Knowledge of the NX protocol (see http://www.gwright.org.uk/protocol.pdf for an older version of the protocol), C++/STL/Qt/KDE coding and cross platform coding.<br />
<br />
'''Resources:''' http://freenx.berlios.de , http://blog.gwright.org.uk/articles/category/nx , http://nomachine.com/ , http://svn.berlios.de/wsvn/freenx<br />
<br />
'''Mentor:''' George Wright <gwright at kde dot org><br />
<br />
==== Decibel ====<br />
<br />
Decibel is a realtime communication framework for KDE 4.x.<br />
<br />
----<br />
<br />
'''Project:''' KDE4 integration<br />
<br />
'''Brief Explanation:''' Decibel should integrate well with the KDE 4 environment. This includes getting contact data from Akonadi and storing contact state there, storing account data in KWallet as well as integration with Nepomuk to store semantic information on connections made.<br />
<br />
'''Expected Results:''' A working and tested implementation of integration components.<br />
<br />
'''Knowledge Prerequisites:''' A good overview of the involved KDE 4 technologies is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/, Akonadi documentation<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Filtering framework for text messaging<br />
<br />
'''Brief Explanation:''' Text message that are passed to applications using the Decibel framework should get filtered. This includes processing steps (like processing of Off the record messages) as well as logging, etc. This filtering framework needs to be made more flexible as it currently is and some basic filters need to be written.<br />
<br />
'''Expected Results:''' The filtering API of Decibel is improved and sample filters are developed and tested.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Improve Telephony features<br />
<br />
'''Brief Explanation:''' Decibel currently has limited support for telephony features required for VoIP integration. This support needs to be improved and missing features (call forwarding, conferencing, etc.) should be implemented.<br />
<br />
'''Expected Results:''' A VoIP backend based on the existing telepathy backend with the additional telephony features implemented.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required. Familiarity with the telepathy spec and VoIP is helpful.<br />
<br />
'''Resources:''' http://decibel.kde.org/, http://telepathy.freedesktop.org/spec.html<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
==== Kopete ====<br />
'''Project:''' Integrate Decibel and Kopete<br />
<br />
'''Brief explanation'''<br />
Add support for Decibel to Kopete. This will involve some a lot of work within the Kopete core library (libkopete) in addition to making all the current protocol implementations into Telepathy Connection Managers. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
'''Note:''' This is an advanced project. The proposal will need to be very detailed and very complete. Basically, you need to show that you've done your homework, so to speak. The student will also need to be able to work closely with his/her mentor and the rest of the Kopete developer community by being available on IRC and being subscribed to the Kopete mailing list. <br />
<br />
'''Mentor:''' Matt Rogers<br />
<br />
----<br />
<br />
<br />
<br />
=== Amarok ===<br />
Consider these suggestions a starting point to create your own proposal. Some need more detail. Please contact us and let us help you with the proposal before submitting. Find us on IRC on [irc://irc.freenode.net/amarok irc.freenode.net #amarok] or email the public mailing list [mailto:amarok@kde.org amarok@kde.org].<br />
<br />
-----<br />
'''Project:''' CD Stack collection view<br />
<br />
'''Brief Explanation:'''<br />
In iTunes you might have seen the very fancy view with albums flying by very prettily and not very usefully. Now, imaging instead that you have a stack of CDs in a tower. You scroll up and down through it, take one out, and open it to see what tracks are on it. A mockup of this idea can be found here: [http://leinir.dk/temp/gallery/mockups.php?gallery=mockups&image=mockups/cd-stack-in-glorious-pen-o-vision.jpg CD Stack]. Qt has a Model/View system that allows multiple views to the same data. This project would be a new view on the current collection browser. It could be implemented in 3D using OpenGL or using the pseudo-3D techniques that projects like Marble use.<br />
<br />
'''Expected Results:'''<br />
A working (not necessarily polished) implementation of such a CD stack interface, most preferably Model/View based.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, and while experience with Qt (and QGV) is nice it is by no means required, as it can be learned relatively easily. OpenGL and/or 3D programming helpful.<br />
<br />
-----<br />
<br />
'''Project:''' Context View development and Applet writing<br />
<br />
'''Brief Explanation:'''<br />
The Context View is one of the most visually evident features of the new Amarok 2. It takes up the middle part of the Amarok window and provides a view into the information about the song that a user is playing. As such, it is essential to Amarok that the Context View be functionally pleasing, polished, and pretty.<br />
<br />
A project focused on the Context View would consist of mainly continuing development on the CV itself, completing features that are planned but have not yet been implemented, as well as writing new Applets and DataEngines to display further data.<br />
<br />
'''Expected Results:'''<br />
A Context View that uses libplasma to provide an Amarok-specific way of viewing current data in a beautiful and innovative form. The basic structure and architecture is already there, but it needs substantial work to complete.<br />
<br />
Also, time permitting, the development of new applets and data engines for Amarok's CV.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, but this is probably a less KDE project as others. Experience with Qt is nice but by no means required, as it can be learned relatively easily.<br />
<br />
'''Mentor:'''<br />
Leo Franchi (lfranchi) is the original author of the Context View (in Soc 2007) and is willing to mentor any interested student. He can be contacted on #amarok at irc.freenode.net or (better) at lfranchi AT gmail DOT com.<br />
<br />
-----<br />
<br />
'''Project:''' Nepomuk collection<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a plug-in system that allows it to access music metadata from various backends. A plug-in to read and write data to and from Nepomuk should be written in this project. Additionally, Amarok should be extended to make real use of Nepomuk's capabilities by re-adding labels support.<br />
<br />
'''Expected results:'''<br />
A plugin to use Nepomuk as a metadata store from Amarok. Additionally, support for labels should be added to Amarok 2.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE would be helpful<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
-----<br />
<br />
'''Project:''' UPnP Support<br />
<br />
'''Brief explanation:'''<br />
Using the UPnP protocol users can, for example, share music from their Vista computer to a PS3. Amarok lacks any sort of UPnP support. Being able to act as a client (the PS3) or possibly a UPnP media server (Vista) would be useful. See [http://pupnp.sourceforge.net/ libupnp] for more information about UPnP's implementation in open source. The nature of how UPnP works would need to be researched a bit more, as the creator of this idea (Ian Monroe) has only seen it in use on friends computers. :)<br />
<br />
'''Expected results:'''<br />
*Using either Amarok's Internet Service framework or the straight Amarok collection framework, create a plugin which allows Amarok to browse and play music off of a UPnP share. Playing music may require the creation of a KIO for UPnP.<br />
*Allow Amarok to share it's collection with other devices via UPnP. This is secondary priority and may not be feasible to accomplish during Summer of Code.<br />
<br />
'''Material Prerequisite:''' Some UPnP devices or computers to test with.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and networking would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
-----<br />
<br />
'''Project:''' Amarok Scripting<br />
<br />
'''Brief explanation:'''<br />
Starting with Amarok 1.2, Amarok has enabled scripting through a script manager and its DCOP interface. For Amarok 2 we have a straight port of the old DCOP API to DBus. The old API was created over time, and perhaps could be thought out better. Additionally KDE 4 has introduced technology like Kross that could allow true integration of scripts into Amarok, including GUIs. In-process scripting has its own issues though!<br />
<br />
'''Expected results:'''<br />
*This is a more open-ended idea. Contact the Amarok mailing list or on IRC to get help working out the proposal.<br />
:*Perhaps redesign the Amarok DBus API <br />
:*..and/or add a Kross interface and then <br />
:*Create a script showcasing the technology.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and Ruby would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
<br />
-----<br />
<br />
'''Project:''' CD Ripping<br />
<br />
'''Brief explanation:'''<br />
Amarok has never really felt a need for good CD ripping support. We always felt there were better programs suited for this task. This hasn't stopped folks from finding ways to use Amarok to rip their CDs though. ;) <br />
<br />
'''Expected results:'''<br />
*An excellent CD ripping solution integrated into Amarok. <br />
*Cross-platform (Linux, Mac, Windows)<br />
*This task is not too large, so there would be higher standards of polish.<br />
<br />
-----<br />
<br />
'''Project:''' Mass-tagging<br />
<br />
'''Brief explanation:'''<br />
Users sometimes have poorly tagged tracks. Amarok has always lacked an easy way to download information about tracks from FreeDB or Musicbrainz and then tag multiple tracks at once.<br />
<br />
'''Expected Results:'''<br />
*To bring the functionality of programs like EasyTag or [http://musicbrainz.org/doc/PicardQt PicardQt] into Amarok.<br />
*A creative UI to accomplish the goal<br />
<br />
-----<br />
<br />
'''Project:''' Playlist and Playlist browser<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a snazzy new playlist, though its code could use some refactoring to take advantage of Qt 4.4 features. Also it is missing features from 1.4.<br />
<br />
'''Expected Results:'''<br />
*Mass inline tag-editing in the playlist (like in Amarok 1.4)<br />
*Allow users to pick which fields are shown<br />
*Dynamic playlist and smart playlist support<br />
*Improve memory management for large playlists<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential and knowledge of Qt is nice, experience with Model/Views in Qt is a bonus<br />
<br />
'''Mentor:'''<br />
Ian Monroe and other Amarok developers. <br />
<br />
----- <br />
'''Project:''' Media Devices as Collection Provider<br />
<br />
'''Brief explanation:'''<br />
Media device support is very important in a modern media player due to their widespread popularity. Media devices haven't found much love in Amarok 2 development. Amarok 2 has a flexible collection system, that was designed in part with media devices in mind. Whereas in Amarok 1.4 the collection was solely local files so the Collection Browser could only show local files. In Amarok 2 collections have been abstracted, allowing sources from the Internet and ''with this project'' media devices as well.<br />
<br />
'''Expected Results:'''<br />
*Integrate the media device framework into Amarok 2.<br />
*Support at least one kind of media device, while having the framework available for others.<br />
<br />
'''Material Requirements:'''<br />
A media device to test with.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, KDE.<br />
-----<br />
<br />
'''Project:''' Mp3tunes.com service synchronization<br />
<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an mp3tunes locker. This will allow us to use Amarok 2 for managing the mp3tunes locker as well as provide a framework for backing up all local content.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an mp3tunes locker as well as downloading content from the lock er to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the basic mp3tunes service . He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Ampache service synchronization<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an Ampache server. This will allow us to use Amarok 2 for managing the collection on the Ampache server. This will be a cross project task as the Ampache API used by Amarok 2 does currently not support uploading of content. There is great communication between the 2 projects, and the original Ampache API was developed in collaboration with Amarok developers.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an Ampache server as well as download content from the server to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the Ampache service. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Add new service<br />
<br />
'''Brief explanation:'''<br />
Add support for a new online service to the Amarok 2 service framework. This is a project that requires a student that already has a good idea or contacts with an interested service. Getting added to Amarok will mean that the service will have itself and its contents made available to a potentially huge new audience, and Amarok user will enjoy having access to even more great content. Ideas for services ( just to throw something out there ) could be the internet archives collection of live recordings, remixes from ccmixter.org, or something similar<br />
<br />
'''Expected results:'''<br />
Being able to play content from the service directly within Amarok. Depending on the type of service, downloads or purchasing of content might also be possible, as might other features unique to the service.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and many of the services. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----<br />
<br />
=== Digikam ===<br />
<br />
'' Project:'' Nepomuk integration<br />
<br />
''' Project Information:'''<br />
Integration between Digikam and Nepomuk could allow the user to better organize his/her pictures and access them easily from other apps, or even from other computers as Nepomuk is a networked system.<br />
<br />
'''Brief explanation:'''<br />
Nepomuk could allow the user to organize the pictures in a finer way : Nepomuk allows the user to define properties on his picture, extending the usecases of standard metadata (XML/IPTC/XMP...). The user can add any property under the form subject - predicate - object. Think of it as finer grained tags. You could for example define the predicate "is on the picture" to list all the people present on it (facebook does that). In a larger scope, the user can link picture to any resource known by Nepomuk (project, meetings...).<br />
<br />
The other advantage is that Nepomuk stores the information in a central index, which means that it can easily be accessed by other apps (I think of Akonadi). This allows tighter integration, as OS X does in its latest version with the iPhoto library.<br />
<br />
----<br />
<br />
=== Okular ===<br />
<br />
''Project:'' Okular backend<br />
<br />
'''Project Information:'''<br />
Okular has plug-in system that allow it read different documentation formats. It currently reads a range of formats, but there are several that might be able to be improved (e.g. XPS) or implemented.<br />
<br />
'''Brief explanation:'''<br />
The project would need to identify a format that requires improvement (or implementation). Candidates that have been requested in the past include the Microsoft Word (.doc) format and the .lit e-book format. Given a suitable library, potentially any format could be considered. Consider:<br />
* Microsoft Visio<br />
* Microsoft Access snapshot (would require implementing a .emf file renderer - not simple, but could be useful in many other places in KDE).<br />
<br />
Note that improving PDF requires changes to the poppler library, and you would need significant previous experience with PDF (and ideally with poppler) to make much progress.<br />
<br />
'''Expected results:'''<br />
A working backend, capable of rendering most documents to a readable level. <br />
<br />
'''Knowledge Prerequisite:''' C++ is pretty much essential, and at least passing knowledge of Qt. C programming experience may be useful for some libraries.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the okular mailing list.<br />
<br />
=== K3b ===<br />
<br />
'''Project:''' Port K3b to libburnia libraries<br />
<br />
'''Project Information:''' K3b currently uses cdrtools/cdrkit. This project should rewrite k3b to take advantage of three libburnia libraries - libburn, libisofs, libisoburn.<br />
<br />
'''Expected results:''' Experimental K3b branch with dropped support for cdrtools/cdrkit, and k3b features provided on top of libburnia libs backends.<br />
<br />
''trueg: I do not support the idea of dropping cdrecord integration. K3b already supports different backends. This architecture should be extended.''<br />
<br />
'''Contact for more information:''' mario AT libburnia-project DOT org<br />
<br />
'''Mentor (volounteer): Sebastian Trueg <trueg@k3b.org>'''<br />
<br />
=== Other applications ===<br />
<br />
==== Application User Interface Test System ====<br />
<br />
There are a couple of tools available for Qt / KDE that allow testing of applications - squish and kdexecutor. Both are binary only, and are specific to the systems that they are built on. <br />
<br />
It would be useful to have an open source tool that allowed us to test applications in a scripted way. Similar open source tools include Dogtail and LDTP, which use the accessibility interfaces in Gnome. <br />
<br />
There are arguments for and against using accessibility - it might be a lot more useful to implement a separate system, using some of the Qt4 specific features including QMetaObject. Qt4 has a nice set of hooks, and QTestLib shows how they can be implemented. However instead of requiring specific code in the application (as done by QTestLib), it would be more flexible to use LD_PRELOAD and a small interface library. <br />
<br />
More discussion: Brad Hards <bradh@kde.org><br />
<br />
==== (Multiple) image printing application ====<br />
<br />
This idea comes from my father, who is missing this kind of feature he was using in Paint Shop Pro. He says that there it was possible to open many images and when you selected them for printing the application would present you with a paper page, onto which you could drag the images, which were presented on a panel on the left side of screen. You could then interactively position and resize images on the paper and so see how the page look like when printed. There were also special functions available which would automatically resize and position the images.<br />
<br />
This application could also have a feature added to make it easier to print one image onto multiple pages (think posters). Here you could select how many pages of what size there should be and how many space on each page would overlap so you could glue the pages together after printing.<br />
<br />
I think it would be nice to also find a way to integrate such an application with imageviewer like Gwenview and photo management app like DigiKam.<br />
<br />
=== Usability ===<br />
<br />
The KDE Usability Project is willing to offer support mentoring to one or two projects (more if additional design mentors are available) which involve heavy UI development or UI redesign activities.<br />
<br />
=== Infrastructure ===<br />
<br />
KDE infrastructure tools, like Bugzilla, the Review Board, etc.<br />
<br />
=== KDE dependencies and non-KDE projects ===<br />
<br />
Depending on the relevance of the proposal, the KDE Project will accept student proposals on projects that are not part of KDE, but which are either KDE dependencies or relevant to KDE or the Free Software Desktop.<br />
<br />
==== Qt Cryptographic Architecture ====<br />
<br />
The Qt Cryptographic Architecture (QCA) isn't strictly part of KDE, however it is used in a range of KDE applications (and other applications). <br />
A range of projects are possible, in terms of adding security features to applications (e.g. SASL, encrypted content, client side puzzles). <br />
<br />
A specific need is the provision of alternative backends, which are typically the interface between QCA and some underlying crypto library. We already have several, but only the OpenSSL one is fairly complete, and OpenSSL is pretty ugly. A new backend would require some previous crypto knowledge, and ability to program in C++ and C. No GUI experience required! We probably only need one good alternative on each platform.<br />
<br />
- '''Alternative backend - GNU crypto libraries''': We have a basic backend using libgcrypt, which is mostly working. However a lot of the more interesting capabilities are present in gsasl and GNUtls. <br />
Mentor: Brad Hards <br />
<br />
- '''Alternative backend - Mozilla Network Security Services''': The Mozilla project has a library that is separately packaged on most Linux systems. It offers a fairly complete alternative to OpenSSL. We have a basic skeleton for NSS, but it only offers a couple of basic crypto primitives.<br />
Mentor: Brad Hards<br />
<br />
==== Strigi ====<br />
<br />
Strigi [1] and Pinot [2] are desktop search tools for the Linux and<br />
free Unix desktop. While targeted at different desktop environments,<br />
they have a history of collaboration, for instance on parsers for the<br />
Xesam query languages [3].<br />
<br />
Their features list overlap significantly as both projects offer most<br />
of the functionality users expect of desktop search systems.<br />
<br />
Both projects are written in C++ and feature an abstraction layer that<br />
makes them backend independent, though both only have one fully<br />
functional backend. Strigi's backend of choice is based on CLucene [4]<br />
while Pinot's is based on Xapian [5].<br />
<br />
This proposal is to bring this collaboration one step further by<br />
allowing them to use each other's indexing and search backends.<br />
<br />
Benefits include :<br />
* better abstraction layer for each project<br />
* wider testing of the respective back-ends<br />
* more choice to these projects' users<br />
* ease of evaluating and comparing CLucene and Xapian strengths and weaknesses<br />
<br />
The goal of project is to let Strigi use Pinot as a backend and vice<br />
versa so that both can query each others interfaces using<br />
the Xesam query language, and whatever query language is native<br />
to the backend.<br />
<br />
The emphasis is on completeness of querying. Performance optimizations<br />
and support for writing are secondary.<br />
<br />
[1] http://strigi.sf.net/<br />
[2] http://pinot.berlios.de/<br />
[3] http://www.xesam.org/<br />
[4] http://clucene.sourceforge.net/<br />
[5] http://www.xapian.org/<br />
<br />
==== Soprano & Nepomuk ====<br />
<br />
'''Project: Full Featured Query API'''<br />
<br />
'''Description''':<br />
For powerful semantic queries on the desktop we need a powerful query API. At the moment we are restricted to SPARQL queries which are then parsed by the Soprano backend. It would be much more efficient and easy to use if we had a query API that allowed to represent queries (independent of any query language) using a class structure. Queries could then easily be created, manipulated, and translated. Application developers would not have to learn a specific query language but would create a query object and have Nepomuk/Soprano evaluate that.<br />
<br />
This query API would become part of the official Soprano API and replace the simple Soprano::Model::executeQuery interface we have now.<br />
<br />
'''References:'''<br />
* Implementation of something similar in Java: http://sparql.sourceforge.net/<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
<br />
==== D-Bus ====<br />
<br />
* a named pipe or shared memory transport implementation for win32<br />
<br />
* can QLocalSocket and QSharedMemory (in 4.4) be used?<br />
<br />
==== APOC ====<br />
<br />
'''Project: KDE (KConfig) integration with APOC'''<br />
<br />
'''Project Information''':<br />
<br />
APOC (http://apoc.freedesktop.org) is a framework for centralized (e.g. in LDAP) storage and management of application and desktop configuration. It has integrations with the GNOME configuration system (gconf) and various desktop-independent applications (OpenOffice.org, firefox, Java). <br />
<br />
This project is to integrate APOC with KConfig so that KDE application preferences can be managed as well.<br />
<br />
APOC is also proposing another, different GSOC project using [http://live.gnome.org/SummerOfCode2008/Ideas GNOME as mentoring organisation].<br />
<br />
'''Knowledge Prerequisites''': <br />
* C++ coding <br />
* XML knowledge <br />
* KDE coding and configuration experience helpful<br />
<br />
'''Expected Result:'''<br />
* A documented mapping of KConfig preference structure onto the APOC file format.<br />
* A working KConfig backend that reads data from APOC<br />
<br />
'''Contact''': <br />
<br />
APOC is discussed on the [http://lists.freedesktop.org/mailman/listinfo/apoc apoc mailing list] (apoc@lists.freedesktop.org) and on the #apoc channel at irc.freenode.net.<br />
<br />
'''Mentor''': <br />
[mailto:joerg.barfurth@sun.com J&ouml;rg Barfurth]<br />
<br />
==== PolicyKit ====<br />
<br />
'''Project: PolicyKit Integration for KDE'''<br />
<br />
'''Description''':<br />
PolicyKit is a toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems.<br />
<br />
'''Expected results:'''<br />
* Provide a D-Bus session bus service that is used to bring up Qt/KDE authentication dialogs used for obtaining privileges.<br />
* Exemplary integration of PolicyKit within KDE (eg changing system clock from System Settings/clock plasmoid)<br />
* Write a Qt/KDE frontend to manage privileges<br />
<br />
'''References:'''<br />
* Specification: http://people.freedesktop.org/~david/polkit-spec.html<br />
* http://hal.freedesktop.org/docs/PolicyKit-gnome/<br />
<br />
'''Mentor:'''<br />
<br />
==== Other Freedesktop.org initiatives ====<br />
<br />
Both KDE and Gnome have previously acted as mentor organisations for projects that are under the Freedesktop.org umbrella. If you want to do a cross-desktop project, you can consider submitting it to one (or more) organisations. This is one case where you almost certainly want to have a mentor identified before you submit.<br />
<br />
If you submit to more than one organisation, please note which organisations you have submitted it to (since KDE has to coordinate with the other mentoring organisations).</div>Zwabelhttps://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas&diff=22326Projects/Summer of Code/2008/Ideas2008-03-20T00:16:58Z<p>Zwabel: Add KDevelop Idea</p>
<hr />
<div>This page is an open list for ideas for the 2008 edition of [http://code.google.com/soc Google Summer of Code]. This page is open for new ideas from anyone - you do need to log in to the wiki to edit this page though (see below for why).<br />
<br />
This list is not exhaustive. It is just a collection of some ideas. To get further ideas, please feel free to use any resources and [[#Past_ideas|past ideas]].<br />
<br />
Before proceeding, '''read''' the [[Projects/Summer of Code/2008/Participation|participation instructions]] and [[#Notes_on_editing_this_page|the notes on editing this page]]. They are useful for students and developers alike.<br />
<br />
== Past ideas ==<br />
<br />
You may want to take a look at the ideas page for [http://wiki.kde.org/tiki-index.php?page=KDE%20Google%20SoC%202006%20ideas 2006] and [[Projects/Summer_of_Code/2007/Ideas|2007]]. Many of the ideas there are still valid today.<br />
<br />
== Notes on editing this page ==<br />
<br />
Before making any modifications, please '''log in''' to Techbase. This will help us track who is contributing to the ideas. This page is protected, so you can't modify it without logging in anyways.<br />
<br />
When adding a new idea, please bear in mind the question: can a student with very little knowledge of KDE code complete this work in three months? If you can't answer "yes", your idea is probably not for this page. Please remember that this is '''not''' a generic wishlist page for KDE developers.<br />
<br />
When making modifications to existing ideas, please consider whether you're changing it more fundamentally or just superficially. If your changes are substantial, you probably have an entirely new idea. Similarly, if your idea is modified and you feel it no longer reflects your original thought, please split the idea in two, restoring yours.<br />
<br />
Please use the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] if you want to discuss an idea.<br />
<br />
Finally, do '''not''' delete ideas without a reason for doing so (like, for instance, being contrary to KDE ideals, being completely unrelated to KDE, being unfeasible, etc.) -- you may want to state in the [[Talk:Projects/Summer of Code/2008/Ideas|talk page]] why you removed the idea.<br />
<br />
Do '''not''' re-add ideas that were removed without discussing first with the developers of the target application.<br />
<br />
== Project ideas ==<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 />
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 />
When adding an idea to this section, please try to include the following data:<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 />
=== KDE Libs ===<br />
<br />
==== KDE Core libraries ====<br />
<br />
The KDE core libraries (kdecore, kdeui, kio, kparts) are the most basic libraries that all KDE applications depend upon.<br />
<br />
----<br />
'''Project:''' ODF writer<br />
<br />
'''Brief explanation:'''<br />
The ODF file format could be used for a wide range of applications, not just traditional office tools such as a word processor or spreadsheet.<br />
<br />
As an example, consider a tool like ksnapshot (which does screenshot captures). When writing documentation on how to perform some task with an application, you might work through the application taking many screenshots. If we had a class in kdelibs that could write ODF files, and the right application integration, perhaps the tool could create a file full of screenshots, which could then be annotated with some explanation to create a "visual guide" for that task.<br />
<br />
ODF is a pretty simple format to write (much less simple to read, because of the many options), and there is significant expertise in the KOffice community on that format.<br />
<br />
'''Expected results:'''<br />
* Properly designed, implemented, documented and tested class(es) for ODF writing.<br />
* Two usages of the class in different KDE applications (e.g. Okular and ksnapshot).<br />
<br />
'''Hints for proposal:'''<br />
* Explain what design and coding principles you will apply (goal: convince us that the code will be suitable for kdelibs)<br />
* Identify schedule for each element (goal: demonstrate that the task can be completed in the time you have available)<br />
* State your understanding of ODF (goal: demonstrate commitment to the task outcomes)<br />
<br />
'''Knowledge prerequisites:''' Sound C++ and Qt knowledge. Some familiarity with other ODF tools would be useful. <br />
<br />
'''Mentor:''' TBA<br />
<br />
----<br />
'''Project:''' Diskspace Service<br />
<br />
'''Brief explanation:'''<br />
<br />
Applications that write large amounts of data to partitions must nor fill them up completely. As an example there is strigi/soprano which can have a large index and will fill your ~ until 0 bytes remain. Other applications are e.g. those that write data to .thumbnails.<br />
<br />
To prevent this there is the need for a service that can be queried by applications, whether the user-set limit of remaining MB is already reached or not.<br />
<br />
As an extra the user could be notified if the set limit is reached.<br />
<br />
Mentor: Sebastian Trueg<br />
<br />
----<br />
'''Project:''' Support for fingerprint authentication<br />
<br />
'''Brief explanation:'''<br />
Many laptops come with a simple fingerprint scanner that can be used to authenticate users. It would be nice if KDE had support for these fingerprint scanner integrated. This way you could use them to log into KDE, unlock KWallet, maybe even use it to enter nickname in highscores for games... It would probably be a good idea to work with [http://reactivated.net/fprint/wiki/Main_Page fprint] project when integrating the support.<br />
<br />
----<br />
'''Project:''' Smart toolbars<br />
<br />
'''Brief explanation:'''<br />
Currently the policy is to have as few buttons in toolbar as possible by default. Only the ones that have a very high chance of being used by almost all users of an application. Maybe there could be an option added to toolbars so that it would monitor which actions (from menus) the user uses. When the new smart toolbar notices that the user has used some action very frequently and which doesn't have a button in the toolbar yet, it could suggest to the user to automatically add it to the toolbar. Buttons could also be removed after not using toolbar buttons for a long time. Off course there should be 3 options for this feature: 1. to automatically add and remove toolbar buttons without asking, 2. to ask before adding or removing, and 3. to disable this feature so that toolbars are the same as now.<br />
<br />
==== Solid ====<br />
<br />
Solid is the KDE hardware abstraction layer, that enables KDE programs to get consistent results when running on different platforms.<br />
<br />
==== Phonon ====<br />
<br />
Phonon is the KDE audio abstraction layer, that enables KDE programs to produce basic and medium-level multimedia functionality in any platform without platform-specific code.<br />
<br />
==== KHTML ====<br />
<br />
KHTML is the current KDE HTML engine, used by the Konqueror web-browser and other applications to display HTML in their interfaces.<br />
<br />
==== KJS ====<br />
<br />
KJS is the JavaScript engine used by KHTML and Kross to run JavaScript programs.<br />
<br />
==== Sonnet ====<br />
<br />
Sonnet is the KDE grammar, spell-checker and language-detection engine.<br />
<br />
==== Kross ====<br />
<br />
Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and KDE JavaScript transparently into native applications to bridge the static and dynamic worlds together.<br />
<br />
==== Oxygen ====<br />
<br />
Oxygen is the KDE 4's default look-and-feel. It comprises of the Oxygen icon set (including the palette and guidelines for icons), the Oxygen sound theme, the Oxygen wallpaper collection, the Oxygen window decoration and the Oxygen widget style. Note that for Summer of Code, you must produce code, so the window decoration and widget styles are your more likely candidates.<br />
<br />
==== KDE-Print ====<br />
<br />
* Implement an easy usable [http://www.fineprint.com/products/fineprint/index.html fineprint-like] solution for collecting pages from different printing sources (browser, kword, krita...) and allow it to rearrange single pages (not printing jobs), delete pages, add blank pages. Information also in wish-list-item: [https://bugs.kde.org/show_bug.cgi?id=90989 90989]. I am the reporter of this wish, you can contact me there. I do not have the abilities to program, but I am willing to help testing an implementation and discuss how it should look like.<br />
* WARNING! i'm doing exactly this for my semester project at school (we are two students, so we can't apply for SoC with this). We are probably developing it in pure QT (the other student is a gnome user).You can get in contact with me: asranie@fryx.ch<br />
<br />
=== KDE Base applications ===<br />
<br />
==== Konqueror ====<br />
<br />
Konqueror is KDE's powerful web browser and file manager.<br />
<br />
'''Project: Bookmark Wallet'''<br />
<br />
'''Description:''' This isn't actually a project to be a part of Konqueror itself, but rather a separate application similar to KWallet. The application should provide a database for the storage of URL bookmarks. The database should be able to connect to remote storage, such as the Google bookmarks service, for synchronization and backup. The URLs should be easily manageable, and include a concept of ratings for the URLs. A plugin should be written to allow Konqueror to easily interface into the system, or preferably Konqueror itself should be modified to use the storage system when it is available. The application should provide an interface which is easy to connect to from a browser plugin, so that plugins could be written for other browsers, such as Firefox, as well. There should also be a plugin interface into the database, to allow support for other remote storage backends, such as foxmarks, to be created. The application should handle multiple concurrent connections to the database without issues. Additionally, the application should provide an event interface to notify all connected browsers whenever a bookmark is added, changed or removed.<br />
<br />
Comment: Rather than developing a separate application, interested students should have a look at the [http://websvn.kde.org/trunk/KDE/kdepim/akonadi/resources/localbookmarks/ Akonadi resource localbookmarks]<br />
<br />
Comment: Would be great if this would include saving RSS-Feeds in as well, synchronising them with webbased feedreaders<br />
<br />
Comment: a database of feeds would indeed be great. If implemented with a "feedtype" field, it would solve the problem of feeds containing news that's best read in a traditional aggregator, audio that's best heard in a music player, video that's best seen in a video player, etc. Apps could just open the query the feed DB for suitable feeds. Or perhaps they could query for feeds with particular enclosure mimetypes? Hmm. That raises the issue of pre-loading the feed, and integration with libsyndication.<br />
<br />
==== Dolphin ====<br />
<br />
Dolphin is KDE 4's default file manager application.<br />
<br />
'''Project: Support Windows' "Previous Versions"'''<br />
<br />
'''Description:''' Shadow Copy (also called Volume Snapshot Service or VSS) is a feature introduced with Windows XP with SP1, Windows Server 2003, and available in all releases of Microsoft Windows thereafter, that allows taking manual or automatic backup copies or snapshots of a file or folder on a specific volume at a specific point in time. It is used by NTBackup and the Volume Shadow Copy service to backup files. In Windows Vista, it is used by Windows Vista's backup utility, System Restore and the Previous Versions feature. Samba supports Shadow Copy since version 3.0.3.<br />
<br />
==== Konsole ====<br />
<br />
Konsole is KDE's terminal application.<br />
<br />
==== Kate and KWrite ====<br />
<br />
Kate is KDE's Advanced Text Editor, both a full-featured text editor application and a KPart engine ready for embedding into other applications (like KDevelop, Quanta and Kile). KWrite is a simple text editor based on the KatePart engine and is KDE's default text editor.<br />
<br />
----<br />
<br />
'''Project:''' vi mode for the Kate editor<br />
<br />
'''Project overview:''' Create a vi-like modal editing mode for the Kate editor part and improve the kate command line to a point where it can be used efficiently for vi commands in this mode.<br />
<br />
'''Expected results:''' This project should implement a vi-like, modal editing mode for kate. This mode will be selectable by the user.<br />
<br />
'''Mentor:''' Christoph Cullmann has agreed to mentor this project.<br />
<br />
=== KDE Workspace ===<br />
<br />
==== Plasma ====<br />
<br />
Plasma is KDE 4's desktop and panel tool, replacing KDE 3's kicker and kdesktop. It's an advanced and powerful application with revolutionary ideas.<br />
<br />
* '''Plasma Packages'''<br />
** Plasma provides a simple packaging system for widget (plasmoids), SVG themes, wallpaper sets and indeed any type of application add-on data. It is not a replacement for apt, rpm, klick, etc. but rather is designed to help with the challenge of creating, sharing, installing and managing run time add-ons as have been made popular with KDE's Get Hot New Stuff framework.<br />
*** ''Project I: A GUI Creator For Packages'': This project involves taking the already started user application "plasmagik" and refining it to be ready for production use. The application must take a plasma package description, display it in a user friendly way in the UI and allow the user of the application to add files to the various nodes in the structure (e.g. graphics to an "images" entry). In particular this project would consist of:<br />
**** Removing assumptions based on the plasmoid package structure and instead using the generic Plasma::PackageStructure class.<br />
**** Making the UI more user friendly<br />
**** Streamlining the upload support<br />
**** Writing a tutorial on KDE's TechBase on how to employ the application as an add-on creator.<br />
**** As the plasmagik application already has had a fair amount of work done it and an active community of developers interested in its future, the scope and support for this project should be within the limits and expectations of the SoC.<br />
*** ''Project II: Package Management'': This project involves creating a small utility application consisting of a dialog and a control panel that uses it which allows the user to list, share and remove installed Plasma packages. As there are no dependencies, binary compatibility, etc issues usually associated with full package management applications, this would be well suited to a SoC project. <br />
* '''Zeroconf Integration''': This project would involved adding a zeroconf announce and discovery feature to libplasma that would provide a Plasma::Applet with a simple API to find other Applets of the same type on the local network. A test plasmoid would be created to prove the working status of the zeroconf support. Remaining time would be spent adding zeroconf features to applicable existing plasmoids.<br />
* '''DataEngine + Plasmoid for zeroconf services''': Browser for zeroconf services available (perhaps doable with above project as well?)<br />
* <s>'''Physics Engine''': Take an existing 2D physics engine and experiment with using it within a containment to emulate "natural" object interactions.</s> taken<br />
* '''Setting a video as desktop background'''<br />
* '''Dynamic desktop background''': A desktop background which displays different wallpapers according to information like time of the day, season, weather etc.<br />
* '''Mobile device containment''': Implement a Plasma::Containment that is appropriate in form factor and UI layout for a UMPC/tablet style device.<br />
* '''Touchscreen profile''': The use of UMPC form factors with a touch screen is increasing -- certainly in some business areas. Plasma is prepared for handling different form factors and for providing a user interface experience that adjusts to device characteristics. The touchscreen profile SoC project (touchscreen hardware will probably be arranged through the mentors) aims to identify where Plasma / KDE works well and where it doesn't on small (VGA or SXGA) screen sizes; then it will fix the bits where it doesn't work well and introduce a general mechanism for handling small screens. In addition, UMPC on-screen keyboards introduce new UI challenges; integrating these in a meaningful way with plasma is an extra part of this project (or possibly an extra project). Dialog and menu handling on small screens, with pagination of menus and (re)pagination of tabbed dialogs is another topic. '''Mentors:''' Adriaan de Groot and Armijn Hemel.<br />
* '''Phase''': improving the Phase/Animator system by:<br />
** implementing animation curves (already in the API and used by plasmoids, but not actually implemented)<br />
** optional keys for individual animations, allowing them to be turned off or otherwise tweaked individually / in groups<br />
** chaining animations<br />
** going through uses of customAnimation in libplasma using code and reimplementing generally useful ones within Animator itself<br />
<br />
==== KRunner ====<br />
<br />
KRunner manages the screen locking, run command dialog and provides a general natural language interface to applications, desktop services, network locations, files and data (e.g. math calculations, spell checking, word definitions, etc). It replaced the Run Command dialog in kdesktop from KDE3, is multithreaded and shares code with Plasma.<br />
<br />
Some of the items below may take an entire SoC project, others may be better combined to flesh out an entire summer's worth of work.<br />
<br />
* '''Ranking''': Results are returned to KRunner by individual runners. These result must then be ordered for the user prior to display. This project would consist of improving the ranking of returned results by working on two related fronts:<br />
** Tweaking individual runners to more accurately rate their own results.<br />
** Improving the final ranking system employed by the host application.<br />
* '''Abstracting runner management out of KRunner''': The main pieces of using runners (SearchContext, SearchMatch and AbstractRunner) exist in a shared library (libplasma). However, much of the code for managing the actual runners at runtime is contained within the krunner application itself. Abstracting this code out would make it easier for other components and applications to user runners as well.<br />
* '''Using runners in Kickoff''': The kickoff menu has a search tab. Currently it does it's own internal search. It should, instead, be using AbstractRunners for this. This task would go well with the runner management task above.<br />
* '''Xesam search runner''': Write an AbstractRunner plugin that uses the Xesam query spec to forward user queries to a search store. The trick will be in making it performant as well as providing support for paging through requests.<br />
* '''Write as many runners of your choice''': one might call this a "marathon" (get it? runners? as many as you can? ahaha! *sigh*). I wrote [[http://aseigo.blogspot.com/2007/10/what-runners-do-we-need-want-dream-of.html this blog entry]] looking for ideas for runners and got many, many suggestions. I think it reasonable to expect that over the course of a summer's work one might be able to write 5-10 runners depending which ones were selected.<br />
<br />
==== KWin ====<br />
<br />
KWin is KDE's X11 Window Manager program, greatly improved when compared to its older brother in KDE 3.<br />
*'''Compiz-like Effects in KWin''': Effects like Desktop Cube often greatly improve the usability, especially when it comes to multiple desktops, and they are just cool.<br />
<br />
==== KDM ====<br />
<br />
KDM is KDE's Display Manager and login application.<br />
*'''More Ways of entering login data''': Currently, KDM only supports logging in with Username and Password in two fields on the one login mask. Entering first Username and then Password in two separate masks (Yeah, just like GDM) or searching for users while typing in the letters of a username would be really handy and cool.<br />
<br />
==== KScreenSaver ====<br />
<br />
*'''Plasma Dashboard Screensaver''': There could be a new default screensaver added. When started it would show the Plasma Dashboard with all the plasmoids on it. The Dashboard could be the default one (the one that shows up when you press Ctrl+F12) or the user could create a custom one just for this screensaver. These two options should be in the screensaver's properties. For creating custom layout there should be some tool to set background and add plasmoids.<br />
<br />
=== KDE Runtime ===<br />
<br />
''' Project''': KHelpcenter: What's this explosion<br />
<br />
'''Description''': A lot of help about elements of the user interface is available in the form of "What's This?" texts. Unfortunately it's pretty cumbersome to get to this information for a user as it needs clicking on the "question mark button" in the title bar of the window/dialog and then clicking on the user interface element. This project is about making this information more conveniently available by providing an "exploded" view of the "What's This?" help as part of the application's manual in KHelpcenter.<br />
<br />
All "What's This?" texts of a given window could get displayed in a view at once, e.g. by using some bubble views and connecting lines to the interface elements. These views could be extracted from the run-time instances of the windows by inspecting the widget hierarchy. This could either be done as a special offline run to pre-generate help pages or dynamically at run-time of the application. Investigations of what method would be the best would be part of the project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': KHelpcenter: Cheat sheets<br />
<br />
'''Description''': Task based documentation of applications can often be presented best as step-by-step instructions how to achieve certain user goals. With the help of application's D-Bus interfaces KHelpcenter could be extended to provide interactive versions of these step-by-step instructions. Users would be provided with explanations and instructions how to accomplish tasks together with links that would open corresponding dialogs, execute described actions, etc. In the Eclipse project this kind of help is called cheat sheets.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KOffice ===<br />
<br />
==== KWord ====<br />
'''Project:''' Improve ISO OpenDocument support<br />
<br />
'''Explanation:''' Improve loading and saving of the ISO OpenDocument format what includes 1) extend the current saving code, 2) extend the current loading code and 3) probably also extend the rendering engine aka the text flake-shape.<br />
<br />
'''Expected results:''' be sure everything we are able to load, display and edit is also saved back correctly using the default file format.<br />
<br />
'''Mentor:''' Sebastian Sauer <mail@dipe.org><br />
<br />
-----<br />
<br />
'''Project:''' Collaborative editing of documents over a network.<br />
<br />
'''Explanation:''' Make it possible for two or more users to work at the same document in KWord at the same time over a network. Both users would open the same document, and changes made by each user are synchronized to the other user's editing session.<br />
<br />
----<br />
<br />
'''Project:''' Version control integration.<br />
<br />
'''Explanation:''' Integrate version control system support with KWord to allow easy control over revisions of documents. It should be possible to connect with remote revision control systems, to allow collaborative work on projects, similarly to how software is developed. It should be easy for the user to browse through the history of document versions in the version control system, to see what has changed. CVS, Subversion and git should be supported.<br />
<br />
----<br />
<br />
'''Project:''' Improve legacy MS Office (2003) documents support<br />
<br />
'''Explanation:''' Current MS Office formats support is kinda limited (especially write support). To decrease the barrier for adoption, better MS Office support is a way to do that.<br />
<br />
==== KSpread ====<br />
==== Kexi ====<br />
Kexi is an integrated data management application for desktop users like Microsoft Access.<br />
<br />
-------<br />
'''Project:''' Improve Kexi Data Import/Export<br />
<br />
'''Brief explanation:''' Currently Kexi allows importing CSV files into an existing database, and converting MySQL/PostgreSQL/MS Access databases into Kexi databases.<br />
<br />
The aim of this project is to provide plugin(s) that import from more database backends/formats.<br />
<br />
You can select backend you want to implement migration for:<br />
<br />
* HSQLDB - the OpenOffice.org Base's DB backend (ODB file format, very important to have)<br />
* ODBC<br />
* Paradox<br />
* DBase (e.g. using [http://linux.techass.com/projects/xdb Xbase])<br />
* Firebird (note: pending licence checks if we want GPL-compliance)<br />
<br />
For the ODBC driver, a migration plugin and a backend plugin should be provided. For Paradox, only a migration plugin is required, although this will require modifying the migration framework to allow more than one file to be selected as the source database (i.e. the database to be imported).<br />
<br />
Both a migration plugin and a backend plugin could be provided for HSQLDB, which should be implemented using JNI to invoke JDBC methods in the HSQLDB library. To avoid Java and OO.org dependencies, a small tool could be developed in Java to export/import to/from a intermediate format, and then used from within a Kexi migration plugin.<br />
<br />
In any case, migration plugins are simpler to implement than direct access plugins (drivers), so these can be developed first.<br />
<br />
'''Expected results:''' HSQL support would enable OpenOffice.org Base format for KDE and KOffice itself, a good companion to already existing OpenDocument support. ODBC connectivity would add many new possibilities directly to KDE.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:'''<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_DBaseMigrationPlugin "DBase Migration Plugin for Kexi" proposed by Jonathon Manning in 2006]<br />
*[http://kexi-project.org/wiki/wikiview/index.php?GoogleSummerOfCode2006_ParadoxAndHSQLAccess "Paradox & HSQL access for Kexi" proposed by Joseph Wenninger in 2006]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl>, Sebastian Sauer <mail@dipe.org><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Kexi Web Forms<br />
<br />
'''Brief explanation:''' Web Forms allow to read-only or read-write access to database projects created with Kexi. It is optional feature for uses where client has no Kexi installed for any reason. The fact that the Web Forms will use Web standards, adds another advantage over competitors like MS Access (which uses proprietary Windows-only ActiveX bindings).<br />
<br />
Proposed solution is to develop a small standalone web server. It is probably already written in C++ or C by FOSS community. Good examples are lighttpd - http://www.lighttpd.net/ <br />
and (being already in KDEnetwork module) KPF - http://rikkus.info/kpf.html.<br />
<br />
The web server would be dynamically linked to kexidb and thus can access Kexi databases via universal KexiDB API, and create HTML content on demand as an answer to HTTP requests.<br />
<br />
For alternative solution see "Alternative solution for Kexi forms using PHP" below.<br />
<br />
'''Expected results:''' Shortly, it is internet-enabler for KOffice/KDE data management.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of C++ and HTTP/web standards, (knowledge of Qt and experience with a given database format/backend is recommended)<br />
<br />
'''More info:''' [http://jacek.migdal.pl/gsoc/ Solution proposed by Jacek Migdal last year]<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
-------<br />
'''Project:''' Alternative Solution for Kexi Forms Using PHP<br />
<br />
'''Brief explanation:''' Create a Kexi plugin generating PHP code saving it directy to the filesystem. This will require Apache (or other PHP-compatible web server) to be present and configured, and also will require the plugin to be packaged with a script that will install appropriate tools that allow r/w accessing the Apache/php subdirs.<br />
<br />
'''Expected results:''' The generated code could directly access MySQL or PostgreSQL servers at the backend, so users could immediately have a robust server-side solution without complex requirements.<br />
<br />
'''Knowledge Pre-Requisite:''' knowledge of PHP, web standards and C++, (knowledge of Qt is recommended)<br />
<br />
'''Mentor:''' Jaroslaw Staniek <js@iidea.pl><br />
<br />
'''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kexi kexi at kde.org]<br />
<br />
==== Krita ====<br />
<br />
'''Project:''' Sumi-e brush engine<br />
<br />
'''Project Information:''' While there is already an attempt at a sumi-e brush engine in Krita, the current code is limited and uses an old-fashioned way of simulating brushes. <br />
<br />
'''Expected results:''' This project should implement an anti-aliased, bidirectional ink-transfer simulation of a sumi-e brush, together with a user interface to define brushes. The brushes should react to pressure, tilt and rotation of the a tablet stylus. The results should be realistic. Loan hardware for use during the development phase is available.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic knowledge of basic 2d graphics principles. A list of relevant papers and books is available.<br />
<br />
'''Mentor:''' Boudewijn Rempt <boud@valdyas.org> The mentor can help preparing the project proposal for submission to Google.<br />
<br />
-----<br />
<br />
'''Project:''' Sketch-pad interface for Krita<br />
<br />
'''Project Information:''' Krita is a large and complex application built around a sophisticated painting engine. The goal of this project is to create a new interface around the Krita engine, specialized for quick sketching.<br />
<br />
'''Expected results:''' This project should implement a new interface around Krita, presenting the user a single-layer plus tracing paper interface with a single freehand sketching tool. Easy to use and graphic color and paint operation (brush, pencil, eraser etc.) interface elements must be designed and implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:''' <br />
<br />
-----<br />
<br />
'''Project:''' Shader filters and generators for Krita<br />
<br />
'''Project Information:''' Some initial work has already been done to make it possible to write filters in the OpenGL shading language. This project should take that initial code as a basis and implement a fully functioning plugin for Krita that allows filters and shaders to be executed on images in any colorspace.<br />
<br />
'''Expected results:''' The plugin should have a finished user interface and make it possible to experiment with shader filters in an interactive way. Example filters must be implemented.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, OpenGL.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Animation support<br />
<br />
'''Project Information:''' There is no support at all in Krita for animated images such as GIF or MNG or for working with images in an animation context, such as textures or backgrounds in applications like Blender. The applicant should first investigate user needs and use cases and then implement support in the user interface and in the import/export filters.<br />
<br />
'''Expected results:''' A user-friendly way of working with animated images (i.e., not by making each frame a layer), but e.g. a docker that shows the the animation running in thumbnail format. Import/export filters for relevant file formats.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' RAW plugin<br />
<br />
'''Project Information:''' Krita's current raw plugin is based on a shell exit to dcraw. This is not sufficient and needs to be re-implemented.<br />
<br />
'''Expected results:''' A next generation plugin should implement loading of raw images either through libopenraw or libkdcraw; preferably designed in such a way that we can switch libraries when opportune. The plugin should allow the user to set conversion parameters in a way that is useful to photographers. An extension to this project could be the implementation of a bayer colorspace model: that is, a colormodel that allows us to load the raw images and edit them in the native raw format, without conversion.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' PSD and Gimp plugins<br />
<br />
'''Project Information:''' Krita is powerful enough to handle nearly all that the Gimp and Photoshop are capable of saving. This project is about creating dedicated file import/export filters that can handle as much of these file formats as possible, possibly through the use of existing libraries.<br />
<br />
'''Expected results:''' 4 plugins: psd import/export and xcf import/export. These plugins should be able to handle complex files in all supported colorspaces.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Photoshop-compatible brush engine<br />
<br />
'''Project Information:''' A paintop plugin that can load and handle current photoshop brushes. This entails reverse engineering of the Photoshop brush file format and implementing a procedural brush engine that matches the Photoshop brush engine.<br />
<br />
'''Expected results:''' A procedural brush engine with settings dialog that can load and save current photoshop brush files.<br />
<br />
'''Knowledge Pre-Requisite:''' C++<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
'''Project:''' Workspaces<br />
<br />
'''Project Information:''' A workspace is a loadable package of settings that finetune Krita for a particular purpose. A workspace could contain additional plugins (like an image browser plugin for batch operations) and a subset of resources. Example workspaces could be batch-editing of images, editing of animation sequences or painting or sketching.<br />
<br />
'''Expected results:''' the user interface and framework to make packages of plugins and resources that users can switch between. Also extra plugins to extend krita in areas like batch processing that do not exist yet.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:''' <br />
<br />
<br />
-----<br />
<br />
'''Project:''' Kipi and digikam plugins compatibility<br />
<br />
'''Project Information:''' Kipi and digikam provide lots of interesting plugins for working with 8 and 16 bit RGBA images. It would be great to be able to re-use those plugins from within Krita.<br />
<br />
'''Expected results:''' Two plugins that load kipi and digikam filters into two new menus in the filter menu. Code to convert Krita layers to the digikam image representation and back, taking care of icc profiles and other niceties.<br />
<br />
'''Knowledge Pre-Requisite:''' C++, artistic workflow<br />
<br />
'''Mentor:'''<br />
<br />
=== KDE SDK ===<br />
<br />
==== Umbrello ====<br />
<br />
Umbrello is the UML drawing and design tool in KDE.<br />
<br />
----<br />
<br />
'''Project:''' Add the capability to draw SysML diagrams (http://www.omg.org).<br />
<br />
----<br />
<br />
'''Project:''' Port Umbrello to QGraphicsView<br />
<br />
----<br />
<br />
==== Kobby ====<br />
<br />
<br />
'''Project:''' Kobby. A text editor which allows multiple users modify a set of documents at the same time. This is called a collaborative text editor.<br />
<br />
'''Brief explanation:'''<br />
* The idea is to create a KDE based application that depends on the [http://gobby.0x539.de/trac/wiki/InfinoteProtocol infinote] library which is the successor of the obby library.<br />
* It would be really nice to have integration with already existing editing and coding solutions: as KDevelop, or Kate for instance.<br />
* It would be even better if it was a katepart plugin so it can be used everywhere kateparts are used. The plugin integration can probably be done by extending KTextEditor to use the infinote API.<br />
<br />
You can find the [http://gobby.0x539.de/trac/ Gobby page here], where you can [http://gobby.0x539.de/trac/wiki/InfinoteProtocol also check out the infinote] library code. Svn repository: svn://svn.0x539.de/infinote/trunk<br />
<br />
'''Mentor:''' Andreas Ramm <psychobrain@gmx.net><br />
<br />
COMMENT: I had filed my vision of collaborative editing in KDE applications as wishlist item [http://bugs.kde.org/show_bug.cgi?id=149498 149498].<br />
Also see bugs [http://bugs.kde.org/show_bug.cgi?id=79721 79721] and [http://bugs.kde.org/show_bug.cgi?id=145011 145011]<br />
<br />
COMMENT: Infinote is under heavy development, and both the protocol and the library API have gaps and are subject to change. Whether you view this as a drawback or a chance to help shape and be on the cutting edge of open-source collaborative editing is down to you.<br />
----<br />
<br />
=== KDE Edu ===<br />
<br />
==== Marble ====<br />
<br />
'''Project:''' Marble - Routing<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/marble Marble] is a generic geographical map widget and framework that is meant to be used by KDE4 applications. It is also distributed as a standalone application in KDE4.<br />
<br />
'''Brief explanation:'''<br />
* Build on the inclusion of OpenStreetMap data in Marble.<br />
* Implement routing algorithms, ex. A*<br />
* implement a display of the route on the globe.<br />
* Optionally, show a list of roads and turns to get to destination.<br />
<br />
'''Expected results:'''<br />
Ability to chose start point, end point and type of transport (car, bike, foot <br />
etc.) and get a display of a route on the globe.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, knowledge of OpenStreetMap.<br />
<br />
'''Mentor:'''<br />
<br />
-----<br />
<br />
<br />
'''Project:''' Marble - OSM Annotation<br />
<br />
'''Brief exmplanation:'''<br />
* With a UMPC (possibly with built-in GPS receiver), it is possible to go into the field and hold a "verification party" to check the accuracy of OSM data. However, making notes when the OSM data is inaccurate is somehow annoying.<br />
* This project will implement on-screen annotation for OSM data overlaid on Marble, including mark and circle (i.e. drawing stuff on the map) and text annotation (taken together, it means you can draw a circle on the map and add a note saying what's wrong there).<br />
* Integration with UMPC stylus and on-screen keyboard input methods is needed.<br />
* Aggressive caching of Marble / OSM data in order to display it in the field is needed as well (compare Google Earth on an iPod).<br />
* Bonus points for optimizing for battery life.<br />
<br />
'''Mentor:''' Adriaan de Groot and Armijn Hemel. Touchscreen hardware might be provided on loan through the mentors.<br />
<br />
----<br />
<br />
==== Parley ====<br />
<br />
'''Project:''' Parley - Practice<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/parley Parley] is the vocabulary trainer that comes with KDE4. It is based on KVocTrain but has a much improved GUI. It allows to manage and exchange vocabulary collections that are stored in XML and provides advanced features, such as different practice modes.<br />
<br />
'''Brief explanation:''' The library and the GUI for editing vocabulary have been rewritten to a great extent. Now the thing that is still lacking is the most important part, the actual vocabulary practice. Based on QGraphicsView a nice practice dialog can be implemented, learning does not have to look boring.<br />
<br />
'''Expected results:''' A working practice which supports different modes of practice, ranging from multiple choice and written tests to conjugation and other grammar practices. Support for themeing is desireable.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, QGraphicsView, basic SVG knowledge.<br />
<br />
'''Mentor''': Frederik Gladhorn <frederik DOT gladhorn AT kdemail DOT net><br />
<br />
<br />
-----<br />
<br />
==== KStars ====<br />
<br />
'''Project:''' KStars: Millions of stars<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. Its display includes 130,000 stars down to 9th magnitude, which is well below the naked-eye limit, but inadequate for advanced purposes. <br />
<br />
'''Brief explanation:''' We would like to see KStars displaying millions of stars, without adversely affecting the program's responsiveness. Much of the infrastructure needed to accomplish this was implemented as part of the KDE-4.0 port, but the remaining work to make millions of stars a reality would be a nice SoC project.<br />
<br />
'''Expected results:''' Expanding the KStars database to include at least a million stars, while maintaining the current level of responsiveness. This will likely require asynchronous disk i/o to read in regionalized chunks of stars data, so that only the onscreen portion of the sky is loaded into memory.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, and probably Qt. Threaded programming a plus.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Prettyfication<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. The display is interactive, but it could be made more beautiful. <br />
<br />
'''Brief explanation:''' We often get good suggestions for making KStars look better. Choose any of the following ideas: realistic rendering of asteroids and comets (including tails!); texture-mapping of the sky (this would mostly allow a photorealistic Milky Way); texture-mapping of planets; realistic sky-lighting effects (i.e., sky is blue in the daytime, gets gradually darker and colorful at sunset).<br />
<br />
'''Expected results:''' Successful implementation of any of these ideas to make KStars more beautiful.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Printable star charts<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It already has a print feature, but the printed chart could be much better. <br />
<br />
'''Brief explanation:''' A printed star chart should at least include a legend explaining the symbols, and provide some information <br />
on the location of the user, the time and date, etc. The user would ideally be able to annotate the chart in various ways.<br />
<br />
'''Expected results:''' Significant improvements to the printed star charts in KStars.<br />
<br />
'''Knowledge Pre-Requisite:''' Basic programming skills, ability to quickly learn QPainter API.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
'''Project:''' KStars: Many Moons<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/kstars KStars] is a desktop planetarium program for KDE. It currently includes Earth's moon and 4 of Jupiter's moons. <br />
<br />
'''Brief explanation:''' Generalize the JupiterMoons class to encapsulate any planet's Moons. The project will require some research to identify a public source of orbital data for planetary moons, most likely from a NASA webpage. <br />
<br />
'''Expected results:''' Implement moons for at least Mars, Jupiter, Saturn, and Pluto with the new system.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. The project doesn't require much contact with Qt/KDE APIs, and the existing JupiterMoons class can be used as a template.<br />
<br />
'''Mentor''': Jason Harris <kstars AT 30doradus DOT org><br />
<br />
<br />
-----<br />
<br />
==== Step ====<br />
<br />
'''Project:''' Step: 3d mode<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Implement physical simulation in 3d. This involves:<br />
* convert all classes in StepCore to templates with dimension as a template parameter, implement specialized versions where required, modify meta-object system to handle it<br />
* implement 3d mode in GUI: viewing and editing<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view 3d simulations in Step with the same set of objects as in 2d.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, basic OpenGL, basic physics (mechanics). Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: a game<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
The idea is to create a game based on physical simulation where the player have <br />
a fixed list of equipment (like springs, balls, cat and mice, teapot, etc.) and should use it to build a machine to achieve a given goal (for example put the ball in a basket, capture the mice, prepare a tea, etc.). The user places the equipment, than press Start button which starts physical simulation and if (in certain time limit) the goal is achieved the game is won. In the other case the user could try again. Similar projects: old game named "The Incredible Machine" and newer (but commercial) one named "Crazy Machines".<br />
<br />
The game can be implemented as standalone application using StepCore or as special restricted 'game' mode for Step (probably with tweaked graphics).<br />
<br />
'''Expected results:'''<br />
Playable game and several levels to test it.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++. Could be useful: Qt, basic physics (mechanics).<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: simulation of chemical reactions<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1. This project also relates to [http://edu.kde.org/kalzium Kalzium].<br />
<br />
'''Brief explanation:'''<br />
Simulate some basic chemical reactions using classical molecular dynamics methods with empirical potentials. At first initial settings for simulation should be prepared by hand (as XML file), if there will be enough time an editor could be implemented too. This project involves:<br />
* convert required classes from StepCore to handle 3d simulations (you will need only several classes which are trivial to convert)<br />
* implement required objects and potentials in StepCore<br />
* implement GUI for observing the simulation (investigate the possibility to use avogadro library for visualization), GUI should also allow altering of some properties like masses and charges<br />
* prepare demonstrations of several common reactions<br />
<br />
'''Expected results:'''<br />
Chemical reaction viewer which could load predefined experiment, modify some basic properties and run the simulation. Prepared simulation for several common reactions.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, basic chemistry. Could be useful: Qt, basic quantum mechanics, knowledge of common molecular dynamics simulation techniques and numerical methods.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: fast water and gas simulation<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
Currently Step has molecular dynamics based simulation of gas and water (that is a gas is simulated as a collection of particles). This is very usefull for demonstrating microscopical properties of the gas as well as its connection with macroscopical quantities like temperature. But this is far from optimal to demonstrate things like a boat floating in the water, water flowing from a glass, etc. This project involves:<br />
* investigate fast methods of simulating water and gas: ranging from molecular dynamics but with simplified potentials, various optimizations, coarse graining methods, to lattice Boltzmann methods; investigate existing libraries for water simulation (for example take a look at [http://elbeem.sourceforge.net/ elbeem] library from Blender)<br />
* implement selected method of simulation or incorporate selected library in StepCore<br />
* implement GUI in Step for creating and modifying macroscopical quantities of gas and watter<br />
<br />
'''Expected results:'''<br />
Ability to easily simulate in Step experiments like a boat floating in the water, water flowing from a glass, etc.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, physics, numerical methods. Could be useful: Qt.<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
-----<br />
'''Project:''' Step: other ideas<br />
<br />
'''Project Information:'''<br />
[http://edu.kde.org/step Step] is an interactive physical simulator for KDE. Currently it lives in playground but it will be included in kdeedu package for KDE 4.1.<br />
<br />
'''Brief explanation:'''<br />
These are smaller ideas related to Step. You can combine several of them to compose you project.<br />
* use KAlgebra library for parsing user-supplied expressions in PropertiesBrowser; allow value in Meter, x- and y-values in Graph to be arbitrary expression; implement ParametricForce object that will apply a force given by user-supplied expression; implement a series of ParametricJoint objects that will allow creation of various parametric constraints (like fixed particle trajectory)<br />
* scripting for Step using either QtScript or Kross<br />
* multi-threaded calculations in StepCore (knowledge pre-requisite: multi-threaded programming)<br />
* correctly handle stiff problems in StepCore (knowledge pre-requisite: numerical methods)<br />
* calculation of gravitational and electromagnetic force between non-point objects by integrating (knowledge pre-requisite: numerical methods)<br />
* make StepCore compilable without Qt<br />
* improve soft-body support: implement automatic creation of arbitrary-shaped soft bodies, better soft-body border handling, investigate better (more accurate) methods of modeling soft bodies (knowledge pre-requisite: physics)<br />
* support for non-convex polygons (probably by implementing triangulation)<br />
* optimize collision detection (AABB trees, etc.)<br />
* framework for dynamic object creation/destruction in order to allow implementing particle emitters<br />
* statistical models (for example prey/predator model)<br />
If you have other ideas please feel free to propose them !<br />
<br />
'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com><br />
<br />
==== RoxGT ====<br />
<br />
'''Project:''' RoxGT <br />
<br />
'''Project Information:'''<br />
RoxGT is a OSS done by Ugo Sangiori for building Graph-based applications. It aims essentially for academic jobs, such as graph algorithm execution and theorem proofs. <br />
<br />
'''Brief explanation:'''<br />
Rewrite the RoxGT, today it's written in Java as a Eclipse Plugin. This project aims to transform RoxGT into a full featured KDE4-Application, with all the benefits that Kross can give for the implementation of the algorithm execution in every language suported by Kross, and not only Java.<br />
<br />
Possibly integration of RoxGT in Marble, as a kparts to do things like 'shortest path between 2 points' when marble is used as GPS mode.<br />
Possibly integration of RoxGT in Umbrello, examining the UML and searching for design flaws into the Graph-generated UML.<br />
<br />
'''Expected results:'''<br />
Ability to create, edit and view simulations in graphical mode of Graph-Theory algorithm execution.<br />
<br />
'''Knowledge Pre-Requisite:''' Required: C++, Could be useful: Qt.<br />
<br />
'''Mentor:''' Looking for One.<br />
<br />
'''Student''' Tomaz Canabrava - tomaz <dot> canabrava <at> gmail <dot> com<br />
<br />
----<br />
<br />
=== KDE PIM (Personal Information Management) ===<br />
<br />
==== Kontact ====<br />
<br />
==== KOrganizer ====<br />
<br />
'''Project''': Beautiful month view<br />
<br />
'''Description''': The month view of KOrganizer has a long history, which is beginning to show, especially in terms of visually attractivity and performance. With KDE 4 and especially the latest versions of Qt 4 there is an unprecedented opportunity to add some beauty to this view. The goal of this project would be to create a new version of the month view which is able to display a month's worth of events in a beautiful, efficient and user-friendly way. This would include appointments, todos, multi-day events. In addition of a good display of events one could also think about advanced ideas like dynamical zooming of days, 3D indicators of categories or calendar associations, and more. There is a lot of room for creativity in this project.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
==== KPilot ====<br />
<br />
==== KMail ====<br />
----<br />
'''Project:''' Message-View: Use more than one line per message<br />
<br />
'''Project Information:'''<br />
As known from other email-apps there is a use-case for having three panes next to each other. However the message-list is currently restricted to one line per message which makes it quite unuseable for that purpose. Thus a new view is needed.<br />
<br />
'''Knowledge Prerequisite:''' Qt Interview Framework<br />
<br />
==== Kleopatra ====<br />
<br />
Kleopatra is the KDE Certificate Manager. In KDE 4.1, it will have gained OpenPGP support (it originally comes from the X.509 world). It is currently being prepared to be integrated into the [[http://www.gpg4win.org GnuPG For Windows]] installer, too, and therefore needs to work in a size-reduced KDE environment (basically, kdecore and kdeui only).<br />
<br />
All of the Kleopatra projects naturally require familiarity with Qt, C++, and GnuPG/OpenPGP concepts.<br />
<br />
----<br />
'''Project:''' OpenPGP web-of-trust visualization<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement a mechanism to visualize the user's personal OpenPGP web of trust.<br />
<br />
'''Detailed Description:'''<br />
For a long time now, Kleopatra has had the ability to show a ''hierarchical view'' of the user's X.509 (aka. S/MIME, aka. CMS) keyring. Such a view lends itself naturally to X.509 certificates, whose trust model ''is'' hierarchical. Here, ''subjects'' (signees) are children of their respective issuers (signers) in a standard tree view, so that root certificates end up being top-level items.<br />
<br />
Naturally, this simplistic hierarchical view is hard to generalize to OpenPGP's Web-of-Trust (WoT) model where everyone may certify everyone else. It is the goal of this task to identify and implement such a generalized ''hierarchical view'' that fits this extended trust model.<br />
<br />
At least two views are obvious candidates (but this task is not restricted to only these):<br />
<br />
Extend the current X.509-type hierarchical view around the idea that my own key can be seen as my own personal ''root certificate'': Keys signed by me would be first-level children of my top-level key, and keys signed by those people would be second-level children, etc. The depth of a key in the item would be the same as that reported as <tt>depth</tt> in the output of <tt>gpg --check-trustdb</tt>. Problems with this approach include mapping a directed cyclic graph onto a tree for putting it into a tree view. Some people also have the opinion that the reverse of what is described here would be what users expect (rationale: <tt>gpg</tt> lists the signers below the signee in an <tt>--list-signatures</tt> operation).<br />
<br />
The second option is to use a graph visualization widget (to be found somewhere or written) that would allow to browse the WoT interactively. This ''might'' break the timeframe, but could be made into a more general component that can be used elsewhere if the project progresses exceptionally well.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a visualization tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* It should contain the X.509 case as a special subset.<br />
* It is easy to find the people I have signed.<br />
* It is easy to see the trust path between two certificates.<br />
* It is easy to see when such a trust path does not exist.<br />
With regard to Gpg4Win, the solution should fail gracefully in the absence of either the external tool, or KMail/Akonadi.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra. Graph visualization knowledge would help, too.<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
----<br />
'''Project:''' Keysigning Party Support<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement functionality to automate the challenge-response mail algorithm used after OpenPGP keysigning parties<br />
<br />
'''Detailed Description:'''<br />
Everyone that has been to a keysigning party has probably gotten a challenge mail to decrypt and send back afterwards. This is done in order to verify that the owner of the email address is also the owner of the (secret) key. This procedure is the basis for most OpenPGP Keysigning Policies, including the one from [http://www.math.uni-bielefeld.de/~mmutz/sign-policy.html#act your mentor].<br />
<br />
There are two ways to do this:<br />
* Interface with an already existing robot that is hooked into the local mail server, or<br />
* Interface with KMail/Kontact (or, if ready by then Akonadi).<br />
<br />
The second option is preferable, as it allows users with a normal desktop system to participate in the system. The first option would have to do a lot of user handholding for being usable enough for the target audience.<br />
<br />
'''Expected results:'''<br />
A completed, tested, and documented implementation of a OpenPGP challenge/response tool for OpenPGP, integrated into Kleopatra's 1.9.x/2.x branch. Important capabilities include:<br />
* Track sent challenges<br />
* Validate responses.<br />
* Alert the user when all responses necessary for a signing have been received.<br />
* Optionally, do this without user interaction.<br />
* Optionally, do this per user-id.<br />
* Deal gracefully with responses that are not forthcoming.<br />
With regard to Gpg4Win, the solution should also have no further external dependencies (mainly Qt, boost, kdelibs, kdeui, gpgme), but this is no hard requirement.<br />
<br />
Optionally, a MIME message format that facilitates the automatic handling of these challenge/response mail could be created and publicized.<br />
<br />
'''Knowledge Prerequisites:''' Same as for Kleopatra<br />
<br />
'''Mentor:''' [mailto:mutz@kde.org Marc Mutz]<br />
<br />
==== Akonadi ====<br />
<br />
Akonadi (http://kdepim.kde.org/akonadi/) is the framework for groupware and other PIM applications for KDE4.1 and later. <br />
<br />
----<br />
'''Project:''' Akonadi backend for Microsoft Exchange Groupware server<br />
<br />
'''Project Information:'''<br />
The proposed SoC task will implement an Akonadi backend to allow users to work with Microsoft Exchange servers and applications using compatible protocols (e.g. Outlook).<br />
<br />
'''Brief explanation:'''<br />
The implementation will almost certainly need to use the OpenChange (http://www.openchange.org) libraries. A proof-of-concept implementation has been done (available in KDE's SVN archive), but has bit-rotted as the OpenChange libraries have evolved. <br />
<br />
'''Expected results:'''<br />
A completed, and tested, backend that can operate with a current Microsoft Exchange server. Important capabilities include:<br />
* ability to receive mail,<br />
* ability to create and receive appointments, and to view the calendar,<br />
* ability to access the address book, and<br />
* ability to create and receive tasks.<br />
<br />
Sending mail is outside the scope of Akonadi, and is a "growth" potential if the project is proceeding particularly well.<br />
<br />
'''Knowledge Prerequisite:''' You need to have some familiarity with groupware applications (e.g. knowledge of how appointments and address books are used). C and C++ is pretty much essential, and at least passing knowledge of Qt. <br />
It would be useful (but not absolutely essential) if you had access to a Microsoft Exchange server you can use for testing - we may be able to arrange access.<br />
<br />
'''Mentor:''' Optional, possibly Brad Hards <bradh@kde.org><br />
<br />
----<br />
<br />
'''Project:''' Akonadi testing framework<br />
<br />
'''Project Information:''' Akonadi uses helper processes, called Agents, to do the actual processing of PIM data, e.g. transfer from/to an external storage.<br />
Agent functionality can depend on operations on the Akonadi store performed by other participating processes (Agents and/or clients), e.g. updating an external storage when a user application applies changes to PIM data.<br />
<br />
'''Brief explanation:''' In order to test such a setup automatically or semi-automatically, a testing framework needs to provide the following items:<br />
* means to launch Akonadi in a defined state, e.g. by restoring a data base dump<br />
* means to start a certain set of Agents<br />
* means to trigger changes on Akonadi's data<br />
* means to check the resulting state of Akonadi<br />
<br />
'''Expected results:'''<br />
* tools or test templates for developers to create and run test scenarios, probably using a scripting language like Python or Ruby.<br />
* example test scenarios for at least one agent and one resource<br />
<br />
'''Knowledge Pre-Requisite:''' An understanding of the concept of collaborating services, knowledge how to setup shell environments<br />
<br />
'''Mentor:''' Kevin Krammer <kevin.krammer@gmx.at><br />
<br />
----<br />
<br />
'''Project''': Akonadi Resouce: GroupDAV<br />
<br />
'''Description''': [http://www.groupdav.org/ GroupDAV] is a standard protocol to access groupware servers. It's for example implemented by [http://www.opengroupware.org OpenGroupware.org] or [http://www.citadel.org Citadel]. The task of this project is to create a native [http://pim.kde.org/akonadi Akonadi] resource to provide access to GroupDAV enabled servers to all KDE applications, in particular the KDE PIM suite. There is an existing KDE 3 based KResource supporting GroupDAV which could be used as a starting point.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Calendar<br />
<br />
'''Description''': Googgle Calendar provides an API to access the calendar data on the server. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource, so that any accessible Google calendar can be displayed and edited in Akonadi enabled applications, e.g. in KOrganizer.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Google Contacts<br />
<br />
'''Description''': Googgle recently has opened their [http://code.google.com/apis/contacts/ Google Contacts Data API]. This makes it possible to access the contacts data which is stored at Google, e.g. for GMail. The task of this project would be to implement an [http://pim.kde.org/akonadi Akonadi] resource to access contact data stored at Google, so that it can be displayed in Akonadi enabled applications, e.g. in KAddressbook.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
----<br />
<br />
'''Project''': Akonadi Resource: Facebook friends and events<br />
<br />
'''Description''': Facebook has an [http://wiki.developers.facebook.com/index.php/API API] that can be used to query a user's friends and information about these. The API also gives access to a user's events. The aim of this project is to implement an Akonadi resource to access contact data stored on Facebook for a user's friends, and also give access to a user's events in Akonadi so that this information can be used in KOrganizer and KAddressbook.<br />
<br />
'''Mentor''': <br />
<br />
Note that there already is [http://websvn.kde.org/trunk/playground/pim/kfacebook/akonadi/ an implementation].<br />
<br />
----<br />
<br />
'''Project''': Akonadi Agent: PIM Data Mining<br />
<br />
'''Description''': PIM data usually contains a lot of related PIM data in some explicit or implicit form. Emails contain contact data as sender or recipients or as part of the signature. Emails also can contain calendar data, e.g. when sending groupware invitations or just by mentioning a date as part of an informal mail about getting together for a beer. The goal of this project is to implement an [http://pim.kde.org/akonadi Akonadi] agent which transparently collects all this information in the background and makes it available to the user e.g. as a special address book ("Email addresses of people to whose emails I answered on a mailing list", etc.). There are many interesting options what and how to implement this and part of the project would be to investigate, what makes sense to be collected and which methods are best suited to get the most useful information from the available raw data.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KDE Games ===<br />
<br />
'''Project''': Polytris clone<br />
<br />
'''Description''': Polytris is an old DOS game based on the Tetris concept. Its unique feature is that the number of blocks a piece is build from isn't fixed to four as in the original Tetris, but that it's variable. There are the simple one block pieces which fit everywhere, but there are also the challenging ten block pieces, which provide a complex setting which then has to be filled with other pieces. Difficulty of the game increases over time not by letting pieces fall faster, but by increasing the average number of blocks the pieces are constructed of.<br />
<br />
The task of this project is to create a KDE 4 version of this game. In addition of implementation of the basic game functionality extra credits are given for great playability, beautiful appearance, and a creative and motivating scoring scheme.<br />
<br />
'''Mentor''': [mailto:schumacher@kde.org Cornelius Schumacher]<br />
<br />
=== KDE Development & Web Development ===<br />
<br />
==== Kompare ====<br />
<br />
'''Project Information:'''<br />
[http://www.caffeinated.me.uk/kompare/ Kompare] is a graphical difference viewer.<br />
<br />
-----<br />
'''Project:''' Semantic diff<br />
<br />
'''Brief explanation:'''<br />
Implement a plugin-based approach for different (potentially incomplete) diff-algorithms. Documents are not just lines of text, but have semantics, and these plugins should help to see changes made to the document.<br />
<br />
Possible plugins are:<br />
* File information diff: show date, size, last-modification, ...<br />
* Programming language diff: detect changes like renamed variables, reindentation, namespace-changes, changes in comments, other refactorings ... (the more the better)<br />
* XML-diff<br />
* Latex-diff: whitespace is ignored.<br />
* config-file diff: in many config-files the order does not matter.<br />
* Image diff: at least show both images next to each other.<br />
* Video diff: show both videos next to each other and link their time. Should be interesting for diffs after reencoding.<br />
<br />
'''Expected Result:'''<br />
A native and Kross (for scripting) plugin-support for Kompare. Some of the above mentioned plugins.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Knowledge of C++.<br />
<br />
Comment: I think one of the most obvious applications of this is in SVG: it would be possible to graphically show the original image + new_rect merged as new_image fairly easily. You could even make elements transparent, and show them in steps, with onion-skinning, almost animating from previous version to new version. I'd also really like to see this "semantic-diff" for ODF documents.<br />
<br />
----<br />
<br />
==== KLinkStatus ====<br />
<br />
'''Project Information:'''<br />
[http://klinkstatus.kdewebdev.org/ KLinkStatus] is a link checker, part of the kdewebdev module.<br />
<br />
-----<br />
'''Project:''' Aided correction of broken links<br />
<br />
'''Brief explanation:'''<br />
Currently, it is possible to find out broken links but it is not possible to fix them. It would be great if those links could also be corrected within KLinkStatus. The corrector should present the user with sugestions, like a spell checker does (it might be possible to reuse some of the KSpell heuristics). Possible errors are typos in domain and paths, absolute vs relative path, and wrong directories.<br />
<br />
'''Expected results:'''<br />
Ability to fix broken links, being effectively assisted with suggestions.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' Site check automation<br />
<br />
'''Brief explanation:'''<br />
KLinkStatus already provide a D-Bus interface that allows to check sites in the background based on a configuration file and then export the results to HTML. A system administrator can already automate check using cron jobs. However it would be nice to offer a nice frontend inside KLinkStatus (without the need of super user permissions). The results could then be exported into files and/or emailed to the site administrator.<br />
<br />
'''Expected results:'''<br />
Easy site check automation and notification system.<br />
<br />
'''Knowledge Pre-Requisite:''' Some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ or a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
-----<br />
'''Project:''' HTML validation<br />
<br />
'''Brief explanation:'''<br />
HTML validation is a very requested feature by users. KLinkStatus already have the infrastructure for this, using libtidy, but some work is still missing in order to actually correct the HTML documents. <br />
<br />
'''Expected results:'''<br />
- Visual indication of which document have HTML validation problems<br />
- Ability to fix individual documents or several documents at a time <br />
- Ability to efectively preview, compare (perhaps using the Kompare kpart) and edit partial parts of a document<br />
- Configurable HTML validation parameters<br />
<br />
'''Knowledge Pre-Requisite:''' HTML, some knowledge of the Qt/KDE framework. Language wise, this feature can be implemented using C++ and, for some parts of it, a script language like Python, Ruby or Javascript.<br />
<br />
'''Mentor:''' Paulo Moura Guedes <moura at kdewebdev dot org><br />
<br />
==== KDevelop ====<br />
'''Project:''' Distribution integration<br />
<br />
'''Brief explanation:'''<br />
Integration of the build-system of one specific distribution into KDevelop. Usually it is quite easy to get the source-code of a package and build it, for example using "apt-get source" and "dpkg-build" under debian, or "osc" under openSUSE.<br />
<br />
'''Expected results:'''<br />
A user can start KDevelop, and choose a package from a list that should be retrieved from some distribution repository. Then KDevelop would download the source-package and create a project-directory+file into which all the necessary information is extracted, inluding a copy of the original project source that can be edited from within KDevelop. The developer can edit the source with code-completion, -navigation, and all the nice extras out of the box. Then the developer can build the package using the distribution-specific mechanisms, with the own changes to the source-tree are included as a patch.<br />
One of the most tricky things here would be providing KDevelop with correct include-path information for all the source-files. A simple hack to retrieve include-paths from existing makefiles is already implemented within KDevelop, and can be re-used. An additional bonus could be management of multiple separate patches on top of the source-tree, that can easily be submitted upstream.<br />
It would be nice if all the stuff could be implemented in a way that it's easy to add support for other Distributions.<br />
<br />
'''Knowledge Pre-Requisite:'''<br />
C++, package-building experience for a popular distribution(Maybe openSUSE or Ubuntu/Debian)<br />
<br />
==== Quanta ====<br />
<br />
=== KDE Network ===<br />
<br />
==== KRDC ====<br />
<br />
Add NX support to KRDC.<br />
<br />
-----<br />
'''Project:''' NX support in KRDC.<br />
<br />
'''Brief explanation:'''<br />
KRDC lacks NX support, which is gaining momentum in the free software world. Build upon the work done by George Wright in the 2006 SoC and the work done by Urs Wolfer in the 2007 SoC to create a top quality NX client for KDE.<br />
<br />
'''Expected results:'''<br />
Fully working NX integration for KRDC, including support for advanced NX features such as sound, VNC/RDP tunnelling etc. Feature parity with the commercial NX client shouldn't be necessary, but aiming for that isn't a bad idea. All NX connection handling code should be in the cross-platform client library nxcl (C++/STL/autotools), and all GUI specific code should be in KRDC.<br />
<br />
'''Knowledge Prerequisites:''' Knowledge of the NX protocol (see http://www.gwright.org.uk/protocol.pdf for an older version of the protocol), C++/STL/Qt/KDE coding and cross platform coding.<br />
<br />
'''Resources:''' http://freenx.berlios.de , http://blog.gwright.org.uk/articles/category/nx , http://nomachine.com/ , http://svn.berlios.de/wsvn/freenx<br />
<br />
'''Mentor:''' George Wright <gwright at kde dot org><br />
<br />
==== Decibel ====<br />
<br />
Decibel is a realtime communication framework for KDE 4.x.<br />
<br />
----<br />
<br />
'''Project:''' KDE4 integration<br />
<br />
'''Brief Explanation:''' Decibel should integrate well with the KDE 4 environment. This includes getting contact data from Akonadi and storing contact state there, storing account data in KWallet as well as integration with Nepomuk to store semantic information on connections made.<br />
<br />
'''Expected Results:''' A working and tested implementation of integration components.<br />
<br />
'''Knowledge Prerequisites:''' A good overview of the involved KDE 4 technologies is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/, Akonadi documentation<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Filtering framework for text messaging<br />
<br />
'''Brief Explanation:''' Text message that are passed to applications using the Decibel framework should get filtered. This includes processing steps (like processing of Off the record messages) as well as logging, etc. This filtering framework needs to be made more flexible as it currently is and some basic filters need to be written.<br />
<br />
'''Expected Results:''' The filtering API of Decibel is improved and sample filters are developed and tested.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required.<br />
<br />
'''Resources:''' http://decibel.kde.org/<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
----<br />
<br />
'''Project:''' Improve Telephony features<br />
<br />
'''Brief Explanation:''' Decibel currently has limited support for telephony features required for VoIP integration. This support needs to be improved and missing features (call forwarding, conferencing, etc.) should be implemented.<br />
<br />
'''Expected Results:''' A VoIP backend based on the existing telepathy backend with the additional telephony features implemented.<br />
<br />
'''Knowledge Prerequisites:''' A good understanding of Decibel is required. Familiarity with the telepathy spec and VoIP is helpful.<br />
<br />
'''Resources:''' http://decibel.kde.org/, http://telepathy.freedesktop.org/spec.html<br />
<br />
'''Mentor:''' Tobias Hunger <tobias at aquazul dot com><br />
<br />
==== Kopete ====<br />
'''Project:''' Integrate Decibel and Kopete<br />
<br />
'''Brief explanation'''<br />
Add support for Decibel to Kopete. This will involve some a lot of work within the Kopete core library (libkopete) in addition to making all the current protocol implementations into Telepathy Connection Managers. <br />
<br />
'''Knowledge Prerequisite:''' C++, Qt, KDE. <br />
<br />
'''Note:''' This is an advanced project. The proposal will need to be very detailed and very complete. Basically, you need to show that you've done your homework, so to speak. The student will also need to be able to work closely with his/her mentor and the rest of the Kopete developer community by being available on IRC and being subscribed to the Kopete mailing list. <br />
<br />
'''Mentor:''' Matt Rogers<br />
<br />
----<br />
<br />
=== KDE Multimedia ===<br />
====[http://dragonplayer.org Dragon Player] ====<br />
<br />
'''Project:''' External Subtitle File Support<br />
<br />
'''Brief explanation'''<br />
Dragon Player does support subtitles, but only for DVD's or subtitles that are bundled with the video file using formats like MKV. It can not load external subtitle files, such as .srt. As there isn't really a subtitle library that I know of, fixing this might require writing subtitle parsers (luckily most subtitles have simple formating). Displaying the subtitles themselves is non-trivial. Perhaps create a MKV file on-the-fly to make use of the multimedia backends subtitle parser and displaying? The more likely solution is to put the VideoWidget in a QGraphicsView and then superimpose the subtitle.<br />
<br />
'''Expected Results'''<br />
*Support for most of the popular subtitle formats.<br />
*A solution that works regardless of the Phonon backend being used.<br />
<br />
'''Knowledge Prerequisite:''' C++, Qt. Experience with subtitle formats a bonus.<br />
<br />
'''Mentor:''' Ian Monroe<br />
----<br />
<br />
=== Amarok ===<br />
Consider these suggestions a starting point to create your own proposal. Some need more detail. Please contact us and let us help you with the proposal before submitting. Find us on IRC on [irc://irc.freenode.net/amarok irc.freenode.net #amarok] or email the public mailing list [mailto:amarok@kde.org amarok@kde.org].<br />
<br />
-----<br />
'''Project:''' CD Stack collection view<br />
<br />
'''Brief Explanation:'''<br />
In iTunes you might have seen the very fancy view with albums flying by very prettily and not very usefully. Now, imaging instead that you have a stack of CDs in a tower. You scroll up and down through it, take one out, and open it to see what tracks are on it. A mockup of this idea can be found here: [http://leinir.dk/temp/gallery/mockups.php?gallery=mockups&image=mockups/cd-stack-in-glorious-pen-o-vision.jpg CD Stack]. Qt has a Model/View system that allows multiple views to the same data. This project would be a new view on the current collection browser. It could be implemented in 3D using OpenGL or using the pseudo-3D techniques that projects like Marble use.<br />
<br />
'''Expected Results:'''<br />
A working (not necessarily polished) implementation of such a CD stack interface, most preferably Model/View based.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, and while experience with Qt (and QGV) is nice it is by no means required, as it can be learned relatively easily. OpenGL and/or 3D programming helpful.<br />
<br />
-----<br />
<br />
'''Project:''' Context View development and Applet writing<br />
<br />
'''Brief Explanation:'''<br />
The Context View is one of the most visually evident features of the new Amarok 2. It takes up the middle part of the Amarok window and provides a view into the information about the song that a user is playing. As such, it is essential to Amarok that the Context View be functionally pleasing, polished, and pretty.<br />
<br />
A project focused on the Context View would consist of mainly continuing development on the CV itself, completing features that are planned but have not yet been implemented, as well as writing new Applets and DataEngines to display further data.<br />
<br />
'''Expected Results:'''<br />
A Context View that uses libplasma to provide an Amarok-specific way of viewing current data in a beautiful and innovative form. The basic structure and architecture is already there, but it needs substantial work to complete.<br />
<br />
Also, time permitting, the development of new applets and data engines for Amarok's CV.<br />
<br />
'''Knowledge Prerequisite:'''<br />
Knowledge of C++ is required, but this is probably a less KDE project as others. Experience with Qt is nice but by no means required, as it can be learned relatively easily.<br />
<br />
'''Mentor:'''<br />
Leo Franchi (lfranchi) is the original author of the Context View (in Soc 2007) and is willing to mentor any interested student. He can be contacted on #amarok at irc.freenode.net or (better) at lfranchi AT gmail DOT com.<br />
<br />
-----<br />
<br />
'''Project:''' Nepomuk collection<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a plug-in system that allows it to access music metadata from various backends. A plug-in to read and write data to and from Nepomuk should be written in this project. Additionally, Amarok should be extended to make real use of Nepomuk's capabilities by re-adding labels support.<br />
<br />
'''Expected results:'''<br />
A plugin to use Nepomuk as a metadata store from Amarok. Additionally, support for labels should be added to Amarok 2.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE would be helpful<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
-----<br />
<br />
'''Project:''' UPnP Support<br />
<br />
'''Brief explanation:'''<br />
Using the UPnP protocol users can, for example, share music from their Vista computer to a PS3. Amarok lacks any sort of UPnP support. Being able to act as a client (the PS3) or possibly a UPnP media server (Vista) would be useful. See [http://pupnp.sourceforge.net/ libupnp] for more information about UPnP's implementation in open source. The nature of how UPnP works would need to be researched a bit more, as the creator of this idea (Ian Monroe) has only seen it in use on friends computers. :)<br />
<br />
'''Expected results:'''<br />
*Using either Amarok's Internet Service framework or the straight Amarok collection framework, create a plugin which allows Amarok to browse and play music off of a UPnP share. Playing music may require the creation of a KIO for UPnP.<br />
*Allow Amarok to share it's collection with other devices via UPnP. This is secondary priority and may not be feasible to accomplish during Summer of Code.<br />
<br />
'''Material Prerequisite:''' Some UPnP devices or computers to test with.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and networking would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
-----<br />
<br />
'''Project:''' Amarok Scripting<br />
<br />
'''Brief explanation:'''<br />
Starting with Amarok 1.2, Amarok has enabled scripting through a script manager and its DCOP interface. For Amarok 2 we have a straight port of the old DCOP API to DBus. The old API was created over time, and perhaps could be thought out better. Additionally KDE 4 has introduced technology like Kross that could allow true integration of scripts into Amarok, including GUIs. In-process scripting has its own issues though!<br />
<br />
'''Expected results:'''<br />
*This is a more open-ended idea. Contact the Amarok mailing list or on IRC to get help working out the proposal.<br />
:*Perhaps redesign the Amarok DBus API <br />
:*..and/or add a Kross interface and then <br />
:*Create a script showcasing the technology.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt, KDE and Ruby would be helpful.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok<br />
<br />
-----<br />
<br />
'''Project:''' CD Ripping<br />
<br />
'''Brief explanation:'''<br />
Amarok has never really felt a need for good CD ripping support. We always felt there were better programs suited for this task. This hasn't stopped folks from finding ways to use Amarok to rip their CDs though. ;) <br />
<br />
'''Expected results:'''<br />
*An excellent CD ripping solution integrated into Amarok. <br />
*Cross-platform (Linux, Mac, Windows)<br />
*This task is not too large, so there would be higher standards of polish.<br />
<br />
-----<br />
<br />
'''Project:''' Mass-tagging<br />
<br />
'''Brief explanation:'''<br />
Users sometimes have poorly tagged tracks. Amarok has always lacked an easy way to download information about tracks from FreeDB or Musicbrainz and then tag multiple tracks at once.<br />
<br />
'''Expected Results:'''<br />
*To bring the functionality of programs like EasyTag or [http://musicbrainz.org/doc/PicardQt PicardQt] into Amarok.<br />
*A creative UI to accomplish the goal<br />
<br />
-----<br />
<br />
'''Project:''' Playlist and Playlist browser<br />
<br />
'''Brief explanation:'''<br />
Amarok 2 has a snazzy new playlist, though its code could use some refactoring to take advantage of Qt 4.4 features. Also it is missing features from 1.4.<br />
<br />
'''Expected Results:'''<br />
*Mass inline tag-editing in the playlist (like in Amarok 1.4)<br />
*Allow users to pick which fields are shown<br />
*Dynamic playlist and smart playlist support<br />
*Improve memory management for large playlists<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential and knowledge of Qt is nice, experience with Model/Views in Qt is a bonus<br />
<br />
'''Mentor:'''<br />
Ian Monroe and other Amarok developers. <br />
<br />
----- <br />
'''Project:''' Media Devices as Collection Provider<br />
<br />
'''Brief explanation:'''<br />
Media device support is very important in a modern media player due to their widespread popularity. Media devices haven't found much love in Amarok 2 development. Amarok 2 has a flexible collection system, that was designed in part with media devices in mind. Whereas in Amarok 1.4 the collection was solely local files so the Collection Browser could only show local files. In Amarok 2 collections have been abstracted, allowing sources from the Internet and ''with this project'' media devices as well.<br />
<br />
'''Expected Results:'''<br />
*Integrate the media device framework into Amarok 2.<br />
*Support at least one kind of media device, while having the framework available for others.<br />
<br />
'''Material Requirements:'''<br />
A media device to test with.<br />
<br />
'''Knowledge Prerequisite:'''<br />
C++, Qt, KDE.<br />
-----<br />
<br />
'''Project:''' Mp3tunes.com service synchronization<br />
<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an mp3tunes locker. This will allow us to use Amarok 2 for managing the mp3tunes locker as well as provide a framework for backing up all local content.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an mp3tunes locker as well as downloading content from the lock er to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the basic mp3tunes service . He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Ampache service synchronization<br />
<br />
'''Brief explanation:'''<br />
Add support for uploading and downloading content from an Ampache server. This will allow us to use Amarok 2 for managing the collection on the Ampache server. This will be a cross project task as the Ampache API used by Amarok 2 does currently not support uploading of content. There is great communication between the 2 projects, and the original Ampache API was developed in collaboration with Amarok developers.<br />
<br />
'''Expected results:'''<br />
Being able to upload local content to an Ampache server as well as download content from the server to the local collection. Optional support for automatic synchronization.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and the Ampache service. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----- <br />
<br />
'''Project:''' Add new service<br />
<br />
'''Brief explanation:'''<br />
Add support for a new online service to the Amarok 2 service framework. This is a project that requires a student that already has a good idea or contacts with an interested service. Getting added to Amarok will mean that the service will have itself and its contents made available to a potentially huge new audience, and Amarok user will enjoy having access to even more great content. Ideas for services ( just to throw something out there ) could be the internet archives collection of live recordings, remixes from ccmixter.org, or something similar<br />
<br />
'''Expected results:'''<br />
Being able to play content from the service directly within Amarok. Depending on the type of service, downloads or purchasing of content might also be possible, as might other features unique to the service.<br />
<br />
'''Knowledge Prerequisite:''' C++ is essential, knowledge of Qt and KDE helpful. Experience with web services might also come in handy<br />
<br />
'''Mentor:''' Nikolaj Hald Nielsen (nhnFreespirit) wrote the service framework and many of the services. He can be contacted on #amarok at irc.freenode.net or (better) at nhnFreespirit AT gmail DOT com.<br />
<br />
----<br />
<br />
=== Digikam ===<br />
<br />
'' Project:'' Nepomuk integration<br />
<br />
''' Project Information:'''<br />
Integration between Digikam and Nepomuk could allow the user to better organize his/her pictures and access them easily from other apps, or even from other computers as Nepomuk is a networked system.<br />
<br />
'''Brief explanation:'''<br />
Nepomuk could allow the user to organize the pictures in a finer way : Nepomuk allows the user to define properties on his picture, extending the usecases of standard metadata (XML/IPTC/XMP...). The user can add any property under the form subject - predicate - object. Think of it as finer grained tags. You could for example define the predicate "is on the picture" to list all the people present on it (facebook does that). In a larger scope, the user can link picture to any resource known by Nepomuk (project, meetings...).<br />
<br />
The other advantage is that Nepomuk stores the information in a central index, which means that it can easily be accessed by other apps (I think of Akonadi). This allows tighter integration, as OS X does in its latest version with the iPhoto library.<br />
<br />
----<br />
<br />
=== Okular ===<br />
<br />
''Project:'' Okular backend<br />
<br />
'''Project Information:'''<br />
Okular has plug-in system that allow it read different documentation formats. It currently reads a range of formats, but there are several that might be able to be improved (e.g. XPS) or implemented.<br />
<br />
'''Brief explanation:'''<br />
The project would need to identify a format that requires improvement (or implementation). Candidates that have been requested in the past include the Microsoft Word (.doc) format and the .lit e-book format. Given a suitable library, potentially any format could be considered. Consider:<br />
* Microsoft Visio<br />
* Microsoft Access snapshot (would require implementing a .emf file renderer - not simple, but could be useful in many other places in KDE).<br />
<br />
Note that improving PDF requires changes to the poppler library, and you would need significant previous experience with PDF (and ideally with poppler) to make much progress.<br />
<br />
'''Expected results:'''<br />
A working backend, capable of rendering most documents to a readable level. <br />
<br />
'''Knowledge Prerequisite:''' C++ is pretty much essential, and at least passing knowledge of Qt. C programming experience may be useful for some libraries.<br />
<br />
'''Mentor:''' Potentially one of several. Contact the okular mailing list.<br />
<br />
=== K3b ===<br />
<br />
'''Project:''' Port K3b to libburnia libraries<br />
<br />
'''Project Information:''' K3b currently uses cdrtools/cdrkit. This project should rewrite k3b to take advantage of three libburnia libraries - libburn, libisofs, libisoburn.<br />
<br />
'''Expected results:''' Experimental K3b branch with dropped support for cdrtools/cdrkit, and k3b features provided on top of libburnia libs backends.<br />
<br />
'''Contact for more information:''' mario AT libburnia-project DOT org<br />
<br />
=== Other applications ===<br />
<br />
==== Application User Interface Test System ====<br />
<br />
There are a couple of tools available for Qt / KDE that allow testing of applications - squish and kdexecutor. Both are binary only, and are specific to the systems that they are built on. <br />
<br />
It would be useful to have an open source tool that allowed us to test applications in a scripted way. Similar open source tools include Dogtail and LDTP, which use the accessibility interfaces in Gnome. <br />
<br />
There are arguments for and against using accessibility - it might be a lot more useful to implement a separate system, using some of the Qt4 specific features including QMetaObject. Qt4 has a nice set of hooks, and QTestLib shows how they can be implemented. However instead of requiring specific code in the application (as done by QTestLib), it would be more flexible to use LD_PRELOAD and a small interface library. <br />
<br />
More discussion: Brad Hards <bradh@kde.org><br />
<br />
==== (Multiple) image printing application ====<br />
<br />
This idea comes from my father, who is missing this kind of feature he was using in Paint Shop Pro. He says that there it was possible to open many images and when you selected them for printing the application would present you with a paper page, onto which you could drag the images, which were presented on a panel on the left side of screen. You could then interactively position and resize images on the paper and so see how the page look like when printed. There were also special functions available which would automatically resize and position the images.<br />
<br />
This application could also have a feature added to make it easier to print one image onto multiple pages (think posters). Here you could select how many pages of what size there should be and how many space on each page would overlap so you could glue the pages together after printing.<br />
<br />
I think it would be nice to also find a way to integrate such an application with imageviewer like Gwenview and photo management app like DigiKam.<br />
<br />
=== Usability ===<br />
<br />
The KDE Usability Project is willing to offer support mentoring to one or two projects (more if additional design mentors are available) which involve heavy UI development or UI redesign activities.<br />
<br />
=== Infrastructure ===<br />
<br />
KDE infrastructure tools, like Bugzilla, the Review Board, etc.<br />
<br />
=== KDE dependencies and non-KDE projects ===<br />
<br />
Depending on the relevance of the proposal, the KDE Project will accept student proposals on projects that are not part of KDE, but which are either KDE dependencies or relevant to KDE or the Free Software Desktop.<br />
<br />
==== Qt Cryptographic Architecture ====<br />
<br />
The Qt Cryptographic Architecture (QCA) isn't strictly part of KDE, however it is used in a range of KDE applications (and other applications). <br />
A range of projects are possible, in terms of adding security features to applications (e.g. SASL, encrypted content, client side puzzles). <br />
<br />
A specific need is the provision of alternative backends, which are typically the interface between QCA and some underlying crypto library. We already have several, but only the OpenSSL one is fairly complete, and OpenSSL is pretty ugly. A new backend would require some previous crypto knowledge, and ability to program in C++ and C. No GUI experience required! We probably only need one good alternative on each platform.<br />
<br />
- '''Alternative backend - GNU crypto libraries''': We have a basic backend using libgcrypt, which is mostly working. However a lot of the more interesting capabilities are present in gsasl and GNUtls. <br />
Mentor: Brad Hards <br />
<br />
- '''Alternative backend - Mozilla Network Security Services''': The Mozilla project has a library that is separately packaged on most Linux systems. It offers a fairly complete alternative to OpenSSL. We have a basic skeleton for NSS, but it only offers a couple of basic crypto primitives.<br />
Mentor: Brad Hards<br />
<br />
==== Strigi ====<br />
<br />
Strigi [1] and Pinot [2] are desktop search tools for the Linux and<br />
free Unix desktop. While targeted at different desktop environments,<br />
they have a history of collaboration, for instance on parsers for the<br />
Xesam query languages [3].<br />
<br />
Their features list overlap significantly as both projects offer most<br />
of the functionality users expect of desktop search systems.<br />
<br />
Both projects are written in C++ and feature an abstraction layer that<br />
makes them backend independent, though both only have one fully<br />
functional backend. Strigi's backend of choice is based on CLucene [4]<br />
while Pinot's is based on Xapian [5].<br />
<br />
This proposal is to bring this collaboration one step further by<br />
allowing them to use each other's indexing and search backends.<br />
<br />
Benefits include :<br />
* better abstraction layer for each project<br />
* wider testing of the respective back-ends<br />
* more choice to these projects' users<br />
* ease of evaluating and comparing CLucene and Xapian strengths and weaknesses<br />
<br />
The goal of project is to let Strigi use Pinot as a backend and vice<br />
versa so that both can query each others interfaces using<br />
the Xesam query language, and whatever query language is native<br />
to the backend.<br />
<br />
The emphasis is on completeness of querying. Performance optimizations<br />
and support for writing are secondary.<br />
<br />
[1] http://strigi.sf.net/<br />
[2] http://pinot.berlios.de/<br />
[3] http://www.xesam.org/<br />
[4] http://clucene.sourceforge.net/<br />
[5] http://www.xapian.org/<br />
<br />
==== Soprano & Nepomuk ====<br />
<br />
'''Project: Full Featured Query API'''<br />
<br />
'''Description''':<br />
For powerful semantic queries on the desktop we need a powerful query API. At the moment we are restricted to SPARQL queries which are then parsed by the Soprano backend. It would be much more efficient and easy to use if we had a query API that allowed to represent queries (independent of any query language) using a class structure. Queries could then easily be created, manipulated, and translated. Application developers would not have to learn a specific query language but would create a query object and have Nepomuk/Soprano evaluate that.<br />
<br />
This query API would become part of the official Soprano API and replace the simple Soprano::Model::executeQuery interface we have now.<br />
<br />
'''References:'''<br />
* Implementation of something similar in Java: http://sparql.sourceforge.net/<br />
<br />
'''Mentor:''' [mailto:trueg@kde.org Sebastian Trueg]<br />
<br />
==== D-Bus ====<br />
<br />
* a named pipe or shared memory transport implementation for win32<br />
<br />
* can QLocalSocket and QSharedMemory (in 4.4) be used?<br />
<br />
==== APOC ====<br />
<br />
'''Project: KDE (KConfig) integration with APOC'''<br />
<br />
'''Project Information''':<br />
<br />
APOC (http://apoc.freedesktop.org) is a framework for centralized (e.g. in LDAP) storage and management of application and desktop configuration. It has integrations with the GNOME configuration system (gconf) and various desktop-independent applications (OpenOffice.org, firefox, Java). <br />
<br />
This project is to integrate APOC with KConfig so that KDE application preferences can be managed as well.<br />
<br />
APOC is planning to propose another, different GSOC project with [http://live.gnome.org/SummerOfCode2007/Ideas GNOME as mentoring organisation].<br />
<br />
'''Knowledge Prerequisites''': <br />
* C++ coding <br />
* XML knowledge <br />
* KDE coding and configuration experience helpful<br />
<br />
'''Expected Result:'''<br />
* A documented mapping of KConfig preference structure onto the APOC file format.<br />
* A working KConfig backend that reads data from APOC<br />
<br />
'''Contact''': <br />
<br />
APOC is discussed on the [http://lists.freedesktop.org/mailman/listinfo/apoc apoc mailing list] (apoc@lists.freedesktop.org) and on the #apoc channel at irc.freenode.net.<br />
<br />
'''Mentor''': <br />
[mailto:joerg.barfurth@sun.com J&ouml;rg Barfurth]<br />
<br />
==== Other Freedesktop.org initiatives ====<br />
<br />
Both KDE and Gnome have previously acted as mentor organisations for projects that are under the Freedesktop.org umbrella. If you want to do a cross-desktop project, you can consider submitting it to one (or more) organisations. This is one case where you almost certainly want to have a mentor identified before you submit.<br />
<br />
If you submit to more than one organisation, please note which organisations you have submitted it to (since KDE has to coordinate with the other mentoring organisations).</div>Zwabel