KDevelop 4 - current showstoppers

Hi,

I realise that we're not releasing kdevelop 4 with kde 4.0,
but I don't think 
that should stop us from trying to get it into some sort of
usable state.  
There are really great things going on under the hood which
I think will make 
kdevelop 4 certainly the most advanced IDE that I have ever
seen for certain 
uses, but at the moment there are a few things stopping it
from even being 
useful as a plain text editor (imho):

1) User Interface
* We can't hide the dock widgets like we could in kdevelop
3.  Thus, it's very 
difficult and annoying to get a reasonably sized text editor
window.
* The dock widgets are significantly out of proportion on
startup (bottom 
widget takes 3/4 of the screen).
* File modification status is not visible anywhere - it
should at least be in 
the title bar and the document selector bar
* I couldn't get a shortcut to switch documents working.
* No recently opened files action (trivially fixable)

2) Projects
* Build selected project - no feedback when no project is
selected
* Currently selected project mechanism is hidden / broken
usability - you 
currently need to select project from project manager,
should be an entry in 
the project menu to select between them.  If there's only a
single project, 
it should always be the currently selected project
* Files aren't saved prior to building (I tried to fix this
but so far I think 
it's still failing)

3) Configuration
* Shouldn't configure project be in the project menu?
* Where did all of the options go?  I know at one point we
had a config dialog 
for the c++ background parser
* Configuration of tool views is not saved.  KMainWindow can
do this for us if 
we set unique object names on each tool view, and then call

applyMainWindowSettings and setAutoSaveSettings.  However we
need all 
toolviews loaded at that time, so we will probably need
custom code for 
non-global tool views.

Hopefully this can stir up some interest in fixing these
relatively minor 
issues which are holding back kdevelop from gaining more use
and thus more 
interested developers etc.

Cheers,
Hamish

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Mittwoch, 31. Oktober 2007, Hamish Rodda wrote:
> 2) Projects
> * Build selected project - no feedback when no project
is selected

IMHO that option should go away anyway as it creates a state
which we 
don't support. It was just a quick hack to be able to test
the building 
of projects.

Idea for replacement:

- context-menu in the projectmanager, needs to be done
anyway
- Build... which pops up a dialog to select 1-n projects to
be built
- Build last built projects (naming should be improved
obviously) which 
just "reruns" the last build action, i.e. if I
built 3 projects before 
and run this action it'll build the same projects again.

That same stuff could work for Rebuild+Install.

Another idea would be putting the selection into the main
menu i.e. 

Build->Projects->[X]Foo, [X]Bar, [ ]Baz

And then have Build->Build, Build->Rebuild and so on
which use that 
selection in the submenu. But I don't think I like that gui
and it 
doesn't scale too well with "many" projects.

> * Currently selected project mechanism is hidden /
broken usability -
> you currently need to select project from project
manager, should be
> an entry in the project menu to select between them. 
If there's only
> a single project, it should always be the currently
selected project

See above, I don't think we should act on selection at all.

> 3) Configuration
> * Shouldn't configure project be in the project menu?

Maybe, I really don't have a strong preference, it was just
fitting well 
with Settings 

> * Where did all of the options go?  I know at one point
we had a
> config dialog for the c++ background parser

Yes, thats KDevelop3 ;) Seriously though I guess this was in

lib/settings at the beginning of the year? If so its still
in that 
directory, but the directory has gone 

To get at the directory checkout

svn co -r641348 
h
ttps://svn.kde.org/home/kde/trunk/KDE/kdevelop/lib641348

But isn't this now the general background parser? AFAIK it
has been 
moved into the platform... If so it should be resurrected
under 
shell/settings in the platform and made available via the
global 
settings (i.e. Configure KDevelop)

Andreas

-- 
Are you a turtle?

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 31 October 2007 13:56:09 Hamish Rodda wrote:
> 1) User Interface
> * We can't hide the dock widgets like we could in
kdevelop 3.  Thus, it's
> very difficult and annoying to get a reasonably sized
text editor window. *
> The dock widgets are significantly out of proportion on
startup (bottom
> widget takes 3/4 of the screen).

That's the number one showstopper for me atm.

But the others are important too.

It would be really great if a few more developers could
motivate themselves to 
help moving kdevelop forwards at this delicate position of
development.

I can see that we're creating a really great application,
but at current 
development speed I fear that we won't have the minimum
needed features by 
the time kde 4.1 is published.

greetings, David


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Hi,

Ok, time for a status update...

On Wed, 31 Oct 2007 11:56:09 pm Hamish Rodda wrote:
> Hi,
>
> I realise that we're not releasing kdevelop 4 with kde
4.0, but I don't
> think that should stop us from trying to get it into
some sort of usable
> state. There are really great things going on under the
hood which I think
> will make kdevelop 4 certainly the most advanced IDE
that I have ever seen
> for certain uses, but at the moment there are a few
things stopping it from
> even being useful as a plain text editor (imho):
>
> 1) User Interface
> * We can't hide the dock widgets like we could in
kdevelop 3.  Thus, it's
> very difficult and annoying to get a reasonably sized
text editor window. *
> The dock widgets are significantly out of proportion on
startup (bottom
> widget takes 3/4 of the screen).

