A final word (was:Re: What's up and what's hot)

[Sandy Meier]

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

Hi!

First: Very interesting discussion yesterday, unfortunately I was offline 
(the work on Wednesday was too much. :-))

> I consider myself a "big picture guy" :-), anyway, design decisions are
> made early in the development of a program, they can seldomly be
> reversed and even if, only with massive effort. Here is where the
> problem lies, there are many design decisions that have been made on a
> "first come first serve" basis. Examples:
Yes, discussing design descision were never our strong point in the last 3 
years. Many people don't like to discuss and discuss in the sparetime, they 
just want to code. And if someone has a nice idea he implement it. That's 
all. 
I agree that you get a better design (maybe) if you discuss it before, but it 
is not always much fun.

> - plugin architecture, everything is a plugin, is that really
> necessary? While it obviously structures the code nicely, does it
> really make sense that there is almost no core funtionality that
> plugins can rely on? Is it efficient? Are there other possible
> solutions? How about documentation of the whole thing, its technology
> that is not in widespread use outside of KDE after all.
> - the "splitter" classtree view that is so hard to understand and so
> quirky to handle, can we get rid of that?
If you have a nice idea, you can implement it. I agree the current 
implementation is not easy to use, but I have no better idea :-(. I discuss 
about it with Bernd (who wrote it) on Linuxtag and I think it will be a 
little bit more intuitive in the future.
Abstraction of a Makefile is not a easy task. Maybe we can join the to view, 
to one treeview?

> - abstract editor interface, yeah it lets me use NEdit, so what, I can
> go to tools and start NEdit on the file, that's all the benefit I can
> see from this as of know. 
No, if you click in the classview NEdit jumps to the correct position. I 
think editor plugins are a interesting technical challenge and in my opinion 
it works very well. (Thanks to Matthias, really got job!)

>Would the time have been better spent on much
> necessary improvements of kate? Are we that serious about KDE if we
> cant even improve the core texteditor?
Improving kate is not easy and if you want all features that emacs already 
had you will spend years on the implementation. Nevertheless we already 
extended kwrite/kate with some code hint functions (argHint,Code completion 
box). I hope we will merge it with the official version in some months.

> - project management entirely based on automake/autoconf. Who decided
> that, what about projects that are not automake based? Not qmake based
> either, can I still use HEAD for these, will I be able to in the
> future?
projectmanagment is not only based on automake/autoconf .It is a plugin. 
There exist plugins for tmake and script languages too.

Ciao!
Sandy
- -- 
The question is not, can they reason? nor,can they talk? 
but, can they suffer? (Jeremy Bentham)
- --
for verifying my signature or send encryted emails:
ftp://fara.cs.uni-potsdam.de/stud/smeier/public_key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7c6tzNX6yrHxt6UARAv+YAJ9QbAWS5IQjthwsmj41wwzPG7b0ywCfUXMr
tzUm8HvSBua6WCtH/yf0TXU=
=8W0G
-----END PGP SIGNATURE-----

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