Extending
This chapter describes how to customize to your particular needs and how you can help become better.

Creating Your Own Docs for
Probably the most notable additions to for the general user will be the addition of documentation for the markup or scripting language that you like best. To that end, this chapter will explain how I create the php documentation tree for my personal use.
Before starting on creating your own documentation, you may wish to check out the repository to see if someone else has already done this set.
There are two parts to this process. First, you must obtain the existing documentation for the markup/scripting/etc language that you're after. Second, you have to create the docrc file. The first is up to you, the second is what we'll cover here.
The general form of the docrc file is as follows:

#KDE Config File
[Tree]
Doc dir=<path, relative to this file, of the documentation html files> e.g. php42/
#top level elements
Top Element=<Your description for these docs> e.g. PHP 4.2 documentation

Section 1=Section1.html
Section 2=#Sec2.1,#Sec2.2,#Sec2.3
Sec2.1=Sec2.1.html
Sec2.2=Sec2.2.html
Sec2.3=Sec2.3.html
...

[Context]
ContextList=func1,func2,tag1,tag2,tag3
func1=func1.html
func2=func2.html
tag1=tag1.html
tag2=tag2.html
tag3=tag3.html

The docrc is broken down into two sections: Tree and Context.
The Tree section defines the presentation aspect of the documentation in the documentation tab. For example, you'll see that in the php docs you have something akin to this:
Relating this to the above, my php docrc looks like this:

#KDE Config File

[Tree]

Doc dir=php42/

#top level elements
Top Element=PHP 4.2 documentation

PHP 4.2 documentation=Table of Contents,#Getting Started,#Language Reference

Table of Contents=index.html

Getting Started=Introduction, ...
Introduction=introduction.html
...

Language Reference=Basic syntax, ...
Basic syntax=language.basic-syntax.html
...

Notice the # in front of Getting Started and Language Reference. This indicates that these are sub containers in the tree and have content of their own. I don't believe that there is a set limit to the depth here (other than that driven by sanity) - use your judgement.
For the Table of Contents, you'll notice that it is referenced directly to a file (and consequently shows up at the bottom of the tree view - directories first!).
Spaces don't adversely affect anything, but watch out for & and < characters. These should likely be replaced by &amp; and &lt; respectively in all of the xml based resource files.
The Context section is the section of the docrc file that is used to facilitate context sensitive help. For example, you're writing a PHP script and you'd like to see the docs for the mysql_fetch_array function. You simply highlight the function and then press H for context help. Woosh! You're viewing the docs on mysql_fetch_array. There are only two entry types here: the ContextList and the file association lines.
ContextList 	 Really simple, this is just a comma separated list of the context items you wish to have available (for PHP, these are the functions for PHP).
File association lines 	These are of the form context item=html doc page. e.g. acos=function.acos.html
A pared down version of my docrc Context section is as follows:

#Keywords for context help
[Context]
ContextList=abs,acos,acosh,addcslashes,addslashes,...

abs=function.abs.html
acos=function.acos.html
acosh=function.acosh.html
addcslashes=function.addcslashes.html
addslashes=function.addslashes.html
...

Now you can just save your docrc file, save it in $HOME/.kde/share/apps/quanta/doc or $KDEDIR/share/apps/quatna/doc for local or global use respectively. Then create a directory (the one specified in your docrc file) in the same directory as your docrc file and copy your html doc pages in there.
You'll need to restart and then you'll see your docs.
Once you're sure that they're good and worth sharing, send the docrc file along with a description of any pertinent information on what docs you used to the repository for use by the community. You won't get rich, but you'll feel great knowing that you contributed to the best web development platform around.

Creating Actions in
Actions in are the basis for nearly all the extensions that has and will acquire in the future. The same mechanism that defines an action in enables autocompletion and tag dialogs. With actions, the limit of what you can do is virtually limitless. For means of an example, we will use html tidy on our web pages.
Let's get started: Settings Configure Actions
Once you start the actions dialog you'll see this window. To the left is the list of currently known actions. You can select one of those and perform the same actions for an existing action that we're going to do with our html tidy action.
We're going to make a new action, so let's click on the new button (lower left) and begin.
Now you're presented with a blank set of options to fill in:
Text 	This is the name of the action
Tool tip 	Not sure where this get's displayed. It's optional!
Status text 	Don't know what this is for or where it's used. It's optional!
Place this action onto (checkbox) 	This enables the drop down box for selection of a toolbar to place this action onto. If you don't choose now, you can always add them later from Settings Configure Toolbars.
After filling in these basics, you can select an icon for the action by clicking on the icon button to the left of the 'Text' input box.
Now to the meat of the matter. The actions definition.
If we were defining a markup tag, we could use the tag tab here to input the tags parameters.
To whit:
<tag> 	This is where you enter the tag name as it will appear in your document. e.g. <div align=center>
</tag> 	This is where you enter the closing tag, if any, or uncheck the box if none. e.g. </div>
Run Edit Tag dialog if available 	This runs the dialog editor if there is a tag file defined for this item. Check out the tag files section for more information on tag files.
And now... Back to our regularly scheduled program. Continuing on the html tidy action creation.
Click on the Script tab to reveal the following:
Input box at top 	This is where you place the executable that you're after. In our case, it would be /usr/local/bin/tidy because that's where I keep tidy.
Now on to the Input/Output/Error tabs.
Input Tab
None (radio button) 	Don't take any input for this script. This could be useful if you were calling a Tcl/Tk script that popped up a window for interaction with the user and then returned its results. We'll be choosing something else for tidy.
Selected text (radio button) 	Just what it says. It pushes a copy of the currently selected text out to the standard in of the script in the input box above. We could use this for tidy, but it's no fun to select everything in a large document.
Current document (radio button) 	Pipes the contents of the editor version of the file through to the standard in of the script in the input box above. This is what we'll use for tidy.
Now click on the Output tab. This is where we decide on our redirection for your scripts output.
None 	Duh. This would be fine if you're launching an external application that only takes input but doesn't output anything. This is no real use for us with tidy.
Insert in cursor position 	Just what it says. Be certain you're where you want the text inserted. No good for tidy.
Replace current document 	Total file replacement here. It won't overwrite the file on disk, but it will blast your current edit session. Use with caution. We won't use this for tidy.
Create new document 	Output to a new document in the edit window. This is the best choice for tidy.
Message window 	Output to the message window M . This is useful for debugging and the Error tab, but not much else for Output. Not for tidy.
For the Edit tab, the options are the same as the Output tab. Usually, you'll use the message window, to help in debugging, or none option.