window flags float, window exec
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
On 29-nov-2006, at 19:22, 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
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?
HtH
-jennek
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
>
>
>
whoops. 'active' doesn't twiddle if the application changes. hmph.
feature request!
j
On Nov 29, 2006, at 4:06 PM, joshua goldberg wrote:
> 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:
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).
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).
Thanks, just what the Doctor ordered.
I must have forgotten the annoucement of the topmost message. (Shame,
shame!)
I think we can live without the skinny title bar.
> 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?...
-------------- 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
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
up.
-- N.
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.
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.
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...)
Stefan
--
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.
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...)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com