Tooltips on w32 slow and strange

Tooltips on w32 slow and strange

[Lennart Borgman]

The tooltip implementation on w32 seems a bit strange. In some cases it can
switch to another frame. It is also very slow.

Re: Tooltips on w32 slow and strange

[Stefan Daschek]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> The tooltip implementation on w32 seems a bit strange. In some cases it can
> switch to another frame. It is also very slow.

I sometimes even get tooltips from Emacs when another application has
focus and the Emacs' window (frame) is hidden behind that
application's window. This is quite irritating.

noniq

Re: Tooltips on w32 slow and strange

[Stephan Stahl]

Hi Lennart.

Lennart Borgman said:
> The tooltip implementation on w32 seems a bit strange. In some cases
> it can switch to another frame. It is also very slow.

I reported this too a while ago but got no answer:
http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00060.html

As far as i understand tooltips on w32 emacs does not use normal
w32-tooltips but special emacs frames that are stripped of everything
(modeline, toolbar, minibuffer,...).  Maybe this could be changed..

Stephan
-- 
Stephan Stahl

Re: Tooltips on w32 slow and strange

[Jason Rumney]

Stephan Stahl wrote:

>I reported this too a while ago but got no answer:
>http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00060.html
>
>As far as i understand tooltips on w32 emacs does not use normal
>w32-tooltips but special emacs frames that are stripped of everything
>(modeline, toolbar, minibuffer,...).  Maybe this could be changed..
>  
>
Emacs uses frames for its tooltips on all platforms. To change this on 
Windows would make it more difficult to maintain, and would lose 
functionality.

Re: Tooltips on w32 slow and strange

[Stephan Stahl]

Hi Jason.

Jason Rumney said:

> Emacs uses frames for its tooltips on all platforms. To change this on
> Windows would make it more difficult to maintain, and would lose
> functionality.

OK, I thought it was like this only on w32.

But still the current behavior on w32 is very annoying so there should be
done something..  I have never noticed this mess when creating frames via
C-x 5 2.  Maybe we can find out the differences between that and tooltips?

Stephan
-- 
Stephan Stahl

Re: Tooltips on w32 slow and strange

[Jason Rumney]

Stephan Stahl wrote:

>But still the current behavior on w32 is very annoying so there should be
>done something..  I have never noticed this mess when creating frames via
>C-x 5 2.  Maybe we can find out the differences between that and tooltips?
>  
>
I agree that something should be done. I have looked at this problem on 
a number of occassions, probably when you reported it first (sorry I did 
not reply), and later when I was going through my mail looking at 
unresolved bugs again. But I have been unable to find what it is that is 
going wrong.

Re: Tooltips on w32 slow and strange

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Stephan Stahl wrote:
>
>>I reported this too a while ago but got no answer:
>>http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00060.html
>>
>>As far as i understand tooltips on w32 emacs does not use normal
>>w32-tooltips but special emacs frames that are stripped of everything
>>(modeline, toolbar, minibuffer,...).  Maybe this could be changed..
>>  
>>
> Emacs uses frames for its tooltips on all platforms. To change this on
> Windows would make it more difficult to maintain, and would lose
> functionality.

Are you sure about that?  Under X11, tooltips come without any
decoration and without any impact on the focus (I have
focus-follows-mouse policy).  I never noticed _any_ problem with them.

In contrast, the XEmacs "balloon-help" indeed uses frames, which come
with decoration (like borders and a headline) and most particular
which cause problems with the input focus being diverted for a moment.

We don't want such effects enabled by default on _any_ platform,
believe me.  A mode of mine explicitly enabled the balloon-mode
mechanism on XEmacs, and due to user complaints we have been forced to
create an option for turning it off, and later change this option's
default to off.

If users of Emacs on Windows experience similar effects, this will
significantly hamper acceptance and usability.  So I'd strongly to
those working on the Windows port to see whether something can be done
in that regard.  I can't see at all what functionality could possibly
be lost.  At least the X11 tooltips on Emacs provide no functionality
whatsoever except popping up some text in a single font AFAICS.  No
face support, no clickable areas, nothing.  So if there is a function
for popping them up in the system, I can't see what we could lose by
using it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Tooltips on w32 slow and strange

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 1868 bytes --]

David Kastrup wrote:

>Jason Rumney <jasonr@gnu.org> writes:
>
>  
>
>>Emacs uses frames for its tooltips on all platforms. To change this on
>>Windows would make it more difficult to maintain, and would lose
>>functionality.
>>    
>>

>Are you sure about that?  Under X11, tooltips come without any
>decoration and without any impact on the focus (I have
>focus-follows-mouse policy).  I never noticed _any_ problem with them.
>  
>

Yes I'm sure, the Windows implementation was based on the X11 
implementation. They are special frames in that they have the properties 
you observe, but they are still frames and you can use all of Emacs' 
non-input related display features in them.

>If users of Emacs on Windows experience similar effects
>

They're not quite as bad as XEmacs' problems I think, there seems to be 
a bug in the code that makes sure the tooltip doesn't get focus which 
causes problems when there are multiple frames. Apart from that they 
appear a bit slow on slow machines due to being drawn by the normal 
Emacs redisplay instead of being simple fixed plaintext like in other 
programs.

>At least the X11 tooltips on Emacs provide no functionality
>whatsoever except popping up some text in a single font AFAICS.  No
>face support, no clickable areas, nothing.
>

I'm sure I've seen face support used in tooltips. Maybe only text 
properties work, the face is probably forced to "tooltip".

>So if there is a function for popping them up in the system, I can't see what we could lose by
>using it.
>  
>

I don't think there is a function for popping them up in the system. 
Many armchair critics are not aware of the distinction between 
Microsoft's proprietary C++ GUI toolkit (MFC) and what is available 
directly from the OS APIs, so we often get slated for not using feature 
X, when reimplementing it using the OS APIs is non-trivial.


