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

List:       kdevelop
Subject:    Re: de-mythifing KDevelop and KOffice
From:       Pupeno <pupeno () pupeno ! com>
Date:       2004-04-22 2:13:45
Message-ID: 200404212313.48339.pupeno () pupeno ! com
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think this IS the spirit... if this was going to become a interview/dot 
story, instead of one big interview I'd make small interviews to people \
like  you showing that there are lots of people that put the hands on the \
code. Thanks.

On Wednesday 21 April 2004 15:02, Alexander Dymo wrote:
> As KDevelop developer I'd like to "de-mythify" it a little bit ;)
> 
> > I see that in various places KDevelop and KOffice are named as the two
> > biggest projects that achieved a lot by a very small team of \
> > developers, that also carries the request for help of other developers \
> > to make this aclaimed applications (or set of applications) better.
> > I consider myself a developer and to be honest I'd be afraid of putting
> > my hands in either KDevelop nor KOffice. Why ? Because from the outside
> > both seems to be extremely complex things, that can be broken easily.
> > KDevelop... a program for programmers... you need to make high quality
> > code, there are tons of plug ins (and that means a complex plug in
> > structure) and the complex and huge amount of templates.
> 
> Generally, to work on KDevelop you shouldn't be the expert in \
> programming. If you work with KDevelop (even if you have just started \
> with a tutorial) then KDevelop becames your tool which you can adjust to \
> your needs. So "a program for programmers" becames "a program for you". I \
> bet once you have learned KDevelop in a user level and started to work in \
> it, you see various things (not necessarily very complex) to improve.
> I mostly refer to myself here, but my way to KDevelop developer was \
> exactly as I described above. I wanted to have a good IDE where I can \
> write programs, I started with KDevelop and I started to fix little \
> things that annoyed me. For example, the first thing I done was the \
> little improvement in c++ new class wizard which allows specifying the \
> base class. So, I'm sure there are tons of little things that can be done \
> by a new programmer.
> 
> Now about complexity of KDevelop internals. The program has pretty good
> and easy plugin-based design. Everything in KDevelop is a plugin - a \
> class derived from KDevPlugin interface. Interfaces are well understood \
> and documented.
> You think that the fact we have tons of plugins denotes complexity and \
> you are wrong here! If we had a complex plugin structure (complex \
> interfaces) we wouldn't have so many plugins.
> The plugin structure does denote that KDevelop is easy to extend. Let my
> main argument here be a code itself. Just create "KDevelop Part" using
> KDevelop application wizard and you will get working plugin written using
> just several lines of code. That code will include a class derived from
> KDevPlugin which have only constructor and destructor and a class derived
> from QWidget to embed into KDevelop toolviews. Nothing that complex!
> 
> You say it's easy to break things. If you work on a new plugin or improve
> existing, you just can't break things. Plugins are independent, the fact
> that one particular plugin doesn't work correctly does not imply that
> others will break too (as long as your plugin doesn't crash, of course;) \
> ). That's one of the main points of pluggable architecture.
> I won't say there are no ways to break things. Plugins use core \
> interfaces to communicate to each other, and if you modify interfaces \
> there is always a risk of breaking something. But if you are a newbie, \
> you don't want to touch interfaces, do you? ;)
> 
> Of course, there are plugins that do complex tasks like language support
> parts or project managers. They are indeed complex but I want to say that
> there is always a possibility to make things in a simple way and KDevelop
> always allows to do so. Take a look, for example, at cpp support with \
> code completion, language parser and other glorious stuff and take a look \
> at ruby support that is so simple. Today I'm very curious why we don't \
> have c# support in KDevelop. One could wrote basic c# support
> in a single day (or even in a couple of hours using "KDevelop language
> support" application template).
> 
> Some of KDevelop plugins have even their own plugin structure that can
> simplify your task even more. For example, if you want to write compiler
> options dialog for your beloved compiler, you need to know only about
> KDevCompilerOptions interface and nothing more. I designed new
> documentation part in KDevelop in the same plugin-based way.
> 
> Ok, I'm not going to say that everything is that easy. Improving language
> parsing, code completion stuff or autotools requires more knoledge.
> But if you want to improve those, maybe it's time to take a good book
> and learn new interesting things;)
> 
> > Now, is all this complexity I'm mentioning true ? or there are parts of
> > KDevelop and KOffice that are simple and that a newbie developer could
> > help
> 
> Yes, there are simple parts (majority of KDevelop parts are not complex)
> and there also are simple tasks can be done in complex parts.
> 
> > Maybe some interviews could help.
> 
> Hmm, last time interview with KDevelop developers was held in 2002.
> It would be good to conduct it in 2004.

- -- 
Pupeno: pupeno@pupeno.com
http://www.pupeno.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAhypctCepaMf3unIRAvv6AJ4gR+J76MNKEYtTDDHkhs+1iZdTIQCfcfoU
WZRGVXmHvg3uplfFslyJia0=
=YknC
-----END PGP SIGNATURE-----

-
to unsubscribe from this list send an email to \
kdevelop-request@kdevelop.org with the following body: unsubscribe \
»your-email-address«


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