1:47 a.m.
Hi,
preview-latex contains in its mode setup
(and preview-use-balloon-help
(not (and (boundp 'balloon-help-mode)
balloon-help-mode))
(balloon-help-minor-mode 1))
and preview-use-balloon-help defaults to t. Previews and preview
icons get equipped with help mostly indicating something like "press
mouse 2 to show text, mouse 3 for context menu" or "press mouse 2 for
PostScript error, mouse 3 for source code"). It is usually obvious,
also from the cursor change, that something might happen upon
clicking, and the previous case where mouse 3 deleted the preview
(which annoyed people who are obviously used to checking things out by
clicking on them) has been replaced by a context menu in recent
versions.
On the other hand, we have received several complaints about the
balloon-help-mode which seemingly results from this mode being not so
very "native". The consequences are that the windows that pop up are
fully decorated and tend to interfere with the focus. Apparently,
this situation is quite worse on Windows. I have no idea whether the
Windows situation has improved anything over the last few years, but
how to switch balloon help of has made it into the preview-latex FAQ.
It would appear that outside of preview-latex, ballon-help-mode is
used rather rarely, and it may show, particular on some platforms.
Are there any guidelines about whether a minor mode that goes to the
pain of tagging everything with balloon-help properties should
actively enable the mode?
It is obvious that 90% of all users will not bother changing a given
default or reading documentation and will never discover a feature
that does not hit them squarely in the face. Would you recommend not
using this by default nevertheless?
We have one case of rather "non-obvious" mouse use, namely the one on
error indicators where mouse 2 takes one to the corresponding
PostScript error, and mouse 3 to the source file. Do you have any
suggestions for a behavior which would be "more natural" and thus not
require a balloon help for using? Ignore mouse2 completely, context
menu with the two possibilities on mouse 3? Identical context menu on
both mouse buttons? Go to error directly with mouse2, context menu on
mouse3?
What would be the XEmacs way of doing this?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
4:14 a.m.
* David Kastrup <dak(a)gnu.org> writes:
Hi,
preview-latex contains in its mode setup
(and preview-use-balloon-help
(not (and (boundp 'balloon-help-mode)
balloon-help-mode))
(balloon-help-minor-mode 1))
and preview-use-balloon-help defaults to t.
On the other hand, we have received several complaints about the
balloon-help-mode which seemingly results from this mode being not so
very "native". The consequences are that the windows that pop up are
fully decorated and tend to interfere with the focus.
The frame decoration is the responsibility of the window manager, not
XEmacs. There are a couple of examples in balloon-help.el commentary
section about how to set minimal decorations on the balloon-help
frames.
As for the focus, you are probably going to run into trouble if you
have something like a "focus follows mouse" strategy in your WM. This
problem is sometimes made worse by users who believe that if they ever
take their hand off the rat, it'll somehow stop working.
Apparently, this situation is quite worse on Windows.
Doesn't surprise me. Are decorations even configurable on this
platform?
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| In space, |
| No one can hear you rip a stinky |
|------------------------------------<steve(a)sxemacs.org>---|
12:53 a.m.
* Ben Wing <ben(a)666.com> writes:
> > Apparently, this situation is quite worse on Windows.
>
> Doesn't surprise me. Are decorations even configurable on
> this platform?
Absolutely.
Cool. Learn something new every day. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| In space, |
| No one can hear you rip a stinky |
|------------------------------------<steve(a)sxemacs.org>---|
3:54 p.m.
Steve Youngs <steve(a)sxemacs.org> writes:
* David Kastrup <dak(a)gnu.org> writes:
> preview-latex contains in its mode setup
> (and preview-use-balloon-help
> (not (and (boundp 'balloon-help-mode)
> balloon-help-mode))
> (balloon-help-minor-mode 1))
> and preview-use-balloon-help defaults to t.
> On the other hand, we have received several complaints about the
> balloon-help-mode which seemingly results from this mode being
> not so very "native". The consequences are that the windows
> that pop up are fully decorated and tend to interfere with the
> focus.
The frame decoration is the responsibility of the window manager,
not XEmacs.
Care to explain then why the tooltips of Emacs and pretty much every
other application are, in contrast, completely undecorated (they _are_
in a separate window as can be seen when triggering one at the edge of
the frame)?
As for the focus, you are probably going to run into trouble if you
have something like a "focus follows mouse" strategy in your WM.
This problem is sometimes made worse by users who believe that if
they ever take their hand off the rat, it'll somehow stop working.
It seems that there is a way to ask for undecorated focus-less windows
under X, and other applications manage to get them. I seem to
remember vaguely that somebody once told me the balloon-help-mode
might be sort of a proof-of-concept code, showing that the XEmacs
frame/window/display model was so versatile that you could code
functionality like that completely using Elisp instead of requiring
more low-level stuff, or code it completely using the GUI abstraction
model of XEmacs so that no platform-specific code for X/Windows/MacOS
was needed. Whatever.
The question was not why it is impossible to get any better behavior
for balloon-help-mode and why every other application that manages
doing so is non-existent.
The question was whether there exist suggestions or conventions or
experiences about whether modes supporting balloon help should
actively enable the help or leave the fingers off it until the user
explicitly requests it.
It would appear that we might cause fewer problems in the long run for
users if we just keep our finger off it by default, since it does not
seem to be much part of the XEmacs mindshare.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
12:30 p.m.
>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> Steve Youngs <steve(a)sxemacs.org> writes:
> The frame decoration is the responsibility of the window
> manager, not XEmacs.
This is imprecise. The frame decoration is under control of the
window manager, but there are at least two ways in X to bypass the
window manager completely, and of course there is a protocol by which
the application may request specific decorations.
This issue came up at the time of the 21.4 release, nobody cared to
fix it then, and it looks like nobody cares to fix it now. I'll try
to take a look this week and if it can be done from Lisp I'll fix it.
If it can't, it wouldn't get into 21.4 most likely anyway.
David> The question was whether there exist suggestions or
David> conventions or experiences about whether modes supporting
David> balloon help should actively enable the help or leave the
David> fingers off it until the user explicitly requests it.
My intuition is that unless the user goes to the trouble of setting
the frame decorations to minimum via the window manager, the frame
decorations and focus switch are so distracting that that they
violate th eprinciple of least astonishment. Leave them off IMO.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:32 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> Steve Youngs <steve(a)sxemacs.org> writes:
>> The frame decoration is the responsibility of the window
>> manager, not XEmacs.
This is imprecise. The frame decoration is under control of the
window manager, but there are at least two ways in X to bypass the
window manager completely, and of course there is a protocol by
which the application may request specific decorations.
This issue came up at the time of the 21.4 release, nobody cared to
fix it then, and it looks like nobody cares to fix it now. I'll try
to take a look this week and if it can be done from Lisp I'll fix
it. If it can't, it wouldn't get into 21.4 most likely anyway.
In my opinion, there may be more pressing things for 21.4 to do.
balloon-help-mode has been reported by X users (where you likely could
fix things) as annoying, and by Windows users as completely
destructive to the work (I think that the versions around that time,
around 21.4.9 or so, might have even crashed). There is good reason
that its default is off for XEmacs-21.4, and regardless of whether it
would get fixed, there is no reason to change that in the stable
series. I don't know any other package that would tamper with the
defaults, and it probably was a mistake to do so in preview-latex in
the first place, but it was a mistake inspired by the desire to offer
equal functionality for Emacs and XEmacs.
There are probably very few packages around which even provide the
XEmacs-specific balloon-help when one enables the mode.
David> The question was whether there exist suggestions or
David> conventions or experiences about whether modes supporting
David> balloon help should actively enable the help or leave the
David> fingers off it until the user explicitly requests it.
My intuition is that unless the user goes to the trouble of setting
the frame decorations to minimum via the window manager, the frame
decorations and focus switch are so distracting that that they
violate th eprinciple of least astonishment. Leave them off IMO.
I have come to the same conclusion. The respective setting now has a
different default, this is reflected in documentation and FAQ, and I
have changed the one occurence where the tooltip was rather essential
for guessing the functionality of the user interface.
It is my guess, however, that usable tooltips in general are the sort
of stuff GUI-heavy users quite appreciate. Fixing the functionality
in 21.5 to a state where it can be enabled by default might for that
reason be a good idea. Only then can one hope that third-party
developers actually get into the habit of writing the appropriate
properties into their menus (where they are not supported at all right
now) and other elements of interest.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
7222
days inactive
7224
days old
6 comments
4 participants
participants (4)
-
Ben Wing -
David Kastrup -
Stephen J. Turnbull -
Steve Youngs