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

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

Hi,


Le 13/10/2013 10:32, Dodji Seketeli a écrit :
> 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.

Currently, I have installed the whole Nemiver project so I haven't the 
issue. I agree that it would be better to have three packages: 
libnemivercommon, nemiverplugin and nemiver. Anjuta is already split 
into libanjuta and anjuta.


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

Ok.


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


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

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


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


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


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

Sure, this is how it's working in Anjuta. The shell only load a few 
mandatory components. Then these components can load additional ones, 
using the anjuta_shell_get_interface_function.

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


Regards,

Sébastien