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

[Dodji Seketeli <dodji seketeli org>]

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

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

Yes, I know that.  But it's been a long time and without real users
outside of Nemiver itself, there might be adjustments to do ;-)

> and it includes dynmods too.

I don't get this.  I don't think there is a formal library definition
that "packages" the dynmod.  My understanding is that the dynmods get
installed by makefiles like src/dbgengine/Makefile.am, not by the
src/common/Makefile.am, which is the one "building"
libnemivercommon.so.  So my guess is that we'd need to install e.g the
dynmod + headers that are installed today from src/dbgengine/ as
something separate from the whole Nemiver thing -- if you are taking
the route of reusing IDebugger.

Or we could just say that "thou shall just install Nemiver as a distro
package dependency and be done with it".  I am not sure that is great
though ;-)


> I have only removed the
> dependency on gnome-vfs and the comment in Makefile.am.

Woops, gnome-vfs? See, I told you this thing would need "adjustments"
:-)  This should die indeed ;-) I'll accept your patch for this ;-)

> > In Nemiver parlance, there is a workbench that contains perspectives.  A
> > perspective is roughly speaking a tool.
>
> I think eclipse has a similar concept.

Yes, I borrowed the concept from them ;-)

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

Your call.  :-)

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

To me (in Nemiver at least), at this level of abstraction, the text
editor is not a "tool".  It's at a lower abstraction level.  It's a
component that can be used (or shared) by some tools.  A tool (a
perspective) is an aggregate of several components that cooperate to let
the user achieve a task.

> > 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)?

Today you cannot.  But nothing prevents us from adding entry points in
the IPerspective to query components by "kind" or name, if you prefer.
That is, in a type that implements the IPerspective interface, when you
instantiate a component that is meant to be "queried", you register the
component by saying:

    this Gtk::Widget is the "org.nemiver.texteditor/gtksourceview"
    component.

So someone calls:

    Gtk::Widget *w = 
      IPerspective::lookup_component_by_name ("org.nemiver.texteditor/gtksourceview");

It gets the registered component.

You could wire that lookup interface in the IWorkbench interface by
defining something like:

    bool
    IWorkbench::lookup_component_from_perspectives(const string& name,
                                                   Gtk::Widget& comp,
                                                   IPerspective& persp);

That would give you the first component found with that name, and the
perspective it was found from.  You could devise an entry point that
would hand you the list of components found with that name, and the
perspectives they came from.

Would something like that fit your need?

[... ]

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

Maybe if we have the component querying in place, what the code inside a
type implementing a given perspective interface would do is to first
query the Shell/Workbench to see if a tool/perspective has already
instantiated the component; if the component exists, use it; otherwise,
instantiate a new one and register it.

Would that do the trick?

-- 
                Dodji