Gtk version getting closer

Gtk version getting closer

[Jan D.]

Hello.

I am getting closer to getting a Gtk version done.  I estimate I can
check in something useful in a week or two.

I have some questions about how to proceed.

Shall the code be reviewed by this list or any individual before
a possible checkin?

Does this go in a separate branch (how do you "branch" new files) or
directly to CVS latest?  It should not have any impact on current
toolkits, but perhaps better safe than sorry?

Which version of autoconf is the recommended?  Does that version have
builtin tests for Gtk?  If not, is it OK to add a aclocal.m4 file
with those tests?  I think there was such a file previously, but it
is now gone.

I would like to finish dialogs and a scrolling problem (repeat doesn't
work, some bad interaction with Gtk and Emacs timers) before I start
to merge it into CVS latest.  I am currently working off a CVS from
the middle of June.  If I got the time, I will rewrite the
file dialog from Gtk and hopefully it will be accepted into Gtk proper.
If not, I plan to just put it in Emacs (the Gtk file dialog crashes
Emacs if the current directory contains a Latin-1, or rather non-UTF8,
character).

This port tries to reuse as much as it can of current X code, so
it is very dependent on X.  For example, all drawing is done with
standard X calls.  The event loop is mostly unmodified (split into
two functions, but no major code changes).
This makes this a bit of a bastard when it comes to X resources.
For example, geometry is taken from X resources, but fonts and
colours for Gtk widgets must be specified in the Gtk way (~/.gtkrc-2.0).

The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 
I haven't decided if I will try to change that, the advantage would
be the possibility to have a detachable toolbar.  There are detachable
menus already, except detaching popup menus does not work, I don't
know why yet.  Menus could be optimized, it currently rebuilds the
whole tree when menus change, this is not optimal.

I am also not sure if I will do tooltips in menus, I find that to be a bit
of a strange user interface solution.  Mac OSX does not have them
for example.

There are probably tons of bugs, but the more that can run this, the
faster they will be found.  Also, I wan't to get this in such a
shape I can start doing all the other things I have on my TODO list :-)

Thanks,

	Jan D.

Re: Gtk version getting closer

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> Hello.
> 
> I am getting closer to getting a Gtk version done.  I estimate I can
> check in something useful in a week or two.

This is good news.

> Does this go in a separate branch (how do you "branch" new files) or
> directly to CVS latest?  It should not have any impact on current
> toolkits, but perhaps better safe than sorry?

Personally, I would prefer if we could release 21.3, make a new branch 
for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
it will be called at that time)...

> There are probably tons of bugs, but the more that can run this, the
> faster they will be found. 

And the more we will delay releasing 21.4 unless we do at I propose
above...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Gtk version getting closer

[jasonr]

> Personally, I would prefer if we could release 21.3, make a new branch 
> for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
> it will be called at that time)...

I don't think we want to make MORE branches. If it is not judged safe
enough to go in 21.4, then it should go straight into the unicode branch IMO. 
We clearly don't have enough resources to keep two new feature branches
and one maintenance branch going at once. I think it is better to
concentrate our non-bugfixing efforts on the unicode branch after
21.4 is released if we want to see it released this decade.

Re: Gtk version getting closer

[Juanma Barranquero]

On Fri, 8 Nov 2002 09:21:03 +0000 (GMT), jasonr@btinternet.com wrote:

> > Personally, I would prefer if we could release 21.3, make a new branch 
> > for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
> > it will be called at that time)...
> 
> I don't think we want to make MORE branches.

I think Kim meant to:

 - release 21.3, and abandon the EMACS_21_1_RC branch forever
 - branch a new EMACS_21_4_RC for the next release
 - apply the Gtk patch to the trunk

so there would be only two "branches" of development, as there are now:
one for the next release, and another one for development.


                                                           /L/e/k/t/u

Re: Gtk version getting closer

[Juanma Barranquero]

On 08 Nov 2002 12:25:19 +0100, storm@cua.dk (Kim F. Storm) wrote:

> I think the unicode branch should be merged to the trunk (shortly)
> after making the 21.4 RC branch -- meaning ONE LESS branch for
> development!

So all succesive releases from the 21_4_RC branch would be only bug
fixes, and the next "features" release, from the trunk, would be 22.1,
you mean?

Neat.

                                                           /L/e/k/t/u

Re: Gtk version getting closer

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> On Fri, 8 Nov 2002 09:21:03 +0000 (GMT), jasonr@btinternet.com wrote:
> 
> > > Personally, I would prefer if we could release 21.3, make a new branch 
> > > for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
> > > it will be called at that time)...
> > 
> > I don't think we want to make MORE branches.
> 
> I think Kim meant to:
> 
>  - release 21.3, and abandon the EMACS_21_1_RC branch forever
>  - branch a new EMACS_21_4_RC for the next release
>  - apply the Gtk patch to the trunk
> 
> so there would be only two "branches" of development, as there are now:
> one for the next release, and another one for development.

Exactly!  The EMACS_21_4_RC branch would be for bug fix releases to 21.4 only.

I think the unicode branch should be merged to the trunk (shortly)
after making the 21.4 RC branch -- meaning ONE LESS branch for
development!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Gtk version getting closer

[Richard Stallman]

    Shall the code be reviewed by this list or any individual before
    a possible checkin?

Please send the patches here so everyone can look.

    Does this go in a separate branch (how do you "branch" new files) or
    directly to CVS latest?

We could do it either way.  If you have tested building with another
toolkit, and it still works, then I don't see a need for a branch.
However, if you want to make it a branch, I don't think that is
horrible.

    Which version of autoconf is the recommended?  Does that version have
    builtin tests for Gtk?

I don't think we need one.  We don't want to make Gtk the default
at this stage.

    The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 

That is ok for now.

    I am also not sure if I will do tooltips in menus, I find that to be a bit
    of a strange user interface solution.

I think they are important.

Re: Gtk version getting closer

[Jan D.]

> 
>     Shall the code be reviewed by this list or any individual before
>     a possible checkin?
> 
> Please send the patches here so everyone can look.

I will do that shortly, probably within a week.

> 
>     Does this go in a separate branch (how do you "branch" new files) or
>     directly to CVS latest?
> 
> We could do it either way.  If you have tested building with another
> toolkit, and it still works, then I don't see a need for a branch.
> However, if you want to make it a branch, I don't think that is
> horrible.

I would rather not make a branch.  I will make sure all other toolkits
on Unix works.

>     Which version of autoconf is the recommended?  Does that version have
>     builtin tests for Gtk?
> 
> I don't think we need one.  We don't want to make Gtk the default
> at this stage.

I was thinking of the code that autoconf needs to detect the path to Gtk
and that the version of Gtk is correct, in case the user specified --with-gtk
to configure.  If we are using an autoconf that doesn't have this built in,
I need to create an aclocal.m4 with that code.  Since I know there was such
a file previously but now is removed, I would like to know if it is okay
to create one again.  I don't know the reason why it was removed.  It can
be as easy as it was redundant, but there might be some other reason.

> 
>     The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 
> 
> That is ok for now.

A Gtk toolbar can be added later on I guess.  I think Gtk/Gnome users
expect the toolbar to pick up their Gtk theme, so I will raise the
priority for this.  I don't use the toolbar, so it is not important for
me.

> 
>     I am also not sure if I will do tooltips in menus, I find that to be a bit
>     of a strange user interface solution.
> 
> I think they are important.

For the toolbar I agree.  Icons can mean many things, so a tooltip helps.
For menus, however, the text in the menu should be enough or expanded
so the tip is not needed.  I'll see what I can do, but they might not make
it into the first patch.  A cutomize variable to turn tooltips off just
in menus is something I would like to add later on.

	Jan D.

Re: Gtk version getting closer

[Jan D.]

> 
> Exactly!  The EMACS_21_4_RC branch would be for bug fix releases to 21.4 only.
> 
> I think the unicode branch should be merged to the trunk (shortly)
> after making the 21.4 RC branch -- meaning ONE LESS branch for
> development!

If this is the way to do it, then the 21.4 RC branch should start very soon
I think.  Gtk would then go into 21.5 and the unicode trunk I guess?

	Jan D.

Re: Gtk version getting closer

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

>     I am also not sure if I will do tooltips in menus, I find that to be a bit
>     of a strange user interface solution.
>
> I think they are important.

