Discussion:
objc
(too old to reply)
David Bishop
2003-06-25 21:35:48 UTC
Permalink
I searched the archives, but the last mention of objc on this list was back in
2000. Has anything changed since then? If not, how hard would it be to add
ObjC support to gideon? Any documentation on how to go about adding support
for a language?

Thanks.
--
"Sorry about the whole 'bomb' thing" - Bruce Rollins
D.A.Bishop
Raphael Langerhorst
2003-06-26 06:23:20 UTC
Permalink
Hello everyone!

joined the list yesterday. I have asked a question in the forum if C# (mono)
support is planned or something. It seems not many developers read the forum
- please do so. So, any plans? How much work would it be? docs?


greetings,
Raphael
Post by David Bishop
I searched the archives, but the last mention of objc on this list was back
in 2000. Has anything changed since then? If not, how hard would it be to
add ObjC support to gideon? Any documentation on how to go about adding
support for a language?
Thanks.
-
to unsubscribe from this list send an email to kdevelop-***@kdevelop.org with the following body:
unsubscribe »your-email-address«
Alexander Dymo
2003-06-26 10:48:27 UTC
Permalink
Any language support should be written as a kdevelop part and implement
KDevLanguageSupport interface (lib/interfaces).
Implementing methods:
virtual Features features();
virtual KMimeType::List mimeTypes();
should be enough for a language support to start working.

You could look at parts/rubysupport for a simple language support
implementation. For a compilable language support consult parts/adasupport
or parts/pascalsupport (they are not so complex as cppsupport).

Language support can offer additional features:
new class wizard:
virtual void addClass();
add method dialog:
virtual void addMethod(const QString &className);
add attribute dialog:
virtual void addAttribute(const QString &className);

