Re: [anjuta-devel] Sharing code between Nemiver and Anjuta

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

Hi Dodji,


Le 12/10/2013 09:49, Dodji Seketeli a écrit :
> Sorry for my late reply.

My previous message dates from more than 3 months ago. As you notice, 
I'm not in hurry.


> I read and re-read your message and I must say
> that, for what it's worth, I like the general direction things are
> taking.

Good, it looks fine for me too.


> Yes you are right.  IDebugger does have a lot of entry points.  It's
> somewhat messy in my opinion; there are cleanup/consolidation
> opportunities out there.  And your work (should you choose this
> direction) would help me spot these opportunities and act on them.

The debugger interface in Anjuta has quite a lots of functions too.

I have split it in several interfaces. So a python debugger will not 
implement functions used to read CPU registers and disassemble code. But 
it's a not a big part of the interface and a C debugger has to implement 
all of them anyway.

I don't think we can make something really simpler here. Now, it is 
still interesting to compare both interfaces and find some improvements. 
But I'm less interested by that at the moment.


> I think at very least the
> Nemiver project would need to release libnemivercommon and the dynmods
> as separate and maintained libraries set on their own.  So that Anjuta
> could have a clear dependency on these.

Sure and that's easy. The .pc file is already existing for 
libnemivercommon and it includes dynmods too. I have only removed the 
dependency on gnome-vfs and the comment in Makefile.am.



> Said otherwise, Nemiver's UI is organized as as shell of tools.  Right
> now there is only one tool: a classical debugger.  But there could be
> others.

Anjuta is organized in the same way. It is used at least in Anjuta IDE 
and in gtkpod.


> In Nemiver parlance, there is a workbench that contains perspectives.  A
> perspective is roughly speaking a tool.

I think eclipse has a similar concept. I see it in the mockup of the 
GNOME IDE so perhaps we could implement this in Anjuta. But I'm not 
convinced it is better yet.

Anjuta doesn't have such separation between tools. You are able to have 
more than one tool at the same time and the whole point is to allow them 
to cooperate. By example the debugger and the text editor.


> That or maybe define an adapter for the IDBGPerspective and make
> AnjutaShell use that.  If AnjutaShell needs new entry points that
> IPerspective or IDBGPerspective don't have, well, let's add them.  What
> do you think about that?

I think it needs a bit more changes than just a few functions. I see two 
issues for reusing the current IDBGPrespective object.

First, the perspective handle all the debugger windows: text, terminal, 
breakpoints... In Anjuta, they are handled by the equivalent of the 
workbench. How could I get a list of windows instead of only the parent 
(with get_body)?

Perhaps it can be handled by a particular Layout object that will send 
all windows to the Anjuta shell. Then, how could I use a particular 
layout when loading a perspective?


The second issue is with the terminal and editor windows. These two 
windows are implemented by both Nemiver perspective and Anjuta plugins. 
I would like to use the already existing plugin but I don't know how to 
do this.

I can write a special perspective used only in Anjuta which is 
forwarding request to the corresponding plugin. This code needs to be in 
Nemiver project but it's quite useless for it.

Or do you think we could split the windows used by the perspective 
object as dynamic module by example and use them directly or through a 
configurable perspective?


> It's not even sure it would need more work, IMHO.  The devils lies in
> the details, I guess.

I don't know neither how much work is needed. The work is different 
though, I expect more changes in Nemiver with this option.


> I'll try to make myself available to help as much as I can, at least for
> the Nemiver-related tasks.  I don't have much time, but well, I guess
> you don't either ;-) I am counting on the "no-deadline" property here.

That's enough, I need mainly to discuss. I plan to take care of the 
implementation. If it needs 6 months, 1 or 2 years that's fine, that's 
the advantage of working for free.


> I would have leaned more toward re-using the IDebugger interface first,
> and see how things go.  But if you think that re-using the graphical
> stuff would be a Good Thing then well, let's look into that then.
> If it appears that it incurs too much work, we'll back off and consider
> the first option, I guess.

Exactly, I prefer to try to use the GUI first and if it leads to too 
much troubles, I think I can reuse at least the backend.


Regards,

Sébastien