klingspo@mozart.cs.colostate.edu (Steve Klingsporn) (03/05/91)
Hey, people. If you FTP to 'sumex.stanford.edu,' and cd to 'info-mac/init,' there is a cool INIT w/ a March, 4, 1991 date on it, called "Real Drag." It lets you drag windows (any -- color, too unlike previous hacks) around on the screen a la NeXT -- it's kinda neat, but a bit slow. steve
rosen@cs.utexas.edu (Eric Carl Rosen) (03/05/91)
"Real Drag" is nice, and certainly better than nothing for those of us who have always hated dragging dotted outlines of windows around, but it could be improved. There's no reason for the contents of the window to be lost while dragging if you happen to move part of the window off-screen, except of course, the memory requirements. This should be an option. There's no reason for the contents of background windows over which we drag to be lost (except for the window titlebar), except of course, the memory requirements. This should also be an option. There is another INIT at sumex called 'Dragger' which works perfectly, albeit ONLY in 1-bit mode (It has no effect at higher depths). 'Dragger' is also faster than "Real Drag" (in 1-bit mode, of course). This kind of visual feedback is _very_ useful, especially in a Multifinder environment. I'm surprised that Apple hasn't implemented a toolbox call in addition to DragWindow() that drags the entire window, as opposed to the dotted outline. --Eric
tagreen@bronze.ucs.indiana.edu (Todd A. Green) (03/06/91)
In article <13366@ccncsu.ColoState.EDU> klingspo@mozart.cs.colostate.edu (Steve Klingsporn) writes: > > >Hey, people. > >If you FTP to 'sumex.stanford.edu,' and cd to 'info-mac/init,' there >is a cool INIT w/ a March, 4, 1991 date on it, called "Real Drag." > >It lets you drag windows (any -- color, too unlike previous hacks) >around on the screen a la NeXT -- it's kinda neat, but a bit slow. > > >steve I got the INIT and thought it was an interesting concept for a program that I had thought of doing myself. My main gripe is that is does not keep track of the pixels that the windows get's dragged over. That is to say if you should drag your window over your trash icon the trash icon gets erased and is not redrawn. Not having the source I cannot comment on how it was written, but I would have kept an image of the screen in an offscreen buffer and would not have only updated the dragged window but also the area in which it was before it was dragged. While this would cause the update region to increase in size and thus slow down the "animation" it would be more aesthetically pleasing. Todd ============================================================================== Todd A. Green "<_CyberWolf_>" ---> Pascal <- tagreen@ucs.indiana.edu Unix Systems Administration ---> Unix <--- tagreen@silver.ucs.indiana.edu Macintosh Systems Administration ---> VMS <---- tagreen@bronze.ucs.indiana.edu WCC Office:136.04 phone:855-0949 ---> C <------ tagreen@lothario.ucs.indiana "Friends don't let friends ---> Mac <---- tagreen@iubacs.BITNET Use DOS" - Scott Ostrander ---> SunOS <-- tagreen@lykos (FTP only) ==============================================================================
dawg6844@uxa.cso.uiuc.edu (<blank>) (03/06/91)
tagreen@bronze.ucs.indiana.edu (Todd A. Green) writes: {stuff deleted here so you don't have to read it again...} >I got the INIT and thought it was an interesting concept for a program >that I had thought of doing myself. My main gripe is that is does not >keep track of the pixels that the windows get's dragged over. That is >to say if you should drag your window over your trash icon the trash >icon gets erased and is not redrawn. >Not having the source I cannot comment on how it was written, but I >would have kept an image of the screen in an offscreen buffer and >would not have only updated the dragged window but also the area in >which it was before it was dragged. While this would cause the update >region to increase in size and thus slow down the "animation" it would >be more aesthetically pleasing. >Todd >============================================================================== >Todd A. Green "<_CyberWolf_>" ---> Pascal <- tagreen@ucs.indiana.edu >Unix Systems Administration ---> Unix <--- tagreen@silver.ucs.indiana.edu >Macintosh Systems Administration ---> VMS <---- tagreen@bronze.ucs.indiana.edu >WCC Office:136.04 phone:855-0949 ---> C <------ tagreen@lothario.ucs.indiana >"Friends don't let friends ---> Mac <---- tagreen@iubacs.BITNET > Use DOS" - Scott Ostrander ---> SunOS <-- tagreen@lykos (FTP only) >============================================================================== So DO it, 'cyberwolf'. ________________________________________________________________________________ Dan Walkowski | To understand recursion, Univ. of Illinois, Dept. of Comp. Sci. | you must first understand recursion. walkowsk@cs.uiuc.edu | -- ________________________________________________________________________________ Dan Walkowski | To understand recursion, Univ. of Illinois, Dept. of Comp. Sci. | you must first understand recursion. walkowsk@cs.uiuc.edu |
rosen@cs.utexas.edu (Eric Carl Rosen) (03/06/91)
In a previous post, I alluded to a similar program, Dragger, which performs a similar function to "Real Drag" except slightly faster, a bit more aesthetically, and only in 1-bit mode. I incorrectly stated that Dragger was available at sumex. It is my recollection that it was, but it is no longer there if it actually were. The author of Dragger, Oliver Steele <steele@cs.unc.edu>, gives permission to distribute Dragger in a non-commerical context only. If you are interested in comparing Dragger with "Real Drag", I'll either e-mail you a copy or post to comp.binaries.mac if interests warrants. I'd also like to encourage anybody who would like to improve on the ground broken by Dragger and now "Real Drag". If you want to bounce ideas off me, feel free. --Eric (rosen@cs.utexas.edu)
6600dtam@ucsbuxa.ucsb.edu (Marc "Tae-Kwon" Tamsky) (03/06/91)
Just as an aside....it doesn't work with Stuffit Deluxe's windows i.e. it has no effect, no it doesn't crash in SD. I wonder why....? -- = Marc Tamsky Under Capitalism, man expoits man. = = 6600dtam@ucsbuxa.ucsb.edu Under Communism, it's just the opposite. = = POB 12600, UCSB -J K Galbraith. = = Santa Barbara, CA 93107 (805)-562-5645 =
rosen@cs.utexas.edu (Eric Carl Rosen) (03/07/91)
[Marc "Tae-Kwon" Tamsky] wonders:
>Just as an aside....it doesn't work with Stuffit Deluxe's windows
Well, I don't own Stuffit Deluxe, so this is just conjecture, but my guess
is the author doesn't call the toolbox function DragWindow() in response to
a mouseDown event in the window titlebar. Instead, the author probably uses
his own function, for whatever reason(s).
--Erictagreen@bronze.ucs.indiana.edu (Todd A. Green) (03/07/91)
> [more stuff deleted] > >So DO it, 'cyberwolf'. > > >________________________________________________________________________________ >Dan Walkowski | To understand recursion, >Univ. of Illinois, Dept. of Comp. Sci. | you must first understand recursion. >walkowsk@cs.uiuc.edu | >-- I wish that I had the time to pursue all my interests, but seeing as how I am a student and work full time for the university, my time is rather limited. Besides why redo what someone else has already done? James Osborn has already written a good program. I was merely offering some suggestions as how to improve it. It would be more sensible for him to come out with an update than for someone else to start from scratch. If you'd personally like to have some code examples off how to create and use offscreen gworlds I'd be more than happy to mail them too you. But I believe discussions like these are meant for email, so could we please confine them to that domain so that others don't have to suffer? Todd ============================================================================== Todd A. Green "<_CyberWolf_>" ---> Pascal <- tagreen@ucs.indiana.edu Unix Systems Administration ---> Unix <--- tagreen@silver.ucs.indiana.edu Macintosh Systems Administration ---> VMS <---- tagreen@bronze.ucs.indiana.edu WCC Office:136.04 phone:855-0949 ---> C <------ tagreen@lothario.ucs.indiana "Friends don't let friends ---> Mac <---- tagreen@iubacs.BITNET Use DOS" - Scott Ostrander ---> SunOS <-- tagreen@lykos (FTP only) ==============================================================================
klingspo@mozart.cs.colostate.edu (Steve Klingsporn) (03/08/91)
I agree with Real Drag INIT's shortcomings. I have felt this, but honestly was way too lazy to post a news article about it. It'd be nice (yet would slow things down) if what the window overlaps (notice that window outlines are preserved!) is drawn back as the window moves. Here's a question: IS THERE an INIT out there that allows you to "Set Screen Depths" for files? e.g., Set up an entry for "Karnov" (16 colors), and thus avoid the annoyance of switching the screen? I know about Switch-A-Roo. Steve Klingsporn
hardin@dino.cad.mcc.com (John Hardin) (03/08/91)
Steve Klingsporn writes: > > Here's a question: IS THERE an INIT out there that allows you to > "Set Screen Depths" for files? e.g., Set up an entry for "Karnov" > (16 colors), and thus avoid the annoyance of switching the screen? > I know about Switch-A-Roo. Steve, Check out HandOffII. It's similar to OnCue in its file launching capabilities, but for each file in the HandOff menu you can associate a sound level *and* a color depth. It also has the notions of Briefcases and Categories. These allow files to be logically grouped (i.e., hierarchy). I do *not* know if you can have Briefcases/Categories inside of each other (i.e., if the hierarchy is deeper than 2 levels). Briefcases are neat in that you can optionally launch *all* of the files within them in one "swell foop". Right at the end of *last* year, I was able to upgrade from DiskTools for the index page from the manual and $29.95. Considering HandOffII sells for $50-52 from MacConnection and the like, I think I got a great deal. One shortcoming with HandOffII I've noticed is that you can't *individually* assign sound/color levels to files within Briefcases/Categories. For example, I wanted to have a Category called "Games". In it I wanted to place, among others, Klondike and Solarian. Solarian requires 256 colors while Klondike only needs 16. I could *not* configure the HandOff menu this way. (Yeah, I know...*silly*!) What I had to do was create *separate* Categories called "Games (16)" and "Games (256)". It's not that bad, but it's not optimal, either. Outside of this minor deficiency, I think it's a great product. I recommend you check it out. NOTE: I have no affiliation with HandOffII, the HandOff Corporation (the *former* owners), or the Connectix Corporation (the *new* owners) other than as a satisfied customer. -jwh -- John Hardin MCC CAD Program AT&T: 512/338-3535 3500 W. Balcones Center Drive ARPA: hardin@mcc.com Austin, TX 78759-6509 UUCP: {harvard,gatech,uunet}!cs.utexas.edu!hardin%mcc.com
rosen@cs.utexas.edu (Eric Carl Rosen) (03/11/91)
Due to interest, I'll be posting the Dragger cdev/INIT to comp.binaries.mac . If those of you who have not yet sent e-mail requests would kindly wait until it appears, I'd appreciate it. --Eric
dbarnhar@oiscola.Columbia.NCR.COM (dbarnhar) (03/11/91)
In article <HARDIN.91Mar8092016@dino.cad.mcc.com> hardin@dino.cad.mcc.com (John Hardin) writes: > >Check out HandOffII. It's similar to OnCue in its file launching >capabilities, but for each file in the HandOff menu you can associate >a sound level *and* a color depth. It also has the notions of >Briefcases and Categories. These allow files to be logically grouped >(i.e., hierarchy). I do *not* know if you can have Briefcases/Categories >inside of each other (i.e., if the hierarchy is deeper than 2 levels). I do not own HandOff II, but I have seen it. One thing I noticed is that the color switching doesn't seem to work for certain games. For example Gauntlet. When Gauntlet loaded, it discovered that it was in 256 color mode, then printed out a dialog box to that effect, and then the color changed! When I clicked "OK" in the dialog box, Gauntlet exited, and the machine was left in 16 color mode. Admittedly this was version 1.0, and I haven't seen the product since. Is there a newer version that fixes this problem? Also one other side effect I noticed in testing this product was that if you use the "Launch other application" mode where it uses a different application to load documents whose applications you don't have, it seems to change all the old documents into documents of the new type, so you can't tell (for example) the difference between Macwrite II documents and Macwrite 4.6 documents using the "view by name" mode of the finder. Has this also been "fixed" or changed since 1.0? Otherwise it seems to be a pretty neat product, especially if it no longer has the limitations it used to have. Dave Barnhart NCR Cooperative Computing Systems Division 3245 Platt Springs Rd. West Columbia, SC 29169 email: uunet!ncrlnk!ncrcae!oiscola!dbarnhar -- Dave Barnhart NCR Cooperative Computing Systems Division 3245 Platt Springs Rd. West Columbia, SC 29169 email: uunet!ncrlnk!ncrcae!oiscola!dbarnhar