[-- Attachment #1.2: Type: text/html, Size: 2732 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Tooltips on w32 slow and strange

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

> >As far as i understand tooltips on w32 emacs does not use normal
> >w32-tooltips but special emacs frames that are stripped of everything
> >(modeline, toolbar, minibuffer,...).  Maybe this could be changed..
> >
> >
> Emacs uses frames for its tooltips on all platforms. To change this on
> Windows would make it more difficult to maintain, and would lose
> functionality.

Could not this functionality be encapsulated so that it could use the
platform
specific tooltips? It could perhaps be the easiest way to solve the problem?

What functionality could be lost?

Re: Tooltips on w32 slow and strange

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

> I don't think there is a function for popping them up in the system.
> Many armchair critics are not aware of the distinction between
> Microsoft's proprietary C++ GUI toolkit (MFC) and what is available
> directly from the OS APIs, so we often get slated for not using feature
> X, when reimplementing it using the OS APIs is non-trivial.

There is a window class (is that the term?) TOOLTIPS_CLASS which can be used
with CreateWindowEx. I am not an expert on this but there are examples in
MSDN.

Re: Tooltips on w32 slow and strange

[Miles Bader]

On Mon, 14 Feb 2005 13:26:46 +0100, David Kastrup <dak@gnu.org> wrote:
> At least the X11 tooltips on Emacs provide no functionality
> whatsoever except popping up some text in a single font AFAICS.  No
> face support, no clickable areas, nothing.

Have you tried it?

I've certainly used faces (and CJK characters etc) in Emacs tooltips
[under X11] and they worked just great.

Hmmm; here's a simple example:

   (x-show-tip
    (propertize "*** hello ***"
		'face '(variable-pitch :foreground "green"
				       :background "steelblue" 
				       :height 3.0)))

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Tooltips on w32 slow and strange

[Miles Bader]

On Mon, 14 Feb 2005 14:54:36 +0100, Lennart Borgman
<lennart.borgman.073@student.lu.se> wrote:
> Could not this functionality be encapsulated so that it could use the
> platform
> specific tooltips? It could perhaps be the easiest way to solve the problem?
> 
> What functionality could be lost?

(1) face support (and some other stuff like various frame params)

(2) multi-lingual support would probably at least require work to get
right -- right now it comes basically for free.

"Emacs Frame" tooltips seems to work really well in X11; why not just
make them work well in Windows too?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Tooltips on w32 slow and strange

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 1284 bytes --]

Lennart Borgman wrote:

>----- Original Message ----- 
>From: "Jason Rumney" <jasonr@gnu.org>
>
>  
>
>>I don't think there is a function for popping them up in the system.
>>Many armchair critics are not aware of the distinction between
>>Microsoft's proprietary C++ GUI toolkit (MFC) and what is available
>>directly from the OS APIs, so we often get slated for not using feature
>>X, when reimplementing it using the OS APIs is non-trivial.
>>    
>>
>
>There is a window class (is that the term?) TOOLTIPS_CLASS which can be used
>with CreateWindowEx. I am not an expert on this but there are examples in
>MSDN.
>  
>
That documentation is for the "Common Controls" API, which is a 
constantly changing API, the availability of which depends on which 
version of Windows you have installed, and which other software you have 
installed that might have installed later versions.

As such, I do not beleive that it fits the definition of "anything that 
is normally distributed (in either source or binary form) with the major 
components (compiler, kernel, and so on) of the operating system on 
which the executable runs", and certainly we cannot redistribute some 
version of it to guarantee minimum functionality above what was included 
in the original release of Windows NT.


