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

[Dodji Seketeli <dodji seketeli org>]

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

> > 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.
>
> In this case the perspective looks more like the Anjuta shell itself.

OK.


> > Today you cannot.  But nothing prevents us from adding entry points in
> > the IPerspective to query components by "kind" or name, if you prefer.
>
> Sure, that would be fine for me but it could change the usage of
> perspective in Nemiver.
>
> If I can get each component of a perspective and display them as I
> want, the perspective object is used only as a group of components. By
> example, the layout manager is useless for this usage.

Ah, I see.  You mean that components being graphical (widgets), they can
only belong to one parent widget at a time; so even if you lookup a
component that is already parented, you can't do much with it; right?

So, yes, I think you need to devise a new perspective that would use the
components that the DBGPerspective type uses (call stack, breakpoint
view, etc).  For instance, if you look at the CallStack type, declared
in src/persp/dbgperspective/nmv-call-stack.h, it's a component that
needs the IDebugger interface.  It contains a CallStack::widget() member
function that returns the widget that visualizes the call stack and
knows how to update itself with respect to the events emitted by the
IDebugger interface.  One could use this component and its graphical
visualization.  You could instantiate and use that widget, right?

I guess that new perspective is what you already have as the debugging
tool, in Anjuta.  It's just that, for instance, its call stack widget
would now be the one declared in nmv-call-stack.h.  Would that work?

> Then if we can consider a perspective only as a group of components,
> it can be similar to an Anjuta profile. Which is just a list of
> components (plugins) loaded by the workbench (AnjutaShell).

Where is the layout of one component vs the others done in this case?  I
am asking this b/c in Nemiver the Perspective is obviously responsible
of laying itself out.  In fact the DBGPerspective delegates the layout
of its widgets (graphical components) to a LayoutManager type.  And that
LayoutManager can perform several kinds of layout.  The kind of layout
to be chosen is defined in a gsettings key.  Maybe we could define a
layout kind of "none" or "embedding-friendly" that would *NOT* parent
the widgets of the components of the DBGPerspective.  It would
essentially do nothing.  That way, you can query the components of the
IDBGPerspective interface, get their widgets from the Anjuta shell (I
think) and parent them (effectively laying them out) as the shell sees
fit.  Would that work?

> > 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"
> > So someone calls:
> >        IPerspective::lookup_component_by_name ("org.nemiver.texteditor/gtksourceview");
> > It gets the registered component.
>
> To be more precise, a component is not only a widget for me but an
> interface. So I could have something like
>       IPerspective::lookup_iface<IEditor> ("IEditor");
> which return an object of the perspective implementing the editor
> interface.
>
> By example, do you think it would be useful to use an interface for
> the editor in Nemiver?

We can indeed factorize an interface out of a family of components, yes.
I haven't done this yet at the level of the graphical component b/c I
haven't felt a need for it, but it has surely been done elsewhere in the
code.

But to be even more precise, the component is an object that implements
one or more interfaces.  So you need to specify the name of the object
(that name is exported/set by a naming registration mechanism) and
specify the interface that you want, from that object.

Hence something like:

    IPerspective::lookup_iface<IEditor> ("org.gnome.devtools.TextEditor", "IEditor");

> > 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);
>
> I think the Anjuta plugin can use directly the debugger perspective so
> I don't think I need something special at the workbench level.

OK.  Sorry for the noise then.

> I think I miss these components below the debugger perspective in
> Nemiver. Do you think it makes sense to split the debugger
> perspective?

What do you mean by "split"?  You mean pack them in a separate shared
library?  separate directory in the source code? (they are the stuff
under src/persp/dbgperspective/nmv-*.{cc,h} today.

Cheers.

-- 
                Dodji