Re: [Anjuta-devel] Why anjuta2?
- From: Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>
- To: Anjuta devel <anjuta-devel lists sourceforge net>
- Cc: GNOME Devtools <gnome-devtools gnome org>
- Subject: Re: [Anjuta-devel] Why anjuta2?
- Date: 14 Nov 2002 10:35:15 +0530
<snip>
> From Biswa's post it seems the first decision a potential anjuta
> developer has to make is which version of anjuta to work on. I'm
> wondering why good working code is being thrown away to write something
> from scratch.
Because people feel that though the code is 'working', it is not 'good'
in the sense that it is not modular enough or extensible enough. I tend
to agree - it is becoming more and more difficult to add features to
Anjuta, esp. if this involves modifying the GUI and/or reusing existing
projects. And you don't have to write the whole IDE from scratch -
Anjuta2 code is derived from gIDE and is pretty old and stable. The only
thing is that it is just a shell and depends totally on plugins for all
functionality. Which is why it seems a bit bare ATM.
Let me give you an example: there is currently a strong demand to allow
people to use their favourite editor with Anjuta - because people are
used to VI/Emacs/whetever key bindings/quirks, etc. This is practically
impossible with Anjuta1 since the editor code (scintilla) is tightly
bound with the rest of the stuff. Anjuta2, on the other hand, makes it
trivial to add a new editor part - write a Bonobo component with an
extremely simple interface (this has some performance and other
drawbacks IMO - but that's a different issue). All you need to do is
define a interface so that a container can get the editor text, the
current cursor position and insert text at a given position, and
register the component - that's it - you can now use your favourite
editor with Anjuta2 !
Another example: The current project manager of Anjuta is extremely
limited - it doesn't support multiple directory->target
type->target->dependencies hierarchy, which is essential for large
projects. Again, it is pretty difficult to replace the PM with a better
one because the PM, symbol manager and editor codes are all mixed
together and there is no clear segregation between the GUI and the
functionality. We found this out the hard way when we tried to integrate
a new PM that Stef had written into Anjuta1 code base. Anjuta2 solves
this problem by making the project manager a plugin. (Disclaimer - I
haven't yet gone through the relevant part of Anjuta2 for this yet).
> Does someone want to do some anjuta2 advocacy? To paraphrase Biswa, it
> seems I should work on anjuta2 because currently anjuta1 is better.
> That sounds like a reason to work on anjuta1 ;-).
I was of the same opinion as you but am slowly converting. I still think
it would be easier to re-structure the current Anjuta code to Anjuta2
style rather than re-write all that code from scratch for Anjuta2 - but
only just. But both are almost equally difficult tasks and we have to
bite the bullet sometime. It was decided (after much discussion and
postponements) that the time is *now* (after Anjuta 1.0.0 release).
So, to conclude, the current status is:
1. Anjuta1 has many features.
2. Anjuta2 lacks lots of features.
3. Anjuta1 code is messy and not extensible.
4. Anjuta2 code is extensible and clean.
5. Anjuta1 is a dead branch - only minor features and bug fixes.
6. All fresh development should be targetted for Anjuta2.
7. The good parts of Anjuta1 should be segregated, cleaned up and ported
to Anjuta2.
Again, this was a common decision made by consensus - but this is a
decision that *has been* made and unlikely to be reversed.
Hope this helps.
Rgds,
Biswa.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]