BerndPol &tdevelop; is a very powerful and flexible IDE which offers many ways to tailor it to your needs. To start configuration select SettingsConfigure &tdevelop;.... This will cause the configuration dialog to pop up consisting of a selection window to the left and the configuration dialog on the right hand side whose contents will vary upon the configuration item you did select. Select a configuration item Select a configuration item We will discuss these configurations in a different order, split up into the main topics of General Configuration, Configuring the Documentation, and Advanced Configuration which makes for a more intuitive reading. If you want directly look up a certain configuration item use one of the following links. General User Interface File Templates Editor Abbreviations Scripting Tools Menu External Tools Documentation Code Snippets File List File Selector C++ Class generator Formatting C++ Parsing General configuration concerns the more common tasks of tailoring &tdevelop; as there are: General Setup Selecting the User Interface Selecting an Editor Selecting a Source Format Style Setting Up the Code Snippets Tool Configuring the File Selector The General configuration dialog allows you to define some basic &tdevelop; behaviour which seldom will change in everyday work. This concerns: General project options such as defining a default parent directory &tdevelop; shall use for new projects. deciding whether you want &tdevelop; to automatically load the project you last worked on. Selecting a font for the most commonly used output view windows, namely: the Messages Output View &tdevelop; uses to communicate ⪚ compilation progresses, and the Application Output View which will show error and state information concerning a running application. Some common behaviour concerning the displayed lines in the Messages Output View window, namely: whether long lines will wrap around, and if directory entry and exit messages issued by make will be shown. The level of detail of messages concerning the compilation process shown in the Messages Output View window. The general configuration dialog Load last project on startup Mark this checkbox if you want to continue to work with the last project you worked on. This will cause &tdevelop; to automatically load this project on start-up. It will usually be shown in the state you left work so you can readily proceed. Default projects directory: By default, &tdevelop; uses a common parent directory for all new projects. Enter the absolute path of this common directory in the box or select it from your directory structure. &tdevelop; will place the any new project here as a subdirectory. You may of course change the directory path of a new project at the time you set it up in the &appwizard;. Window font: The Application Output View window is used to display error and state information from applications which are run from inside &tdevelop;. These are informations the applications usually sends to the console when run stand-alone. So you do not need to leave the IDE when testing the application you currently work on. To select a font suitable for the Messages Output View window click the Window Font button showing the currently selected font (it says Luxi Sans in the above illustration). The &kde; standard Select Font dialog will pop up from which you may select the font to be used. On first start-up, &tdevelop; initializes this font setting to the standard font for which your &kde; user has been configured. This setting is fixed, so if you alter PreferencesAppearances & ThemesFonts in the Control Center, this will not effect this &tdevelop; font selection. You will have to explicitely reselect the Messages Output View window font. Compiler Output &tdevelop; preprocesses the messages the Messages Output View window receives during the build processes in order to filter superfluous information. You can control the level of detail &tdevelop; will display using the dropdown box in this field. Very Short Displays only warnings, errors, and the filenames which are compiled. Short Suppresses all compiler flags and formats the output to be more readable. Full Displays all output messages unmodified. There is an alternative way to switch the compiler output detail. Just right click in the Messages Output View window and select the according detail level from the popup menu. Line wrapping By default, &tdevelop; will wrap long lines around in the Messages Output View window so that valuable information will not be easily overlooked. In some cases this will clutter long message lists. Remove the checkbox mark if you do not want the lines wrap around. There is an alternative way to switch the line wrapping. Just &RMB; click in the Messages Output View window and mark/unmark the Line Wrapping entry in the menu which will pop up. Directory navigation messages The make tool usually will display messages like Entering directory, or Leaving directory when it switches the directories it currently works in. As this clutters the messages list in the Messages Output View window, &tdevelop; suppresses those messages by default. Mark the checkbox if you want to protocol which directories make worked in. Changes in this setting effect the processing of new messages only. Old directory navigation messages will be kept visible when you switch this feature off. UI Designer Integration This let you choose the way you want .ui files to be displayed in &tdevelop;. &tdevelop; comes with its own UI designer called KDeveDesigner that can either be embedded or be run as a separate program. Qt Designer can also be used to edit .ui files. Use &tdevelop;'s embedded designer This uses &tdevelop; own designer embedded within &tdevelop; Run &tdevelop;'s designer as a separate application The KDevDesigner application will be run separately in its own window. KDevDesigner in its own window Run Qt Designer Qt Designer from your Qt installation will be started externally whenever you click on a .ui file in &tdevelop;. Terminal Emulation You choose here which terminal you want to be integrated within KDevelop. Use &kde; setting This uses &kde; setting as set in &kcontrol; in &kde; component Component Chooser tab which sets the default terminal emulator used by all &kde; applications that need a terminal. Other Choose some other terminal different from the default one. user interface switch modes switch UI modes As already said in the Available User Interface Modes chapter there are five different ways the &tdevelop; work area may be set up, namely: Simplified IDEAl window mode This is a simplified version of the IDEA user interface. It is designed to be simple and clean. It also does not uses docked toolviews. IDEAl window mode This is a clone of the IDEA user interface, similar to the Tabbed pages mode and is default. Childframe window mode All tool views are initially docked to the mainframe. Editor and browser views will live like toplevel windows within a view area of the mainframe. A typical example of this user interface mode is MS Visual Studio 6.0. Tabbed pages mode All tool views are initially docked to the mainframe. Editor and browser views will be stacked in a tab window. A typical example of this user interface mode is KDEStudio, our friend C++-IDE in the world of KDE. Toplevel window mode All editor, browser and tool views will be toplevel windows (directly on desktop). The main widget contains the menu, toolbars and statusbar only. A typical example of this user interface mode is Borland Delphi 6.0. To switch the user interface mode select Settings Configure &tdevelop;... from the menus. The Customize KDevelop dialog will pop up, where you have to select User Interface in the left hand tree. This will display the following settings dialog to the right. Select a user interface mode Select a user interface mode Select the radio button of the user interface mode you want to switch to, then click OK. Do not forget to restart &tdevelop; in order to let any of these selections take effect. When you selected either the Simplified IDEAl window mode or the IDEAl window mode or the Tabbed pages mode two more configuration sections will become available: Use Tabs and Use Close On Hover. These allow to configure under which circumstances tabs will be shown on top of the document windows and whether you may close the document by a click on the tab icon. In Simplified IDEAl window mode and in IDEAl window mode only yet another configuration section will be available, Toolview Tab Layout which effectively allows to select between different sizes of the toolview tabs which surround the main working area in this mode. Configuring the Documents Tab Bar Display In the IDEAl and tabbed pages modes there will be named tabs on top of the document windows by default, so you can easily select different documents with a &LMB; click. If you prefer to provide more space for the document windows in the &tdevelop; main work area, you may change to another behaviour in the Use Tabs configuration section. Always This is the default — show a tab comprising an icon and the document name on top of any document window in the &tdevelop; main area display. When more than one Do not show a tab when only one document is displayed. If there is more than one document, however, &tdevelop; will display an according tab bar as in the Always selection above. You may want to select this mode if you work on a single document most of the time as this provides more vertical space. Never Never show any document selection tab. You may prefer this mode if you seldom use the mouse to switch between documents. It provides more vertical space for all document windows. To select another the document window or to close any, use the &tdevelop; Window menu. Setting Up to Close a Document by a Click On Its Tab When you configured &tdevelop; to display the documents tab bar, either always or when more than one document is displayed in the main work area, you may add more functionality to the tabs beyond their document selection capability. Use the Use Close On Hover coniguration section for this. No This is standard behaviour. No extra functionality is added to the tabs. They may be used only to select document windows on &LMB; clicks. Yes When you selected this radio button, &tdevelop; will allow to close a document window by a &LMB; click. Use the mouse to point at the small icon on the on the left tab border. It will change to a close symbol. Now click with the &LMB; on this changed symbol and &tdevelop; will close the according document window. Yes, Delayed After selecting this radio button, &tdevelop; will allow to close a document window as shown in the Yes case above. The icon will not change instantly, however, but there will be a short delay before the close icon shows up. Configuring the Toolview Tab Layout The Toolview Tab Layout configuration section will be available in IDEAl mode only. Use these radio buttons to set up the look of the toolview tabs which surround the main working area in this mode. Icons Each tab will show an icon only. If the associated toolview is displayed, the tab will open and a descriptive text for this toolview be shown. You may want to use this mode if you work on a monitor with limited resolution. The icons are not very descriptive, however. If you want to find out which toolview is assigned to a given tab, point at it with the mouse and wait a second. A short tooltip will then pop up with the toolview name. Text This is the default toolview tab display mode. Each tab displays the name of its associated toolwiew. Text and Icons If the standard text toolview display looks too flat to you and you are working on a high-resolution monitor you may want to select this radio button. It will cause the name of the associated toolview be displayed on each tab plus an icon to the left of it, making the tabs easier to distinguish. See the Folded Toolview Tabs illustration below for an example. Folded Toolview Tabs If you selected the IDEAl mode toolview tabs to display texts (with or without accompanying icons) you need not worry about them being hidden behind some toolview window. If one of the bottom toolview windows occupies more space than is available to display all (vertical) tabs, they will fold around as this illustration shows: Toolview tabs fold to not be hidden behind another view window Toolview tabs fold to not be hidden behind another view window The active toolview window must be shown fixed (non-overlap mode), sharing the work area with the other windows, to force such tab folding. Press the small square in the window border to accomplish this as shown in the example. Configure File Templates Configure File Templates &tdevelop; allows you to select your favorite text editor tool. Mark the Editor entry in the left hand side selections tree of the Configure KDevelop window. The following dialog will be displayed to the right. Select an editor Select an editor To select a new editor, click on the arrow on the drop down list field. Depending on the editor parts interfaces your &kde; version has compiled in you will be provided with a list of editors you may select from (see the Important note below for this). Click on the editor of your liking and click OK. Currently there are two possibilities: Embedded Advanced Text Editor This is the &kde; standard Kate editor part. Qt Designer Based Text Editor This is the editor &Qt; provides in its Designer component. These editor interfaces are fully integrated in the &tdevelop; IDE concept. Particularly the possibility to jump to the offending source code line by just clicking on an error message in the Messages Output View window has been provided. Changing the editor will not effect already open files. There are two possibilities to proceed. Either close all open text windows and reopen them one by one. Or simply close the whole project and reopen it again. The windows will then automatically open under the new text editor interface. KDevelop lets you use editor interfaces which have registered with &kde; and that provide a KatePart interface. If you miss one one of the selections shown above check your &kde; installation if the corresponding KPart was correctly installed. What to do if the file has been changed externally: Do nothing The file will be marked as externally changed and the user will be asked to verify any attempt to overwrite it. Alert the user A dialog will alert the user that a file has changed and offer the user to reload the file. Automatically reload the file if safe, alert the user if not Any files that are not modified in memory are reloaded and an alert is shown for any conflicts. (... to be written ...) (... to be written ...) (... to be written ...) (... to be written ...) (... to be written ...) (... to be written ...) (... to be written ...) &tdevelop; automatically formats a source text in a predefined style. This style is highly configurable. The reformat source feature is currently available for C, C++, and &Java; only. Especially you cannot use it for scripting languages like ⪚ PHP. This is because &tdevelop; uses the astyle application to implement this feature. To set up a specific format style, select Settings Configure &tdevelop;.. from the menubar. The Customize KDevelop dialog will pop up, where you have to select Source Formatter in the left hand tree. This will display a series of three settings dialog tabs to the right, namely a General Formatting Setup, a Indentation Style Setup, and a Other Formatting Setup. Any style changes apply to newly entered text only. If you want to change the formatting style of an already existing source text you will have to explicitely use the EditReformat Source command. The exact outcome of these style formatting definitions depends on the editor you use. Currently, most settings are tailored to the Kate editor part (the Embedded Advanced Text Editor). Some other editors (⪚ the Qt editor) may rely on their own configuration settings. You will have to experiment in this case to find out the exact effects of the style settings provided here. There may be incompatibilities between the configuration style settings provided here and the editor you use up to the extent that in extreme cases it even might destroy your files. Make sure you have a backup of your source files before you try out these settings with an none KDE standard editor. The General tab of the Source Formatter dialog allows you to select one out of five predefined source format styles. Source format style general setup Source format style general setup A formatted source example will be displayed in the field to the right. If none of the predefined styles is to your liking, you may click the top User defined radio button and define your own source formatting style preferences on the other two tabs which will become available then. Currently only the predefined source formatting styles will be demonstrated by an example text. If you decide to define your own style, no example display will be available. You have to experiment on an actual source text to tailor the settings to your liking. Proper indentation is the main means to enhance readability of a source text. I you selected the Indentation tab of the Source Formatter dialog you will be presented with a series of indentation formatting choices grouped into three boxes as following. Source format indentation style setup Source format indentation style setup Default Settings The preset format choices will cause the source text to resemble the ANSI formatting style: namespace foospace { int Foo() { if (isBar) { bar(); return 1; } else return 0; } } Defining Indentation Width and Characters The radio buttons grouped in the Filling group define how indents in the source text will be drawn. Use tabs This will cause the editor to insert a tab character for each indentation level. The tab width is predefined in the editor settings (8 or 4 character columns usually). Use SettingsConfigure Editor... to redefine it. The actual tab width definition procedure depends on the editor you selected in the Selecting an Editor configuration step. You will have to look up the corresponding editor help to find out. Use spaces If you select this radio button, the editor will enter a number of spaces for each indentation level. Change the number from the default 2 to the indentation width you prefer. Indented Entities This defines which of the (C/C++) entities will be formatted with an extra indent beyond the current indentation level. By default only namespaces and labels will be extra indented. You may want to experiment with various settings to tailor those extra indents to your liking. Continuation The settings grouped here apply to those cases where the source formatter automatically wraps around long source lines. It takes two special cases in account, namely that in deeply nested indents there should remain enough room for the source and that conditionals should get extra indent levels on continuation to make them stand out properly. This applies to static word wrap cases only where a fixed maximum line width is used in the source text. If you set up your editor to dynamically wrap around long lines in display only (which is possible in the &kate; editor part) the effects of these settings usually will not show. Maximum in statement This setting limits the maximum possible indentation for the continuation lines so that enough space will remain to keep the text readable. No continuation line will ever be indented beyond the number of columns you selected in this field. The default is set to 40 character columns (half a standard 80 column page). You may want to increase this value to account for wider paper (e.g if you use landscape printing for your sources). Or decrease the value accordingly to take larger margin settings of your printouts into account. Minimum in conditional Conditionals or source following ⪚ an assignment operator should usually get an extra indent on continuation lines in order to keep the text readable. The amount of this extra indent is defined here. The default is set to Twice current which means that continued conditionals will get an extra indent level of the standard indentation size you selected in the Filling group. You may change this extra indent to another fixed width (including zero) using the arrows or by entering the value directly. Other source format style settings Other source format style settings Controlling the position of braces The radio buttons the (somewhat misnamed) Brackets group control the position of block delimiting braces in a (C/C++) source text. There are three possibilities from which you can select. Break This inserts a line break before each opening brace. Both delimiting braces of any block will be put at the same indentation level as the block head statement. namespace foospace { int Foo() { if (isBar) { bar(); return 1; } else return 0; } } Attach This will keep the opening brace of a block in line with the block head statement. Closing braces will be on the same indentation level as the block head statement. The else of an if statement will be kept in line with the closing brace of the preceding block. namespace foospace { int Foo() { if (isBar) { bar(); return 1; } else return 0; } } Linux Style This is a compromise of the above listed styles. Functional block delimiting braces will be put on extra lines. Braces opening a block in a conditional or loop statement will be kept in line. namespace foospace { int Foo() { if (isBar) { bar(); return 1; } else return 0; } } Controlling Extra Spaces By default &tdevelop; does minimize the use of spaces in source texts. if (isBar(fooArg)==barValue) You may enhance readability if you force the source formatter to insert extra spaces in special positions. Add spaces around parentheses In fact what is meant is to add spaces around the text put in parentheses. This enhances the readabilitiy of function arguments and conditionals. if ( isBar( fooArg )==barValue ) Add spaces around operators This will put spaces around assignment and comparison operators to enhance the readability. if (isBar(fooArg) == barValue) Controlling the formatting of one-line constructs There are a few cases where you don't want the source formatter to split a long line apart. For C/C++ code this can be controlled here. Keep one-line statements This keeps single line statements together in some situations even if they exceed a fixed maximum line length. Keep one-line blocks This keeps single line blocks together in some situations even if they exceed a fixed maximum line length. When editing in &tdevelop; you can store often used parts of code as Code Snippets. To configure the capabilities of the code snippets part select Settings Configure &tdevelop;.. from the menubar. The Customize KDevelop dialog will pop up, where you have to select Code Snippets in the left hand tree. This will show the following dialog in the right hand side. Configuring the code snippets tool Configuring the Code Snippets tool Activate Snippet Preview Mark the Show snippet's text in tooltip checkbox if you want to view the stored text in a tooltip window whenever you keep the mouse cursor over the title of that snippet. Working with Snippet Variables The Code Snippets tool allows for a variable text in predefined places any time you insert a snippet into a file. To accomplish this Code Snippets provides its own variables' mechanism. You can set up it's behaviour in the Variables group. Delimiter The Code Snippets tool distinguishes variables in the text by surrounding the variable name with special delimiter symbols. To use your own delimiter symbol, change the predefined $ character in the Delimiter field. Input method for variables Single dialog for each variable within a snippet – will in turn pop up a separate dialog for each variable which the tool finds when inserting the selected code snippet. One dialog for all variables within a snippet – will pop up a common dialog where the user has to fill in the values of all variables before the snippet will be inserted (... to be written ...) &tdevelop; provides a File Selector plugin which, when loaded at start-up, allows to navigate to any file or directory in the system. The file selector in IDEAl mode The file selector (IDEAl mode) The behaviour of the File Selector can be highly configured. Select Settings Configure &tdevelop;.. from the menubar. The Customize KDevelop dialog will pop up, where you have to select File Selector in the left hand tree. This will show the following dialog in the right hand side. Configuring the file selector Configuring the file selector Configuring the Toolbar There is a toolbar on top of the File Selector which can be configured as usual in the Toolbar group. Select an item in the right hand Selected actions list after which the new action should be inserted. Select the action to be inserted in the left hand Available actions list. Click the right (upper) arrow between both lists. The action will be removed from the Available actions list and inserted into the Selected actions list below the selected item. Select the item to be removed in the right hand Selected actions list. Click the left (lower) arrow between both lists. The selected item will be removed from the Selected actions list and put back into the Available actions list. Select the action to be moved in the right hand Selected actions list. Click the up or down arrow to the right of this list. The selected item will be moved up or down the Selected actions list. Defining When the Contents Should Change Updating the contents in the File Selector window takes time and resources, esp. when changing to another directory. Therefore File Selector is set up by default in such a way that its contents change only on demand, &ie; when you select another directory or when you explicitely want to refresh its contents. Click the Reload button in the toolbar to update the contents of the File Selector. This toolbar button is not available by default, however. You must insert it there first. You can configure the File Selector to immediately reflect certain changes in your work. The settings in the Auto Synchronization group of the configuration dialog are responsible for this. When a document becomes active If you select this checkbox, the contents in the File Selector window will be updated whenever you go to another already open document, ⪚ when you click on the tab of the according edit window in IDEAl mode. If necessary the File Selector will switch to the directory this file belongs to and update the display to show the actual contents in there. When a document is opened If you select this checkbox, the contents in the File Selector window will be updated whenever a document will be opened, ⪚ by the FileOpen menu. If necessary the File Selector will switch to the directory this file belongs to and update the display to show the actual contents in there. When the file selector becomes visible If you select this checkbox, the contents in the File Selector window will be updated whenever it gets visible again. If necessary it will switch to the directory the actual document belongs to and update the display to show the actual contents in there. You may freely combine these settings to tailor the actualization behaviour of the File Selector to your liking. Controlling the History in the Comboboxes There are two comboboxes on top and bottom of the File Selector contents window which control the directory to be displayed (top combobox) and the filters to be applied to the file display (bottom combobox). A history of the most recent settings is kept in the selection field of each combobox. You can configure the number of history entries as follows. Remember locations Enter here the maximum number of directory selections the upper combobox shall remember. Remember filters Enter here the maximum number of filter definitions the lower combobox shall remember. Controlling What Should be Remembered Between Sessions By default the File Selector is set up so that it shows the display of the most recent session again at the next &tdevelop; start-up. You may change this behaviour in the Session configuration group. If &tdevelop; was automatically restarted by the &kde; session manager the changes in these settings will have no effect. In this case location and filter settings of the most recent &kde; session will always be restored. Restore location Remove the checkbox mark here if you don't want the displayed location be remembered between sessions. If you selected one of the automatic update settings the displayed location might automatically change regardless what has been remembered from the recent session. Restore filters Remove the checkbox mark here if you don't want the filters applied to the display be remembered between sessions. (... to be written ...) (... to be written ...) (... to be written ...) &tdevelop; contains a very powerful documentation facility which provides access to several kinds of extensive documentation. In ⪚ IDEAl mode you find a Documentation tab at the right border of the work area. The &tdevelop; documentation window in IDEAl mode The &tdevelop; documentation window (IDEAl mode) &tdevelop; must have loaded the Documentation plugin in order to view the documentation tree. See the Plugin Tools section for more info. You may set up contents and behaviour of the various parts of this documentation window if you select Settings Configure &tdevelop;.. from the menubar. The Customize KDevelop dialog will pop up, where you have to select Documentation in the left hand window. The thus displayed configuration page shows three tabbed configuration dialog pages, namely: Documentation Collections Full Text Search Other The documentation configuration settings have been divided into a series of documentation collections, each providing access to documentation files of some unique format and content type. These setups control which documentation items will be listed on the Contents page of the &tdevelop; Documentation facility, and how the user may access documentation details by indexed and full text searches. The Documentation tab provides a series of configuration pages which are ordered vertically like a stack of index cards. One page at a time will open after a click on its index card title: &Qt; Documentation Collection CHM Documentation Collection Doxygen Documentation Collection &tdevelop; TOC Documentation Collection Devhelp Documentation Collection Custom Documentation Collection Setting up documentation collections Setting up documentation collections All configurations pages on the Documentation tab use a common layout. You will find the currently available documentation items of this type listed on the open page to the left and a set of buttons to the right. Buttons to Maintain Documentation List Contents There are three buttons available to maintain the contents of the documentation setup pages: Add Opens a Documentation Catalog Properties dialog as shown below where you can select the source location of the documentation item to be added and name it. Edit Opens a Documentation Catalog Properties dialog as shown below where you can change the source location of the documentation item previously selected in the list and rename it. Remove Removes the selected documentation entry from the list. The entry will be removed from the list only. Actual documentation sources remain untouched. You will have to remove them explicitely by other means. Add or change a documentation item The button to the right of the Location field opens a directory dialog whose entries usually will be filtered according to the file type of the selected configuration page. The Title field may not be accessible, depending on the documentation type to be maintained. Documentation List Structure Every documentation setup page shows the listed documentation items in a table with four columns: TOC If this check box is marked, this documentation item will show up on the Contents page of the &tdevelop; Documentation facility. Unchecking the TOC check box will in turn disable the Index and Search check boxes (see below). Thus you cannot have documentation collection items indexed but not shown in the contents. Index If this check box is marked, an internal index will be built of this documentation item. This provides fast access to the documentation by the use of the Index and (optionally) Finder pages of the &tdevelop; Documentation facility. The internal index will be built the first time the user selects the Index page. This will delay the first access noticeably, because the index will be read from disk and then cached. All subsequent indexed searches will however use this chache and thus work significally faster. Search If this check box is marked, the contents of this documentation item will be included in the full text search path of the Search page of the &tdevelop; Documentation facility. &tdevelop; utilizes the htdig application collection to perform full text searches. This search is done over an internal index, the htdig machinery has to build before it can be used. Any change of the Search check box marks will thus effect the search runs only after you rebuilt the index on the Search page of the &tdevelop; Documentation facility. Title This is the name of the Documentation item as it will be shown on the Contents page of the &tdevelop; Documentation facility. Former &tdevelop; versions allowed to select the documentation items to be displayed on a per-project basis. This is not available any more. On this configuration page all &Qt; documentation is set up. Setting up the &Qt; documentation collection Setting up the &Qt; documentation collection Normally &tdevelop; will fill this in on its first start-up. It looks for standard *.xml, or *.dcf documentation files in the &Qt; installation directory. The table to the left lists the files &tdevelop; found by their standard titles. If you have a non-standard installation, either there will be no information listed at all or the entries will possibly refer to improper locations (⪚ to another &Qt; installation available in your system). You may adjust the entries using the buttons to the right of the list field. &tdevelop; will use the titles already provided by the installed &Qt; documentation. Hence the Title field in the Documentation Catalog Properties dialog is inaccessible. By default, not all &Qt; documentation will be shown on the Contents page of the &tdevelop; Documentation facility. Use the TOC check box in the setup table to select the documentation to be shown. If you want to have some specific &Qt; documentation included in the search indexes or full text search use the Index and Searchcheck boxes in the setup table. On this configuration page you may collect documentation according to the &Microsoft; CHM help file standard. Setting up &Microsoft; CHM standard documentation files Setting up &Microsoft; CHM standard documentation files By default, this configuration page will be empty (as shown above). You may add new entries using the buttons to the right of the list field. &tdevelop; will filter *.chm files in the directory dialog associated to the Add and Edit buttons. For more information on the format of &Microsoft; *.chm files see ⪚ PHP: Documentation - Extended CHM Format at http://de2.php.net/docs-echm.php. On this configuration page all &API; documentation generated by &doxygen; is set up. Setting up Doxygen generated &API; documentation Setting up Doxygen generated &API; documentation In short, such an &API; documents the interface to certain library functions. The &API; documentation on this page should be produced by the externally provided &doxygen; tool. &doxygen; generated &API; documentationconsists of a series of html files, starting with index.html. Additionally there may exist tag files which contain information to link to already existing &API; documentations. Thus &tdevelop; will look for index.html and *.tag files when seaching for &doxygen; generated &API; documentation. There are some structural constraints assumed when searching for &doxygen; generated &API; documentation. The directory in which the index.html file resides should contain subdirectories with separate documentation collections. Each of these subdirectories is assumed to contain a .tag file and a html/ subdirectory. You may have a look at $TDEDIR/share/doc/tde/HTML/en/tdelibs-apidocs for an example of such a &doxygen; &API; documentation layout. The older &kde; KDoc generated &API; format is not directly supported any more. If you still want to use such documentation, you may add it on the Custom Documentation Collection page. &tdevelop; will have filled in a link to the current &kde; Libraries &API;, provided it found one. There are several ways for &tdevelop; to find out: Either you provided the configure command with the --with-tdelibsdoxy-dir option when you compiled &tdevelop; (see the How to Obtain a &tdevelop; &API; Documentation chapter). Or the configure command did automatically find a &doxygen; generated &kde; Libraries &API; in one of several standard locations it knows of. Or as a last resort the $TDEDIR/share/doc/tde/HTML/en/tdelibs-apidocs/ was found at the first &tdevelop; startup. If &tdevelop; did not find a valid &doxygen; generated &kde; Libraries &API; at its first start-up the Doxygen Documentation Collection list will be empty. You may add your own &API; documentation entries (⪚ from your current projects) by using the buttons to the right. If you want to have them included in the indexed and/or full text search mark the Index or Search check boxes in the setup table. &tdevelop; uses the title information from the index.html. Hence the Title field in the Documentation Catalog Properties dialog is inaccessible. The &kde; system provides more &API; documentation than the &kde; Libraries &API; only. You will need additional interfaces information if you want to ⪚ include the &kate; part into you programs. For this &kate; part &API; for example you should compile and install the &kde; Base Libraries &API; from the sources (using the make apidox and make install commands on the tdebase sources) and then add an entry to the Doxygen Documentation Collection list like this: Adding a &kde; base &API; to the list Adding a &kde; Base &API; to the list (Of course you should replace the /home/dev/mykde-system/ directory in the Location field example with the path to your &kde; installation.) You must put the &API; of your current project into this Doxygen Documentation Collection as well. Former &tdevelop; versions did put it into the documentation tree on a per-project basis. This is not provided any more. The main bulk of the &tdevelop; documentation facility provides immediate access to structured documentation, local as well as remote ones. You can configure this on the KDevelopTOC Documentation Collection page. Providing KDevelopTOC structured documentation access &tdevelop; comes with a bunch of predefined KDevelopTOC files which are automatically entered in the table at installation time. To keep the display manageable only the most often used will initially be marked for display. If you want to see another documentation, mark the TOC check box in the setup table. KDevelopTOC files cannot be indexed to perform a full text search because they usually point to a remote location. On the other hand, such a .toc file can have an index manually defined, using the <index> tag. Thus the Index check box will be enabled ony when &tdevelop; finds an <index> tag in the .toc file. (For more detail see the description below in the &tdevelop; TOC Files section.) The Search check box in the setup table will alway be disabled. You may add new entries using the buttons to the right of the list field. &tdevelop; will filter *.toc files in the directory dialog associated to the Add and Edit buttons. Other than former &tdevelop; versions will the Remove button not change the *.toc files on disk, so the remove operation is safe now. There is a special feature associated with this. To illustrate, follow these steps: In the documentation tree find an entry shortly below the &Qt;/&kde; documentation (⪚ KDE2 Development Book (kde.org)). Click on the plus sign next to it. A tree will open where you can quickly navigate to subsequent chapters nested several levels deep, all offline. But if you finally select one of the chapters, &tdevelop; will in many cases try to access a remote documentation file. The rationale behind this is not only to locally navigate remote documentation without wasting net access ressources, but to provide the developer with easy, structured access to the documentation he/she needs. Using these tools one can access almost any local or remote documentation in a structured fashion even if the original is laid out flat or structured in another way. All that is needed is access to files and/or parts of files which are displayable by the Konqueror. Such structured access is made possible through the use of special table of content files, which are denoted by .toc filename extensions. Any such &tdevelop; TOC file contains an &XML; structured description of the document to be accessed. Standard Directory of &tdevelop; TOC Files When &tdevelop; was installed usually a series of predefined .toc files has been put into the $TDEDIR/share/apps/kdevdocumentation/tocs directory. These are fairly simple, structured text files. You may look at them using a text editor or other text display facility. header <!DOCTYPE tdeveloptoc> <tdeveloptoc> (title) (base address) (content structure) (index structure) </tdeveloptoc> This &XML; structure will be parsed by the &tdevelop; Documentation plugin to set up the documentation tree contents and to guide the user in navigating the documentation. It contains all information necessary to display titles and access the documentation file contents. title <title> (some title string) </title> This is the title &tdevelop; will display at the basic levels in the documentation tree. This displayed title cannot be changed by the user. If you want another text be displayed, you must manually change the <title> entry in the .toc file. base address <base href=" (base document &URL;) "/> This &URL; points to the location where all files of this documentation are located. It will be prepended before each section &URL; in the following content structure list. So, if you ⪚ downloaded a documentation from a remote server, all you need to display the files from this new location is to change its <base> &URL;. content structure <tocsect1 name=" (section title) " url=" (section &URL;) "> ... <tocsectn name=" (section title) " url=" (section &URL;) "/> ... </tocsect1> All remaining navigation and access information is stored in a series of nested <tocsecti> ... </tocsecti> pairs. Each i denotes a consecutive nesting level down to number n which will correspond to the finally displayed documentation section. Any <tocsecti> entry must have a name="xxx" attribute associated with it (the "xxx" denotes the actual title string). This name will be displayed as level title in the documentation tree. It should correspond to an actual documentation section. There may be an url="" attribute associated with any i nesting level. When the user clicks on a section title in the documentation tree &tdevelop; will try to access the file at the location pointed to by the combined base and section &URL;. The <tocsectn/> entry must have an url="" attribute whatsoever. This final nested <tocsectn/> does not come in pairs but will immediately be closed by a / before the > bracket. Any address combined of base and section &URL; must point to some displayable text file. Usually this will be an HTML-structured file. It is possible to link to anchor marks within such an HTML file using the standard # notation of the format: /base-url/section-url#anchor-mark. index structure <index> <entry name=" (index entry title) " url=" (index section &URL;) "/> </index> Index is a plain list of index entries - pairs of title and &URL;. Index is not mandatory. DevHelp documentation is another means of structured documentation access. It uses structured table of content files denoted by a .devhelp extension similar to &tdevelop; TOC files to access documentation for the GNOME 2 desktop. You can control which DevHelp files should be accessible on the DevHelp Documentation Collection configuration page. Providing DevHelp documentation DevHelp files originally were accessible on the LiDN website, but this seems to be not maintained for some time now. More recent DevHelp documentation is available at the DevHelp Books Download web page. When &tdevelop; is installed it will attempt to find all .devhelp files in some standard places in the system, ⪚ in the subdirectories of /opt/gnome/share/. Initially these files will not be marked for display. If you want to see another documentation, mark the TOC check box in the setup table. You may add new entries using the buttons to the right of the list field. &tdevelop; will filter *.toc files in the directory dialog associated to the Add and Edit buttons. This is for your own purpose. You may add almost any documentation files here, provided they can be displayed by the &konqueror; plugins. Providing custom documentation Usually this collection will be empty at first &tdevelop; startup. We have filled in a deliberate item to show the entry structure. Handling is straightforward here. Use the buttons to the right of the list field to add, edit or remove the document items. &tdevelop; will not filter anything in the directory dialog associated to the Add and Edit buttons. You will have to explicitely select the items for display in the &tdevelop; documentation facility. Mark the TOC check box of the entry in the setup table. Custom documention cannot be indexed or searched. Thus the Index and Search check boxes have no effect here as shown above. (... to be written ...) Setting up text search indexes (... to be written ...) (... to be written ...) (... to be written ...)