Re: [MACTCL] Popup Boxes on MacTclTk

[Jim I. <ji...@ap...>]

Daniel,

On Tuesday, August 28, 2001, at 05:07  PM, Daniel A. Steffen wrote:

> Jim,
>
> At 9:35 -0700 on 28/8/01, Jim Ingham wrote:
>> I don't think you want to make the overrideredirect windows float, 
>> since overrideredirect  only changes look, not behavior on X11 and 
>> Windows, but floating windows have different behavior (for instance 
>> they vanish when the Application is backgrounded, and they don't 
>> receive keystrokes).
>
> well on unix overrideredirect changes behaviour as a consequence of the 
> fact that the window is no longer a normal window, i.e. the window 
> manager ignores it for the purposes of <enter>/<leave>  and focus 
> detection, doesn't decorate it etc. There seems to be no way to get 
> exactly that behaviour in the current (pre Carbon) MacOS Window Manager.

Yeah, but Tk handles most enter/leave tracking and focus change on its 
own, and doesn't rely on the window managers for most of this stuff, so 
I am not sure how much difference this would make.  In my experience 
with X11 Tk widget behavior doesn't much change when in an 
overrideredirect window.  It might cause problems to change this.

>
>
> as I said I don't think making overrideredirect windows float is really 
> a good solution, but in some sense it is as bad as the current 
> behaviour, with the looks now wrong but more correct behaviour...


Not sure.  Have to check a few X11 Tk apps that use overrideredirect 
windows for something substantial.

>
>
> maybe a better solution would be to modify GeneratePollingEvents() to 
> not only ignore floating windows in front of the current window but 
> also windows with the override_redirect flag set. Possibly this could 
> also be achieved by changing TkpIsWindowFloating() to check for 
> override_redirect. Maybe this is worth a try?
> (unix TkpChangeFocus() seems to do something similar to cope with 
> certain X window managers, i.e. it ignores windows with 
> override_redirect set)
>
>> The better solution here is to add the kHelpWindowClass window type to 
>> the list of types in unsupported1.  This is available only in 
>> carbonlib 1.1, but that is fairly common, and not hard to install on 
>> older (8.5 era) machines. This gives you the correct help tag look 
>> (which is more than just overrideredirect.)
>
> the problem is that you can't use carbon features selectively, if you 
> want to use any carbon feature such as the kHelpWindowClass you have to 
> go carbon all the way, which we can't really do with classic Tk...

This isn't true in this case.  TkMacHaveAppearance returns the 
Appearance version, so when you got a request for a help window passed 
into unsupported1 you would pass kHelpWindowClass to the CreateWindow 
cal if the Appearance version is > 1.1, and one of the floating windows 
members of the enum otherwise.  It is not even a different API, it is 
just some number passed to the Window Manager API's.

>
> Do you know how OS9 popup balloons get the window manger to essentially 
> ignore them?  popup balloons would seem to have features equivalent to 
> what we would like for overrideredirect... I suspect this  was done by 
> hacking a custom case into OS window layering code though.

I haven't had time to poke around in the Classic Window Manager code at 
all, so no, I don't know how it works.

>
>
> In any case for the purpose of Tk popup balloons, the 'unsupported1 
> style  floating sideTitlebar' solution works well enough for me, the 
> looks aren't so bad (see attached), so this is not really an urgent 
> problem.
>

Yeah, but on systems that support it, the real help tag window is lots 
nicer.  I will send you the patches I made for the X version if you want 
when I get in to work tomorrow, and if somebody feels like 
conditionalizing it for different Appearance versions, they are 
welcome...

Jim
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
ji...@ap...
Developer Tools - gdb