Re: [evolution-patches] Patch for GtkHTML and Composer, take two



On Thu, 2003-09-11 at 19:01 -0400, Ettore Perazzoli wrote:

> It causes the composer to completely remove the GtkHTML toolbar / menu
> items when the focus is not in the editor widget, and the effect is a
> bit disturbing:

Yup.  The code in gtkhtml and the composer simply removes its items when
things get focused/unfocused.

> It's also a bit confusing that you do have cut/copy/paste keybinding
> when you are in the to/cc/bcc/subject entries, but the corresponding
> icons are only available if the focus is in the HTML.

That should just be a matter of putting toolbar items in
evolution-composer-entries.xml.

> Ideally we would want the following:
> 
>       * No items disappear at any given time.
> 
>       * The items that only work for the HTML text (e.g. "insert table",
>         "insert link", "font size" etc.) are made insensitive when the
>         focus is in the to/cc/bcc/subject entries, and made sensitive
>         when the focus is in the HTML part.  (Of course if HTML is
>         disabled they should be insensitive at all times.)

This should be easy to do.  Just merge in all the items as soon as the
controls are created, and sensitize/desensitize them in the activate
callback --- instead of merging/demerging them there.

>       * The items that should work for both the HTML text and the
>         entries ("cut", "copy", "paste", "select all" etc.) should be
>         sensitive both when the focus is in the HTML and when it's in
>         the entries.  But then, they should dispatch the command where
>         it's supposed to go, i.e. to the widget that has the focus... 
>         (Maybe this can only be done by making to/cc/bcc having their
>         own cut/copy/paste items.)

I don't know what BonoboUI does if you try to merge in conflicting
items.  If it has the same semantics as EggMenu, it should just just
make the last-merged ones win.

In any case, those items are already split out from the rest of the
commands and they can be merged/demerged easily.

>       * The items that don't really need a cursor to operate should be
>         available and sensitive at all times; e.g. "Find" and "Replace"
>         would probably be a bit annoying if they were insensitive when
>         the focus is not in the main text.

Ah, but wouldn't you expect them to Find/Replace on the focused entry?
:)  I have no idea.

> I think we should revert the parts of this patch that have already been
> committed to CVS, and restore the previous behavior until we come up
> with something that is closer to correct.
> 
> (It's a bit sad that Bonobo makes this all so complicated; we should
> probably make sure that the new menu merging code in GTK 2.4 doesn't
> repeat the same mistakes...)

If merging conflicting items doesn't do the right thing, it should be
easy to fix BonoboUI to do it properly.  That's the only Bonobo-side bug
now as far as I'm concerned.

I don't mean to sound harsh, but I really don't want to spend any more
time on this right now :)  But please feel free to ask me about other
focus/activation issues.  It is the merging code that I don't know well.

  Federico




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]