Peter Castine

So, I know how to make a floating window.

How do I get it to not disappear when bringing another app (say, 

I know it's non-standard Mac OS behavior, but it's not as if this 

would be the first instance of Max, how can I say this?... extending 

the User Interface beyond what Apple designed in the Mac UI guidelines.-

On this occasion I want to popup a small floating window with a 

dropfile object in it. I want the window to float so it can't 

accidently get covered by the main patch window (which is big, maybe 

800x600). This is no problem as long as you can see the file you 

want to drag while Max is frontmost *and* you take care to drag 

without interrupting the mouse action. If you click-on-file/release- 

mouse-button/mouse-down-to-drag (which is what a lot of people 

actually do), Finder is made frontmost and the dropfile window 

disappears into the abyss, a confusing and frustrating experience.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

How do I get it to not disappear when bringing another app (say,  
Finder) to the front? Can this be done?

I know it's non-standard Mac OS behavior, but it's not as if this  
would be the first instance of Max, how can I say this?... extending  
the User Interface beyond what Apple designed in the Mac UI guidelines.-

On this occasion I want to popup a small floating window with a  
dropfile object in it. I want the window to float so it can't  
accidently get covered by the main patch window (which is big, maybe  
800x600). This is no problem as long as  you can see the file you  
want to drag while Max is frontmost *and* you take care to drag  
without interrupting the mouse action. If you click-on-file/release- 
mouse-button/mouse-down-to-drag (which is what a lot of people  
actually do), Finder is made frontmost and the dropfile window  
disappears into the abyss, a confusing and frustrating experience.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

window-flags-float-window-exec

On 29-nov-2006, at 19:22, Peter Castine wrote:

> So, I know how to make a floating window.

> How do I get it to not disappear when bringing another app (say, 

> Finder) to the front? Can this be done?

> I know it's non-standard Mac OS behavior, but it's not as if this 

> would be the first instance of Max, how can I say this?... 

> extending the User Interface beyond what Apple designed in the Mac 

> On this occasion I want to popup a small floating window with a 

> dropfile object in it. I want the window to float so it can't 

> accidently get covered by the main patch window (which is big, 

> maybe 800x600). This is no problem as long as you can see the file 

> you want to drag while Max is frontmost *and* you take care to drag 

> without interrupting the mouse action. If you click-on-file/release- 

> mouse-button/mouse-down-to-drag (which is what a lot of people 

> actually do), Finder is made frontmost and the dropfile window 

> disappears into the abyss, a confusing and frustrating experience.

Drag&Drop initiated from the finder-in-foreground is able to drop 

into a window of an application-in-background.

I just tried dropping a file from finder-in-fg to the DropRegion help 

So I do not understand what you mean by the window "dissappearing 

If the problem is that the max window gets covered by finder windows 

- use cmd-tab to cycle apps (yes this can be done while DnD is in 

But I expect that this is not in everyone's toolbox.

I know of only one instance of a window that is on top of everything 

the "Force Quit Applications" dialog. But that is not an application.

And there is the "About this Mac" dialog, which is also on top of 

(except force quit), and it really looks like a floating window.

> A real question.
>
> So, I know how to make a floating window.
>
> How do I get it to not disappear when bringing another app (say,  
> Finder) to the front? Can this be done?
>
> I know it's non-standard Mac OS behavior, but it's not as if this  
> would be the first instance of Max, how can I say this?...  
> extending the User Interface beyond what Apple designed in the Mac  
> UI guidelines.-
>
> On this occasion I want to popup a small floating window with a  
> dropfile object in it. I want the window to float so it can't  
> accidently get covered by the main patch window (which is big,  
> maybe 800x600). This is no problem as long as  you can see the file  
> you want to drag while Max is frontmost *and* you take care to drag  
> without interrupting the mouse action. If you click-on-file/release- 
> mouse-button/mouse-down-to-drag (which is what a lot of people  
> actually do), Finder is made frontmost and the dropfile window  
> disappears into the abyss, a confusing and frustrating experience.
>
> Any ideas?
>
> Thanks,
> Peter

I am not sure whaty the problem is.
Drag&Drop initiated from the finder-in-foreground is able to drop  
into a window of an application-in-background.
I just tried dropping a file from finder-in-fg to the DropRegion help  
patch open in max-in-bg.
This is on MacOS 10.4.8
So I do not understand what you mean by the window "dissappearing  
when bringing another app to the front"

If the problem is that the max window gets covered by finder windows  
the moment the finder goes foreground,
then this is what I do
- initiate drag in finder-in-fg
- use cmd-tab to cycle apps (yes this can be done while DnD is in  
progress)
- use cmd-~ to cycle windows in max
- terminate drag by dropping on target
But I expect that this is not in everyone's toolbox.

I know of only one instance of a window that is on top of everything  
else no-matter-what:
the "Force Quit Applications" dialog. But that is not an application.
And there is the "About this Mac" dialog, which is also on top of  
everything else
(except force quit), and it really looks like a floating window.
Maybe you can do this from a C external?

what about using the output from the 'active' object to twiddle 

On Nov 29, 2006, at 1:22 PM, Peter Castine wrote:

> Peter Castine +--> Litter Power & Litter Bundle for Jitter

> Interface Building for |home | chez nous|

> Max/MSP Extremely cool |bei uns | i nostri|

what about using the output from the 'active' object to twiddle  
@floating?

> A real question.
>
> So, I know how to make a floating window.
>
> How do I get it to not disappear when bringing another app (say,  
> Finder) to the front? Can this be done?
>
> I know it's non-standard Mac OS behavior, but it's not as if this  
> would be the first instance of Max, how can I say this?...  
> extending the User Interface beyond what Apple designed in the Mac  
> UI guidelines.-
>
> On this occasion I want to popup a small floating window with a  
> dropfile object in it. I want the window to float so it can't  
> accidently get covered by the main patch window (which is big,  
> maybe 800x600). This is no problem as long as  you can see the file  
> you want to drag while Max is frontmost *and* you take care to drag  
> without interrupting the mouse action. If you click-on-file/release- 
> mouse-button/mouse-down-to-drag (which is what a lot of people  
> actually do), Finder is made frontmost and the dropfile window  
> disappears into the abyss, a confusing and frustrating experience.
>
> Any ideas?
>
> Thanks,
> Peter
>
> --------------    http://www.bek.no/~pcastine/Litter/    -------------
> Peter Castine             +--> Litter Power & Litter Bundle for Jitter
>                                Universal Binaries on the way
> iCE:  Sequencing,  Recording &
>       Interface  Building  for                   |home    | chez nous|
>       Max/MSP   Extremely cool                   |bei uns |  i nostri|
>       http://www.dspaudio.com/                   http://www.castine.de
>
>
>


whoops. 'active' doesn't twiddle if the application changes. hmph.

On Nov 29, 2006, at 4:06 PM, joshua goldberg wrote:

> what about using the output from the 'active' object to twiddle 

> On Nov 29, 2006, at 1:22 PM, Peter Castine wrote:

>> So, I know how to make a floating window.

>> How do I get it to not disappear when bringing another app (say, 

>> Finder) to the front? Can this be done?

>> I know it's non-standard Mac OS behavior, but it's not as if this 

>> would be the first instance of Max, how can I say this?... 

>> extending the User Interface beyond what Apple designed in the Mac 

>> On this occasion I want to popup a small floating window with a 

>> dropfile object in it. I want the window to float so it can't 

>> accidently get covered by the main patch window (which is big, 

>> maybe 800x600). This is no problem as long as you can see the 

>> file you want to drag while Max is frontmost *and* you take care 

>> to drag without interrupting the mouse action. If you click-on- 

>> file/release-mouse-button/mouse-down-to-drag (which is what a lot 

>> of people actually do), Finder is made frontmost and the dropfile 

>> window disappears into the abyss, a confusing and frustrating 

>> Peter Castine +--> Litter Power & Litter Bundle for 

whoops.  'active' doesn't twiddle if the application changes.  hmph.

> what about using the output from the 'active' object to twiddle  
> @floating?
>
> On Nov 29, 2006, at 1:22 PM, Peter Castine wrote:
>
>> A real question.
>>
>> So, I know how to make a floating window.
>>
>> How do I get it to not disappear when bringing another app (say,  
>> Finder) to the front? Can this be done?
>>
>> I know it's non-standard Mac OS behavior, but it's not as if this  
>> would be the first instance of Max, how can I say this?...  
>> extending the User Interface beyond what Apple designed in the Mac  
>> UI guidelines.-
>>
>> On this occasion I want to popup a small floating window with a  
>> dropfile object in it. I want the window to float so it can't  
>> accidently get covered by the main patch window (which is big,  
>> maybe 800x600). This is no problem as long as  you can see the  
>> file you want to drag while Max is frontmost *and* you take care  
>> to drag without interrupting the mouse action. If you click-on- 
>> file/release-mouse-button/mouse-down-to-drag (which is what a lot  
>> of people actually do), Finder is made frontmost and the dropfile  
>> window disappears into the abyss, a confusing and frustrating  
>> experience.
>>
>> Any ideas?
>>
>> Thanks,
>> Peter
>>
>> --------------    http://www.bek.no/~pcastine/Litter/     
>> -------------
>> Peter Castine             +--> Litter Power & Litter Bundle for  
>> Jitter
>>                                Universal Binaries on the way
>> iCE:  Sequencing,  Recording &
>>       Interface  Building  for                   |home    | chez  
>> nous|
>>       Max/MSP   Extremely cool                   |bei uns |  i  
>> nostri|
>>       http://www.dspaudio.com/                   http:// 
>> www.castine.de
>>
>>
>>
>
>


You don't want a conventional floating window, which by definition disappears when in the background. David Z kindly added a new command to thispatcher a year or so ago:

Note you need a regular window, so you won't have the "skinny" titlebar you would with a floating window (though this is technically possible in OS X).

On 29-Nov-2006, at 22:42, John Pitcairn wrote:

> David Z kindly added a new command to thispatcher a year or so ago:

> Note you need a regular window, so you won't have the "skinny" 

> titlebar you would with a floating window (though this is 

I must have forgotten the annoucement of the topmost message. (Shame, 

I think we can live without the skinny title bar.

> You don't want a conventional floating window, which by definition 

Well, floating windows disappear by _convention_ (actually Macintosh 

User Interface Guideline #437b, section IV, subsection d.ii). Someone 

actually has to write code to make them do that (or rely on a 

framework that provides the code that makes 'em do that). The three 

attributes (skinny title bar, floating behavior, disappear-when-not- 

foreground-app) can be independent of each other. But this is just 

nit-picking, for which I apologize. In general it is right and proper 

On 29-Nov-2006, at 21:28, jennek geels wrote:

> Drag&Drop initiated from the finder-in-foreground is able to drop 

> into a window of an application-in-background.

The problem isn't drag&drop, the problem is that if the patcher 

window has a loadbang -> 'window float, window exec' -> thispatcher 

in it, the window ain't _there_ anymore. No window, no dropregion. 

On 29-Nov-2006, at 22:26, joshua goldberg wrote:

> whoops. 'active' doesn't twiddle if the application changes. hmph.

Once upon a time I think I wrote an external that twiddled when the 

app switched. Not sure if it would work on OS X though. Wonder where 

On 29-Nov-2006, at 22:42, John Pitcairn wrote:
> David Z kindly added a new command to thispatcher a year or so ago:
>
> topmost 1
>
> Note you need a regular window, so you won't have the "skinny"  
> titlebar you would with a floating window (though this is  
> technically possible in OS X).

I must have forgotten the annoucement of the topmost message. (Shame,  
shame!)

> You don't want a conventional floating window, which by definition  
> disappears when in the background.

Well, floating windows disappear by _convention_ (actually Macintosh  
User Interface Guideline #437b, section IV, subsection d.ii). Someone  
actually has to write code to make them do that (or rely on a  
framework that provides the code that makes 'em do that). The three  
attributes (skinny title bar, floating behavior, disappear-when-not- 
foreground-app) can be independent of each other. But this is just  
nit-picking, for which I apologize. In general it is right and proper  
that the float window disappears.

On 29-Nov-2006, at 21:28, jennek geels wrote:
> Drag&Drop initiated from the finder-in-foreground is able to drop  
> into a window of an application-in-background.

The problem isn't drag&drop, the problem is that if the patcher  
window has a loadbang -> 'window float, window exec' -> thispatcher  
in it, the window ain't _there_ anymore. No window, no dropregion.  
Poof. Vanish. Gone.

On 29-Nov-2006, at 22:26, joshua goldberg wrote:
> whoops.  'active' doesn't twiddle if the application changes.  hmph.

Once upon a time I think I wrote an external that twiddled when the  
app switched. Not sure if it would work on OS X though. Wonder where  
the code is?...

On 29 Nov 2006, at 23:21, Peter Castine wrote:

> The three attributes (skinny title bar, floating behavior, 

> disappear-when-not-foreground-app) can be independent of each other.

This we know: just look at the way the Apple Mail program presets a 

skinny-title-bar windows which neither floats or disappears...

In Max, floating windows present a problem: keyboard focus and 

keyboard control/navigation (e.g. for numericals) tend to get screwed 

nick rothwell -- composition, systems, performance -- 

> The three attributes (skinny title bar, floating behavior,  
> disappear-when-not-foreground-app) can be independent of each other.

This we know: just look at the way the Apple Mail program presets a  
skinny-title-bar windows which neither floats or disappears...

In Max, floating windows present a problem: keyboard focus and  
keyboard control/navigation (e.g. for numericals) tend to get screwed  
up.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


Quote: Peter Castine wrote on Thu, 30 November 2006 12:21

----------------------------------------------------

> Once upon a time I think I wrote an external that twiddled when 

> the app switched. Not sure if it would work on OS X though.

Almost certainly not I suspect. I'm sporadically trying to track down the appropriate (Carbon?) API and hopefully some sample code to receive an OS notification when the foreground app changes in OS X. Must have another poke around Apple's developer docs...

An object that spits out the name of the current active app when banged, and spits out the name when it changes, could be very very useful to my users.

Quote: Peter Castine wrote on Thu, 30 November 2006 12:21
----------------------------------------------------
> Once upon a time I think I wrote an external that twiddled when 
> the app switched. Not sure if it would work on OS X though. 

An object that spits out the name of the current active app when banged, and spits out the name when it changes, could be very very useful to my users.


>> Note you need a regular window, so you won't have the "skinny" 

>> titlebar you would with a floating window (though this is technically 

Don't close it automatically, it will crash:

Open this patch, drag something onto it from Finder...

Crashes here reproducable - Powerbook 10.4.8, Max 4.6.2

(I wonder if the support reads these infos deep in an existing thread...)

Peter Castine wrote:
>> topmost 1
>>
>> Note you need a regular window, so you won't have the "skinny"  
>> titlebar you would with a floating window (though this is  technically 
>> possible in OS X).
>
>
> Thanks, just what the Doctor ordered.

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


I had/have lots of problems with switching/opening/closing windows in Max with several fullscreen 1 windows. I reported this to support months ago.

One of the many things/objects in Max that will bite you when you think they're relatively safe (I mean they're not heavy duty real-time scheduler stuff)

I've experienced similar problems when opening an OS file-save if any window is topmost. If the file dialog opens another dialog (replace?), that's a sure-fire crash.

I reported this as a bug, the response was that it's not remotely a priority (understandable I guess).

So it's necessary to set all topmost windows back to non-topmost before my file dialog opens, in case the user replaces a file, then set those back to topmost when the dialog is done with. Sigh.

In the auto-close case, try sending topmost 0 before wclose.

> I reported this as a bug, the response was that it's not remotely a

??? not understandable ! Any crash should be fixed... A fix might solve 

other problems as well. It might be that someone else (apple) has to fix 

it, but a crash caused by normal user behaviour should be fixed in any 

> So it's necessary to set all topmost windows back to non-topmost

> before my file dialog opens, in case the user replaces a file, then

> set those back to topmost when the dialog is done with. Sigh.

> In the auto-close case, try sending topmost 0 before wclose.

Thanks for the workaround, but I'd like to know the connection/reason 

why its crashing (I guess if there is an answer for it, there is a fix 

John Pitcairn wrote:
> I reported this as a bug, the response was that it's not remotely a
> priority (understandable I guess).

??? not understandable ! Any crash should be fixed... A fix might solve 
other problems as well. It might be that someone else (apple) has to fix 
it, but a crash caused by normal user behaviour should be fixed in any 
case.

> So it's necessary to set all topmost windows back to non-topmost
> before my file dialog opens, in case the user replaces a file, then
> set those back to topmost when the dialog is done with. Sigh.
>
> In the auto-close case, try sending topmost 0 before wclose.

Thanks for the workaround, but I'd like to know the connection/reason 
why its crashing (I guess if there is an answer for it, there is a fix 
as well...)

window flags float, window exec