Yes, but current behavior is a little bit disturbing.  Often you can
"right-click" (= mouse-3 resp. mouse-2 in Emacs) on some such entities
like menu entries to couse a context menu with a help entry to appear.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Gtk version getting closer

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 08 Nov 2002 01:08:43 +0100
> 
> > There are probably tons of bugs, but the more that can run this, the
> > faster they will be found. 
> 
> And the more we will delay releasing 21.4 unless we do at I propose
> above...

If the Gtk version is not built by default and if it doesn't screw
other toolkits, we don't need to be afraid of that.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Thu, 7 Nov 2002 20:39:07 +0100 (CET)
> 
> This port tries to reuse as much as it can of current X code, so
> it is very dependent on X.  For example, all drawing is done with
> standard X calls.  The event loop is mostly unmodified (split into
> two functions, but no major code changes).

Does this mean the code won't work with the Windows port of Gtk?

Re: Gtk version getting closer

[Jan D.]

> 
> > From: "Jan D." <jan.h.d@swipnet.se>
> > Date: Thu, 7 Nov 2002 20:39:07 +0100 (CET)
> > 
> > This port tries to reuse as much as it can of current X code, so
> > it is very dependent on X.  For example, all drawing is done with
> > standard X calls.  The event loop is mostly unmodified (split into
> > two functions, but no major code changes).
> 
> Does this mean the code won't work with the Windows port of Gtk?

I assume it does not work with MS Windows.  X specific calls in Gtk
are used, as well as a lot of X calls in the ordinary Emacs code for X.

The goal has been to reuse as much code unchanged as possible (see
http://mail.gnu.org/pipermail/emacs-devel/2001-December/004383.html).

Since I don't do MS Windows I don't know what effort would
be required to make it work.  If one used only Gtk code instead of
Xlib I assume it would run on MS Windows as well.  This is what I
started to do, but then changed to the current X specific approach.

	Jan D.

Re: Gtk version getting closer

[Richard Stallman]

    Yes, but current behavior is a little bit disturbing.

Could you explain what is disturbing about it?  Then I can
think about the issue.

							   Often you can
    "right-click" (= mouse-3 resp. mouse-2 in Emacs) on some such entities
    like menu entries to couse a context menu with a help entry to appear.

You can often do this in Emacs, or you can often do this in other
programs?

Re: Gtk version getting closer

[Richard Stallman]

    I was thinking of the code that autoconf needs to detect the path to Gtk
    and that the version of Gtk is correct, in case the user specified --with-gtk
    to configure.  If we are using an autoconf that doesn't have this built in,
    I need to create an aclocal.m4 with that code.

There is no need for an aclocal.m4.  You can put the code directly
into configure.in.  That is how we handle other such issues.

    >     The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 
    > 
    > That is ok for now.

    A Gtk toolbar can be added later on I guess.  I think Gtk/Gnome users
    expect the toolbar to pick up their Gtk theme, so I will raise the
    priority for this.

Yes, we definitely want to have it, but we could make a first release
without it.

    For menus, however, the text in the menu should be enough or expanded
    so the tip is not needed.  I'll see what I can do, but they might not make
    it into the first patch.  A cutomize variable to turn tooltips off just
    in menus is something I would like to add later on.

If Emacs supports tooltips in menus for other toolkits, that should
work with GTK too if possible.

Re: Gtk version getting closer

[Richard Stallman]

    > Does this mean the code won't work with the Windows port of Gtk?

    I assume it does not work with MS Windows.  X specific calls in Gtk
    are used, as well as a lot of X calls in the ordinary Emacs code for X.

    The goal has been to reuse as much code unchanged as possible (see
    http://mail.gnu.org/pipermail/emacs-devel/2001-December/004383.html).

    Since I don't do MS Windows I don't know what effort would
    be required to make it work.  If one used only Gtk code instead of
    Xlib I assume it would run on MS Windows as well.  This is what I
    started to do, but then changed to the current X specific approach.

I think that is an ok approach.

Re: Gtk version getting closer

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> Could you explain what is disturbing about it?  Then I can
> think about the issue.

Tooltips are poping up and hiding other info.  As somebody else
explained, for menu entries tooltips are not that important, because
menu texts are better to understand than tool bar icons.

Yes, one can get used to the tooltips and their texts are often very
good; nevertheless having an option to disable menu entry tooltips
separately would be nice.

> 							   Often you can
>     "right-click" (= mouse-3 resp. mouse-2 in Emacs) on some such entities
>     like menu entries to couse a context menu with a help entry to appear.
>
> You can often do this in Emacs, or you can often do this in other
> programs?

I know you can often call a context menu in Emacs, but it's impossible
to jump from a menu entry directly to the manual where this menu entry
will be explained.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Gtk version getting closer

[Eli Zaretskii]

On Mon, 11 Nov 2002, Karl Eichwalder wrote:

> As somebody else
> explained, for menu entries tooltips are not that important, because
> menu texts are better to understand than tool bar icons.

Where the menu item's text is self-explanatory, there usually is no 
tooltip that pops up.  In other words, tooltips for menu items should be 
defined only where they are really needed.

> I know you can often call a context menu in Emacs, but it's impossible
> to jump from a menu entry directly to the manual where this menu entry
> will be explained.

You should be able to do a "C-h k", then click the menu item and get its 
explanation.  Another C-h function jumps to the manual for a description 
of any key, but the problem in using this with menu items is that menu 
items are generally not described at all in the manual.  So this is a 
documentation problem rather than a functionality problem; if someone 
writes an appendix for the manual with the description of all the menu 
items, it would be instantly available for the purpose you want it.

Re: Gtk version getting closer

[Karl Eichwalder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Where the menu item's text is self-explanatory, there usually is no 
> tooltip that pops up.  In other words, tooltips for menu items should be 
> defined only where they are really needed.

That's even worth ;)  If you want to sell a product consistency is an
important issue.  The ideal goal should be: all or nothing.  If
tooltips appear only now and then, the user might think there is
something broken.

> You should be able to do a "C-h k", then click the menu item and get its 
> explanation.

Sure, that's a good way for the advanced user (to be more precise: for
the keyboard user).  You are not going to convince the mouse user he
wants to learn those key combos ;-)

> Another C-h function jumps to the manual for a description of any key,
> but the problem in using this with menu items is that menu items are
> generally not described at all in the manual.  So this is a
> documentation problem rather than a functionality problem;

Yes and no.  For the moment it would be good enough if Emacs would jump
to the documentation of the function; just print a message want you
intend to do.

> if someone writes an appendix for the manual with the description of
> all the menu items, it would be instantly available for the purpose
> you want it.

Sounds useful.  Maybe, I can spend some time on it next year.  Is it
okay to write it in German and to wait for someone to translate it?  Or
shall I try it in English and hope for corrections?

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Gtk version getting closer

[Jan D.]

> Where the menu item's text is self-explanatory, there usually is no 
> tooltip that pops up.  In other words, tooltips for menu items should be 
> defined only where they are really needed.
> 

This isn't always the case.  Maybe the help texts should be
reviewed and expanded/removed as a result?  For example,
in Options we have:
  "Save Place in Files between Sessions"

The tooltip for that is "Save Emacs state for next session".
I think that the menu entry is much clearer hear, the tip is confusing.

Much of the tips doesn't add anything IMHO.  If a user has used any
other GUI-based application, things such as "Open File", "Insert File",
"Save As" does not need any tip.

Sometimes the tips uses a different concept than the menu item.  In
the Tools -> PCL-CVS submenu, we have "Examine Directory".  The tip
says "Examine the current state of a workarea".  Directory is
understandable, but what is workarea?  If it is the same as directory,
why not use directory?  The PCL-CVS submenu itself can be made clearer
by renaming it to "CVS operations" or something like that.

Also, there is the problem with inconsistency.  Some menu items have
tips, other doesn't as pointed out elsewhere.  I do agree with the
view that the user might think something is broken when no tips
appear for some things.  For submenus there are no tips.  The PCL-CVS
entry could use one, since PCL-CVS is kind of cryptic.  But of course
I'd prefer PCL-CVS to be renamed in the menu instead.

The tips appear in the wrong places (i.e. under the pointer)
sometimes.  I don't have a Lucid version available, but in the Motif and
Gtk version you can click and release on a menubar item to make the menu
appear.  Then you can navigate the menus with arrow keys.  The
tip displayed is for the menu item marked with the arrow keys, but
the tip appears where the pointer is.  The pointer can be on the other side
of the screen, so this looks funny.

I do think tips can have a negative effect on menu item strings.  It is
too easy to make a menu with cryptic strings and then fully explain the
items in the tip instead.  This forces the user to select the menu item
and then wait for the tip to appear for the full explanation.  If tips
did not exist, more thought would be going into selecting good
menu item strings.

I really would like to see tips for menus removed, but a customize
item to turn them off for menus is okay too.

	Jan D.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Tue, 12 Nov 2002 08:24:23 +0100
> 
> If you want to sell a product consistency is an
> important issue.  The ideal goal should be: all or nothing.  If
> tooltips appear only now and then, the user might think there is
> something broken.

I see the point, but I actually thought about this before and I
disagree.  I find it disgusting when a GUI program sticks into my face
a tooltip that doesn't add any useful information.  I think Emacs's
paradigm is better.

> > You should be able to do a "C-h k", then click the menu item and get its 
> > explanation.
> 
> Sure, that's a good way for the advanced user (to be more precise: for
> the keyboard user).  You are not going to convince the mouse user he
> wants to learn those key combos ;-)

