Re: Need input from the community for anjuta (was Re: Proposed module: anjuta)



On Jan 6, 2008 10:00 PM, Vincent Untz <vuntz gnome org> wrote:
[...]
 
We do want the stand-alone apps for the old coders like us, don't we? I
don't think it's only a few coders here and there...
(there's integration with glade3 and devhelp in anjuta)

I think we want stand alone apps too, in these cases the stand
alone apps are only frontends and most if not all of the important
code is encapsulated into a library - mostly I think its important
for testing and bug fixing ( i.e. we can fix bugs and test them
in the Glade frontend and know that they work well before
pushing fixes to anjuta), I suppose the frontend code also
makes a good example for Anjuta developers to integrate
our functionality.


> If Anjuta is really hard to translate, and if the
> strings could be improved, we could postpone until
> 2.24, with the provision that the Anjuta developers
> need to work with the translation teams between now
> and the 2.24 string freeze to fix this stuff.  This
> is something that could have probably been addressed
> earlier in the release cycle, if somebody had taken
> the initiative.

Again, the summary was probably a bit misleading. There's also the fact
that we don't know if it's good from a usability point of view (which is
a hard question for an IDE, I guess). Basically, is it just ready?
That's why we'd like to know what people using it think about it.

I couldnt really speak for its readyness from experience since I am
more of an emacs bum myself as well, as far as usability goes I am
sure there are some things to do to make it better as there always
will be, one thing that is appreciable and IMO appropriate for an IDE
is its use of gdl's docking widget - which allows the user to save their
session and organize what tools go in which windows, notebook tabs
or panes etc.

Another point about i18nness is; I think translatability will improve
dramatically after already being included (and exposed) for one
release cycle, if we dont include it this release cycle I'm sure Anjuta
will improve, but incentive for i18n bugfixing might be low.

All in all I think that the task of Anjuta is really difficult, support for
generating configure.in and Makefile.am according to project deps
seems like a particularly hard task, even when compared to fancy
doodads like symbol browsing and stuff - if the community embraces
it then Anjuta will strive.

My gut feeling about readiness is to trust Naba, he backed down
from proposing it last release cycle because it wasnt ready, if
he proposed it for this release cycle I think we should go with it.

+1

Cheers,
          -Tristan



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]