Re: Anjuta 2 future features?

[Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>]

Hi

> Hello all,
> 
> I needed to do some fixing of large HTML tables today so I apt-got
> anjuta1 to use it's collapsable code paths.  I havn't used Anjuta1 since
> Anjunta 2 became usable.  Wow, the code completion and collapsable code
> were amazing.  Well I always thought Anjuta1 was amazing when I was
> using it.

Thanks.

> 
> I personaly like Anjuta 2's UI and programming interface so I was
> wondering what the status of development is.  Last time I realy looked
> into it Anjuta 1 developers were racing to get 1.0 out the door with the
> notion of moving to Anjuta 2 and putting Anjuta into maintenance mode.
> Then I heard that Anjuta 2's features would take a while to catch up
> with Anjuta 1 so some developers went and did a port of Anjuta 1 to Gtk
> 2.  Recently Anjuta 2 development pace has picked up a bit but it still
> seems that the Anjuta team isn't so sure about it and have split their
> efforts between the two projects thereby slowing the development of
> Anjuta 2 a bit more than I had hoped for.  Please correct me if I am
> wrong here.

No, this is right. Currently, there are a number of (almost mutuatlly
exclusive) groups of developers working on anjuta1 and anjuta2.
Specifically:

1) Naba is working on Anjuta1 HEAD porting it to GNOME2 and stabilizing.
This is pretty close to an alpha release and almost all features work
correctly.

2) I am maintaining the stable branch and aiming to make a 1.0.2 release
sometime this month. This is likely to be the last feature release of
anjuta on GNOME 1.x. I'd probably make maintenance releases fixing major
bugs and such but that's about it. I intend to join anjuta1 HEAD/anjuta2
development full-fledged after that.

3) Jeroen, Gustavo and a few others are working on anjuta2 and they are
doing a great job. I really love the GDL dock, the automake backend and
the architecture in general.

4) TTimo has the unique distinction of having contributed significant
patches to both anjuta1 and anjuta2 (apart from Naba who ported the
symbol browser to anjuta2 a long time back).

However, as you say, it is pretty lagging feature wise and I am not sure
moving all development effort to anjuta2 now is such a good idea since:
	1. This will mean a long stretch of time when users are stuck
featurewise.
	2. I do not like rewriting things from scratch at the drop of a hat.

So, while it is true that anjuta1 architecture is not as elegant as
anjuta2's, I have a feeling that it might be easier (effort-wise) to
refactor anjuta1, bringing the good parts o anjuta2 into it, than
porting all anjuta1 features to anjuta2. This point is, of course,
debatable, and strictly my personal opinion, and I reserve the right to
change it any time ;-)

> The reason I ask is that I am the creator of gobject-factory, a gobject
> boilerplate code generator.  I have always had the intention of moving
> it into Anjuta 2 at some point.  I am actualy now contemplating
> scrapping the whole project and creating a gobject code generator
> exclusivly for Anjuta 2 that is not bogged down by the same problems
> that other code generators like glade face (like overwriting changes
> made by hand).

Go for an anjuta2 plugin. If the anjuta1 code refactoring happens, then
it is quite likely that we will be able to use it in anjuta1 as well.

> 
> I was wondering if the same or similar in memory parsed code structure
> would exist for Anjuta 2 and if I should hold my breath for it to be
> implemented soon.  This would make my life easier in terms of adding
> methods, properties and other such stuff dynamicly.  If it is not I can
> still do it using regular expressions but that might take a small hit in
> performance.  I need to know the timetable on this feature so I can
> choose a path to take.  I plan to start after I get resonably far with
> the current project I am working on.

I am currently in talk with the Glade guys regarding glade/anjuta
integration. They are willing to meet us half-way, but they insist that
they want Glade to be strictly a GUI designer without code generation
capability. It seems that your project can fit the gap nicely. If you
enhance GObject factory to include GTK introspection (so that we can
figure out the callback signatures without hardcoding), then, together
with sourcebase (which is like anjuta1 tagmanager on steroids), we can
come up with a *very good* clean implementation of a glade-integrated
IDE. And while you're about it, you might want to check out the glade2c
module. It does something similar (but not quite since it wants to
generate the full GUI code). However, the current recommended approach
is to just write the callbacks and use libglade to generate teh GUI from
.glade file at runtime. So I am not too keen on the glade2c idea, but
your project sounds right on track.

Also, if I remember correctly, you were using XSLT as a templating
language. It would be nice to have a standard template language  for
anjuta - maybe you can generalize the templating part to server that
purpose ? I have been looking at empy lately and it seems pretty nice
(written in Python) for our templating needs.

> 
> Other features I would like to see (and might implement myself at some
> point):
> 
> Collapsable code - great for debugging syntax
> An incramental search toolbar like in anjuta 1
> Python bindings or at least a dependency so I may use python ;-)  I
> guess I could use Perl since gnome-build has perl dependencies but I
> want python because it is easier to read others code and has the best
> GTK-2 bindings available:-)

I'll probably add Python bindings for anjuta1 soon, but my plate is
pretty full now, so, if you want to go ahead and implement it in
anjuta2, more power to you. I wouldn't worry about the dependency too
much since Python is pretty standard (at least on LInux distributions)
these days and some GNOME programs already depend on it. It would also
make programs written in gnome-python easier to integrate into
anjuta1/anjuta2.

Hope this helps.

-- 
Rgds,
Biswa.