KDevelop: General direction and UI - don't worry

[Robert Knight]

> Popup menu in Eclipse barely fits my screen.
> So what? Who cares? 90% of people just use Eclipse, VS and Xcode.

It's not just about numbers of menus or widgets.  There is the
organization to think about as well.  It is perfectly possible that
people might think KDevelop is cluttered and Visual Studio is not even
if VS had more menus, widgets etc.  Maybe there are some other subtle
differences that change the way people perceive the UI?  My impression
is that people can tell you that they find one program easier than
another quite clearly, even if they can't tell you what exactly it is
that makes one program better or maybe they give completely the wrong
rationalization for their gut feeling - it is still wrong to just
dismiss their opinion in that case.

> Fine, but that won't make KDevelop any more usable than it is now.

Usable for whom?  Are you targeting people who work day-in/day-out
with Eclipse and Visual Studio and are very comfortable with them?  In
that case they probably won't mind a largish number of menus as long
as they are well organized and easy to navigate (it isn't just a
numbers game).  Are you targeting heavy Emacs and Vim users? In that
case minimizing UI clutter and maximizing keyboard-navigability and
very fast startup should be your highest priorities.  Are you
targeting developers new to the KDE/Qt platforms and possibly
programming in general?  In that case the startup/project creation
experience will probably be very important, as will reducing the
amount of widgets, dockers and other "stuff" on screen.  You obviously
don't have the resources to target every one of those groups - it
would be nice for us as users to know who you're gunning for and who
should wait or use something else.

With the announcement for Qt Creator is that it is pretty clear what
it is about and who it is for and the philosophy which drives it.  It
has a pretty minimal feature set right now - but they are the (mostly)
the right features for the users its aimed at.

Regards,
Robert.

2008/11/3 David Nolden <zwabel at googlemail.com>:
> Am Montag, 3. November 2008 21:23:12 schrieb Alexander Dymo:
>> I'd personally expect the finished KDevelop4 to
>> 1) start fast
>> 2) open any kde/cmake project from the directory on my disk without much
>> question
>> 3) load that project as fast as possible
>> 4) compile it and compile parts of it
>> 5) set a breakpoint, launch debugger and stop on it
>> 6) give me code completion
>> 7) rename class/method without much effort from my side
>> 8) check in and out my project from any modern VCS
>> etc.
>> etc.
>
> I completely forgot to respond to these technical aspects. In general you have
> quite well matches exactly what I wish too.
>
> So let's see where we are:
> 1 - Is the case
> 2 - Not perfect yet, but in general is working
> 3 - I've already discussed with aleix how to achieve that by caching the cmake
> results in the duchain, and actually this has relatively high priority for
> me, since I'm tired of waiting for the project to be loaded. So I hope we'll
> have something soon here.
> 4 - Compiling works, yesterday aleix has checked something in to compile
> single files. Imo we need to adapt the builder a bit to leverage this
> functionality, so when we had a build-error, the first thing the builder
> tries is re-building that exact file, and then again with the full build.
> 5 - I hope Vladimir will come up with something soon. :)
> 6 - Is the case
> 7 - Maybe the case this evening :-D
> 8 - The stuff is there but I've never tried it, this probably needs a lot of
> testing
>
> My personal addition: Documentation support integrated with the duchain, and
> konsole integration.
>
> I've probably forgotten something, but anyway, seems like we're quite near to
> all those goals!
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>