Re: future of scaffold

["Gustavo M." Giráldez <gustavo giraldez gmx net>]

Hi!

(Warning: long mail)

I want to have as many people involved in this discussion as possible,
since that will bring new ideas and points of view to the table.  That's
why I've cc'ed the list.  Please, anyone interested in hacking Scaffold,
speak up, share your thoughts, so we can build a solid infrastructure
for a great Gnome IDE.

On Fri, 2003-12-26 at 11:16, Jeroen Zwartepoorte wrote:
> Hey Gustavo,
> 
> So i'd like to put some thoughts of mine about the future of scaffold
> down here.
> 
> The Mono guys are porting SharpDevelop to Gtk# atm. What they're doing
> is changing the SWF (System.Windows.Forms) code to Gtk#. They're not
> using gtksourceview. They'll likely use GdlDock in the GUI, but that's
> about all it will have in common with Scaffold. So it looks like
> Scaffold# is not very attractive to them. (i haven't done any work on it
> lately anyway. Working on GdlDock mostly atm)
> 
> Your comment about making python plugins work in scaffold started me
> thinking. I'm thinking we can make a small core, written in C that uses
> the new Action API in gtk 2.3 and have plugins around that written in
> C/Python/C# etc. This would require some refactoring.
>
> The reason i'm in favor of something like this is that i'm still not
> happy with our current architecture of having a DocumentManager
> interface and an implementation of that in NotebookDocumentManager. It
> really sucks when you have plugins depending on other plugins etc.
> What's your opinion on this? Has it changed after reading the JBuilder
> Opentools document? :) (/me hopes it has)

I think using the Action API solves just a small part of the problem,
i.e. the UI merging of the different plugins.  It can also be used for
plugins offering a visual artifact on which the user can perform
actions, such as a file entry in the project view.

I agree Scaffold's core should be as small as possible, and have most
functional parts implemented as plugins.  I think that's the spirit of
the current implementation.

A single plugin should be also as small as possible, and do one thing
well.  The problem is that plugins should interact with each other, to
allow the user to accomplish more complicated tasks, and to be able to
present more useful information.

Personally, I don't care whether the plugins are written in C, C++,
Python, C#, or any other language of choice.  In fact, I'd like to have
plugins written in as many languages as possible, and have each one talk
to each other in a clean and simple way.  If a plugin implements a
service which could be used by other plugins to make the user experience
better, it should be possible to export the service and be used from
outside without much trouble.  To accomplish that, we need to clearly
define the interfaces which plugins will realize or use.

As I see it, we have two alternatives: compile-time interfaces and
runtime interfaces.  For compile time interfaces, the plugin needs to
know the interface when it's built, and for runtime interfaces, the
methods and properties can be discovered during execution, using
reflection mechanisms.  Both have advantages and disadvantages, and I
think are suitable for different uses.  That's why I'll propose to use
both:

a) Have a set of predefined core interfaces (implemented using
GInterface) for very basic IDE functionality: a source file (or
document), the project, a build target, etc..

b) A runtime system to discover extra functionality, so we don't need to
change the core interfaces whenever we need to do communication between
two plugins.

The other piece of the puzzle, which is a service the shell should
provide, is a mechanism to register and retrieve objects which implement
the above interfaces.  The current value storage system is a solution to
this, but it'll probably need some changes and extensions.  For example,
I'd like to have the objects organized in a hierarchical fashion (note
that the hierarchy is also a kind of interface).  Another addition I'd
like to see is a moniker-like resolution system so any plugin could
claim a subpath of the hierarchy, and provide factory and/or directory
services.

> Is this doable though: if you have plugins written in different
> languages, can you still depend on them easily without having to write
> bindings for a plugin first? .Net gets around this by having a common
> Intermediate Language. We don't have that in C...

Well, we don't have an intermediate language, but we have the GObject
runtime system, which I think is good enough for our purposes.  As long
as we have gobject bindings and we provide bindings for the core and
shell interfaces, we can use almost any language.

The idea is not to depend on a particular plugin at compile time, i.e.
don't #include a plugin header from other.  If you ever need to do that,
that means you should instead use a runtime interface (a gobject
property for example), or define a new/extend an existent core
interface.

Ok, so this was all very vague.  My intention is to get the ball rolling
and get more people involved in the design.  I'll try to follow up
shortly with a more concrete proposal of an API for the shell and a set
of core interfaces, but I think I've outlined the basic functionality
I'd like to see:

- shell with service/object registering capabilites (to allow plugins to
advertise themselves), ui merging and session managment (so plugins can
save project independent data)

- a moniker interface, for container-like plugins. E.g. the document
manager could claim /Documents and create a new object exporting the
document interface, whenever someone tries to access /Documents/foo.c.

- a UI merging interface for plugin visual elements (even the shell
could implement it), to allow plugins to add context actions and/or
information to some UI elements from other plugins.  A typical example:
a version control plugin would want to add version information and
operations (update, commit, etc.) to a source file in the project
plugin, which is a row in a tree view widget.

- a document interface, offering services such as save, get text, insert
text, etc. and notifications of user changes.

- a project interface, for example to allow other plugins to save
project dependent data, enumerate targets and source files, get local
configuration information, etc..  Some users of these services: a
debugger, a packaging plugin, etc..

- a build target interface, with methods such as build, clean, enumerate
sources, add source, etc..  Maybe project and target interfaces could be
combined.

Thanks for reading this far.  Please comment on this.  Ideas, criticism,
corrections, any kind of feedback is welcome (as long as it's
constructive ;-)

Btw Jeroen, the JBuilder Opentools documents did give me some ideas
which are part of what I'm proposing.  For anyone interested, here are
the URLs:

http://linuxberg.vc-graz.ac.at/mirror/jbuilder/techpubs/jbuilder9/opentools.pdf
http://info.borland.com/techpubs/jbuilder/jbuilder9/opentools/ref/OpenToolsAPI/

Regards,
Gustavo