Re: future of scaffold

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
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-devtools
>