Each of those C-h functions has a menubar equivalent; see the "Help"
menu and its submenus.

> For the moment it would be good enough if Emacs would jump
> to the documentation of the function; just print a message want you
> intend to do.

But that's just it: there _is_ no documentation for those functions,
only doc strings (and even those are sometimes absent, since some of
the menu items invoke lambda-expressions).

> Is it
> okay to write it in German and to wait for someone to translate it?  Or
> shall I try it in English and hope for corrections?

I think it's better to write English.  It's much easier for someone to
fix English than to translate from German.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Tue, 12 Nov 2002 13:34:06 +0100 (MET)
> 
> Maybe the help texts should be reviewed and expanded/removed as a
> result?

Yes, of course.

> Also, there is the problem with inconsistency.  Some menu items have
> tips, other doesn't as pointed out elsewhere.  I do agree with the
> view that the user might think something is broken when no tips
> appear for some things.  For submenus there are no tips.

I think most of the problems are with menus defined by packages
outside menu-bar.el.  In particular, packages maintained by their own
maintainers.  I do agree that consistency is important (provided that
we agree about what should tooltips in menus do ;-).

> I do think tips can have a negative effect on menu item strings.  It is
> too easy to make a menu with cryptic strings and then fully explain the
> items in the tip instead.

The main reason for tooltips in menus is that menu items are usually
limited in length.  Tooltips can be longer, especially since the font
used for them is (or should be) smaller.

Re: Gtk version getting closer

[Miles Bader]

Karl Eichwalder <keichwa@gmx.net> writes:
> > Where the menu item's text is self-explanatory, there usually is no
> > tooltip that pops up.  In other words, tooltips for menu items
> > should be defined only where they are really needed.
> 
> That's even worth ;)  If you want to sell a product consistency is an
> important issue.  The ideal goal should be: all or nothing.  If
> tooltips appear only now and then, the user might think there is
> something broken.

Tooltips in Gnome (at least on my system!) are often `consistent' to the
point of stupidity:  in many cases a tooltip is popped up with _exactly_
the same text as the menu item or for icons, the same text repeated
_twice_ in the tooltip (presumably one line is the `label' and the other
is the `description')!  This not only seems odd, it seems broken.
Clearly in many cases it's really the fault of the application or the
user that added an icon or whatever without a good description -- but
that's the real world, such things exist.

Perhaps it would be better to could pop up a tooltip that says
`This tooltip intentionally left blank'...

The way I use tooltips is to pause over something and wait to see if
something pops up; if nothing does, I just think `oh there's no tooltip
for that.'  Maybe I'm wierd, but since I gained this habit by using
non-emacs programs (emacs being a relative newcomer to using tooltips), I
think there must be something to it.

[Indeed, it would seem that Gnome's insistence on `consistency' in this
case may actually be damaging, by actually _causing_ people to think that
`everything must have a tooltip']

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Gtk version getting closer

[Eli Zaretskii]

On 13 Nov 2002, Miles Bader wrote:

> The way I use tooltips is to pause over something and wait to see if
> something pops up; if nothing does, I just think `oh there's no tooltip
> for that.'

Same here.  For me, no tooltip means there's nothing else to be said 
about that particular widget except what its appearance and text already 
say.

Re: Gtk version getting closer

[Jan D.]

> > I do think tips can have a negative effect on menu item strings.  It is
> > too easy to make a menu with cryptic strings and then fully explain the
> > items in the tip instead.
> 
> The main reason for tooltips in menus is that menu items are usually
> limited in length.  Tooltips can be longer, especially since the font
> used for them is (or should be) smaller.

If one sets a default font for everything in .Xdefaults, or use
for example CDE, KDE (and perhaps Gnome) tools for setting style,
the tooltip will pick up that default font.  That usually makes the
tooltip font larger than the menu font.  I see this all the time
with various OS:es and users.  I don't think any assumption about font
should be made at all when writing menu strings or tooltip strings.

There is nothing "wrong" with a long menu string.  After all, it only
pops up when the menu is selected and does not take screen space otherwise.
And when the menu is selected, it is the focus of attention, so it can
take up as much space it needs.  In the Option menu, many menu strings
are longer than their tip.  And in many cases, the tip would have
made a better menu string, IMHO (for example Syntax Highlightning).

The alternative is to have a long tooltip.  Then one has to wait for
the tooltip to appear, shift focus of attention to the tooltip (which
may be on the other side of the screen), and then shift attention back
to the menu.

All this move of attention is what makes an UI seem strange.  True, the same
happens with the toolbar, so ideally, it should have (the option to have)
text under the icons.

	Jan D.

Re: Gtk version getting closer

[Richard Stallman]

    Tooltips are poping up and hiding other info.  As somebody else
    explained, for menu entries tooltips are not that important, because
    menu texts are better to understand than tool bar icons.

Sometimes they are important, for beginners.  Any time a menu item has
tooltip text, it was added explicitly so the menu item would have it.
I can recall a case in the menu bar where the discussion of what menu
item text to use was based on the idea of having a tooltip to go with
it.

I think the right way to address this problem is with an option to
turn off the menu tooltips.  Non-beginners might want to set that
option.

Re: Gtk version getting closer

[Robert J. Chassell]

   On 13 Nov 2002, Miles Bader wrote:

   > The way I use tooltips is to pause over something and wait to see if
   > something pops up; if nothing does, I just think `oh there's no tooltip
   > for that.'

That makes sense.

The problem is not with experts, but with people just learning.  Such
people think that Emacs is broken when they don't see a tooltip.

For example, all the menu items in the `File' and `Edit' menus have
tooltips, but there is no tooltip for the `Expand Aliases' menu item
in the Mail mode menu.  (I myself just discovered this -- I normally
don't look at tooltips.)

The lack of an `Expand Aliases' menu item tool tip will hurt some
people, such as those who don't yet understand address aliases or are
confused by them.

The problem here is that it takes great talent both to be an expert
and to write tips that help a novice.  And to have interest in the
problem.

