Difference between revisions of "Projects/PIM/KMail Junior Jobs"

< Projects‎ | PIM
Jump to: navigation, search
(Bug 178402: Font settings for message list have no effect: Another one done.)
(Add JJ about using UI files)
Line 65: Line 65:
  
 
'''Description:''' KMail does many manual calls to readEntry() and writeEntry() for reading and saving configuration. These are error-prone and should be ported to the 'new' KConfigXT system, that is already used in some places (you'll notice the ''GlobalSettings'' class being used a lot).
 
'''Description:''' KMail does many manual calls to readEntry() and writeEntry() for reading and saving configuration. These are error-prone and should be ported to the 'new' KConfigXT system, that is already used in some places (you'll notice the ''GlobalSettings'' class being used a lot).
 +
 +
=== Convert more dialogs and layouts to [[Development/Tutorials/Using_Qt_Designer|UI files]] ===
 +
 +
''' Starting point:''' UI files in the ui/ subdirectory and the files where those UI files are used
 +
 +
'''Difficulty:''' Easy (but possibly boring)
 +
 +
'''Description:''' In many places in KMail, the layout is hardcoded in the application. That code usually involves setting up layout, creating widgets, setting labels and so on. A typical example can be found in the constructor ''MailingListFolderPropertiesDialog::MailingListFolderPropertiesDialog()'' in the file ''kdepim/kmail/mailinglistpropertiesdialog.cpp''.
 +
 +
[[Development/Tutorials/Using_Qt_Designer|Using UI files]] for this boring code has several advantages, for example it is much easier to change the layout later, even for non-programmers, and the code is less cluttered, as the UI parts are now separate from it.
 +
 +
Your task would be to pick some hardcoded layout in KMail and convert that to a UI file.
 +
 +
As some widgets are going to be removed or replaced during the Akonadi port of KMail, please ask on IRC or by mail first if separating the layout of the particular widget you have chosen makes sense, or if it will replaced by something else soon, in which case the work wouldn't make much sense.

Revision as of 22:45, 14 August 2009

Contents

KMail Junior Jobs

On this page, you'll find small coding jobs for a beginner to work on. All these problems are relatively easy, some of them might even be one-liners. Of course, it is always a good idea to find your own thing to fix, the best motivation is scratching your own itch.

These tasks are intended for beginners with little or no experience programming with KDE. For those beginners, the biggest challenges are not actually the coding problems, but setting the development environment up, finding the correct place of code where the bug happens (in the jungle of all those source files) and interacting with the community, with the final step being sending the patch.

The knowledge prerequisite for those jobs are not that big. You should be familiar in C++, and knowing Qt a bit would help. Knowing kdelibs or KMail internals is not required, that can usually be picked up during coding.

For more general information, visit the following places:

  • KDE Techbase: Contains a lot of information about developing KDE, in particular a section on how to build KDE from source
  • KMail's HACKING file: Some KMail specific information.

The steps for your first coding contribution are roughly like this:

  1. Build KDE trunk from sources, including KDEPIM
  2. Set up your development environment, i.e. your editor or IDE
  3. Pick something to work on, like some of the things suggested below
  4. Start coding and fix the problem!
  5. Send in a patch (We prefer reviewboard)

Should you need help, feel free to ask us in the #kontact IRC channel, or mail either Thomas McGuire (the KMail maintainer) or the kde-pim mailing list.

If you find some information missing, feel free to add it to this page after you learn it.

Below follows a list of junior jobs. It always includes a rough location where in the KMail sources to start.

The default column sizes of the message structure viewer are too small

Starting point: kmmimeparttree.cpp

Difficulty: Easy

Description: When starting KMail for the first time (i.e. empty kmailrc configuration file), the column sizes for the message structure viewer are not good. The name column is too small, although it should be the largest. KMail should provide good default column sizes for the default window size.



Better handling of empty column titles in the message list

Starting point: messagelistview/core/themeeditor.cpp, messagelistview/core/view.cpp

Difficulty: Medium

Description: When using the classic theme, you can select additional columns by right-clicking the header. There are many icon-only columns here, like Action Item or Signature. For those icon columns, the column header text doesn't fit into the width, and this looks bad. Your job would be to add an option to the theme editor like Don't display column header text. This would simply show nothing as the column header, but still show the column names in the context menu. Also, the default themes should be adjusted to use this.


Bug 156653: Changing the font size has no effect on the separate reader window

Starting point: kmreaderwin.cpp, kmreadermainwin.cpp

Difficulty: Medium

Description: The font setting has no effect when using a fixed font, and when using the separate reader window. Your job is to fix the situation.


Bug 89446: Convert more settings to KConfigXT

Starting point: kmail.kcfg

Difficulty: Easy (but possibly boring)

Description: KMail does many manual calls to readEntry() and writeEntry() for reading and saving configuration. These are error-prone and should be ported to the 'new' KConfigXT system, that is already used in some places (you'll notice the GlobalSettings class being used a lot).

Convert more dialogs and layouts to UI files

Starting point: UI files in the ui/ subdirectory and the files where those UI files are used

Difficulty: Easy (but possibly boring)

Description: In many places in KMail, the layout is hardcoded in the application. That code usually involves setting up layout, creating widgets, setting labels and so on. A typical example can be found in the constructor MailingListFolderPropertiesDialog::MailingListFolderPropertiesDialog() in the file kdepim/kmail/mailinglistpropertiesdialog.cpp.

Using UI files for this boring code has several advantages, for example it is much easier to change the layout later, even for non-programmers, and the code is less cluttered, as the UI parts are now separate from it.

Your task would be to pick some hardcoded layout in KMail and convert that to a UI file.

As some widgets are going to be removed or replaced during the Akonadi port of KMail, please ask on IRC or by mail first if separating the layout of the particular widget you have chosen makes sense, or if it will replaced by something else soon, in which case the work wouldn't make much sense.


KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal