I'm attaching here two different patches I prepared last year about call tips.
In this way my work will not be lost.

I'm also attaching the body of three mail I sent/received from Gustavo about the
first patch.

Mails follow:

===============================================

Jan 29, 2004.
From Paolo to Gustavo:

Yesterday I implemented calltips. I have a proof-of-concepts
implementation, but I'm not sure about the API.
ATM, the API looks like:

void   gtk_source_view_show_call_tip (GtkSourceView   *view,
                                       GtkTextIter     *iter,
                                       const gchar     *desc,
                                       guint            start_hl,
                                       guint            end_hl);

void   gtk_source_view_highlight_call_tip_region
                                      (GtkSourceView   *view,
                                       guint            start_hl,
                                       guint            end_hl);

void   gtk_source_view_cancel_call_tip  
                                     (GtkSourceView   *view);

gboolean gtk_source_view_has_active_call_tip (GtkSourceView   *view);

It is very similar to the one provided by scintilla.
I don't like it too much and I was thinking to change it by creating a
GtkSourceCallTip class:

GtkWidget *gtk_source_call_tip_new (GtkSourceView *view);

/* Properties to set desc, highlighted region and location (i.e. a
GtkTextIter) */
/* Add a construct only (?) view properties too */

What do you think?

======================================

Jan 31, 2004
From Gustavo to Paolo

> What do you think?

A class would be overkill IMO.  Unless there are some specific needs of
extending its functionality (which is a requirement I don't see).  I
like the API you outlined above.

======================================

Feb 06, 2004
From Paolo to Gustavo

Hi Gustavo,
        attached to this mail you can find a first version of my call tips
patch.
It implements the interface I described to you in a previous mail.
Please, give a look at it and lemme know what do you think.
To test it put the cursor at col 10 to show the call tip and then move
the cursor to col 15 to change the hl region and to col 20 to cancel the
call tip.
I'm not very happy with the current implementation for a few reasons:
1. I'm not sure if the call tip position algo I have chosen is the best
one.
2. The call tip should be automatically canceled when the top level
window is resized or moved, when the view scrolls horizontally, when the
user uses a keyboard command (ex. Up, Down, Home, PageUp, etc.) that is
not compatible with editing the argument list of a function (see also
the FIXME in calltip_event_handler)
3. To change the highlighted region I have to first hide and then show
the call tip (any idea on how to avoid this hack?)

Point 2 is somewhat complex to solve since:
1. I don't know how to implement it in a sane way
2. I don't know how to define the list of keyword commands that should
automatically cancel the call tip.

Summarizing: I think current implementation still needs some love before
being committed, but I need some help to solve some of its problems.

Ciao,
Paolo

======================================

Feb 15, 2004
From Gustavo to Paolo

Hey Paolo,

On Fri, 2004-02-06 at 11:43, Paolo Maggi wrote:
> Hi Gustavo,
>       attached to this mail you can find a first version of my call tips
> patch.
> It implements the interface I described to you in a previous mail.
> Please, give a look at it and lemme know what do you think.
> To test it put the cursor at col 10 to show the call tip and then move
> the cursor to col 15 to change the hl region and to col 20 to cancel the
> call tip.
> I'm not very happy with the current implementation for a few reasons:
> 1. I'm not sure if the call tip position algo I have chosen is the best
> one.

What's the problem with it?

> 2. The call tip should be automatically canceled when the top level
> window is resized or moved, when the view scrolls horizontally, when the
> user uses a keyboard command (ex. Up, Down, Home, PageUp, etc.) that is
> not compatible with editing the argument list of a function (see also
> the FIXME in calltip_event_handler)

Yeah, this is a problem cause you can easily get a misplaced calltip.

Tracking window resize/move implies connecting to the view's toplevel
widget (gtk_widget_get_toplevel) "configure_event" signal.  Caveat: you
also need to connect to the view's "hierarchy_changed" just in case the
user reparents the widget.

As for scrolling, you need to connect to the view's adjustment widgets
"value_changed" signal.  You can get those from the GtkTextView struct. 
Caveat: you need to connect to "set_scroll_adjustments" text_view signal
to track changes to the adjustment widgets.

Besides that, I don't think the calltip should disappear when you scroll
the view without moving the cursor itself, unless of course the cursor
goes out of view.  I'd rather move the calltip to follow the buffer
spot.  Also, maybe Up & Down shouldn't remove it since you can have a
multiple line argument list.

> 3. To change the highlighted region I have to first hide and then show
> the call tip (any idea on how to avoid this hack?)

I fixed that in the attached patch (the patch is from HEAD).  I'm not
entirely sure what was it, but the configure event is received *after*
an initial expose to the window and thus the box is drawn using the old
window dimensions.

> Point 2 is somewhat complex to solve since:
> 1. I don't know how to implement it in a sane way
> 2. I don't know how to define the list of keyword commands that should
> automatically cancel the call tip.
> 
> Summarizing: I think current implementation still needs some love before
> being committed, but I need some help to solve some of its problems.

Ok, another thing I found out is that there's no way to unhighlight a
portion of the text.  That's fixed in the patch I'm sending you.  One 
thing not fixed in the patch, but which needs to be, is that the calltip
window is not being destroyed ever, thus leaked.

Having actually seen the implementation, I understand now your desire to
make it a separate class.  So, on second thoughts, it does make sense.

It makes even more sense if we are to implement support for overloaded
functions, as BenM was asking today in IRC.  About that, do you have any
ideas on what would the API look like?

One last thing/request: make the border around the label theme
configurable.  I.e. don't use border_width.  Probably you want to use
the style's thickness.

(Heh, this calltip stuff turns out to be much more complicated than I
had thought)

Hope this helps,
Gustavo


> 
> Ciao,
> Paolo
> 
>