A small guide how to extend Gideon via plugins:

1.) For a plugin foo, create a file foo.desktop which contains
    KDevelop/Part in its list of ServiceTypes. See
    parts/doctreeview/kdevdoctreeview.desktop for an example.
    If you install this file into $(kde_servicesdir), your
    plugin will automatically be loaded.

    You can change the default loading by changing some settings in your foo.desktop file:
	#set it to "Global" or "Project", this property is _not_ optional
	X-KDevelop-Scope=
	#you can add a list of programming language which are supported by your plugin
	#if your plugin works with all languages leave the field empty (optional)
	X-KDevelop-ProgrammingLanguages=
	#you can add a list of keywords, the plugin will be only loaded if all keywords match with the 
	#keywords in the projectfile (optional)
	Keywords=

	an example from the Java Debugger Plugin:
	#######################
	X-KDevelop-Scope=Project
	X-KDevelop-ProgrammingLanguages=Java
	Keywords=
	##########################
    

2.) Create a factory class FooFactory which inherits KDevFactory. Put a
    section
    
        extern "C" {
            void *init_libfoo()
            {
                return new FooFactory;
            }
        }

     into the source file, so that the factory can be accessed by
     KDE's library loader. Keep in mind that the name of the method
     init_libfoo() is required for a library with the name libfoo.so.
     This may be simplified by the use of the K_EXPORT_COMPONENT_FACTORY 
     macro which is defined in klibloader.h:
       K_EXPORT_COMPONENT_FACTORY( libfoo, FooFactory );

     Your factory must reimplement the createPartObject() method
     of KDevFactory and produce the part there.
     See parts/doctreeview/doctreeviewfactory.cpp for an example.



3.) Implement your part. It must be derived from  KDevPlugin.
    KDevPlugin takes two arguments: 1.) A parent argument. This also
    comes from createPartObject(). 2.) A name, which in turn
    is given to the QObject constructor.


A part can access other components of the IDE via some accessors
of KDevPlugin: The application core via core(), the project management
via project(), the programming language specific stuff via
languageSupport(), the make frontend via makeFrontend(), the
part which displays appication output via appFrontend(), and
finally the symbol database via classStore(). In order to see 
what these components provide, see lib/interfaces/kdev*.h

Parts can also store user preferences on a per-project basis. To this
end, they can access a QDomDocument representing the project file
(which is stored as xml) via document(). For your convenience, you
don't have to use the quite complex DOM API. Strings can very easily 
be read from and written to this document using the DomUtil class.
Here, entries are identified by a 'path' in the document. You can
think of the DOM document as representing a file system rooted in
the dom document node. For example, the autoproject part uses the statement

  QString cflags = DomUtil::readEntry(*part->document(), "/kdevautoproject/cflags");

to read the CFLAGS variable set by the user, and uses the statement similar to

  DomUtil::writeEntry(*part->document(), "kdevautoproject/cflags", "--no-exceptions");

to write it back. In order to avoid conflicts between different plugins, you
should use your part name as top-level 'directory' in the configuration tree.
