Xref: utzoo comp.sys.mac.programmer:5465 comp.sys.mac:29728 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!indri!eta!nic.MR.NET!srcsip!gorby!mnkonar From: mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) Newsgroups: comp.sys.mac.programmer,comp.sys.mac Subject: Re: Why no Command/Drag under MultiFinder? Keywords: MultiFinder Message-ID: <20173@srcsip.UUCP> Date: 7 Apr 89 22:27:50 GMT References: <1562@neoucom.UUCP> <28399@apple.Apple.COM> <1706@etive.ed.ac.uk> Sender: news@src.honeywell.COM Reply-To: mnkonar@gorby.UUCP (Murat N. Konar) Organization: Honeywell Systems & Research Center, Camden, MN Lines: 30 In article <1706@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >Just a quick observation. The finder allows Command/drag on inactive >windows; they move around, but don't come to the front and don't >become active. I recall this facility being in the interface >guidelines, so conformant applications should do it as well, although >I don't know how many do (MOTU's Performer doesn't, which is irritating >me). > So: why doesn't this paradigm extend to MultiFinder? If I'm running >MacFoo in as the foreground application, shouldn't I be able to command/drag >the finder windows around without otherwise waking the finder up? And the >other way round, of course... Or is there something about "layers" which >makes this undesirable or difficult to do? I think that the list of windows is maintained such that each applications windows are in a layer unique to that application. I.E. the linked list of windows is switched in and out with the application, so as far as the finder (or anyone else) is concerned, windows of an application in the background are non-existent. I agree that it would be nice if MF could do what you want it to. Maybe in the future. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)