Perhaps someone from the Emacspeak contingent could and will help?
Emacspeak is intended not only for knowledgeable and determined geeks,
but also for ordinary people who cannot look at a screen.  (Do the
blind use a keyboard-only variation on the menus for sighted people,
such as that provided by `tmm-menubar'?)

Otherwise, I fear that Emacs will remain less well used than it should
be, and continue to possess a false, off-putting reputation.

--
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Jan D.]

> 
> The problem is not with experts, but with people just learning.  Such
> people think that Emacs is broken when they don't see a tooltip.
> 

IMHO, people that are new and use "common" applications will be
surprised by tooltips in menus.  Not a lot of applications
have them.  I've never seen them on any Mac or MS Windows application.

	Jan D.

Re: Gtk version getting closer

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    On 13 Nov 2002, Miles Bader wrote:
> 
>    > The way I use tooltips is to pause over something and wait to see if
>    > something pops up; if nothing does, I just think `oh there's no tooltip
>    > for that.'
> 
> That makes sense.
> 
> The problem is not with experts, but with people just learning.  Such
> people think that Emacs is broken when they don't see a tooltip.
> 
> For example, all the menu items in the `File' and `Edit' menus have

Maybe we could have a "tree-state" customize option here:

- always show tooltips
  (generate a tooltip with the same text as the menu item if
   no explicit tooltip is specified)
- show available tooltips
  (the current functionality - show tooltips is available)
- no tooltips
  (never show tooltips for menu items).


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Gtk version getting closer

[Stefan Monnier]

> IMHO, people that are new and use "common" applications will be
> surprised by tooltips in menus.  Not a lot of applications
> have them.  I've never seen them on any Mac or MS Windows application.

Confusing users is bad.  But surprising them isn't.


	Stefan

Re: Gtk version getting closer

[Francesco Potorti`]

>   > The way I use tooltips is to pause over something and wait to see if
>   > something pops up; if nothing does, I just think `oh there's no tooltip
>   > for that.'

That's how it works on all systems I have ever seen.

>The problem is not with experts, but with people just learning.  Such
>people think that Emacs is broken when they don't see a tooltip.

When there is a row of buttons, one of which has a tooltip, I expect a
tooltip for every other button in the row.  You get the idea.

Re: Gtk version getting closer

[Jason Rumney]

"Jan D." <jan.h.d@swipnet.se> writes:

> For submenus there are no tips.  The PCL-CVS entry could use one,
> since PCL-CVS is kind of cryptic.

Submenus do have tips. PCL-CVS has the tip "Module-level interface to
CVS". But I think it depends on your toolkit as to whether Emacs
can show those tips or not. Xaw3D shows the tips. MS-Windows does
not. Apparently Motif does the same as MS-Windows (fails to notify
Emacs when a submenu is selected).

Re: Gtk version getting closer

[David Masterson]

>>>>> Karl Eichwalder writes:

> Richard Stallman <rms@gnu.org> writes:

>> Could you explain what is disturbing about it?  Then I can think
>> about the issue.

> Tooltips are poping up and hiding other info.  As somebody else
> explained, for menu entries tooltips are not that important, because
> menu texts are better to understand than tool bar icons.

If tooltips are active, they tend to pop up on their own.  This can be
disconcerting for menus, but perhaps that's because I'm slightly more
used to the MS-Windows approach.  In that case, tooltips for menus
only popup if you use the "What's this?" command (Shift-F1).  This
"What's this?" command can be applied to any widget on the screen (but
not every widget answers it).

Perhaps you want to think about this approach for menu tooltips?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jan D.]

> 
> > IMHO, people that are new and use "common" applications will be
> > surprised by tooltips in menus.  Not a lot of applications
> > have them.  I've never seen them on any Mac or MS Windows application.
> 
> Confusing users is bad.  But surprising them isn't.
> 

If it is a negative surprise, it is.  I don't know what this would be.
Anybody knows someone who can do a usability test on this? :-)

	Jan D.

Re: Gtk version getting closer

[Robert J. Chassell]

   > The problem is not with experts, but with people just learning.  

   Maybe we could have a "tree-state" customize option here:

   - always show tooltips
     (generate a tooltip with the same text as the menu item if
      no explicit tooltip is specified)
   - show available tooltips
     (the current functionality - show tooltips is available)
   - no tooltips
     (never show tooltips for menu items).

We definately should provide an option to turn tooltips on or off, but
no more.  Otherwise, I fear that no one will fill in the empty
tooltips; and tooltips with the same text as the menu item are
terrible, as Miles also said.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Stefan Monnier]

>    > The problem is not with experts, but with people just learning.  
> 
>    Maybe we could have a "tree-state" customize option here:
> 
>    - always show tooltips
>      (generate a tooltip with the same text as the menu item if
>       no explicit tooltip is specified)
>    - show available tooltips
>      (the current functionality - show tooltips is available)
>    - no tooltips
>      (never show tooltips for menu items).
> 
> We definately should provide an option to turn tooltips on or off, but
> no more.

Been there: tooltips-mode


	Stefan

Re: Gtk version getting closer

[David Masterson]

>>>>> Robert J Chassell writes:

> Maybe we could have a "tree-state" customize option here:

>    - always show tooltips
>      (generate a tooltip with the same text as the menu item if
>       no explicit tooltip is specified)
>    - show available tooltips
>      (the current functionality - show tooltips is available)
>    - no tooltips
>      (never show tooltips for menu items).

You missed one (the MS-Windows one):

- show a tooltip if requested
  (have a "What's this?" function that will show the tooltip, if any,
   for a selected widget like a menu entry)

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jan D.]

> > 
> >    Maybe we could have a "tree-state" customize option here:
> > 
> >    - always show tooltips
> >      (generate a tooltip with the same text as the menu item if
> >       no explicit tooltip is specified)
> >    - show available tooltips
> >      (the current functionality - show tooltips is available)
> >    - no tooltips
> >      (never show tooltips for menu items).
> > 
> > We definately should provide an option to turn tooltips on or off, but
> > no more.
> 
> Been there: tooltips-mode

Is it possible to disable tooltips for menus only with that now?  Can't
check out latest CVS, bootstrap failed.

	Jan D.

Re: Gtk version getting closer

[Richard Stallman]

    This isn't always the case.  Maybe the help texts should be
    reviewed and expanded/removed as a result?  For example,
    in Options we have:
      "Save Place in Files between Sessions"

    The tooltip for that is "Save Emacs state for next session".
    I think that the menu entry is much clearer hear, the tip is confusing.

I am surprised you think so.  I think they are both clear
and that they complement each other.

The same for the other items in that menu--they are useful.  This menu
shows why menu item tooltips need to work.

    The tips appear in the wrong places (i.e. under the pointer)
    sometimes.  I don't have a Lucid version available, but in the Motif and
    Gtk version you can click and release on a menubar item to make the menu
    appear.  Then you can navigate the menus with arrow keys.  The
    tip displayed is for the menu item marked with the arrow keys, but
    the tip appears where the pointer is.  The pointer can be on the other side
    of the screen, so this looks funny.

That is indeed a bug; it would be good to fix it.

Re: Gtk version getting closer

[Richard Stallman]

I agree with you on the issue of menu tooltips.

Re: Gtk version getting closer

[Richard Stallman]

    There is nothing "wrong" with a long menu string.

It makes the whole menu wider.  We have already made an effort to
reduce the width of these menus and we would be very reluctant to
install changes that make them even wider.

      And in many cases, the tip would have
    made a better menu string, IMHO (for example Syntax Highlightning).

We can certainly try to improve the text of both the menu items and
the tips.

Re: Gtk version getting closer

[Richard Stallman]

    The problem here is that it takes great talent both to be an expert
    and to write tips that help a novice.  And to have interest in the
    problem.

Would you like to work on improving them?  You have the sort of skills
that it needs.

Re: Gtk version getting closer

[Robert J. Chassell]

       The problem here is that it takes great talent both to be an expert
       and to write tips that help a novice.  And to have interest in the
       problem.

   Would you like to work on improving them?  You have the sort of skills
   that it needs.

I am not a good person for working on menu tips since I hardly ever
use menus.  Only the messages on this mailing list inspired me to look
into the menus in GNU Emacs.  The last time I used a menu system in an
editor application was in 1984, before I discovered Emacs.  I left
those menus behind as soon as I discovered the (undocumented)
keybindings.

The task deserves someone who has more experience with mice and menus
than I, and who is acquainted with contemporary novice users and
understands their mental model of an application.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Jan D.]

onsdagen den 13 november 2002 kl 17.55 skrev Jason Rumney:

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>> For submenus there are no tips.  The PCL-CVS entry could use one,
>> since PCL-CVS is kind of cryptic.
>
> Submenus do have tips. PCL-CVS has the tip "Module-level interface to
> CVS". But I think it depends on your toolkit as to whether Emacs
> can show those tips or not. Xaw3D shows the tips. MS-Windows does
> not. Apparently Motif does the same as MS-Windows (fails to notify
> Emacs when a submenu is selected).

Okay!  Thanks for the info, I missed that.  I'm sure such tips can
be shown in Gtk, at least it notifies when a submenu is choosen, so
the possibility is there.

	Jan D.

Re: Gtk version getting closer

[Jan D.]

onsdagen den 13 november 2002 kl 18.09 skrev David Masterson:

>>>>>> Karl Eichwalder writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>
>>> Could you explain what is disturbing about it?  Then I can think
>>> about the issue.
>
>> Tooltips are poping up and hiding other info.  As somebody else
>> explained, for menu entries tooltips are not that important, because
>> menu texts are better to understand than tool bar icons.
>
> If tooltips are active, they tend to pop up on their own.  This can be
> disconcerting for menus, but perhaps that's because I'm slightly more
> used to the MS-Windows approach.  In that case, tooltips for menus
> only popup if you use the "What's this?" command (Shift-F1).  This
> "What's this?" command can be applied to any widget on the screen (but
> not every widget answers it).
>
> Perhaps you want to think about this approach for menu tooltips?

