Integrating the Dialog

Das KDevelop-Programmierhandbuch: Leitfaden zur C++-Anwendungsentwicklung für das K Desktop Environment (KDE) mit Hilfe der KDevelop-IDE in der Version 1.2
Zurück | Kapitel 6. The Dialogeditor: Where your Dialogs are Build | Vor

# 6.7. Integrating the Dialog

Whenever you created a widget, you probably want to add it to the project to execute the action it is designed for. As a widget can be constructed for several purposes, we will watch for two cases: a `QWidget` inherited widget and a `QDialog` one.

## 6.7.1. `QWidget` inherited

Let's say you created a widget that will be part of the main view. If it fills the whole view area, you have to add an instance pointer to the header declaration of your `KTMainWindow` instance replacing the currently set view widget. Then change the code in the `initView` method to set this widget the main view. Additionally, you could remove the View class of the generated project, but mind that the document instance and the App instance depends on the view class. In this case, it is technically a much better way to create a mini-KDE application and construct your `KTMainWindow` instance yourself.

More often the widget is intended to be a part of the view area, which means it is combined with other widgets. This can be done by using one of the following classes that provide a divider to separate two widgets:

1. `QSplitter`

2. `KPanner`

3. `KNewPanner`

If the main view shall contain more than two widgets, you have to use another instance of the divider as one of the two managed widgets by the first one. Then add the according widgets to each panner and set the first panner the view area.

## 6.7.2. `QDialog` inherited

If your widget inherits `QDialog`, it is probably intended to change one or more values; often this is used to set the application preferences. To invoke the dialog, you have to add a slot to the `App` class by adding the method declaration and the implementation body. Then add the constructor call to the method as well as a call to `show()` or `exec()` the dialog. Finally, you should take care for processing the results of the dialog; this can either be done by the dialog who changes values of the parent widget itself or by retrieving the values from the dialog (which would make your dialog a lot more reusable in other projects). Mind that you should call `delete` if you called the dialog instance with `new` to avoid memory leaks.

Finally, you have to connect a menuentry (with according statusbar help) to the new slot invoking the dialog; optionally a keyboard accelerator and a toolbar icon. For this, add a resource ID to the file `resource.h` with a define. Then add an according menuentry to one of the popup menus already present in the menubar or create a new popup to add your menuentry. The menuentry consists of:

- an optional icon pixmap. Call this with the `Icon("iconname.xpm")` macro of `KApplication` to use the provided `KIconLoader` instance.

- the menuentry name. Add this with the `i18n("&&;entryname")` macro of `KApplication` to allow internationalization. The ampersand should be in front of the letter that will be displayed underlined to access the entry directly by keyboard acceleration.

- the member instance to call. Normally this would be the `this` pointer.

- the member slot to call. Use `SLOT(yourmethod()` to call the slot on the signal `activated()`.

- the accelerator key. This should be set to zero as this is done by an entry in `initKeyAccel()` where you have to introduce an accelerator key together with the slot to call. Then call `changeMenuAccel()` to change the menu item's accelerator. This will make it configurable by a key-chooser dialog later. For standard actions, use the enumerable values given by `KAccel`.

- the menu ID as set in `resource.h`

Zurück | Anfang | Vor
Setting Widget Properties | Hoch | Printing Support