Re: gdl's editor vs. anjuta2-old's editor.

[Dave Camp <dave ximian com>]

> Now, let's put the thought from our 'requirements' side. We need lots of
> sofisticated interfaces, because we are designing an IDE and not a
> simple application which can work with the limited set of interfaces.
> So, this, practically, puts the 'concept of generic components' in a
> very bad place.
> 
> Actually, this problem has arisen from the fact that, you are trying to
> treat the document compoments similar the nautilus's file handlers and
> evolution's attachment handlers. It might be worth while to note that
> these handlers need minimum of either Bonobo::PersistStream or
> Bonobo::PersistFile interface to work with nautilus or evolution. In
> short we need something 'more' than that.

I agree that ideal components will require advanced interfaces. 
However, there is a wealth of useful controls that support only the
basic interfaces and are useful to have inside of anjuta2.  Right now
anjuta2 has the ability to edit and preview HTML documents because we
use a generic framework that allows the gtkhtml editor to be used inside
of anjuta2.  We shouldn't take away this ability just because we feel
that our needs are "too advanced".  The fact of the matter is that
people will be developing content editors for nautilus sooner and more
often than anjuta2 components, because nautilus is a core component of
the desktop.  We should take advantage of these controls where we can,
but provide interfaces that people interested in integrating more
tightly with anjuta2 can use. 

> 
> Ok, now let's come to the 'adaptation of lack-of-interfaces'. We somehow
> need to deal with this. What I did was, instead of letting the
> application deal with this dirty work, I have put an intermidiate object
> which will actually be doing the dirty work of handling the
> lack-of-interfaces -- called 'AnjutaDocument'. This is a generic
> interface which 'always' sticks with the main application. The
> application expects a certain set of interfaces from this generic
> object. You can treat it as a 'virtual class'.
I understand what you are doing, but I think that in practice this
abstraction layer is both unnecessary and problematic. 

The main reason I believe that it is unnecessary is the fact that we
have been using a direct method in gIDE for almost a year now, and it
hasn't caused any significant problems. 

I disagree with the notion that the application should not deal with the
"dirty work" of detecting various interfaces.  Bonobo has well-defined
ways of discovering and utilizing various interfaces, so it isn't that
difficult.  Right now in anjuta2, if you want to add a breakpoint
marker, you ask the control if it supports the Marker interface.  If it
does, you add the marker, if not you don't. 

How would this work with an abstraction layer?  It can work one of three
ways.  

The first way is that the abstraction layer can return a failure
condition, saying that the control does not support the marker
interface.  In this case the abstraction layer has bought you nothing
over the direct access method;  you still need to support the same
number of interfaces. 

The second way is that the abstraction layer pretends to work, ignoring
the failure condition and allowing the application to ignore the
failure.  The problem here is that the application can't deal gracefully
with the failure, because it doesn't know it happened. 

The final way is that the abstraction layer simply won't allow controls
that don't support the marker interface.  This is the worst option,
because it drastically limits the functionality of anjuta2. 

> You found some interfaces, such as setFile() etc., which you didn't
> expect from a sharable component, because this component is *not*
> sharable. It is an integral part of anjuta (or for that matter,
> DocumentManager).
If it is not a shared component, and is only used internally, there is
no reason to export it as a corba component. 
> 
> Diagramatically:
> 
> ------------------------------------------------
> |                                              |            
> |    Anjuta                                    |
> |                                              |
> ------------------------------------------------
>           ||                      ||        ||
> -----------------------        [Other components]
> |                     |
> | Document Manager    |
> |                     |
> -----------------------
>        ||    ||
>        ||    ||
> - - - - - - - - - - - -
> |                     |
> |   Anjuta Document   |
> |                     |
> - - - - - - - - - - - - 
> |   |   |   |   |   |
> |   |   |   |   |   |
> --- --- --- --- --- ---
> |*| |*| |*| |*| |*| |*|
> --- --- --- --- --- ---
> [ Editing controls ]
The existing anjuta2 code has a similar diagram, except without the
anjuta document abstraction layer.  This layer is effectively part of
the document manager.  This reduces code size (corba isn't light) and
makes the code easier to manage. 

>
> The only thing it sees is the Document Object. The document manger just
> creates or destroys 'document objects'.  Document objects, in turn
> manages the editing controls.
I think I understand what you are talking about here.  And the anjuta2
document manager actually works very similarly, but it avoids overuse of
corba where we don't believe it's necessary. 
 
> I think it will be more easier to bring the features from the
> scintilla-control into AnjutaEditor, because, AnjutaEditor seems to be
> more complex than the scintilla-control. Either way, our motive is to
> upgrade the control.
This sounds fair.  My suggestion would be to put AnjutaEditor into gdl,
and hack it to export the proper interfaces.  I wouldn't mind doing this
work myself. 

I think it would be a good idea for me to send mail to the list
explaining in-depth the design and implementation of the anjuta2
document manager.  I'll try to do that some time in the next few days. 

-dave