This sounds good.  As pointed out, C-h k is (almost) Emacs version
of "What's this?".  Could C-h k be bent to show a tooltip when
invoked on a menu or toolbar item?

How does MS Windows handle the menu when doing this?  Do you first select
"What's this?" and then the menu item?  Or is it the menu item first and
"What's this?" afterwards?  If the first, is the menu still open when
the tooltip is shown?

	Jan D.

Re: Gtk version getting closer

[Jan D.]

>     This isn't always the case.  Maybe the help texts should be
>     reviewed and expanded/removed as a result?  For example,
>     in Options we have:
>       "Save Place in Files between Sessions"
>
>     The tooltip for that is "Save Emacs state for next session".
>     I think that the menu entry is much clearer hear, the tip is confusing.
>
> I am surprised you think so.  I think they are both clear
> and that they complement each other.

Well, this is just an example, but here are my reasoning.

The menu item has "between Sessions", implying this applies
    for all sessions to come.  The tip says "next Session", implying
    it is only for the next session.

The menu item has "Save Place in Files", the tip says "Save Emacs state".
    Neither is 100% correct, there is more that places saved, but
    less than the full Emacs state.  If this is for a beginner, I
    imagine (but could be wrong) that "Save Places" is easier to
    understand than "Save state", as stats can mean many things.

I think I would have written "Reopen files when Emacs is started".

> The same for the other items in that menu--they are useful.  This menu
> shows why menu item tooltips need to work.

I am not against tips, I just don't think showing them as today is
a good idea.  The "What's this?" approach seems workable.  Then we
could have even longer (multiline) tips.

>     The tips appear in the wrong places (i.e. under the pointer)
>     sometimes.  I don't have a Lucid version available, but in the Motif 
> and
>     Gtk version you can click and release on a menubar item to make the 
> menu
>     appear.  Then you can navigate the menus with arrow keys.  The
>     tip displayed is for the menu item marked with the arrow keys, but
>     the tip appears where the pointer is.  The pointer can be on the other 
> side
>     of the screen, so this looks funny.
>
> That is indeed a bug; it would be good to fix it.

It is not that easy to get the information about where the selected
menu item is on the screen, so I think this is hard to do.  I'll keep it
in mind when I start on Gtk menu tips.

	Jan D.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 13 Nov 2002 11:15:43 +0100 (CET)
> 
> If one sets a default font for everything in .Xdefaults, or use
> for example CDE, KDE (and perhaps Gnome) tools for setting style,
> the tooltip will pick up that default font.

I meant a decent setup, not the default.  I once proposed to make the
default font for the tooltips smaller than the one chosen for the
default face, but was told that there are problems to do that with X,
and I don't know enough about X to suggest a solution.

FWIW, my .emacs selects a much smaller font for tooltips.

> The alternative is to have a long tooltip.  Then one has to wait for
> the tooltip to appear, shift focus of attention to the tooltip (which
> may be on the other side of the screen), and then shift attention back
> to the menu.

That's how tooltips work on all GUI platforms I've seen; Emacs just
tries to be compatible here.  (Of course, you have variables to
customize the time delay for pop-up and pop-down, if the defaults
annoy you.)

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 13 Nov 2002 16:38:11 +0100 (MET)
> 
> I've never seen [tooltips for menus] on any Mac or MS Windows
> application.

Really?  Please click on any menu-bar item in the Internet Explorer,
then move the mouse pointer across the menu that drops down, and watch
the bottom of the IE display, the area we call ``echo area''.

Re: Gtk version getting closer

[Jan D.]

torsdagen den 14 november 2002 kl 19.57 skrev Eli Zaretskii:

>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Wed, 13 Nov 2002 16:38:11 +0100 (MET)
>>
>> I've never seen [tooltips for menus] on any Mac or MS Windows
>> application.
>
> Really?  Please click on any menu-bar item in the Internet Explorer,
> then move the mouse pointer across the menu that drops down, and watch
> the bottom of the IE display, the area we call ``echo area''.

I don't think that qualifies as a tooltip.  I suppose you mean what also is
called "status bar" or "status area", I have not run Internet Explorer.
But to be more specific, I mean menus that pop up windows with text
near the pointer when a menu item is selected.

	Jan D.

Re: Gtk version getting closer

[Jan D.]

>> If one sets a default font for everything in .Xdefaults, or use
>> for example CDE, KDE (and perhaps Gnome) tools for setting style,
>> the tooltip will pick up that default font.
>
> I meant a decent setup, not the default.  I once proposed to make the
> default font for the tooltips smaller than the one chosen for the
> default face, but was told that there are problems to do that with X,
> and I don't know enough about X to suggest a solution.
>
> FWIW, my .emacs selects a much smaller font for tooltips.

Yes, but you must be considered a power user.  Most users seem to just
use the tools available in the GUI to select fonts and colours.


>> The alternative is to have a long tooltip.  Then one has to wait for
>> the tooltip to appear, shift focus of attention to the tooltip (which
>> may be on the other side of the screen), and then shift attention back
>> to the menu.
>
> That's how tooltips work on all GUI platforms I've seen; Emacs just
> tries to be compatible here.  (Of course, you have variables to
> customize the time delay for pop-up and pop-down, if the defaults
> annoy you.)

I still believe that this is not how tooltips for menus work on the
majority of GUI platforms.  Most GUI platforms does not have
tooltips for menus at all.  But I think the "What's this?" approach
explained elsewhere is better.

	Jan D.

Re: Gtk version getting closer

[David Masterson]

>>>>> Jan D writes:

> onsdagen den 13 november 2002 kl 18.09 skrev David Masterson:

>>>>>>> Karl Eichwalder writes:

>>> Richard Stallman <rms@gnu.org> writes:

>>>> Could you explain what is disturbing about it?  Then I can think
>>>> about the issue.

>>> Tooltips are popping up and hiding other info.  As somebody else
>>> explained, for menu entries tooltips are not that important,
>>> because menu texts are better to understand than tool bar icons.

>> If tooltips are active, they tend to pop up on their own.  This can
>> be disconcerting for menus, but perhaps that's because I'm slightly
>> more used to the MS-Windows approach.  In that case, tooltips for
>> menus only popup if you use the "What's this?" command (Shift-F1).
>> This "What's this?" command can be applied to any widget on the
>> screen (but not every widget answers it).

>> Perhaps you want to think about this approach for menu tooltips?

> This sounds good.  As pointed out, C-h k is (almost) Emacs version
> of "What's this?".  Could C-h k be bent to show a tooltip when
> invoked on a menu or toolbar item?

> How does MS Windows handle the menu when doing this?  Do you first
> select "What's this?" and then the menu item?  Or is it the menu
> item first and "What's this?" afterwards?  If the first, is the menu
> still open when the tooltip is shown?

You first select "What's this?" if it's available (not always provided
and sometimes it's a simple "?" next to the window's minimize button).
Then you select the "leaf" menu item of interest (ie. menus with
submenus don't trigger the "What's this?").  The menu remains open
during and after the tooltip is shown.

I'm not sure that C-h k should be bent to showing tooltips as C-h k on
a menu item already invokes describe-key and having two different
styles of output for it might be confusing.  In general, you want to
make the tooltip simple to get to, but not constantly popping up in
your way.  My suggestion would be to make the first character of the
menubar (or modeline?) a "?" which would serve as this "What's this?"
button (the equivalent Emacs command can be pretty obscure).  Menus
generally aren't available in non-windows mode (correct?) and you
don't need tooltips in non-windows mode (correct?), so, when the menu
goes away, easy access to tooltips would also go away and this would
be reasonable.

Are tooltips reasonably applied to anything other than (the equivalent
of) an XWindow widget (menu item, button, frame, etc.)?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Eli Zaretskii]

> Date: Thu, 14 Nov 2002 21:07:56 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> 
> > Please click on any menu-bar item in the Internet Explorer,
> > then move the mouse pointer across the menu that drops down, and watch
> > the bottom of the IE display, the area we call ``echo area''.
> 
> I don't think that qualifies as a tooltip.

Nevertheless, Emacs behaves just like that when you turn off
tooltip-mode.  It displays the tooltip text in the echo area.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Thu, 14 Nov 2002 18:49:50 +0100
> 
> we could have even longer (multiline) tips.

I don't think there's anything to prevent us from having multiline
tooltips.  Tooltips are just a special kind of frames, so they could
be multiline.

Re: Gtk version getting closer

[David Masterson]

>>>>> Jan D writes:
                                   
> I am not against tips, I just don't think showing them as today is
> a good idea.  The "What's this?" approach seems workable.  Then we
> could have even longer (multiline) tips.

