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

[Naba Kumar <kh_naba yahoo com>]

On Mon, 2001-11-05 at 22:47, Dave Camp wrote:

> After looking at the document component in the old anjuta2, I'm pretty
> certain that gdl's design fits our needs better.  Here I'll try to
> explain why:
> 
> The GNOME::Anjuta::Document interface reinvents the wheel a lot.  Here
> are some parts of the interface that should be replaced by standard
> bonobo interfaces:
> 
> setFile() - This should be handled by Bonobo::PersistStream and
> Bonobo::PersistFile, the standard interfaces for loading data into
> bonobo controls.
> 
> gotoLine() - We do this in scintilla by having a current_line property
> that can be retrieved or set.
> 
> getHandlerControl(), getHandlerInterface() - The document editor
> should implement Bonobo::Control directly, and use queryInterface() to
> get different interrfaces.
> 
> The gdl editor implements the following interfaces:
> 
> Bonobo::Control - For embedding
> Bonobo::PropertyBag - For the current_line property
> Bonobo::PersistFile - For loading files
> Bonobo::PersistStream - For loading streams
> GNOME::Development::EditorBuffer - For manipulating text
> GNOME::Development::EditorGutter - For placing marks, such as debugging
> markers and bookmark markers.
> 
> Some benefits to our approach:
> 
> The anjuta2 document manager doesn't need components to implement a
> special IDL interface. EditorBuffer and EditorGutter are optional.  As
> long as a component implements Bonobo::Control and either
> Bonobo::PersistFile or Bonobo::PersistStream, anjuta2 can load
> documents using it.  This means that we get, essentially for free,
> html editing (with the gtkhtml control) and image veiwing (with the
> nautilus image viewer), pdf viewing, etc.  Basically any bonobo
> control written to view attachments in evolution will work in the gIDE
> document editor.
> 
> More interestingly, because we use standard interfaces with our
> scintilla control, it can already be used to view source files in
> nautilus, or to view source files attached to mail in evolution.
> 
> So I'd like to use the GDL editor, and port some of the features from
> anjuta2-old to that editor.  Since they both use scintilla, that
> should be easy (easier than trying to port the anjuta2-old editor
> component to use standard bonobo interfaces, I think).
> 
> Questions or comments welcome,
> -dave
First of all, I am afraid, you were looking at the wrong place. I might
as well explain how I approached the design earlier.

There are vast variety of editing components available. Some have good
interfaces and some have bad. The point is, the application should be
able to adapt with the 'lack of interfaces' with any control, if we
really are going to make the interface robust and generic.

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.

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

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

Diagramatically:

------------------------------------------------
|                                              |            
|    Anjuta                                    |
|                                              |
------------------------------------------------
          ||                      ||        ||
-----------------------        [Other components]
|                     |
| Document Manager    |
|                     |
-----------------------
       ||    ||
       ||    ||
- - - - - - - - - - - -
|                     |
|   Anjuta Document   |
|                     |
- - - - - - - - - - - - 
|   |   |   |   |   |
|   |   |   |   |   |
--- --- --- --- --- ---
|*| |*| |*| |*| |*| |*|
--- --- --- --- --- ---
[ Editing controls ]


If you observe the above diagram, you will notice that, the
DocumentManger never accesses the editing controls directly. In fact, it
doesn't even know with which control it will be dealing with (or better
still, it doesn't even know that it is dealing with an external
control).

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.

------------

> setFile() - This should be handled by Bonobo::PersistStream and
> Bonobo::PersistFile, the standard interfaces for loading data into
> bonobo controls.
> 
> gotoLine() - We do this in scintilla by having a current_line property
> that can be retrieved or set.
> 
> getHandlerControl(), getHandlerInterface() - The document editor
> should implement Bonobo::Control directly, and use queryInterface() to
> get different interrfaces.
These generic interfaces should exist in the 'generic editing controls'
and AnjutaDocument isn't a generic control. It's a virtual control that
would be wrapping the real editing controls.

These interfaces are for Anjuta and not for a FooBar application. These
interfaces reduce the burden from the DocumentManager, trying to adapt
to different editing controls.

-------------

Now, what we discussed in the IRC (and what you were supposed to be
looking for) is a totally different bird. The name of that bird is
AnjutaEditor (not AnjutaDocument). And it can be found at
components/document-handlers/anjuta-editor/.

This control is just like any other editing control, including the
scintilla-control in the gdl. It has (or will have) all the generic
interfaces such as Bonobo::PersistFile and Bonobo::PersistStream. In
addition to these generic interfaces, it will also have some high level
interfaces to work with anjuta (other applications may or may not wish
to use those interfaces). It will also have Property bag to manupulate
query/manupulate the control.

I am not saying that this control is ready. In fact, the .idl is not
even written (that is perhaps why you didn't find it). But the widget is
ready (although not compilable). I will just have to spend some to time
to clean up the things.

> So I'd like to use the GDL editor, and port some of the features from
> anjuta2-old to that editor.  Since they both use scintilla, that
> should be easy (easier than trying to port the anjuta2-old editor
> component to use standard bonobo interfaces, I think).
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.

Let me investigate the various options available to make the upgrade
more comfortable. I think I should be able to manage that. Also, I will
make sure that the earlier interfaces are not broken, so that we don't
have to do bunch of modifications in other parts of the program.

--
Regards,
-Naba

PS: The mail is a bit long and I have also taken the liberty to 
posted it in the mailing list, so that we could discuss it together.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com