[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: slim kdevelop
From:       Roberto Raggi <roberto () kdevelop ! org>
Date:       2004-10-08 8:58:31
Message-ID: 200410081058.31711.roberto () kdevelop ! org
[Download RAW message or body]

Hey Ian,

On Thursday 07 October 2004 19:03, Ian Reinhart Geiser wrote:
> Greetings,
> In the hopes of helping make the Quanta integration easier I would like to
> know how hard it would be to bind the Build and Debug menu items to
> projects.  This way if the project doesn't support building or debugging
> it can be removed from the UI.
just wait a little bit.. The Build and the Debug menu will disappear very soon 
(maybe monday :).. I've almost finished the KDevProjectRunner interface, that 
will replace the hardcoded `run' and `debug' stuff. I have some new stuff for 
the KDevProjectEditor and for the Automake/QMakeProjectEditor. 

>
> Also Is it also possible to remove the Diff plugin, and the application
> information console?  Then bind these to projects.
Well the diff plugin is pretty useful.. and actually we have (more or less) 
references to it in the KDevelop SDK, take a look at the interface 
KDevDiffFrontend. Anyway, I think we can remove it, but that means we have to 
check for all the plugins that uses KDevDiffFrontend (i.e. all the plugins in 
kdevelop/vcs). 

>
> Next we need to add a filter for the new project wizard.  This filter will
> keep C++ projects from polluting HTML projects, and HTML projects from
> cluttering C++ projects.
I think we can merge kdevabbrev, kdevfilecreate, kdevsnippet, and 
kdevappwizard in one part, or we can provide a library with the shared code. 
These plugins solves exactly the same problem in 4 different ways :) They 
just creates files/buffers from a sort of `specification'. I propose to write 
a new small part(i.e. KDevTemplate). The interface of the KDevTemplate can be 
something like

struct KDevTemplateInterface 
{
	/* returns all the categories */
	virtual QStringList categories() const = 0;

	/* returns all the templates for the given category */
	virtual QStringList templates(const QString &category) = 0;

	/* expand is just a wrapper around KMacroExpander, it customize
	   the contents of `templ' with the properties `properties' */
	virtual QString expand(const QString &templ, 
		const QMap<QString, QVariant> &properties) = 0;

//
// edit stuff
//
	// add/removeCategory(...)
	// add/removeTemplate(...)
};

now if we want to provide the `file create' feature, all we have to do is

/*slot */ void KDevTemplate::createFile()
{
	if (KDevProject *p = project()) {
		QString templ;

		if (KDevSelectTemplate::chooseTemplate(mainWindow()->widget(), &templ)) {
			QString contents = expand(templ, defaultProperties);

			// default properties contains things like <AUTHOR, "Roberto Raggi">,
			// <EMAIL, "roberto@kdevelop.org">, ...

			QString fileName = saveToFile(contents);
			p->addFile(fileName);
		}
	}
}

we can use exactly the same code for KDevAbbrev. The only difference is we 
don't have to create the file, but we have to add the `expanded code' at the 
current `editor position'.

KDevTemplate can provide easly the same features of KDevAppWizard. For 
instance a possible implementation in `pseudo code' could be:

/*slot*/ void KDevTemplate::createProject()
{
	if (KDevProject *p = project()) 
		closeProject(p);

	// category contains the `category' for the selected project 
	// for instance `qmake simple/app'
	QString category = getProjectCategory();

	// templ contains the `file template' for the selected project manager
	// for instance a .kdevelop file for the qmake project manager
	QString templ = getProjectFileTemplate(category);
	QString projectContents = expand(templ, defaultProperties);
	
	if (KDevProject *p = openProject(saveToFile(projectContents))) {
		foreach (QString fileTemplate, templatesOf(category)) {
			QString contents = expand(fileTemplate, defaultProperties);
			QString fileName = saveToFile(contents);
			p->addFile(fileName);			
		}
	}	
}

>
> Lastly I am wondering how hard it would be to replace the splash screen
> and the about data for KDevelop, so we can make it say other things.
it's not that hard ;) we have some stuff in KDevPlugin for the aboutData, but 
it is just unused. I propose to import the AboutDialog from kontact, it looks 
nice and it provides exactly what we need for showing the about info for 
plugins.

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdepim/kontact/src/aboutdialog.h
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdepim/kontact/src/aboutdialog.cpp

ciao robe

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]