Longer, but not too long.  Otherwise, you're moving into the territory
of describe-* commands.  And, no, the tooltip should not be the same
thing as the output of describe-key as, ultimately, the output of
describe-key could include active areas whereas the tooltip can't, so
the excess would be worthless.  Hmmm, maybe a "?" button to invoke the
tooltip and a "??" button to invoke describe-key...?

Plus, I think it might be reasonable to have tooltips on things like:

* sections of the modeline
* headers in mail messages
* horizontal scrollbar (mentioning truncate-lines)
* the menubar (toggle-menubar?)
* let your imagination flow...

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jan D.]

torsdagen den 14 november 2002 kl 21.29 skrev Eli Zaretskii:

>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Thu, 14 Nov 2002 18:49:50 +0100
>>
>> we could have even longer (multiline) tips.
>
> I don't think there's anything to prevent us from having multiline
> tooltips.  Tooltips are just a special kind of frames, so they could
> be multiline.

I was thinking that tooltips the users ask for generally can be longer
than tooltips that pops up automatically.  The first type you expect, the
second type you don't so one wants to minimize the screen space it
occupies.

	Jan D.

Re: Gtk version getting closer

[Jason Rumney]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Really?  Please click on any menu-bar item in the Internet Explorer,
> then move the mouse pointer across the menu that drops down, and watch
> the bottom of the IE display, the area we call ``echo area''.

I have been using Windows for years, and only noticed this
recently. Who looks at the echo/status area when they are selecting
menus at the top of the window? Tooltips are a much better solution.

Re: Gtk version getting closer

[Miles Bader]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> I am not a good person for working on menu tips since I hardly ever
> use menus.

I rarely use menus in emacs either -- for invoking commands.

I do keep the menu-bar turned on, though, because the menus are great as
_documentation_, especially for modes like Gnus that have 1,000,000
commands that I only occasionally use.  I find it much more convenient
to just browse the menus in such a case than to use the more
conventional emacs help systems (though this obviously only works if
the mode has relatively completely menus; luckily Gnus does...).

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Gtk version getting closer

[Richard Stallman]

    If tooltips are active, they tend to pop up on their own.  This can be
    disconcerting for menus, but perhaps that's because I'm slightly more
    used to the MS-Windows approach.  In that case, tooltips for menus
    only popup if you use the "What's this?" command (Shift-F1).

If users are accustomed to this and like it, it would be a good
approach.  But can it be implemented without changing the toolkits?

This might be a useful change to make in GTK.

Re: Gtk version getting closer

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     In that case, tooltips for menus only popup if you use the "What's
>     this?" command (Shift-F1).
> 
> If users are accustomed to this and like it, it would be a good
> approach.  But can it be implemented without changing the toolkits?
> 
> This might be a useful change to make in GTK.

Some users may be more used to it (I don't know), but I presume not
Gnome users -- Gnome panel menus act exactly like emacs menus currently
do, they pop up tooltips without any special command.

I like the current method, so I hope any change is completely optional
(and certainly I'd like to use a GTK toolkit version of emacs).

-Miles
-- 
Run away!  Run away!

Re: Gtk version getting closer

[Robert J. Chassell]

Miles Bader <miles@gnu.org> wrote

   I rarely use menus in emacs either -- for invoking commands.

   I do keep the menu-bar turned on, though, because the menus are great as
   _documentation_, especially for modes like Gnus that have 1,000,000
   commands that I only occasionally use.  ....

That is a good reason to use menus.  Whoever write the tool tips
should keep this in mind as one of purposes to which the menu bar
will be put.  The task grows more challenging!

In your same circumstance, I type `C-h m' (describe-mode) which
usually provides me with all the information I need, but not always.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 14 Nov 2002 23:03:05 +0000
> 
> Tooltips are a much better solution.

Obviously, I agree.  My whole point was that displaying information
about menu items is not something Emacs invented, it exists on other
GUI platforms.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: David Masterson <dmaster@synopsys.com>
> Date: 15 Nov 2002 08:36:44 -0800
> 
> if you were going to use the menu, I would think the tooltip popping
> up might get in the way.

Can't you prevent this by customizing tooltip-x-offset and
tooltip-y-offset, or maybe tooltip-delay?

Re: Gtk version getting closer

[David Masterson]

>>>>> Miles Bader writes:

> Richard Stallman <rms@gnu.org> writes:

>>> In that case, tooltips for menus only popup if you use the "What's
>>> this?" command (Shift-F1).

>> If users are accustomed to this and like it, it would be a good
>> approach.  But can it be implemented without changing the toolkits?

>> This might be a useful change to make in GTK.

> Some users may be more used to it (I don't know), but I presume not
> Gnome users -- Gnome panel menus act exactly like emacs menus
> currently do, they pop up tooltips without any special command.

> I like the current method, so I hope any change is completely
> optional (and certainly I'd like to use a GTK toolkit version of
> emacs).

Can you be a little more precise as to why you like the current
method?  From another of your messages, my guess is that you don't use
the menu directly, you just use it as documentation.  If so, then
having the tooltips popup on their own makes sense.  However, if you
were going to use the menu, I would think the tooltip popping up might
get in the way.  Obviously, you could turn off the tooltips all
together, but having a "What's this?" command might be a little more
flexible.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Miles Bader]

On Fri, Nov 15, 2002 at 08:36:44AM -0800, David Masterson wrote:
> > I like the current method, so I hope any change is completely
> > optional (and certainly I'd like to use a GTK toolkit version of
> > emacs).
> 
> Can you be a little more precise as to why you like the current
> method?

Because (1) I like having the tooltips, and (2) I don't find them annoying,
and (3) I _do_ find having to use an explicit command to get tooltips
annoying.

Note that (2) is something that depends a lot on the particular parameters
(popup delay etc): some programs (the enlightenment window manager is a good
example) have tooltips that drive me bonkers, but emacs seems to have done
things right.

> From another of your messages, my guess is that you don't use
> the menu directly, you just use it as documentation.

I `use them as documentation' in the sense that I use them to help me
remember rarely used commands (or commands with particularly wierd bindings).
Of course I don't look at the menu and then hit the key (that would be a bit
silly) -- I just select the menu entry.

The main difference I think is that I use the menus occasionally, rather
than for every command (which I've seen novice users do, even when I'm pretty
sure they know the key-binding; I guess they're just used to it).

> If so, then having the tooltips popup on their own makes sense.  However,
> if you were going to use the menu, I would think the tooltip popping up
> might get in the way.

It would be nice to have something besides conjecture.

Has anyone heard any complaints about menu tooltips being annoying?

> Obviously, you could turn off the tooltips all together, but having a
> "What's this?" command might be a little more flexible.

They seem orthogonal, actually...

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Gtk version getting closer

[Robert J. Chassell]

   .... I would think the tooltip popping up might get in the way.

Try setting the tooltip-x-offset and tooltip-y-offset amounts to
something different than the default.  That keeps the tips from
getting in the way.

I just tried:

    (setq tooltip-x-offset 40)
    (setq tooltip-y-offset -40)

which moves the tips quite a distance.

These variables are in:        emacs/lisp/tooltip.el

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Jason Rumney]

David Masterson <dmaster@synopsys.com> writes:

> However, if you were going to use the menu, I would think the
> tooltip popping up might get in the way.

Maybe more vertical separation between the mouse pointer and tooltip
would help here. Or moving the tooltip to below the mouse pointer
might keep it more out of the way (and would be consistent with Gnome,
Sawfish and MS-Windows).

Re: Gtk version getting closer

[David Masterson]

>>>>> Eli Zaretskii writes:

>> From: David Masterson <dmaster@synopsys.com>
>> Date: 15 Nov 2002 08:36:44 -0800
>> 
>> if you were going to use the menu, I would think the tooltip
>> popping up might get in the way.

> Can't you prevent this by customizing tooltip-x-offset and
> tooltip-y-offset, or maybe tooltip-delay?

I guess it's a preference thing.  Some people are used to tooltips
popping up all the time and, so, it doesn't distract them if they're
not interested in the tooltip.  Others prefer the tooltip to be
available when asked for (as in "What's this?") and would be annoyed
if the tooltip popped up while (say) they were thinking about choosing
between menuA and menuB.  The tooltip-delay might help, but it
requires a fine balance between too fast (annoying you when you're not
interested in the tip) and too slow (annoying you when you are
interested).  The offsets are also problematic because the widgets
that the tooltips are applied to are not uniform size, so sometimes
the offset may be too far and sometimes it may be too close.

Perhaps a tooltip-style variable is needed with these options:

* never - deactivate tooltips
* always - full activation of tooltips
* nomenus - activated except for menus
* whatthis - deactivate tooltips, but "What's this?" will activate
  tooltip of selected widget 

Or, perhaps, the style should only be the first 3 and the last one is
a command (which can be applied to a key) that is always available.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[David Masterson]

>>>>> Miles Bader writes:

> It would be nice to have something besides conjecture.  Has anyone
> heard any complaints about menu tooltips being annoying?

I thought that's what I was doing...

Tooltips popping up sometimes (but not always) can be annoying.  It's
a preference thing based upon the environments you've worked in.  The
MS-Windows users, for instance, might prefer a "What's this?" command
to have the tooltip only popup when requested (I don't think of myself
as an MS-Windows user, but some things have rubbed off ;-).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Stefan Monnier]

