Re: future of scaffold

[Jeroen Zwartepoorte <jeroen xs4all nl>]

Hi Gustavo,

This all sounds very good. I'm looking forward to your API proposal. I'm
curious as to how the dynamic interfaces will work.

I'll have specific comments once i see the API proposal :)

Jeroen

On Tue, 2003-12-30 at 04:31, Gustavo M. Giráldez wrote:
> 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
> 
> 
> 
> _______________________________________________
> gnome-devtools mailing list
> gnome-devtools gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devtools
>