Re: Anjuta 2 future features?

[John Palmieri <johnp martianrock com>]

<snip>
> 
> > 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.
This is what I was going to do though it will be a pretty invasive
plugin depending on how much I will have to keep track of.
 
<snip>
> 
> 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. 
This is a good thing.

> 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.

Ok, introspection isn't too bad since I will just be parsing GtkObjects
which are just GObjects with some meat.  Parsing signals is easy since
they are enumerated at the top of every GObject file and registered
usualy in the init method.  I would have to follow the parents to get a
full picture.  the bigest problem is some caching mechanism would have
to be implemented to speed things up.  Perhaps sourcebase fills that
need.  I am very excited about that now that you have told me about it.

My main goal is just to make a GObject code generator so that will be my
focus at first but I will keep in mind the other goal when designing.  

By the way, when is sourcebase going to be integrated into Anjuta 2?  I
figure I better wait for this so I don't duplicate code and stress
myself out.  After all this project is supposed to be in support of my
other projects.  

> 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.
I will look at empy.  I have been rethinking the XSLT stuff.  It is nice
and easy to use but suffers from too much verboseness and can be hard to
read expecialy since it is white space sensitive. I actualy want to move
away from complex templating.  Basicly constructing massive code from
dialog boxes destroys the natural flow of programming.  One has to place
themselves withing the mentality of the template engine and then switch
back to regular coding after an inital burst of productivity gained from
generating redundant code.  What I want is a simple template/druid that
would get people started and then the ability to add methods,
properties, signals as they needed them.  It is like making a photo
album.  One does not go and try to set up every memory they would like
stored in their photo album.  Pictures are taken as life goes on and
inserted into the photo album in the appropriate places.


> > 
> > 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.
Cool, viva la Python.  

--
J5