[-- Attachment #1.2: Type: text/html, Size: 1759 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Tooltips on w32 slow and strange

[David Kastrup]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Mon, 14 Feb 2005 13:26:46 +0100, David Kastrup <dak@gnu.org> wrote:
>> At least the X11 tooltips on Emacs provide no functionality
>> whatsoever except popping up some text in a single font AFAICS.  No
>> face support, no clickable areas, nothing.
>
> Have you tried it?

I thought so, but apparently I am confusing this with menu strings.

> I've certainly used faces (and CJK characters etc) in Emacs tooltips
> [under X11] and they worked just great.

CJK characters (as long as they are Unicode) should provide no
problems by now even in menu strings for most platforms IIRC.

> Hmmm; here's a simple example:
>
>    (x-show-tip
>     (propertize "*** hello ***"
> 		'face '(variable-pitch :foreground "green"
> 				       :background "steelblue" 
> 				       :height 3.0)))

I have not been using x-show-tip directly ever but merely help-echo
properties, but that should make no difference.

Thanks for debunking my ignorance.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Tooltips on w32 slow and strange

[Ralf Angeli]

* David Kastrup (2005-02-14) writes:

> Miles Bader <snogglethorpe@gmail.com> writes:
>
>> Hmmm; here's a simple example:
>>
>>    (x-show-tip
>>     (propertize "*** hello ***"
>> 		'face '(variable-pitch :foreground "green"
>> 				       :background "steelblue" 
>> 				       :height 3.0)))
>
> I have not been using x-show-tip directly ever but merely help-echo
> properties, but that should make no difference.

I just saw those tooltips the first time in my life by enabling
tooltip-mode and hovering with the mouse pointer over some menus
generated by AUCTeX.  If one is used to native GTK tooltips, the ones
generated by Emacs look really awkward.

-- 
Ralf

Re: Tooltips on w32 slow and strange

[David Kastrup]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

> * David Kastrup (2005-02-14) writes:
>
>> Miles Bader <snogglethorpe@gmail.com> writes:
>>
>>> Hmmm; here's a simple example:
>>>
>>>    (x-show-tip
>>>     (propertize "*** hello ***"
>>> 		'face '(variable-pitch :foreground "green"
>>> 				       :background "steelblue" 
>>> 				       :height 3.0)))
>>
>> I have not been using x-show-tip directly ever but merely help-echo
>> properties, but that should make no difference.
>
> I just saw those tooltips the first time in my life by enabling
> tooltip-mode and hovering with the mouse pointer over some menus
> generated by AUCTeX.  If one is used to native GTK tooltips, the ones
> generated by Emacs look really awkward.

Uh what?  Tooltips are enabled by default.  At least I get them also
with -q -no-site-file.  The customization buffer says, however,

    This is a customization buffer.
    `Raised' buttons show active fields; type RET or click mouse-1
    on an active field to invoke its action.  Editing an option value
    changes the text in the buffer; invoke the State button and
    choose the Set operation to set the option value.
    Invoke Help for more information.

    Operate on everything in this buffer:
     Set for Current Session Save for Future Sessions
     Reset Reset to Saved Erase Customization   Finish

    Tooltip Mode: Hide Toggle  on (non-nil)
       State: this option has been changed outside the customize buffer.

Which would appear rather wrong, as it would mean that you could not
customize tooltips off even if you wanted to.

How comes that your Emacs behaves differently than mine?  Have you
explicitly disabled tooltips, or am I just being crazy in some manner
again?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Tooltips on w32 slow and strange

[Jason Rumney]

David Kastrup wrote:

>The customization buffer says, however,
>
>    Tooltip Mode: Hide Toggle  on (non-nil)
>       State: this option has been changed outside the customize buffer.
>
>Which would appear rather wrong, as it would mean that you could not
>customize tooltips off even if you wanted to.
>  
>
I don't think this message stops you from customizing them off. It is 
caused by the default state being calculated at startup (before .emacs 
is read), based on whether you are running on a graphical display rather 
than being a constant. It might also be complicated by the fact that 
Emacs is dumped in text mode, so the default evaluated to nil when dumping.

Re: Tooltips on w32 slow and strange

[Reiner Steib]

On Mon, Feb 14 2005, David Kastrup wrote:

> Uh what?  Tooltips are enabled by default.  At least I get them also
> with -q -no-site-file.  The customization buffer says, however,
[...]
>     Tooltip Mode: Hide Toggle  on (non-nil)
>        State: this option has been changed outside the customize buffer.

I think this is the reason:

,----[ startup.el ]
| (defun command-line ()
| [...]
|   (unless (or noninteractive
| 	      emacs-quick-startup
|               (not (display-graphic-p))
|               (not (fboundp 'x-show-tip)))
|     (setq-default tooltip-mode t)
|     (tooltip-mode 1))
`----

> Which would appear rather wrong, as it would mean that you could not
> customize tooltips off even if you wanted to.

No, apparently the customization are processed later:

$ rm .emacs
$ emacs -no-site-file
[ Customizing Tooltip Mode off ...]
$ cat .emacs
(custom-set-variables
  ;; custom-set-variables was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
 '(tooltip-mode nil nil (tooltip)))
[...]
$ emacs -no-site-file

,----
| Tooltip Mode: Hide Value Toggle  off (nil)
|    State: You have set this option and saved it through Customize in
|    your init file.
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Tooltips on w32 slow and strange

[Ralf Angeli]

* David Kastrup (2005-02-14) writes:

> Ralf Angeli <angeli@iwi.uni-sb.de> writes:
>
>> I just saw those tooltips the first time in my life by enabling
>> tooltip-mode and hovering with the mouse pointer over some menus
>> generated by AUCTeX.  If one is used to native GTK tooltips, the ones
>> generated by Emacs look really awkward.
>
> Uh what?  Tooltips are enabled by default.  At least I get them also
> with -q -no-site-file.  The customization buffer says, however,
[...]
> How comes that your Emacs behaves differently than mine?  Have you
> explicitly disabled tooltips, or am I just being crazy in some manner
> again?

It seems that I disabled them a long time ago:

tooltip-mode: Hide Value Toggle  off (nil)
   State: this option has been set and saved.

At least I cannot remember turning off the mode.  Maybe I repressed
that because I found them so ugly and disturbing. (c;

-- 
Ralf

Re: Tooltips on w32 slow and strange

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

> >There is a window class (is that the term?) TOOLTIPS_CLASS which can be
used
> >with CreateWindowEx. I am not an expert on this but there are examples in
> >MSDN.
> >
> >
> That documentation is for the "Common Controls" API, which is a
> constantly changing API, the availability of which depends on which
> version of Windows you have installed, and which other software you have
> installed that might have installed later versions.
>
> As such, I do not beleive that it fits the definition of "anything that
> is normally distributed (in either source or binary form) with the major
> components (compiler, kernel, and so on) of the operating system on
> which the executable runs", and certainly we cannot redistribute some
> version of it to guarantee minimum functionality above what was included
> in the original release of Windows NT.

Can you please explain more? The only information I can find says that
"minimum operating systems" is "NT 3.51, Windows 95" (that is for TOOLINFO
structure for example) or "Windows 95, NT 3.1" (CreateWindowEx).

Re: Tooltips on w32 slow and strange

[Stefan Monnier]

> I think this is the reason:

> ,----[ startup.el ]
> | (defun command-line ()
> | [...]
> |   (unless (or noninteractive
> | 	      emacs-quick-startup
> |               (not (display-graphic-p))
> |               (not (fboundp 'x-show-tip)))
> |     (setq-default tooltip-mode t)
> |     (tooltip-mode 1))
> `----

Yes I think this is wrong.
Instead, the defcustom of tooltip-mode should set the default value to

        (and (not noninteractive)
	     (not emacs-quick-startup)
	     (display-graphic-p)
	     (fboundp 'x-show-tip))

and then command-line should only do something like
(custom-reeval 'tooltip-mode) where custom-reeval is a new function that
re-sets the value of a custom var by re-evaluating the expression that
describes its default (or saved, or whatever) value,
i.e. something typically used when the value of the expression can change.


        Stefan


--- orig/lisp/tooltip.el
+++ mod/lisp/tooltip.el
@@ -187,25 +187,25 @@
 ;; would be accompanied by a full redisplay.
 
 ;;;###autoload
-(defun tooltip-mode (&optional arg)
+(define-minor-mode tooltip-mode
   "Mode for tooltip display.
 With ARG, turn tooltip mode on if and only if ARG is positive."
-  (interactive "P")
-  (unless (fboundp 'x-show-tip)
+  :init (and (not noninteractive)
+	     (not emacs-quick-startup)
+	     (display-graphic-p)
+	     (fboundp 'x-show-tip))
+  (unless (or (null tooltip-mode) (fboundp 'x-show-tip))
     (error "Sorry, tooltips are not yet available on this system"))
-  (let* ((on (if arg
-		 (> (prefix-numeric-value arg) 0)
-	       (not tooltip-mode)))
-	 (hook-fn (if on 'add-hook 'remove-hook)))
-    (setq tooltip-mode on)
+  (let ((hook-fn (if tooltip-mode 'add-hook 'remove-hook)))
     (funcall hook-fn 'change-major-mode-hook 'tooltip-change-major-mode)
     (tooltip-activate-mouse-motions-if-enabled)
     (funcall hook-fn 'pre-command-hook 'tooltip-hide)
     (funcall hook-fn 'tooltip-hook 'tooltip-gud-tips)
     (funcall hook-fn 'tooltip-hook 'tooltip-help-tips)
     (setq show-help-function (if on 'tooltip-show-help-function nil))
-    ;; `ignore' is the default binding for mouse movements.
+    ;; FIXME: why not use a minor mode map?
     (define-key global-map [mouse-movement]
+      ;; `ignore' is the default binding for mouse movements.
       (if on 'tooltip-mouse-motion 'ignore))))
 
 \f
@@ -521,22 +521,6 @@
     t))
 
 \f
-;;; Do this after all functions have been defined that are called from
-;;; `tooltip-mode'.  The actual default value of `tooltip-mode' is set
-;;; in startup.el.
-
-;;;###autoload
-(defcustom tooltip-mode nil
-  "Non-nil if Tooltip mode is enabled.
-Setting this variable directly does not take effect;
-use either \\[customize] or the function `tooltip-mode'."
-  :set (lambda (symbol value)
-	 (tooltip-mode (or value 0)))
-  :initialize 'custom-initialize-default
-  :type 'boolean
-  :require 'tooltip
-  :group 'tooltip)
-
 (provide 'tooltip)
 
 ;; arch-tag: 3d61135e-4618-4a78-af28-183f6df5636f

Re: Tooltips on w32 slow and strange

[Jan D.]

2005-02-14 kl. 13.26 skrev David Kastrup:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> Stephan Stahl wrote:
>>
>>> I reported this too a while ago but got no answer:
>>> http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00060.html
>>>
>>> As far as i understand tooltips on w32 emacs does not use normal
>>> w32-tooltips but special emacs frames that are stripped of everything
>>> (modeline, toolbar, minibuffer,...).  Maybe this could be changed..
>>>
>>>
>> Emacs uses frames for its tooltips on all platforms. To change this on
>> Windows would make it more difficult to maintain, and would lose
>> functionality.
>
> Are you sure about that?  Under X11, tooltips come without any
> decoration and without any impact on the focus (I have
> focus-follows-mouse policy).  I never noticed _any_ problem with them.

The focus policy is maintained by the window manager, but Emacs tool 
tips are created with override redirect on, which basically means that 
the window manager ignores them, i.e. no decoration, and no focus is 
given to them.

But the X server gives focus to any window when the pointer is over it 
(the window manager changes this for normal windows), so if you manage 
to get the pointer over a tool tip, it will receive the focus.  This is 
hard to do though :-)

W32 doesn't have a window manager, I guess that is the source of the 
problem.

>
> If users of Emacs on Windows experience similar effects, this will
> significantly hamper acceptance and usability.  So I'd strongly to
> those working on the Windows port to see whether something can be done
> in that regard.  I can't see at all what functionality could possibly
> be lost.  At least the X11 tooltips on Emacs provide no functionality
> whatsoever except popping up some text in a single font AFAICS.  No
> face support, no clickable areas, nothing.  So if there is a function
> for popping them up in the system, I can't see what we could lose by
> using it.

The tool tip frames can have any parameter set on them that an ordinary 
frame can have, so there is indeed face support and you can have 
another font also.  See the tool tip section in customize.

What you will loose is perhaps international characters.  Unless of 
course care is taken to convert from Emacs representation to whatever 
w32 uses (UTF8?).


	Jan D.

Re: Tooltips on w32 slow and strange

[David Kastrup]

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

> The tool tip frames can have any parameter set on them that an
> ordinary frame can have, so there is indeed face support and you can
> have another font also.  See the tool tip section in customize.

Yes, others pointed out that I had been babbling nonsense here.

> What you will loose is perhaps international characters.  Unless of
> course care is taken to convert from Emacs representation to
> whatever w32 uses (UTF8?).

I think that has been done with menu strings (which is probably what I
confused this with) on several platforms already, and it might also be
possible for tooltips.  However, I don't know how hard such a
conversion would turn out, and I don't know whether there exist any
serious applications that indeed require the interpretation of text
properties for tooltips.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Tooltips on w32 slow and strange

[Jan D.]

> * David Kastrup (2005-02-14) writes:
>
>> Miles Bader <snogglethorpe@gmail.com> writes:
>>
>>> Hmmm; here's a simple example:
>>>
>>>    (x-show-tip
>>>     (propertize "*** hello ***"
>>> 		'face '(variable-pitch :foreground "green"
>>> 				       :background "steelblue"
>>> 				       :height 3.0)))
>>
>> I have not been using x-show-tip directly ever but merely help-echo
>> properties, but that should make no difference.
>
> I just saw those tooltips the first time in my life by enabling
> tooltip-mode and hovering with the mouse pointer over some menus
> generated by AUCTeX.  If one is used to native GTK tooltips, the ones
> generated by Emacs look really awkward.

Care to elaborate?  The main difference is that GTK tool tips always 
seems to appear below a tool bar button, where as Emacs tool tips are 
some distance from the pointer.  The color and font also differs, but 
that can be customized.  Maybe we can make tool tips appear under the 
button if it is for a tool bar button.  Would that be better?

The problem with the font is that Emacs doesn't support anti aliased 
fonts (yet), but GTK uses them all over, even in tool tips.

	Jan D.

Re: Tooltips on w32 slow and strange

[Jan D.]

>> What you will loose is perhaps international characters.  Unless of
>> course care is taken to convert from Emacs representation to
>> whatever w32 uses (UTF8?).
>
> I think that has been done with menu strings (which is probably what I
> confused this with) on several platforms already, and it might also be
> possible for tooltips.  However, I don't know how hard such a
> conversion would turn out, and I don't know whether there exist any
> serious applications that indeed require the interpretation of text
> properties for tooltips.

The same procedure as for menu strings should work OK (well, at least 
as OK as for menus).

	Jan D.

Re: Tooltips on w32 slow and strange

[Ralf Angeli]

* Jan D. (2005-02-14) writes:

>> I just saw those tooltips the first time in my life by enabling
>> tooltip-mode and hovering with the mouse pointer over some menus
>> generated by AUCTeX.  If one is used to native GTK tooltips, the ones
>> generated by Emacs look really awkward.
>
> Care to elaborate?  The main difference is that GTK tool tips always 
> seems to appear below a tool bar button, where as Emacs tool tips are 
> some distance from the pointer.  The color and font also differs, but 
> that can be customized.  Maybe we can make tool tips appear under the 
> button if it is for a tool bar button.  Would that be better?
>
> The problem with the font is that Emacs doesn't support anti aliased 
> fonts (yet), but GTK uses them all over, even in tool tips.

The deficiencies you just mentioned pretty much sum up my concerns
with Emacs tooltips.  I don't care much about positioning, but the
difference in the font (font family, size, anti-aliasing) and color
used for tooltips alienates them from the rest of the environment.

Ideally there shouldn't be a need to customize the appearance of
tooltips.  It would be desirable if Emacs "simply" used tooltips
provided by the toolkit it was configured for (in case the toolkit
supports tooltips).  This would, for example, also eliminate the need
to re-customize their appearance in case one changes the theme of a
themeable toolkit.

But I guess there are more pressing things to do for the next
release.

-- 
Ralf

Re: Tooltips on w32 slow and strange

[Jan D.]

>
> Ideally there shouldn't be a need to customize the appearance of
> tooltips.  It would be desirable if Emacs "simply" used tooltips
> provided by the toolkit it was configured for (in case the toolkit
> supports tooltips).  This would, for example, also eliminate the need
> to re-customize their appearance in case one changes the theme of a
> themeable toolkit.
>
> But I guess there are more pressing things to do for the next
> release.

Actually this has been talked about before, as part of Emacs and 
GTK/Gnome integration.  I did some modifiactions to have Emacs use GTK 
tooltips when built for GTK, I guess I have that patch lying around 
somewhere.  I'll try to get it in after this release.

	Jan D.

Re: Tooltips on w32 slow and strange

[David Kastrup]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

> * Jan D. (2005-02-14) writes:
>>
>> The problem with the font is that Emacs doesn't support anti
>> aliased fonts (yet), but GTK uses them all over, even in tool tips.
>
> The deficiencies you just mentioned pretty much sum up my concerns
> with Emacs tooltips.  I don't care much about positioning, but the
> difference in the font (font family, size, anti-aliasing) and color
> used for tooltips alienates them from the rest of the environment.
>
> Ideally there shouldn't be a need to customize the appearance of
> tooltips.  It would be desirable if Emacs "simply" used tooltips
> provided by the toolkit it was configured for (in case the toolkit
> supports tooltips).  This would, for example, also eliminate the
> need to re-customize their appearance in case one changes the theme
> of a themeable toolkit.
>
> But I guess there are more pressing things to do for the next
> release.

I agree where matters of prettiness are involved.  However, where
usability is concerned, where the tip interferes with the workflow,
there changes should be considered.  In my experience, X11 tooltips
are currently fine in that regard, but the report from Windows users
sounded alarming to me.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Tooltips on w32 slow and strange

[Eli Zaretskii]

> Date: Tue, 15 Feb 2005 00:08:23 +0900
> From: Miles Bader <snogglethorpe@gmail.com>
> Cc: Stephan Stahl <stahl@eos.franken.de>, Emacs Devel <emacs-devel@gnu.org>,
> 	Jason Rumney <jasonr@gnu.org>
> 
> "Emacs Frame" tooltips seems to work really well in X11; why not just
> make them work well in Windows too?

FWIW, I use Emacs on Windows XP and never saw any special slowness of
the Emacs tooltips.

Re: Tooltips on w32 slow and strange

[Miles Bader]

On Mon, 14 Feb 2005 22:28:19 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
> > "Emacs Frame" tooltips seems to work really well in X11; why not just
> > make them work well in Windows too?
> 
> FWIW, I use Emacs on Windows XP and never saw any special slowness of
> the Emacs tooltips.

Might it be simply that Windows is very slow in window-creation (it is
reputedly much slower to create new OS processes than other OSes) and
the original poster has a very slow machine?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Tooltips on w32 slow and strange

[Jason Rumney]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Mon, 14 Feb 2005 22:28:19 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>> > "Emacs Frame" tooltips seems to work really well in X11; why not just
>> > make them work well in Windows too?
>> 
>> FWIW, I use Emacs on Windows XP and never saw any special slowness of
>> the Emacs tooltips.
>
> Might it be simply that Windows is very slow in window-creation (it is
> reputedly much slower to create new OS processes than other OSes) and
> the original poster has a very slow machine?

I think any slowness to create windows would not be perceptable, as it
would just mean a slightly longer delay before the tooltip pops
up. The perceived slowness I think is the delay between window
creation and drawing its contents. We might be able to hide the
tooltip window until it is completely drawn so the user does not see
this.

But the other problem of focus changing when tooltips pop up is more
urgent, I think.

Re: Tooltips on w32 slow and strange

[Lennart Borgman]

----- Original Message ----- 
From: "Miles Bader" <snogglethorpe@gmail.com>

> Might it be simply that Windows is very slow in window-creation (it is
> reputedly much slower to create new OS processes than other OSes) and
> the original poster has a very slow machine?

No. I would not believe so. Window-creation are very fundamental on w32. The
built in tooltips are windows too.

/ The Original Poster

Re: Tooltips on w32 slow and strange

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Miles Bader <snogglethorpe@gmail.com> writes:
>
>> On Mon, 14 Feb 2005 22:28:19 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>>> > "Emacs Frame" tooltips seems to work really well in X11; why not just
>>> > make them work well in Windows too?
>>> 
>>> FWIW, I use Emacs on Windows XP and never saw any special slowness
>>> of the Emacs tooltips.
>>
>> Might it be simply that Windows is very slow in window-creation (it
>> is reputedly much slower to create new OS processes than other
>> OSes) and the original poster has a very slow machine?
>
> I think any slowness to create windows would not be perceptable, as
> it would just mean a slightly longer delay before the tooltip pops
> up. The perceived slowness I think is the delay between window
> creation and drawing its contents. We might be able to hide the
> tooltip window until it is completely drawn so the user does not see
> this.

Uh, disagree.  The really disturbing effect of a tooltip popup is when
you type keys and Emacs basically appears to freeze without
explanation until the Windows pops up.  Once we start working on a
tooltip, response is gone until we finished the tooltip.  So it is
essential that we do the tooltip in the fastest possible way.  Double
buffering not only makes the operation slower, it also removes the
possibility of guessing just why the machine does not react
immediately.

> But the other problem of focus changing when tooltips pop up is more
> urgent, I think.

That too...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Tooltips on w32 slow and strange

[Kenichi Handa]

In article <fc339e4a0502141548500658c6@mail.gmail.com>, Miles Bader <snogglethorpe@gmail.com> writes:

> On Mon, 14 Feb 2005 22:28:19 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>>  > "Emacs Frame" tooltips seems to work really well in X11; why not just
>>  > make them work well in Windows too?
>>  
>>  FWIW, I use Emacs on Windows XP and never saw any special slowness of
>>  the Emacs tooltips.

> Might it be simply that Windows is very slow in window-creation (it is
> reputedly much slower to create new OS processes than other OSes) and
> the original poster has a very slow machine?

Isn't it better even in X11 to reuse a single tooltip frame
by mapping and unmapping instead of creating and destroying
it.

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

Re: Tooltips on w32 slow and strange

[Eli Zaretskii]

> Date: Tue, 15 Feb 2005 08:48:29 +0900
> From: Miles Bader <snogglethorpe@gmail.com>
> Cc: miles@gnu.org, lennart.borgman.073@student.lu.se, stahl@eos.franken.de, 
> 	emacs-devel@gnu.org, jasonr@gnu.org
> 
> Might it be simply that Windows is very slow in window-creation (it is
> reputedly much slower to create new OS processes than other OSes) and
> the original poster has a very slow machine?

I don't know.  How about if the OP tells us how much time it takes for
the tooltip to pop up, and what machine is that?

Re: Tooltips on w32 slow and strange

[Jan D.]

Kenichi Handa wrote:

> In article <fc339e4a0502141548500658c6@mail.gmail.com>, Miles Bader 
> <snogglethorpe@gmail.com> writes:
>
>> On Mon, 14 Feb 2005 22:28:19 +0200, Eli Zaretskii <eliz@gnu.org> 
>> wrote:
>>>> "Emacs Frame" tooltips seems to work really well in X11; why not 
>>>> just
>>>> make them work well in Windows too?
>>>
>>>  FWIW, I use Emacs on Windows XP and never saw any special slowness 
>>> of
>>>  the Emacs tooltips.
>
>> Might it be simply that Windows is very slow in window-creation (it is
>> reputedly much slower to create new OS processes than other OSes) and
>> the original poster has a very slow machine?
>
> Isn't it better even in X11 to reuse a single tooltip frame
> by mapping and unmapping instead of creating and destroying
> it.

Just a small bit.  In X11 a lot of windows are created (every button, 
menu, etc. are separate windows), and X11 is fast when it comes to 
window creation.  And in any case, we would have to apply the frame 
parameters again (font, color and such) and that still takes some time. 
  They could also be cached of course so we only re-apply what has been 
changed, but then I think it is more effort than it is worth.

	Jan D.

Re: Tooltips on w32 slow and strange

[Ralf Angeli]

* David Kastrup (2005-02-14) writes:

> Ralf Angeli <angeli@iwi.uni-sb.de> writes:
>
>> But I guess there are more pressing things to do for the next
>> release.
>
> I agree where matters of prettiness are involved.  However, where
> usability is concerned, where the tip interferes with the workflow,
> there changes should be considered.  In my experience, X11 tooltips
> are currently fine in that regard, but the report from Windows users
> sounded alarming to me.

Out of curiosity I checked for that focus issue with the latest
pre-compiled Emacs for Windows provided by nqmacs.sf.net.

It's quite easy to reproduce: Start Emacs (in my case there was no
site or user init file present) and type `C-x 5 2' to open a new
frame.  This frame will be on top of the original frame and have
focus.  Now move the mouse pointer onto an icon in the toolbar of the
new frame.  As soon as the tooltip wants to show up, the original
frame will come to front (but not get the focus).

-- 
Ralf

Re: Tooltips on w32 slow and strange

[Stephan Stahl]

Hi.

Eli Zaretskii said:

> I don't know.  How about if the OP tells us how much time it takes for
> the tooltip to pop up, and what machine is that?

I'm not the OP but using Miles Example and C-x C-e'ing it seems fast
enough and takes about half a second on an P4 2,4GHz running XP.

   (x-show-tip
    (propertize "*** hello ***"
                'face '(variable-pitch :foreground "green"
                                       :background "steelblue"
                                       :height 3.0)))

I'd like to provide some findings regarding the strange focus
handling:
emacs -q --no-site-init
C-x 2
C-x b bla	(make it easy to recognise the two frames)
put the mouse on the toolbar to create a popup works fine.
Alt-Tab	      (using XP to switch frames)
put the mouse on the toolbar to create a popup will NOT work right.
    	      (i do not even see the popup but the first frame with
	      the *scratch* buffer pops up while the second with the
	      bla buffer still has input focus.
	      Maybe it is the second frame with the bla buffer that
	      pops-under??? if this is possible..)

Now try doing the same thing but using C-x 5 o to switch the frames will
cause the popup to work just fine.  Does C-x 5 o some thing special
compared to Alt-tab?

Maybe this will help someone..

Stephan
-- 
Stephan Stahl

Re: Tooltips on w32 slow and strange

[Jason Rumney]

Stephan Stahl wrote:

>I'd like to provide some findings regarding the strange focus
>handling:
>emacs -q --no-site-init
>C-x 2
>C-x b bla	(make it easy to recognise the two frames)
>put the mouse on the toolbar to create a popup works fine.
>Alt-Tab	      (using XP to switch frames)
>put the mouse on the toolbar to create a popup will NOT work right.
>    	      (i do not even see the popup but the first frame with
>	      the *scratch* buffer pops up while the second with the
>	      bla buffer still has input focus.
>	      Maybe it is the second frame with the bla buffer that
>	      pops-under??? if this is possible..)
>
>Now try doing the same thing but using C-x 5 o to switch the frames will
>cause the popup to work just fine.  Does C-x 5 o some thing special
>compared to Alt-tab?
>  
>
It gives focus to an Emacs window. The same is seen if you switch focus 
by clicking on the title bar vs in the text area.

Re: Tooltips on w32 slow and strange

[Stephan Stahl]

Hi Jason.

Jason Rumney said:

> Stephan Stahl wrote:

>>Now try doing the same thing but using C-x 5 o to switch the frames will
>>cause the popup to work just fine.  Does C-x 5 o some thing special
>>compared to Alt-tab?
>>
> It gives focus to an Emacs window. The same is seen if you switch focus
> by clicking on the title bar vs in the text area.

But C-x 5 2 seems to do this too.  The frame gets the focus and is shown on
top of all other windows.  But there still seems to be a difference since
Alt-tab makes popups go wrong while C-x 5 2 does not..  I do not know the
code for both but maybe some other has more insight then me..

Stephan
-- 
Stephan Stahl

Re: Tooltips on w32 slow and strange

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 423 bytes --]

Stephan Stahl wrote:

>>>Now try doing the same thing but using C-x 5 o to switch the frames will
>>>cause the popup to work just fine.  Does C-x 5 o some thing special
>>>compared to Alt-tab?
>>>
>>>      
>>>
>>It gives focus to an Emacs window. The same is seen if you switch focus
>>by clicking on the title bar vs in the text area.
>>    
>>
>
>But C-x 5 2 seems to do this too.
>
My point was that Alt-tab does not.


[-- Attachment #1.2: Type: text/html, Size: 891 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Tooltips on w32 slow and strange

[Lennart Borgman]

----- Original Message ----- 
From: "Stephan Stahl" <stahl@eos.franken.de>

> But C-x 5 2 seems to do this too.  The frame gets the focus and is shown
on
> top of all other windows.  But there still seems to be a difference since
> Alt-tab makes popups go wrong while C-x 5 2 does not..  I do not know the
> code for both but maybe some other has more insight then me..

I think this helped me to realize what is happening. I am not quite sure but
I believe this is a good guess:

*** This is where the tooltip window gets created (I did not check further
to see if it where reused, but the timings suggests to me it is not):

>>>> w32fns.c >>>>
void
my_create_tip_window (f)
     struct frame *f;
{
...
  tip_window = FRAME_W32_WINDOW (f)
    = CreateWindow (EMACS_CLASS,
...
      FRAME_W32_WINDOW (SELECTED_FRAME ()), /* owner */
...
      NULL);
...
}


*** There is a SELECTED_FRAME above. As far as I understands it
SELECTED_FRAME is set by operations that Emacs recognize.

*** Emacs does not recognize Alt-Tab. This is the real problem and the case
we have here is just a special problem with its root in this.


I actually wrote about this when we discussed "Popup when buffer file is
changed on disk" which Moheb brought up. I implemented some code to take
care of this (but maybe it was on the wrong level).

I would suggest taking care of the message w32 sends when the user press
Alt-Tab. (This is some kind of "got focus message", but I do not know the
name at the moment.) The best would IMO to make a hook that is run when the
message is received. It could then be used to solve problems like "Popup
..." above too.

I am a bit surprised that this does not seem to happen on other platforms.
Or does it? I can not understand why, can anyone explain?

Re: Tooltips on w32 slow and strange

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 1013 bytes --]

Lennart Borgman wrote:

>I think this helped me to realize what is happening. I am not quite sure but
>I believe this is a good guess:
>
>*** This is where the tooltip window gets created (I did not check further
>to see if it where reused, but the timings suggests to me it is not):
>
>  
>
>>>>>w32fns.c >>>>
>>>>>          
>>>>>
>void
>my_create_tip_window (f)
>     struct frame *f;
>{
>...
>  tip_window = FRAME_W32_WINDOW (f)
>    = CreateWindow (EMACS_CLASS,
>...
>      FRAME_W32_WINDOW (SELECTED_FRAME ()), /* owner */
>...
>      NULL);
>...
>}
>
>
>*** There is a SELECTED_FRAME above. As far as I understands it
>SELECTED_FRAME is set by operations that Emacs recognize.
>  
>
It is probably a bug if focus gained messages from the OS do not set the 
selected frame, but no new Lisp hooks should be needed.

It does seem that any input prevents these focus problems, so it is 
possibly a case of a message being sent between the UI and Lisp threads, 
but not getting processed until input arrives.



[-- Attachment #1.2: Type: text/html, Size: 1583 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Tooltips on w32 slow and strange

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

> It is probably a bug if focus gained messages from the OS do not set the
> selected frame, but no new Lisp hooks should be needed.

Yes, no hook is needed for this and my idea of using the hook for this was
not the best one. It is just that I still think it would be useful sometimes
(as I have mentioned before).

> It does seem that any input prevents these focus problems, so it is
> possibly a case of a message being sent between the UI and Lisp threads,
> but not getting processed until input arrives.

Does not messages get processed as soon as they arrive?

Re: Tooltips on w32 slow and strange

[Stefan Monnier]

> Just a small bit.  In X11 a lot of windows are created (every button, menu,
> etc. are separate windows), and X11 is fast when it comes to window
> creation.  And in any case, we would have to apply the frame parameters
> again (font, color and such) and that still takes some time. They could also
> be cached of course so we only re-apply what has been changed, but then
> I think it is more effort than it is worth.

The tradeoffs are quite different when running X11 remotely, of course.


        Stefan

Re: Tooltips on w32 slow and strange

[Eli Zaretskii]

> Date: Tue, 15 Feb 2005 09:53:40 +0100 (CET)
> From: "Stephan Stahl" <stahl@eos.franken.de>
> Cc: snogglethorpe@gmail.com, miles@gnu.org, stahl@eos.franken.de,
> 	emacs-devel@gnu.org
> 
> I'm not the OP but using Miles Example and C-x C-e'ing it seems fast
> enough and takes about half a second on an P4 2,4GHz running XP.

This is the nominal time: the default value of tooltip-delay is 0.7
seconds.

So this is not slow, it's the normal delay.  Perhaps the OP should
play with the value of tooltip-delay.

Re: Tooltips on w32 slow and strange

[Oliver Scholz]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Mon, 14 Feb 2005 13:26:46 +0100, David Kastrup <dak@gnu.org> wrote:
>> At least the X11 tooltips on Emacs provide no functionality
>> whatsoever except popping up some text in a single font AFAICS.  No
>> face support, no clickable areas, nothing.
>
> Have you tried it?
>
> I've certainly used faces (and CJK characters etc) in Emacs tooltips
> [under X11] and they worked just great.
>
> Hmmm; here's a simple example:
>
>    (x-show-tip
>     (propertize "*** hello ***"
> 		'face '(variable-pitch :foreground "green"
> 				       :background "steelblue" 
> 				       :height 3.0)))
[...]

Coooool!

(x-show-tip
 (propertize "gnu"
             'display
             (create-image (expand-file-name "gnu.xpm" data-directory) 'xpm)))

Now I have to invent something to have an excuse to use something
like that somewhere.

    Oliver
-- 
Oliver Scholz               28 Pluviôse an 213 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.       

Re: Tooltips on w32 slow and strange

[Stephan Stahl]

Hi.

Some people have been looking into this..  Are there any news?

I remembered this old Mail from Lennart Borgman:
"Status bar gets face Mode Line Inactive after Alt-Tab"
http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00366.html

This seems to have the same cause as those problems with the tooltips
on w32.  When i use Alt-Tab the mode line does not get updated (still
the mode-line-inactive face) while it gets updated (mode-line face)
when using C-x 5 o.

Jason Rumney said it could be that the focus gained messages from the
OS are not handled correct.  Any tips to were i could start looking
for clues?  So far my knowledge of the emacs internals is very low..

Stephan
-- 
Stephan Stahl

Re: Tooltips on w32 slow and strange

[Stephan Stahl]

Hmm.. now that i started looking i have found a further symptom
and a new bug:

When using Alt-tab to switch frames the cursor blinking (if enabled)
does not start again.

On WXP:

emacs -Q
C-x 5 2
the cursor does not blink in this second frame. (BUG)
C-l
now it does blink
Alt-tab
the cursor in the first frame does not blink.
Alt-tab
back in the second frame the cursor does blink.

when using C-x 5 o:
emacs -Q
C-x 5 2
the cursor does not blink in this second frame. (still a BUG :-)
C-l
now it does blink
C-x 5 o
the cursor in the first frame does blink.
C-x 5 o
back in the second frame the cursor does blink.

Stephan
-- 
Stephan Stahl

Re: Tooltips on w32 slow and strange

[Jason Rumney]

Lennart has been looking at this. He sent me some replacement files for 
w32term.c etc, but I have not had time to look at it, and he has not had 
time to send it as a patch which would be more convenient for me.



Stephan Stahl wrote:

>Hi.
>
>Some people have been looking into this..  Are there any news?
>
>I remembered this old Mail from Lennart Borgman:
>"Status bar gets face Mode Line Inactive after Alt-Tab"
>http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00366.html
>
>This seems to have the same cause as those problems with the tooltips
>on w32.  When i use Alt-Tab the mode line does not get updated (still
>the mode-line-inactive face) while it gets updated (mode-line face)
>when using C-x 5 o.
>
>Jason Rumney said it could be that the focus gained messages from the
>OS are not handled correct.  Any tips to were i could start looking
>for clues?  So far my knowledge of the emacs internals is very low..
>
>Stephan
>  
>

Re: Tooltips on w32 slow and strange

[Lennart Borgman]

----- Original Message ----- 
From: "Stephan Stahl" <stahl@eos.franken.de>

> I remembered this old Mail from Lennart Borgman:
> "Status bar gets face Mode Line Inactive after Alt-Tab"
> http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00366.html
>
> This seems to have the same cause as those problems with the tooltips
> on w32.  When i use Alt-Tab the mode line does not get updated (still
> the mode-line-inactive face) while it gets updated (mode-line face)
> when using C-x 5 o.
>
> Jason Rumney said it could be that the focus gained messages from the
> OS are not handled correct.  Any tips to were i could start looking
> for clues?  So far my knowledge of the emacs internals is very low..

I wrote some code to take care of this, but it is not uploaded yet. It is
some changes to w32term.c, but I do not know if they are correct and want
others to look at it before it is uploaded. Mail me if you want a copy.