> Of course I don't look at the menu and then hit the key (that would be a bit
> silly) -- I just select the menu entry.

I'm often silly: hitting the key (after reading it in the menu) helps
me remember the binding. ;-)


	Stefan

Re: Gtk version getting closer

[David Masterson]

>>>>> Jason Rumney writes:

> David Masterson <dmaster@synopsys.com> writes:
>> However, if you were going to use the menu, I would think the
>> tooltip popping up might get in the way.

> Maybe more vertical separation between the mouse pointer and tooltip
> would help here. Or moving the tooltip to below the mouse pointer
> might keep it more out of the way (and would be consistent with
> Gnome, Sawfish and MS-Windows).

For some people, this might be enough *most* of the time.  Because the
widgets that might have tooltips are not uniform in size or content,
the visual offsets you mention may sometimes seem too big and
sometimes seem too small (beauty is in the eye of the beholder).

All I'm suggesting is you've got three different types of users:

* Those who don't like tooltips at all (in which case, you provide a
  variable to turn off tooltips).
* Those who find tooltips useful *when* they ask for them (in which
  case, the "What's this?" command makes sense).
* Those who generally find tooltips useful (in which case, the normal
  popups with adjustment variables makes sense).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Eli Zaretskii]

> From: David Masterson <dmaster@synopsys.com>
> Date: 15 Nov 2002 10:46:43 -0800
> 
> >>>>> Eli Zaretskii writes:
> 
> >> From: David Masterson <dmaster@synopsys.com>
> >> Date: 15 Nov 2002 08:36:44 -0800
> >> 
> >> if you were going to use the menu, I would think the tooltip
> >> popping up might get in the way.
> 
> > Can't you prevent this by customizing tooltip-x-offset and
> > tooltip-y-offset, or maybe tooltip-delay?
> 
> I guess it's a preference thing.  Some people are used to tooltips
> popping up all the time and, so, it doesn't distract them if they're
> not interested in the tooltip.  Others prefer the tooltip to be
> available when asked for (as in "What's this?") and would be annoyed
> if the tooltip popped up while (say) they were thinking about choosing
> between menuA and menuB.

I was asking whether _you_ in _your_ particular environment can
prevent the annoyance using the customizable options.

If the answer is YES, then users at least have a way of getting the
tooltips out of their way when they use menus.

Re: Gtk version getting closer

[David Masterson]

>>>>> Eli Zaretskii writes:

>> From: David Masterson <dmaster@synopsys.com>
>> Date: 15 Nov 2002 10:46:43 -0800
>> 
>> >>>>> Eli Zaretskii writes:
>> 
>> >> From: David Masterson <dmaster@synopsys.com>
>> >> Date: 15 Nov 2002 08:36:44 -0800
>> >> 
>> >> if you were going to use the menu, I would think the tooltip
>> >> popping up might get in the way.
>> 
>> > Can't you prevent this by customizing tooltip-x-offset and
>> > tooltip-y-offset, or maybe tooltip-delay?
>> 
>> I guess it's a preference thing.  Some people are used to tooltips
>> popping up all the time and, so, it doesn't distract them if
>> they're not interested in the tooltip.  Others prefer the tooltip
>> to be available when asked for (as in "What's this?") and would be
>> annoyed if the tooltip popped up while (say) they were thinking
>> about choosing between menuA and menuB.

> I was asking whether _you_ in _your_ particular environment can
> prevent the annoyance using the customizable options.

> If the answer is YES, then users at least have a way of getting the
> tooltips out of their way when they use menus.

Oh.  I haven't tried it yet, but I think I could adapt to things even
without the customizable options (it's just a matter of not letting
the tooltip popup distract you when it's not neede).  However, while I
could adapt to it, it doesn't agree with my current preference which
would tend toward the "What's this?" approach.  As has been true in
the past, though, I'm sure that, if you give me a little time to
adapt, I'll forget all about the old way of doing things.  ;-)

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jason Rumney]

David Masterson <dmaster@synopsys.com> writes:

> The MS-Windows users, for instance, might prefer a "What's this?"
> command to have the tooltip only popup when requested

This does not seem to be a universal thing on MS-Windows. I had to
look very hard to find a program that had this feature, and that
program did not have a menu bar (just a dialog interface). The "What's
this?" command seems to be in addition to tooltips in that case, and
gives a 5 - 10 line pop-up that looks more like what C-h k would
produce.

Re: Gtk version getting closer

[David Masterson]

>>>>> Jason Rumney writes:

> David Masterson <dmaster@synopsys.com> writes:
>> The MS-Windows users, for instance, might prefer a "What's this?"
>> command to have the tooltip only popup when requested

> This does not seem to be a universal thing on MS-Windows. I had to
> look very hard to find a program that had this feature, and that
> program did not have a menu bar (just a dialog interface). The
> "What's this?" command seems to be in addition to tooltips in that
> case, and gives a 5 - 10 line pop-up that looks more like what C-h k
> would produce.

I agree.  The general idea is good.  The MS implementation is
incomplete and, therefore, not good.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Richard Stallman]

    The menu item has "between Sessions", implying this applies
	for all sessions to come.  The tip says "next Session", implying
	it is only for the next session.

Both expressions fit what it actually does.

    The menu item has "Save Place in Files", the tip says "Save Emacs state".
	Neither is 100% correct, there is more that places saved, but
	less than the full Emacs state.  If this is for a beginner, I
	imagine (but could be wrong) that "Save Places" is easier to
	understand than "Save state", as stats can mean many things.

I think they are both useful.  If you have specific
suggestions to improve one or the other, please offer them.

    I think I would have written "Reopen files when Emacs is started".

Perhaps "Revisit files of previous session when restarting Emacs."
What do you think?

Re: Gtk version getting closer

[Richard Stallman]

    I am not a good person for working on menu tips since I hardly ever
    use menus.

You can look at the menus for the specific purpose of improving their
tooltips.  It doesn't matter whether you use the menus yourself often;
what matters is that you have the skill to imagine what a newby would
understand, or not understand, when looking at them.

Re: Gtk version getting closer

[Richard Stallman]

    You first select "What's this?" if it's available (not always provided
    and sometimes it's a simple "?" next to the window's minimize button).
    Then you select the "leaf" menu item of interest (ie. menus with
    submenus don't trigger the "What's this?").  The menu remains open
    during and after the tooltip is shown.

This is almost identical to C-h k.  That shows the doc string of the
menu item command.

It is good to make sure each menu item has a function name and a doc
string--to avoid anonymous lambdas there.  I made some changes
of that sort a few months ago, and I think I got rid of them all.

Re: Gtk version getting closer

[Jan D.]

>     The menu item has "between Sessions", implying this applies
> 	for all sessions to come.  The tip says "next Session", implying
> 	it is only for the next session.
>
> Both expressions fit what it actually does.

Yes, they do.  But this is the problem when experts describe things
for beginners, I know, I've been there a lot :-)

For someone used to Emacs, this is totally OK.  But it really doesn't
describe the difference a users sees with and without this option.

>
>     The menu item has "Save Place in Files", the tip says "Save Emacs 
> state".
> 	Neither is 100% correct, there is more that places saved, but
> 	less than the full Emacs state.  If this is for a beginner, I
> 	imagine (but could be wrong) that "Save Places" is easier to
> 	understand than "Save state", as stats can mean many things.
>
> I think they are both useful.  If you have specific
> suggestions to improve one or the other, please offer them.
>
>     I think I would have written "Reopen files when Emacs is started".
>
> Perhaps "Revisit files of previous session when restarting Emacs."
> What do you think?

This is good.  But "previous session" already implies a restart, so
it could be shorter:
  "Visit files of previous session when starting Emacs"

Also, visit is somewhat Emacs specific, most other programs say open.
Emacs menus doesn't have visit in them either.  But if one should
follow other programs convention or use Emacs terms is another
discussion.

I guess this only shows that designing menu texts is hard and also a
matter of taste. :-)

	Jan D.

