This section is a developer's guide explaining the peculiarities of dialog creation in &kappname;. A basic understanding of Qt GUI programming is assumed, as is a knowledge of &kappname; coding standards as laid out in the Project Handbook. The default language of &kappname; is American English, but don't let that put you off! All contributions will be welcome, and as long as you have a basic knowledge of the language, the members of the &kappname; developers list will be happy to help you polish it up. First step is to choose a meaningful name for your dialog (and preferably one that's not already in use! - see the kmymoney2/dialogs source directory). In accordance with &kappname; coding conventions, the name should consist of 2 or 3 (or more) 'words', strung together without spaces. To keep names to a manageable length, these 'words' may be abbreviated, e.g. 'sched' for 'schedule'. Each 'word' should be spelt with an initial upper-case letter. Also, the names of dialogs are always preceded by a letter 'K', thus e.g. KEditSchedTrans. This name will be indicated in the rest of this chapter by <KN>. There are nevertheless occasions where all lower case letters are appropriate, specifically source file names; this will be indicated as <kn>. The dialog screen should be built using Qt Designer. This section assumes that you are using version 3.x of Qt. Version 4 is, at present, an unknown quantity. Open Designer without specifying a project, and select Dialog from the New File/Project tab. Start by changing the form name; this should be set to '<KN>DlgDecl'. Now add your widgets to the form, not forgetting to include a Help button. Remember that users will have many different hardware and screen combinations, and will need to be able to resize windows, so make full use of the various layout and spacer options of Designer. A lot of tutorials can be found on the web to help guide you on this; try your favourite search engine. Fixed widgets, e.g. text labels, can often use the default names assigned by Designer. Other widgets on your form should be given names which are meaningful in an application context. This is particularly important for those widgets which are to be referenced in code. As per the application programming standards, these names should be prefixed with 'm_' to indicate them as member variables of the dialog. Designer contains an option to generate shortcut (accelerator) keys for various widgets (buttons, menu items) by including an ampersand ('&') before the shortcut letter. This should be used for the more common items, since many users prefer to use keyboard input rather than using the mouse. However, this does have the unfortunate side effect of automatically generating an 'accel' property for the widget, referencing a letter which may not be appropriate when the caption is translated to another language. Use the properties menu, therefore, to remove this value, or see below. Fixed text fields and labels in the form do not require any special consideration. Qt Designer and the project's build environment will take care of wrapping the strings into an i18n construct for presentation to translators. When complete, save the form using the Designer default name (<kn>dlgdecl.ui) in the dialogs source code folder (kmymoney2/dialogs). Your code to process form actions should be included in source files named <kn>dlg.h/.cpp, in the same folder as the .ui file. You can view these for many examples of how to code. Some requirements are: This should start with definitions similar to the following #ifndef <KN>DLG_H #define <KN>DLG_H #include "../dialogs/<kn>dlgdecl.h" class <KN>Dlg : public <KN>DlgDecl { TQ_OBJECT public: <KN>Dlg(TQWidget *parent = 0, const char *name = 0); ~<KN>Dlg(); The first two lines are the standard include stoppers, to avoid multiple inclusion of the class data. The include file will have been generated by the Qt UIC (User Interface Compiler) from the .ui file for the dialog, under control of the make process. The TQ_OBJECT macro (written without any punctuation) will cause the Qt MOC (Meta Object Compiler) to generate additional object code and files which are necessary to support the signal/slot functionality (among other things). The class declaration must also include a public slots: and signals: sections if you plan to use the signal/slot mechanism. See the Qt documentation about signals and slots. An example would be slotHelp() which will be connected to the clicked() signal of the help button of your dialog in the constructor of your dialog. Terminate the file with #endif to close off the include stoppers. First, don't forget to have #include directives for Qt headers for any widgets you are going to reference. In the constructor function, connect all signals to their appropriate slots using the Qt connect() call. Then the easy bit; write your code. Finally, terminate the source file with the following #include "<KN>dlg.moc" This is one of the files generated by the Qt MOC (Meta Object Compiler) during the make process; if you finish up with 'vtable' errors, it's probably because you forgot to include this. You will need to edit file Makefile.am in the dialogs source folder before building &kappname;. Note that due to the abstruse rules of make, the lists of files should consist of a single logical line, so be careful regarding any editor options which may cause automatic insertion of line breaks. You can however use a continuation character of backslash to spread the list over multiple physical lines. There must be no character following the continuation character, not even a blank. - Add <kn>dlgdecl.ui and <kn>dlg.cpp to the libdialogs_a_SOURCES line - Add <kn>dlgdecl.ui to EXTRA_DIST - Add <kn>dlgdecl.cpp and <kn>dlgdecl.h to DISTCLEANFILES - Add <kn>dlg.h to NOINST_HEADERS Save the file, and you are ready to build &kappname;. For the first build after updating Makefile.am you should re-run 'make -f Makefile.dist', reconfigure and make. Otherwise, some make rules might not be present and compiling fails. That's all, simple wasn't it.