If there is a Qt bindings for your language and there is a possibility
to use QtDesigner ui files (i think something available to c#)
you could implement ui subclassing feature:
virtual QStringList subclassWidget(const QString& formName);
virtual QStringList updateWidget(const QString& formName, const QString&
fileName);

If you write (or have) a language parser, your language support can have:
class store (a database containing the information about scopes, classes
and methods - their names, names of source files, location in source files,
etc.). Class store libraries can be found at lib/catalog and lib/sourceinfo.
KDevelop provides class browsers that extract information from a class store
and display it in a tree view and toolbar selectors of scopes, classes and
methods.

Catalog is the new persistant class store for KDevelop written by Roberto
Raggi and everybody is highly encouraged to use it. Take a look
at parts/cppsupport for an example of using catalog. parts/pascalsupport
will be based on a catalog (check it out within a two weeks). Catalog is
stored on disk in the database file (Berkeley db) If you use catalog, your
class browser will be parts/classbrowser.

Sourceinfo is the deprecated class store. Look at parts/adasupport
(especially interesting is ada.store.g grammar file) to find out how it is
filled by a parser with information. This class store can't be saved onto a
disk. The class browser for a sourceinfo based stores is parts/classview.

Class store enables you to write a code completion for the language.
At the moment, code completion is available only to cppsupport so
take a look at it for an example.

In general, class stores can be filled with information without specialized
and complex language parsers (take a look at parts/pythonsupport that have
a very simple python parser) but your language support will surely benefit
from having such. There is a hand-written c/c++ parser (lib/cppparser) in
KDevelop that might be used for a objective-c language. Other (not so complex
as c++) languages can be parsed by ANTLR based parsers (library is in
lib/antlr). Consult www.antlr.org for a ANTLR documentation and look at
parts/javasupport, parts/adasupport and parts/pascalsupport for an example of
using such parsers. AFAIK there is an ANTLR based c# parser at www.antlr.org.

If you have a language parser, you can implement "problem reporter"
functionality for your language. The problem reporter catches errors
reported by a parser and displays it in a problem reporter view.
parts/javasupport, parts/adasupport, parts/pascalsupport and
parts/cppsupport have problem reporters.



The language support is important, but it is unusable without a project
manager that can manage projects written on this language. KDevelop
currently provides several project managers. They are:
Automake manager parts/autoproject
QMake manager parts/trollproject
Custom project manager parts/customproject
(works with custom makefiles, also has ant support)
Script project manager parts/scriptproject
(the generic project manager for all scripting languages).
Also available parts/pascalproject and parts/adaproject (they are the
project managers for a compiled language with main source file concept).
Choose your project manager and if the existing project managers don't fit
in, you can modify parts/customproject to use a specific build tool or help us
to develop "generic project manager" suitable for every language and build
tool (there are some ideas which haven't been implemented yet).


Application wizard templates should be also written. Appwizard templates are
simple to create - consult parts/appwizard/README and look at
parts/appwizard/rubyhello, parts/appwizard/pascalhello or
parts/appwizard/adahello.


Another thing to do is to create filecreate templates. They are prototypes
for a source files of your language. These prototypes are placed in
parts/filecreate/file-templates dir and have names equal to the extensions
of language source files. The description of the prototypes is placed
in parts/filecreate/template-info.xml. Consult parts/filecreate/README
for further information.


KDevelop has a support for code abbrevations so you can add some predefined
abbrevations to your language support. Take parts/cppsupport/cpptemplates
as an example.


To edit source files KDevelop uses any editor that supports KTextEditor
interface. In case none from the editors support advanced editing of sources
written on your language (like code folding, syntax highlighting, line
indentation) you can improve QEditor included in KDevelop (parts/qeditor).
By creating QEditorIndenter and QSourceColorizer descendants you can
provide the support for an automatic indentation and syntax highlighting
that will be available for sure in KDevelop. c# colorizer is already available
(parts/qeditor/cs_colorizer.h/cpp).


To obtain source formatter functionality (that is already available to
c-based languages) you can improve astyle library (lib/astyle) that is used
by KDevelop to format sources.


The last thing to have a complete language support in KDevelop is to
write a debugger support. KDevelop already provides GDB support
(parts/debugger) and JDB (java debugger) support (parts/javadebugger).
Take a look at them to get inspiration;).


See also HACKING file for an information on how to create a generic KDevelop
plugin and how to manage project and global configuration information.
--
Alexander Dymo
Ukrainian State Maritime Technical University, IT Department


-
to unsubscribe from this list send an email to kdevelop-***@kdevelop.org with the following body:
unsubscribe »your-email-address«
Raphael Langerhorst
2003-06-26 12:47:16 UTC
Permalink
Thank you very much for this much of information. I will look it through (and
my time table) and then decide whether I can help with C# or not. But thanks
again for the info!


greetings,
Raphael
Post by Alexander Dymo
Any language support should be written as a kdevelop part and implement
KDevLanguageSupport interface (lib/interfaces).
virtual Features features();
virtual KMimeType::List mimeTypes();
should be enough for a language support to start working.
You could look at parts/rubysupport for a simple language support
implementation. For a compilable language support consult parts/adasupport
or parts/pascalsupport (they are not so complex as cppsupport).
virtual void addClass();
virtual void addMethod(const QString &className);
virtual void addAttribute(const QString &className);
If there is a Qt bindings for your language and there is a possibility
to use QtDesigner ui files (i think something available to c#)
virtual QStringList subclassWidget(const QString& formName);
virtual QStringList updateWidget(const QString& formName, const
QString& fileName);
class store (a database containing the information about scopes, classes
and methods - their names, names of source files, location in source files,
etc.). Class store libraries can be found at lib/catalog and
lib/sourceinfo. KDevelop provides class browsers that extract information
from a class store and display it in a tree view and toolbar selectors of
scopes, classes and methods.
Catalog is the new persistant class store for KDevelop written by Roberto
Raggi and everybody is highly encouraged to use it. Take a look
at parts/cppsupport for an example of using catalog. parts/pascalsupport
will be based on a catalog (check it out within a two weeks). Catalog is
stored on disk in the database file (Berkeley db) If you use catalog, your
class browser will be parts/classbrowser.
Sourceinfo is the deprecated class store. Look at parts/adasupport
(especially interesting is ada.store.g grammar file) to find out how it is
filled by a parser with information. This class store can't be saved onto a
disk. The class browser for a sourceinfo based stores is parts/classview.
Class store enables you to write a code completion for the language.
At the moment, code completion is available only to cppsupport so
take a look at it for an example.
In general, class stores can be filled with information without specialized
and complex language parsers (take a look at parts/pythonsupport that have
a very simple python parser) but your language support will surely benefit
from having such. There is a hand-written c/c++ parser (lib/cppparser) in
KDevelop that might be used for a objective-c language. Other (not so
complex as c++) languages can be parsed by ANTLR based parsers (library is
in lib/antlr). Consult www.antlr.org for a ANTLR documentation and look at
parts/javasupport, parts/adasupport and parts/pascalsupport for an example
of using such parsers. AFAIK there is an ANTLR based c# parser at
www.antlr.org.
If you have a language parser, you can implement "problem reporter"
functionality for your language. The problem reporter catches errors
reported by a parser and displays it in a problem reporter view.
parts/javasupport, parts/adasupport, parts/pascalsupport and
parts/cppsupport have problem reporters.
The language support is important, but it is unusable without a project
manager that can manage projects written on this language. KDevelop
Automake manager parts/autoproject
QMake manager parts/trollproject
Custom project manager parts/customproject
(works with custom makefiles, also has ant support)
Script project manager parts/scriptproject
(the generic project manager for all scripting languages).
Also available parts/pascalproject and parts/adaproject (they are the
project managers for a compiled language with main source file concept).
Choose your project manager and if the existing project managers don't fit
in, you can modify parts/customproject to use a specific build tool or help
us to develop "generic project manager" suitable for every language and
build tool (there are some ideas which haven't been implemented yet).
Application wizard templates should be also written. Appwizard templates
are simple to create - consult parts/appwizard/README and look at
parts/appwizard/rubyhello, parts/appwizard/pascalhello or
parts/appwizard/adahello.
Another thing to do is to create filecreate templates. They are prototypes
for a source files of your language. These prototypes are placed in
parts/filecreate/file-templates dir and have names equal to the extensions
of language source files. The description of the prototypes is placed
in parts/filecreate/template-info.xml. Consult parts/filecreate/README
for further information.
KDevelop has a support for code abbrevations so you can add some predefined
abbrevations to your language support. Take parts/cppsupport/cpptemplates
as an example.
To edit source files KDevelop uses any editor that supports KTextEditor
interface. In case none from the editors support advanced editing of
sources written on your language (like code folding, syntax highlighting,
line indentation) you can improve QEditor included in KDevelop
(parts/qeditor). By creating QEditorIndenter and QSourceColorizer
descendants you can provide the support for an automatic indentation and
syntax highlighting that will be available for sure in KDevelop. c#
colorizer is already available (parts/qeditor/cs_colorizer.h/cpp).
To obtain source formatter functionality (that is already available to
c-based languages) you can improve astyle library (lib/astyle) that is used
by KDevelop to format sources.
The last thing to have a complete language support in KDevelop is to
write a debugger support. KDevelop already provides GDB support
(parts/debugger) and JDB (java debugger) support (parts/javadebugger).
Take a look at them to get inspiration;).
See also HACKING file for an information on how to create a generic
KDevelop plugin and how to manage project and global configuration
information.
-
to unsubscribe from this list send an email to kdevelop-***@kdevelop.org with the following body:
unsubscribe »your-email-address«
Raphael Langerhorst
2003-06-27 07:57:56 UTC
Permalink
Hello again,

OK, I will work on that. Anyone else interested in adding support for C#?

Two things mentioned before: I'm no guru at C# yet - but I need to learn it
one day anyway. I am quite an expert at Java, so it shouldn't bee too hard to
learn. Also I know C++ very well.
Second: I also didn't program anything with KDE/QT before - but I want to
learn that as well anyway.
Despite all that, don't worry too much. I normally learn very fast and have
worked through a couple fo programming projects already.

I guess I should switch to the dev list with this, right?


My time plan for this is to have it (basically) done in September or October.
I hope I can stick to that.


greetings,
Raphael

PS: for those who ask what C# has to do with Linux, go to www.go-mono.org
Post by Raphael Langerhorst
Thank you very much for this much of information. I will look it through
(and my time table) and then decide whether I can help with C# or not. But
thanks again for the info!
greetings,
Raphael
-
to unsubscribe from this list send an email to kdevelop-***@kdevelop.org with the following body:
unsubscribe »your-email-address«
Daniel Engelschalt
2003-06-26 13:28:44 UTC
Permalink
alexander, this very good explanation should be put somewhere in the public.

bye,
daniel
Post by Alexander Dymo
Any language support should be written as a kdevelop part and implement
KDevLanguageSupport interface (lib/interfaces).
virtual Features features();
virtual KMimeType::List mimeTypes();
should be enough for a language support to start working.
You could look at parts/rubysupport for a simple language support
implementation. For a compilable language support consult parts/adasupport
or parts/pascalsupport (they are not so complex as cppsupport).
virtual void addClass();
virtual void addMethod(const QString &className);
virtual void addAttribute(const QString &className);
If there is a Qt bindings for your language and there is a possibility
to use QtDesigner ui files (i think something available to c#)
virtual QStringList subclassWidget(const QString& formName);
virtual QStringList updateWidget(const QString& formName, const QString&
fileName);
class store (a database containing the information about scopes, classes
and methods - their names, names of source files, location in source files,
etc.). Class store libraries can be found at lib/catalog and
lib/sourceinfo.
KDevelop provides class browsers that extract information from a class store
and display it in a tree view and toolbar selectors of scopes, classes and
methods.
Catalog is the new persistant class store for KDevelop written by Roberto
Raggi and everybody is highly encouraged to use it. Take a look
at parts/cppsupport for an example of using catalog. parts/pascalsupport
will be based on a catalog (check it out within a two weeks). Catalog is
stored on disk in the database file (Berkeley db) If you use catalog, your
class browser will be parts/classbrowser.
Sourceinfo is the deprecated class store. Look at parts/adasupport
(especially interesting is ada.store.g grammar file) to find out how it is
filled by a parser with information. This class store can't be saved onto a
disk. The class browser for a sourceinfo based stores is parts/classview.
Class store enables you to write a code completion for the language.
At the moment, code completion is available only to cppsupport so
take a look at it for an example.
In general, class stores can be filled with information without specialized
and complex language parsers (take a look at parts/pythonsupport that have
a very simple python parser) but your language support will surely benefit
Post by Alexander Dymo
from having such. There is a hand-written c/c++ parser (lib/cppparser) in
KDevelop that might be used for a objective-c language. Other (not so complex
as c++) languages can be parsed by ANTLR based parsers (library is in
lib/antlr). Consult www.antlr.org for a ANTLR documentation and look at
parts/javasupport, parts/adasupport and parts/pascalsupport for an example of
using such parsers. AFAIK there is an ANTLR based c# parser at
www.antlr.org.
If you have a language parser, you can implement "problem reporter"
functionality for your language. The problem reporter catches errors
reported by a parser and displays it in a problem reporter view.
parts/javasupport, parts/adasupport, parts/pascalsupport and
parts/cppsupport have problem reporters.
The language support is important, but it is unusable without a project
manager that can manage projects written on this language. KDevelop
Automake manager parts/autoproject
QMake manager parts/trollproject
Custom project manager parts/customproject
(works with custom makefiles, also has ant support)
Script project manager parts/scriptproject
(the generic project manager for all scripting languages).
Also available parts/pascalproject and parts/adaproject (they are the
project managers for a compiled language with main source file concept).
Choose your project manager and if the existing project managers don't fit
in, you can modify parts/customproject to use a specific build tool or help us
to develop "generic project manager" suitable for every language and build
tool (there are some ideas which haven't been implemented yet).
Application wizard templates should be also written. Appwizard templates are
simple to create - consult parts/appwizard/README and look at
parts/appwizard/rubyhello, parts/appwizard/pascalhello or
parts/appwizard/adahello.
Another thing to do is to create filecreate templates. They are prototypes
for a source files of your language. These prototypes are placed in
parts/filecreate/file-templates dir and have names equal to the extensions
of language source files. The description of the prototypes is placed
in parts/filecreate/template-info.xml. Consult parts/filecreate/README
for further information.
KDevelop has a support for code abbrevations so you can add some predefined
abbrevations to your language support. Take parts/cppsupport/cpptemplates
as an example.
To edit source files KDevelop uses any editor that supports KTextEditor
interface. In case none from the editors support advanced editing of sources
written on your language (like code folding, syntax highlighting, line
indentation) you can improve QEditor included in KDevelop (parts/qeditor).
By creating QEditorIndenter and QSourceColorizer descendants you can
provide the support for an automatic indentation and syntax highlighting
that will be available for sure in KDevelop. c# colorizer is already available
(parts/qeditor/cs_colorizer.h/cpp).
To obtain source formatter functionality (that is already available to
c-based languages) you can improve astyle library (lib/astyle) that is used
by KDevelop to format sources.
The last thing to have a complete language support in KDevelop is to
write a debugger support. KDevelop already provides GDB support
(parts/debugger) and JDB (java debugger) support (parts/javadebugger).
Take a look at them to get inspiration;).
See also HACKING file for an information on how to create a generic KDevelop
plugin and how to manage project and global configuration information.
--
Alexander Dymo
Ukrainian State Maritime Technical University, IT Department
-
to unsubscribe from this list send an email to
unsubscribe »your-email-address«
-
to unsubscribe from this list send an email to kdevelop-***@kdevelop.org with the following body:
unsubscribe »your-email-address«
David Bishop
2003-06-26 20:30:51 UTC
Permalink
Post by Daniel Engelschalt
alexander, this very good explanation should be put somewhere in the public.
bye,
daniel
I agree. I cleaned it up a bit and made it more generic. You'll find it
inline below (I tried to attach it, but my cvs KMail keeps crashing). I don't
know what an appropriate avenue would be for dissemination (i.e., make a
webpage or just rename it HACKING.newlanguage, and put it in
/usr/share/doc/kdevelop/), but it should be fairly easy to do whatever.


HOW TO ADD SUPPORT FOR A LANGUAGE IN KDEVELOP (GIDEON)

Before beginning: To add support for a language in KDevelop, you need
to be more than passingly familiar with C++, language parsing,
the language you are adding, and KDE/QT. This is not something that
an beginner developer should try to complete. However, you *can*
get minimal language support without too much trouble. That said, lets
move on...

List of things to have "complete" support of a given language in KDevelop:

o) Implement interface KDevlLanguageSupport
o) Language parser for class browser
o) UI subclassing (if the language has Qt bindings)
o) Problem reporter (parses source on the fly and reports syntax errors)
o) Syntax highlighter (add to QEditor if not available elsewhere)
o) Project manager (make/ant/etc)
o) Source file templates
o) Application wizard
o) Source code abbreviations (ife expands to an if else statement, etc)
o) Source formatter (prettyprint functionality)
o) Debugger (gdb/jdb/??? integration)

