KDevelop4 features (Was: change of maintainership in KDevelop)

[Vladimir Prus]

On Tuesday 04 April 2006 13:22, Daniel Franke wrote:

> also I'm not a developer, I'm lurking on this list and following the way of
> kdevelop for a couple of years now. I'm just a former kdevelop user who
> resorted to kate/vi and hand crafted Makefiles about a year ago.
>
> I alread spoke up on this once: before carried away to much on all the
> possible and shiny features for kdevelop version X, please, please someone
> should fix the bugs so many people complain about. Instead of "come on,
> let's add more features", kdevelop development could focus on "come on,
> let's get rid of those three editors, four ui modes and whatnot and
> implement a stable and configurable base where we can go on from, one
> feature at a time" ?!

I guess I've used the term "cool feature" incorrectly.

Here's what I really mean. There's quite a lot of features in the code. 
However, they are not quite as smooth as necessary. Fixing bugs is important,
but can't solve all problems. It's needed to think about some specific use 
cases, and figure out how those use cases can be made as smooth as possible.

Making them smooth will require some rearrangement of UI, some bugfixing, 
maybe some visual tricks, and overall this will be more rewarding that just 
bugfixings, and more good for the users.

Let me continue with examples. There are four ways to select a file in 
KDevelop (not counting the tabs above editor). It's confusing on its own, and 
no local bugfixing can help. It would be great if somebody comes out, design 
the better way to select files and implement. If that person is asked to fix 
bugs in existing suboptimal UI, he'll walk away.

So, I think it's necessary to put as many use cases and current global issue 
to Wiki and then hope at least one item will attract somebody.

- Volodya