Re: Gtk version getting closer

[David Masterson]

>>>>> Richard Stallman writes:

>     You first select "What's this?" if it's available (not always provided
>     and sometimes it's a simple "?" next to the window's minimize button).
>     Then you select the "leaf" menu item of interest (ie. menus with
>     submenus don't trigger the "What's this?").  The menu remains open
>     during and after the tooltip is shown.

> This is almost identical to C-h k.  That shows the doc string of the
> menu item command.

Agreed.  

I have found that it's not obvious that "describe-key" can also be
applied to menus and buttons.  Therefore, I would suggest adding a
"What's this?" entry to the standard Help menu that simply does
describe-key.  You can leave the "Describe Key" entry in the Describe
menu of the Help menu.  Because of MS-Windows precedent, this should
make it's use a little more obvious.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Miles Bader]

BTW, I happened to use a modern MS Windows system today (I'm not sure which
one, but I guess 2K or XP; the menus/title-bars are neon colors, and it was
on a laptop, so probably a `consumer' system), and noticed that the menus had
tooltips popping up without any prompting....  they did a better job of
avoiding the selected menu item that emacs menu tooltips though.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Gtk version getting closer

[Richard Stallman]

    I just tried:

	(setq tooltip-x-offset 40)
	(setq tooltip-y-offset -40)

    which moves the tips quite a distance.

Would there be a better default value for these?

Re: Gtk version getting closer

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     I just tried:
> 
> 	(setq tooltip-x-offset 40)
> 	(setq tooltip-y-offset -40)
> 
>     which moves the tips quite a distance.
> 
> Would there be a better default value for these?

Gnome 1.4 positions its tooltips below the mouse pointer and centered,
everything else I have seen positions them below and to the right (the
start of the text is actually aligned with the LHS of the pointer in
sawfish, I can't check anything else right now). Only Emacs positions
tooltips above the mouse. I think below is less likely to be in the
way, since the pointer usually points upwards. So my suggestion would
be to default to 

(setq tooltip-x-offset 0)
(setq tooltip-y-offset 40)

Re: Gtk version getting closer

[Robert J. Chassell]

       I just tried:

           (setq tooltip-x-offset 40)
           (setq tooltip-y-offset -40)

       which moves the tips quite a distance.

   Would there be a better default value for these?

I don't know what people would like.  The best value depends both on a
person's screen and on the font they are using.

With my usual "10x20" font,

	(setq tooltip-x-offset 20)
	(setq tooltip-y-offset -20)

looks good, but in a plain vanilla instance of Emacs, started as

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'


	(setq tooltip-x-offset 15)
	(setq tooltip-y-offset -15)

is better.  But 15 is too small a value for my "10x20" font.

I suspect that many people use a 1024x768 screen with the default
fonts, a white background and all that, but am not sure.  I run the
default fonts in the `plain vanilla' Emacs, but have a higher
resolution screen.

Do others on this list have a sense of what should be a good default?

--
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Robert J. Chassell]

   ... Only Emacs positions
   tooltips above the mouse. I think below is less likely to be in the
   way, since the pointer usually points upwards. So my suggestion would
   be to default to 

   (setq tooltip-x-offset 0)
   (setq tooltip-y-offset 40)

On my usual system, this and variations of it sometimes cover the menu
item and sometimes not.  On the `Tools' menu, for example, these
values lead to a tip that does OK with `Compile' but that covers up
part of `Ediff Miscellanea'.

But on a `plain vanilla' Emacs, started with

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

the values lead to tips that never cover up their menu item.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Kenichi Handa]

In article <m18EfMJ-000IeAC@localhost>, "Robert J. Chassell" <bob@rattlesnake.com> writes:
> I suspect that many people use a 1024x768 screen with the default
> fonts, a white background and all that, but am not sure.  I run the
> default fonts in the `plain vanilla' Emacs, but have a higher
> resolution screen.

> Do others on this list have a sense of what should be a good default?

At the above is first mail I read thoroughly on this topic,
I don't know if this idea has already been discussed or not.

I think the right thing is to decide the tooltip X/Y offset
according to the size and position of the rectangle area
that activates the tooltip, not according to the mouse
position.  Then we can make tooltip never overlap with the
rectangle area, for instance, by aligning the bottom-left
corner of the tooltip with 5/-5 offset from the top-left
corder of the rectangle area will be good.  This is for
people who use the default mouse cursor.  People who use a
mouse cursor of which hot spot is at bottom may want to
allign the top-left corner of the tooltip with the
bottom-left corner of the rectangle area.

Example:
     +------------------------------+
     |        tooltip text          |
     +------------------------------+
   +---------------+
   |  ICON         |
   |     or MENU   |
   +---------------+

---
Ken'ichi HANDA
handa@m17n.org

Re: Gtk version getting closer

[Miles Bader]

On Thu, Nov 21, 2002 at 10:09:29PM +0900, Kenichi Handa wrote:
> I think the right thing is to decide the tooltip X/Y offset according to
> the size and position of the rectangle area that activates the tooltip, not
> according to the mouse position.  Then we can make tooltip never overlap
> with the rectangle

I think that's an excellent idea -- it would yield much more consistent
results than the current method.  One thing I noticed about the windows
tooltips is that they pop up neatly aligned with the edge of the menu entry
or whatever, whereas the emacs ones seem placed sort of randomly (presumably
they're at a constant offset from the mouse pointer's position when the
tooltip popped up, but the offset from the actual menu item is much more
noticable).

Perhaps it would also be good to pass a hint as to the preferred side of
rectangle to put the tooltip on (which I guess would be ignored if there
wasn't enough space).

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Gtk version getting closer

[jasonr]

> I think the right thing is to decide the tooltip X/Y offset
> according to the size and position of the rectangle area
> that activates the tooltip, not according to the mouse
> position.

Gnome seems to do this with the Y offset, but the X offset
still follows the mouse. It is definitely a good idea for Y
offsets, as it eliminates totally the possibility of
obscuring the item that activated the tip. I think doing the
same with the X offset might look strange in some
circumstances, and detach the tip from the mouse pointer
too much.

Re: Gtk version getting closer

[Jason Rumney]

Miles Bader <miles@gnu.org> writes:

> One thing I noticed about the windows tooltips is that they pop up
> neatly aligned with the edge of the menu entry or whatever

MS-Windows? All the tooltips I've seen on that platform are placed a
certain offset from the mouse pointer (below and to the right if
there's room, but avoiding the bottom and right edge of the
screen). It is relatively easy to make tooltips obscure the item they
are pointing to if you try, although it doesn't happen accidentally
as often as with the default settings in Emacs, I think due to the
positioning of the tooltip as below the pointer instead of above where
it is near the hotspot. 

Gnome on the other hand seems to position them vertically relative to
the menu entry or whatever (below), and horizontally relative to the
mouse (centered, which I'm not sure I like, but maybe its a case of
getting used to it).

> Perhaps it would also be good to pass a hint as to the preferred side of
> rectangle to put the tooltip on (which I guess would be ignored if there
> wasn't enough space).

They should be consistent. Tooltips popping up in different places
based on the preferences of some elisp package author would not be
good.

Re: Gtk version getting closer

[Richard Stallman]

       way, since the pointer usually points upwards. So my suggestion would
       be to default to 

       (setq tooltip-x-offset 0)
       (setq tooltip-y-offset 40)

Could others please try this and comment?  Would this be an
improvement?  Should we use -40 instead of 40?

Do people want to implement smarter methods of preventing the tooltip
from hiding the menu item?

    I don't know what people would like.  The best value depends both on a
    person's screen and on the font they are using.

Perhaps instead of using fixed values specified by these variables
it could calculate the values based on the size of the menu item.

    I think the right thing is to decide the tooltip X/Y offset
    according to the size and position of the rectangle area
    that activates the tooltip, not according to the mouse
    position.  Then we can make tooltip never overlap with the
    rectangle area, for instance, by aligning the bottom-left
    corner of the tooltip with 5/-5 offset from the top-left
    corder of the rectangle area will be good.

Yes, exactly.  The question is, how hard is that to implement
given the toolkits as they are?