Explanations, hints, tips, and all around Good Things To Know, regarding
that list:

Any language support should be written as a kdevelop part and implement
KDevLanguageSupport interface (lib/interfaces/kdevlanguagesupport.h).
Implementing methods:
virtual Features features();
virtual KMimeType::List mimeTypes();
should be enough for a language support to start working. A KDevelop
part is available as a New Project type: C++->KDevelop->KDevelop Part.
FIXME: CAN YOU USE EITHER STANDALONE OR SOURCE TREE BUILD, OR DO YOU
NEED ONE IN PARTICULAR?

You should look at parts/rubysupport for a simple language support
implementation. For a compilable language support, consult parts/adasupport
or parts/pascalsupport (they are not so complex as cppsupport). Pascal
would be a good starting place, as it is the smaller of the two by far.

Language support can offer additional features:
new class wizard: (See cppsupport)
virtual void addClass();
add method dialog: (See adasupport or cppsupport)
virtual void addMethod(const QString &className);
add attribute dialog: (See cppsupport)
virtual void addAttribute(const QString &className);

If there is a Qt bindings for your language and there is a possibility
to use QtDesigner ui files, you could implement ui subclassing feature:
virtual QStringList subclassWidget(const QString& formName);
virtual QStringList updateWidget(const QString& formName, const QString&
fileName);
See cppsupport and javasupport for examples.

