KDevelop4 features (Was: change of maintainership in KDevelop)
ghost at cs.msu.su
Tue Apr 4 11:39:11 UTC 2006
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.
More information about the KDevelop-devel