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

[Dodji Seketeli <dodji seketeli org>]

Hello Sébastien,

Sorry for my late reply.  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.  Please find below some comments I'd like to add.

Sébastien Granjoux <seb sfo free fr> a écrit:

> I have spent some time to check how I can use Nemiver code inside
> Anjuta. I see two ways to do this.
>
>
> The first one is the easiest. I will reuse only the debugger
> backend. On Nemiver side, it corresponds to the IDebugger interface. I
> agree that it's better to use this interface than the gdb backend
> directly. On Anjuta side, this will replace the gdb plugin.
>
> The Anjuta plugin will be in C++, using libnemivercommon and loading
> the module gdbmod. I have to write a wrapper around the debugger
> backend object to implement the C IAnjutaDebugger interface.
>
> The Nemiver IDebugger interface has quite a lots of functions, so it
> is quite some work to wrap all of them and I haven't checked yet if
> some functions are difficult to wrap comparing to the IAnjutaDebugger
> interface.

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.

In general, I'd say that you shouldn't need to wrap *all* of the entry
points anyway.  Just those that are useful to cover the use cases that
you guys have today in Anjuta.


> It can be possible that a change in Nemiver or in IAnjutaDebugger
> could help here. Except that, I don't expect other changes. I have
> been able to load the gdbmod module outside Nemiver quite easily.

OK.  But yes, I agree that I'd need to do some work there.  Beside the
consolidation work I have alluded to above, 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.

> The second possibility is to reuse the GUI of Nemiver: the Context,
> Register, Memory, Breakpoints windows... The advantage is that it
> allows to share much more code. In Anjuta the debugger backend plugin
> is much smaller than the debugger GUI plugin. If we have similar
> ratio, this solution allows to share more than 3 time more code.
>
> Another advantage of this solution is that the interface is
> simpler. The debugger GUI interface needs simpler functions like start
> or stop the debugger, load a program, get the debugger window....
> The Nemiver widgets could communicate with the Nemiver debugger
> backend in C++ like it works in Nemiver.
>
> Of course, there are some drawbacks too. The main issue is that it is
> much more difficult to reuse the Nemiver GUI because, contrary to the
> debugger backend, it is organized in a bit different way than in
> Anjuta.
>
> In Nemiver the GUI is handled by the IDBGPerspective object. This
> object is responsible for creating and organizing all widgets.

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.

In Nemiver parlance, there is a workbench that contains perspectives.  A
perspective is roughly speaking a tool.  A perspective is responsible of
the whole user experience related to a certain task.  For example, the
perspective responsible for the debugging task will layout all the
widgets necessary to deliver the debugging experience to the user and
will make then cooperate as needed.  The workbench doesn't know anything
about debugging. 

Perspectives implement the IPerspective interface.  In other words, the
workbench knows how to manage objects that implement the IPerspective
interface.

Now for debugging, we have defined a sub interface that extends the
IPerspective interface; that is the IDBGPerspective you are talking
about.  It's implemented by instances of the DBGPerspective type.  This
DBGPerspective object is the one that uses all of the concrete debugging
widgets like source code viewer, breakpoint control widget, call stack
widget, memory editing widget, terminal widget, etc ...  And in turns,
it's these low level widgets that use the IDebugger interface to talk to
the low level debugging backend that happens to be GDB today -- but that
could be something else tomorrow, if we provide the right implementation
of that IDebugger interface for that "something else".

> It can be compared to the debugger manager plugin of Anjuta which is
> responsible for the debugger GUI. The difference is that the Anjuta
> plugin handles only the debugger specific windows like the breakpoint
> or the stack windows and can use windows provided by other plugins
> like the editor or the terminal window. Moreover Anjuta plugin doesn't
> control the layout of the windows and give only hints for their
> position.
>
> Another difference is the Nemiver Workbench object. It plays the role
> of the AnjutaShell object in Anjuta as a parent of the other parts of
> the application. I think one option is to write a custom Workbench
> object that will redirect most requests to the AnjutaShell object. One
> issue is that it has to be loaded as a module. Then the toolbar and
> the menu are handled in a different way in Anjuta, they are described
> in a .xml file.

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 the second option is more interesting but it needs more work,

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

> to avoid any ambiguities, I don't ask anyone to do it. I plan to work
> on it. It will all take the time needed, I don't have a deadline.

:-)

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.

> What do you think about these two options?

I think you are getting a good sense of about these things.  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.

Cheers.

-- 
                Dodji