If you write (or have) a language parser, your language support can have
"class store" (a database containing the information about scopes, classes
and methods - their names, names of source files, location in source files,
etc.). Class store libraries can be found at lib/catalog and lib/sourceinfo.
KDevelop provides class browsers that extract information from a class store
and display it in a tree view and toolbar selectors of scopes, classes and
methods.

Catalog is the new persistant class store for KDevelop written by Roberto
Raggi and everybody is highly encouraged to use it. Take a look at
parts/cppsupport for an example of using catalog. parts/pascalsupport will be
based on a catalog (check it out within a two weeks (06/26/03). Catalog is
stored on disk in the database file (Berkeley db) If you use catalog, your
class browser will be parts/classbrowser.

Sourceinfo is the deprecated class store. Look at parts/adasupport (especially
interesting is ada.store.g grammar file) to find out how it is filled by a
parser with information. This class store can't be saved onto a disk. The
class browser for a sourceinfo based stores is parts/classview.

Class store enables you to write a code completion for the language. At the
moment (06/25/03), code completion is available only to cppsupport so take a
look at it for an example.

In general, class stores can be filled with information without specialized
and complex language parsers (take a look at parts/pythonsupport that have
a very simple python parser) but your language support will surely benefit
from having such. There is a hand-written c/c++ parser (lib/cppparser) in
KDevelop that might be used for ObjC or related C-based languages. Other
(not so complex as c++) languages can be parsed by ANTLR based parsers
(library is in lib/antlr). Consult www.antlr.org for a ANTLR documentation
and look at parts/javasupport, parts/adasupport and parts/pascalsupport for
an example of using such parsers. The latest version of ANTLR (2.7.2)
has support for Java, C, Pascal, Ada, C++, CIM, HTML, IDL, Verilog,
VRML, OCL, ASN.1, and SQL. You can write an ANTLR parser for your own
language, of course.

If you have a language parser, you can implement "problem reporter"
functionality for your language. The problem reporter catches errors
reported by a parser and displays it in a problem reporter view.
parts/javasupport, parts/adasupport, parts/pascalsupport and
parts/cppsupport have problem reporters.

The language support is important, but it is unusable without a project
manager that can manage projects written on this language. KDevelop
currently provides several project managers. They are:
Automake manager parts/autoproject
QMake manager parts/trollproject
Custom project manager parts/customproject
(works with custom makefiles, also has ant support)
Script project manager parts/scriptproject
(the generic project manager for all scripting languages).
Also available parts/pascalproject and parts/adaproject (they are the
project managers for a compiled language with main source file concept).
Choose your project manager and if the existing project managers don't fit
in, you can modify parts/customproject to use a specific build tool or help us
to develop "generic project manager" suitable for every language and build
tool (there are some ideas which haven't been implemented yet).

Application wizard templates should be also written. Appwizard templates are
simple to create - consult parts/appwizard/README and look at
parts/appwizard/rubyhello, parts/appwizard/pascalhello or
parts/appwizard/adahello.

Another thing to do is to create filecreate templates. They are prototypes
for a source files of your language. These prototypes are placed in
parts/filecreate/file-templates dir and have names equal to the extensions
of language source files. The description of the prototypes is placed
in parts/filecreate/template-info.xml. Consult parts/filecreate/README
for further information.

KDevelop has a support for code abbrevations so you can add some predefined
abbrevations to your language support. Take parts/cppsupport/cpptemplates
as an example.

To edit source files KDevelop uses any editor that supports KTextEditor
interface. In case none from the editors support advanced editing of sources
written on your language (like code folding, syntax highlighting, line
indentation) you can improve QEditor included in KDevelop (parts/qeditor).
By creating QEditorIndenter and QSourceColorizer descendants you can
provide the support for an automatic indentation and syntax highlighting
that will be available for sure in KDevelop.

To obtain source formatter functionality (that is already available to
c-based languages) you can improve astyle library (lib/astyle) that is used
by KDevelop to format sources.

The last thing to have a complete language support in KDevelop is to
write a debugger support. KDevelop already provides GDB support
(parts/debugger) and JDB (java debugger) support (parts/javadebugger).
Take a look at them to get inspiration.

See also HACKING file for an information on how to create a generic KDevelop
plugin and how to manage project and global configuration information.
--
"Sorry about the whole 'bomb' thing" - Bruce Rollins
D.A.Bishop
Alexander Dymo
2003-06-27 20:15:21 UTC
Permalink
Post by David Bishop
I agree. I cleaned it up a bit and made it more generic. You'll find it
inline below (I tried to attach it, but my cvs KMail keeps crashing). I
don't know what an appropriate avenue would be for dissemination (i.e.,
make a webpage or just rename it HACKING.newlanguage, and put it in
/usr/share/doc/kdevelop/), but it should be fairly easy to do whatever.
Ok, commited as HACKING.language to kdevelop source (without "Before
beginning:" paragraph - to not frighten newcommers;) ).
--
Alexander Dymo
Ukrainian State Maritime Technical University, IT Department


-
to unsubscribe from this list send an email to kdevelop-***@kdevelop.org with the following body:
unsubscribe »your-email-address«
Continue reading on narkive:
Loading...