With the new Ideal mode, this is now working.  (actions
missing, but coming 
shortly).

> * File modification status is not visible anywhere - it
should at least be
> in the title bar and the document selector bar

Fixed

> * I couldn't get a shortcut to switch documents
working.

Fixed

> * No recently opened files action (trivially fixable)

Fixed

> 2) Projects
> * Build selected project - no feedback when no project
is selected

Fixed, but the outputview doesn't come to the front when you
build.

> * Files aren't saved prior to building (I tried to fix
this but so far I
> think it's still failing)

Fixed

> 3) Configuration
> * Shouldn't configure project be in the project menu?
> * Where did all of the options go?  I know at one point
we had a config
> dialog for the c++ background parser

Reinstated.

> * Configuration of tool views is not saved. 
KMainWindow can do this for us
> if we set unique object names on each tool view, and
then call
> applyMainWindowSettings and setAutoSaveSettings. 
However we need all
> toolviews loaded at that time, so we will probably need
custom code for
> non-global tool views.

Still TODO for Ideal, and for Qt Dockwidget (harder)

... a pretty good scorecard!

Post your most hated showstoppers too, maybe we can make it
to something worth 
using by kde 4.0.  I've got a few more I'll dig up
tomorrow...

Cheers,
Hamish.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> ... a pretty good scorecard!

Agreed, you rock. =]  Can't wait to try this stuff out.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 13/nov/07, at 18:14, Hamish Rodda wrote:
>
> With the new Ideal mode, this is now working.  (actions
missing,  
> but coming
> shortly).

Wow, it looks very nice  tnx a lot
Hamish!

ciao robe


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 14.11.07 04:14:09, Hamish Rodda wrote:
> On Wed, 31 Oct 2007 11:56:09 pm Hamish Rodda wrote:
> > 2) Projects
> > * Build selected project - no feedback when no
project is selected
> 
> Fixed, but the outputview doesn't come to the front
when you build.

AFAIK the reason is simply that Sublime doesn't provide a
hook for that.
If that has changed meanwhile this shouldn't be too hard...

> > 3) Configuration
> > * Shouldn't configure project be in the project
menu?
> > * Where did all of the options go?  I know at one
point we had a config
> > dialog for the c++ background parser
> 
> Reinstated.

Sorry, for not taking a closer look which of those might
still be needed
when I removed them :(

> > * Configuration of tool views is not saved. 
KMainWindow can do this for us
> > if we set unique object names on each tool view,
and then call
> > applyMainWindowSettings and setAutoSaveSettings. 
However we need all
> > toolviews loaded at that time, so we will probably
need custom code for
> > non-global tool views.
> 
> Still TODO for Ideal, and for Qt Dockwidget (harder)

How much harder? compared to getting ideal to have drag+drop
support and
letting the user choose the toolview that fills the
corner...

IMHO we don't need both, we just need one of the two with
all features
implemented. And from my POV what the dockwidgets have that
our ideal
mode doesn't have (yet) is drag'n'drop for the toolviews and
somehow
defining which toolview gets the corner-space. Ideally the
latter could
be done "on-the-fly", but a plain config option
that needs a restart
would be sufficient as well.

> ... a pretty good scorecard!

Yeap, you're doing an amazing job.

Andreas

-- 
Someone whom you reject today, will reject you tomorrow.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 31.10.07 23:56:09, Hamish Rodda wrote:
> Hopefully this can stir up some interest in fixing
these relatively minor 
> issues which are holding back kdevelop from gaining
more use and thus more 
> interested developers etc.

Showstoppers for me personally:

- jump-to-def/decl, ideally cross-project
- svn-support (am on that, and hopefully have it done by the
end of the
  week)
- for daily work there's a need to integrate the project
support better,
  i.e. somehow adding new files to a project, or at least
updating the
  project model when a project file changes. (my goal for
next week, at
  least for qmake, cmake comes afterwards)
- keyboard-shortcuts, specially for the toolviews

I think thats a pretty short list, which should be fixable
in a few
weeks.

Andreas

-- 
Don't get to bragging.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 13 November 2007 18:43:32 Andreas Pakulat wrote:
> > Still TODO for Ideal, and for Qt Dockwidget
(harder)
>
> How much harder? compared to getting ideal to have
drag+drop support and
> letting the user choose the toolview that fills the
corner...
>
> IMHO we don't need both, we just need one of the two
with all features
> implemented. And from my POV what the dockwidgets have
that our ideal
> mode doesn't have (yet) is drag'n'drop for the
toolviews and somehow
> defining which toolview gets the corner-space. Ideally
the latter could
> be done "on-the-fly", but a plain config
option that needs a restart
> would be sufficient as well.

Will it be possible to have multiple widgets in one tab with
ideal? That's an 
important feature I think, that the dockwidgets can deliver.
No widget will 
need the full height of my 1600x1200 screen.

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> IMHO we don't need both, we just need one of the two
with all features
> implemented. And from my POV what the dockwidgets have
that our ideal
> mode doesn't have (yet) is drag'n'drop for the
toolviews and somehow
> defining which toolview gets the corner-space.

Having done a few different things involving Qt and drag
& drop, this shouldn't be too hard.  I cant imagine that
the other feature would be too hard either, although I
haven't really looked at the architecture.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel