Re: [anjuta-devel] Code assistance plugin

[Sébastien Granjoux <seb sfo free fr>]

Hi Jesse,


Le 11/05/2012 11:05, Jesse van den Kieboom a écrit :
> libpeas really releases the burden of managing a complete plugin
> system (in GObject C).

It's valid for a new project but Anjuta already has its own working 
plugin system.


> Furthermore, it uses
> gobject introspection which allows it to very easily support multiple
> languages if those languages support gobject introspection.

Anjuta support introspection too, you can write a plugin in python and I 
think in Vala. We need to do something for other languages but it's not 
a big deal. Moreover there is not so much Anjuta plugins outside Anjuta 
tree.


> More important though, we can focus development of this now on just one
> library, instead of having each application implementing their own
> system.

I'm agree.


> Many GNOME applications have switched to using libpeas now and
> it works great.

Yes, but I think that comparing to other programs, Anjuta has a more 
heavy use of plugins, so it could be more difficult.


> Another great thing is that having a common library for
> plugins is also going to allow us, for example, to write a common remote
> plugin repository which all applications using libpeas can then benefit
> from.

If a plugin can only be used with only one application, I don't see the 
issue of providing Anjuta plugin for Anjuta, and GEdit plugin for GEdit. 
But I'm agree it would be nice to be able to use the same plugin with 
both programs, for a simple thing, I think it's not that difficult and 
in this case using the plugin system would be a must.


> At last, there is no reason to be afraid. If some feature is
> missing, we can implement it, it's open source after all :)

Sure, that's a major advantage but it needs a consensus and some work.


On the disadvantage side, I think that changing the plugin system of 
Anjuta will take one month of work compare to the maintenance which is 
very low. If we keep libpeas for long enough, let's say more than 5 
years, I think it's a gain but it's not very big and it's not that obvious.

Finally, we can do it just for the fun. I'm not against this move at all 
but I think I can do more useful improvements at least during this cycle.



> There are a few things here that I think are wrong argumentation. First,
> I think using a premise that you want to support both gsv and scintilla
> is not fair. To me this seems a really unnecessary feature. Just choose
> one and stick with it.

I understand your opinion but I'm not convinced.


> If you don't like the feature set of one of those then choose the other.
> You can abstract every single piece of code, but
> a one-fits-all approach is almost never a good design.

From the user point of view, Scintilla has still more features than 
GtkSourceView. The advantage of GtkSourceview is that it is better 
integrated in GNOME, so if you use both GEdit and Anjuta, it's probably 
better to use it. I don't think one-editor-fits-all approach is the best 
one.



> you
> spent time now to write the abstraction layer and to maintain it so you
> have a common denominator for two widgets which provide different
> functionality. Then you need to not just have the abstraction layer, but
> also an implementation layer translating from the abstract concepts to
> the concrete backend implementation. I agree that you need the right
> quantity of abstraction, but I don't agree with your idea of the "right
> quantity" :)

I think one additional advantage of this layer is that it makes plugins 
easier to write because you just need to know the interface not the 
complete GtkSourceView object.



> I agree mostly with your view of an IDE, it's even in the name
> "Integrated" development environment. It should integrate several
> components together. This does not mean however that you need to
> integrate all possible things together. Again, having two widgets for
> text editing doing almost the same is in my opinion useless. You only
> need one tool for each task, if there are more than one, then you pick
> the one you think is the best.

Picking the one I think is the best is not that easy because not 
everybody has the same opinion and this can change over the time. I'm 
agree that there is a lots of abstraction layer in Anjuta but I think 
it's rather a good thing than a bad one.


> Well, please tell me what language (other than assembly and punch cards)
> could be more low level than C. I'm sorry, but C is really not a
> highlevel language.

Obviously assembly. I was kidding but depending on your point of view 
words could mean something a bit different.


> Vala is completely integrated in autotools
> (http://www.gnu.org/software/automake/manual/html_node/Vala-Support.html) and
> works fine.

The last time that I have tried I get some trouble to build code in Vala 
in a separate build directory (it's the default setup in Anjuta). I 
think it has been fixed but it's new.


> Debugging
> with gdb is probably easier in C because vala translates in a bunch of C
> which then doesn't easily translate back into the original source. Then
> again, you will have far less use of a debugger with vala anyway because
> it has better compile time checks (static analysis) and memory management.

I think that providing the same level of debug support that we have for 
C in vala will be really challenging, I think even the C++ support is 
still late. I think it's probably the biggest disadvantage and I don't 
buy you argument than in vala debugger is almost unnecessary. Memory 
management bugs happen in C but they are not the most common nor the 
most difficult ones to find.


Vala is very interesting. I haven't really tried yet, I have to do it. 
Anyway, I'm not paid to work for GNOME so I don't care that much about 
my productivity and I like the low level feeling of the C.


> Independent of gedit, yes. Independent of gtksourceview, I'm not so
> sure.

Ok, then it would be interesting to go more in the details to see if 
it's possible or not.


> I would not merge it into libanjuta, because then other people need to
> depend on libanjuta and will get all the anjuta specific things as well.
> It should be a standalone library in my opinion.

Sure, I haven't been clear enough both libraries should be standalone. I 
just wanted to say that we need to link to both libraries.


> Yes, the lack of documentation is a bit worrysome. It seems like it's
> not really a completely endorsed project from llvm, so I don't know if
> we should rely on it completely.

Well with an abstraction layer we can retarget it to something else. 
There are some work on gcc to use plugins in python :)


Regards,

Sébastien