Re: [anjuta-devel] Search Dialog in Anjuta 3.2?

[Andreas Volz <lists brachttal net>]

Am Wed, 08 Feb 2012 22:20:09 +0100 schrieb Sébastien Granjoux:

> > - *stable* gdb plugin
> I suppose you mean that the current plugin is not stable enough. I
> have done a few improvements for Anjuta 3.4 for simple thing it looks
> like it's working. I have seen one bug report from you and I will be 
> interested by more details.

I've often problems after intensive debugging session. For example
after 30-60 minutes and 10 times restarting application in gdb. All
simple cases are working well.

Maybe there's one point to improve the crash situation. Most time I'm
just frustrated, because after crashing my project isn't saved and I've
to reopen all my files, breakpoints,...

Maybe you should save more often of provide some sort of "crash
assistant" like openoffice has one. So after a crash user should be
able to just continue at the same place. This would improve the
situation.

> > - autotools support (for parsing project)
> Isn't it good enough now? I think Anjuta has the best autotools
> support than any other IDE.

Ok, just after some first try of code::blocks and codelite you may be
right. But I've not yet looked into new eclipse autotools support.

There's just one limitation that troubles me. I've just created a
ticket for it.

https://bugzilla.gnome.org/show_bug.cgi?id=669780

With old anjuta version it wasn't possible to create (never mind), but
project manager showed files. Now it doesn't even parse them correct
and show files. Bad as I've to use file browser to access my code files.

> > - fast and good symbol browser
> > (symbol browser was never good enough for me. No chance if you
> > compare search quality with eclipse or cscope/kscope!)
> > - jump to declaration/implementation of function (was in most cases
> > not working)
> I don't use it very often but it seems to work here. From time to
> time I have to delete the .anjuta_sym_db.db file to recreate a good
> database but I don't use Anjuta as a normal user.
>
>
> > - TODO plugin (possible to replace)
> Ok, so it's more something nice to have.

For simple TODO I'll use text files as long it's broken.

For my use case of managing local bugs and requirements in Anjuta I'll
choose an alternative.

> > - *free* configurable editor colors
> You can configure most of the color of the syntax highlight on
> Scintilla but the setting dialog was quite buggy. I have improved it
> for Anjuta 3.4, so it should run fine now. Then for this bug 
> https://bugzilla.gnome.org/show_bug.cgi?id=669359, we need to add a 
> preference somewhere but it shouldn't be a problem.

Yes, this is my current problem. Reason I don't use Scintilla is that
there this bug is even more worse at the moment. :-)

> > - a good merging/diffing GUI (like integration of "meld") (also with
> >    CSV support) would be a perfect dream! If you ever worked with
> >    eclipse synchronize feature you know what I'm talking about.
> I don't know what Anjuta can add by integrating "meld". But I haven't 
> used eclipse synchronize, I will look at it.

You'll benefit from this feature most in (larger) team working. As
example see this image. It explains the usage:

http://luksza.org/wp-content/uploads/2010/08/egit-sync-view-change-set.jpg

On the right you see this synchronize perspective. This is what you
would get if you do a svn update. I think it's generated with some 
svn diff -r HEAD command. So it'll fight against the problem that you
will just do a svn update and get all including conflicts and stuff you
don't like from the trunk. With the idea of viewing differences before
just getting them you prevent problems in front and could choose what
to merge into your local copy. If you've ever just updated a trunk
where 20 other peoples commit also you know the problem. It's also
helpful so solve conflicts for the code integrator use case.

If you integrate meld or write your own GUI diff tool isn't important.
But I think a IDE with VCS integration could/should offer some GUI diff
and merge tool. Without synchronize view doesn't help for sure.

> > - I've *no* need to create libs, headers,... related to autotools
> >    with a GUI. Easy use cases are ok, but the complex stuff will
> > never be supported by a wizard as it offers just to much
> > possibilities. I just edit Makefile.am with an editor.
> My goal is to make it possible to write a complete project without 
> knowing autotools, something equivalent to what you have on other IDE 
> using other project formats. I think it's still not complete but I
> will not add a button for every feature of autotools. Indeed, for
> someone knowing autotools it is only nice to have if it's working
> well.

The creator GUI is nice to have. I need only to parser for the project
manager window.

But keep on the good work! I see the progress in Anjuta over the years.
I was just frustrated, because some use cases aren't working for me any
longer. If you say there's some work on it I'm happy. :-)

regards
        Andreas

-- 
Technical Blog <http://andreasvolz.wordpress.com/>