Idea/dream/wish: Exposé for classic Mac OS

[CC_333]

Neat!

I just tried it on my PowerTower Pro 225 running Mac OS 8.5.1 with a G3/300 upgrade, and it seems to work pretty well! In particular, it appears to work 100% perfectly with Finder windows, and during my limited testing, there have been no weird crashes or lockups, so I think it's safe to say that it is reasonably Mac OS 8.x compatible as is (I haven't tried 9.x yet).

A couple oddities emerge when third-party apps come into play, however:

• It doesn't seem to like Internet Explorer. I opened up a blank IE window in addition to a couple folders in the background, and activating Exposé wouldn't make the IE window zoom away. Instead, it just becomes sort of unresponsive, like something is blocking it from receiving mouse events. Clicking to the desktop enables me to access other zoomed windows, and Exposé works as normal there. Deactivating Exposé unblocks the IE window.
• Photoshop 6.0 is a bit weird too. For my next test, I opened up Photoshop 6.0 with a document window, and tried invoking Exposé. The document window zoomed like it was supposed to, but the tool palettes didn't, behaving more or less as the IE window did (ie, appearing active, but unresponsive). A key difference, however, is that when I click to the desktop, they disappear, unlike the IE window, which sort of just got stuck.

I'm not totally familiar with how every feature should work, but I think this covers enough of it to be useful.

It seems unnecessary because Exposé appears to run just fine as is, but just out of curiosity, how feasible and beneficial would a PPC-native version be?

c

 

[Crutch]

This is terrific @CC_333 , thank you for the quick and detailed feedback! One thing I should have mentioned is that the speed optimizations I did (bypassing the Window Manager) definitely made it likely that Exposé would not play nicely with floating palettes. Thank you for confirming that -- I need to dig in and work on this, and will do so soon!

The IE bug is more surprising. It sounds like Exposé is successfully moving that window offscreen (thus why mouse downs aren't getting processed), but not redrawing/updating the layer's visRgn correctly. I will look into this after fixing the floating window issue.

I probably wouldn't do a PPC native version, just because I really prefer 68k development and have some embedded assembly in there. But I might It probably wouldn't make much of a difference, it should already run quite speedily on a PPC Mac.

 

[CC_333]

This is terrific @CC_333 , thank you for the quick and detailed feedback!

Of course! I'm glad to be of help!!

One thing I should have mentioned is that the speed optimizations I did (bypassing the Window Manager) definitely made it likely that Exposé would not play nicely with floating palettes. Thank you for confirming that -- I need to dig in and work on this, and will do so soon!

I see. That makes sense. I know virtually nothing about how the Window Manager works, but is there a way to have both the original routines and your new, assembly-based ones exist at the same time (I realize this can cause some needless bloat) and conditionally invoke one or the other depending on which would best handle a given window type?

The IE bug is more surprising. It sounds like Exposé is successfully moving that window offscreen (thus why mouse downs aren't getting processed), but not redrawing/updating the layer's visRgn correctly. I will look into this after fixing the floating window issue.

Yes. I forgot to mention also that rapidly zooming, unzooming and rezooming led to the windows being half drawn, instead of completely zoomed. Perhaps this is due to some differences in how Mac OS 8.5 does things?

Given that the average user is very unlikely to do that deliberately, I don't think it would be a huge problem, but you might want to look into it nevertheless, in case I'm wrong. It could relate somehow to the problems with IE, for all we know!

c

 

[Crutch]

Yes - your suggestion of using the Window Manager in cases where a floating window is detected is certainly one approach. I hope to make my hacky stuff play nicely with floating windows though — I am going to give it a try!

 

[cheesestraws]

I'd really like to read the code for this when you get it to a stage you're happy with it! This is good stuff.

 

[Crutch]

Thanks @cheesestraws . This will definitely happen eventually. The main impediment is my personal pride & desire not to share code that is kind of a giant mess right now due to the multi layered hackage and trying of things ....

I am a tiny bit proud of the FrameRect replacement code. It turns out that writing code from scratch to correctly draw XOR'ed rectangles that clip to the screen and allow various pen widths and bit depths (so you have to worry about all the special cases, like what if this edge is only partly offscreen, or what if these two edges overlap such that you have to combine them so they don't XOR over each other...) is pretty not trivial but is worth it because it saves gobs of time on slower Macs ...

 

[CC_333]

Any updates?

I don't mean to be a pest, but I'm eager to know...

c

 

[Crutch]

Working on your floating palette issue in my spare time this week (but there isn’t much of that) — it’s tricky so I’m guessing probably another 1-2 weeks for an update. Thanks again for flagging this!

 

[CC_333]

Ah, of course! Take all the time you need/can get.

I'm not going anywhere

I'd offer to help look through the code, if not for the fact that I don't know how to code very well (I *barely* got the hang of basic Java, which allegedly is similar to C, so if you wrote Exposé's non-assembly parts mostly in C, maybe I could study it and figure it out eventually; C++, on the other hand, left me completely mystified, so if that's what you used, well....).

c

 

[PB170]

Hello!

Checking in here for the first time in a while Great to see all the activity here!

I've been using beta 4 continuously since last year, and it's quickly become as natural and pleasant to use as the OS X original. I've been using it daily (just checked, and my PowerBook has seen an average of 4 h 19 min of use per day this year ). It's working great, hasn't crashed a single time and makes using the computer so much more efficient. Love it! With an average number of windows open, the animation speed is much slower than on OS X (about 1.0 second compared to 0.25 in the original) but I surprisingly forgot about that quickly after I left the evaluation and began using it normally. Ties in pretty well with the speed the desktop refreshes at with the large number of items I usually have scattered there

 

[PB170]

• I rolled my own fast 68k asm code to draw the zoom rects; it's more than twice as fast and will make a very obvious difference on slower systems.
• Major changes to zoom rects animation: now skips drawing or uses fewer trailing rects in som cases. This is just for visual nicety: the animation speedup is mainly from writing my own version of FrameRect, not drawing fewer rectangles, but I think @PB170 will be happy (Also, I ended up not using my idea described earlier to use thicker rects in some cases.)

Oh wow, I can't believe you actually rewrote the zoom rect algorithm in assembly! That's incredible. Really impressed! And oh what a difference it makes It such a drastic change, it actually feels odd to use now that I'm so used to the slower speed Thanks so much for this update! It's crazy how fast it is. I made some measurements and the animation runs at between 0.30 and 0.36 seconds which means it's over three times faster and now almost matches its OS X counterpart!

I didn't realize it at first (it all happens so fast, ha! ) but the optimizations to the window hiding part is also super cool. It’s indeed instant (literally changes from one frame to another even when recording the screen at 60 fps!).

Amazing job! I can imagine the complexities involved in these rewrites. Truly impressed!


I no longer follow along with all your changes to the animation, but visually it looks great. Also, I'm kind of happy that you went on to scrap the thicker rects Could have been interesting to see, but I feel using the same zoom rects as the Finder makes for a more coherent experience.

It would be interesting if you could detail how the algorithm works in its current form.

Lots of other visual optimizations like not zooming a window that's hidden behind other windows to clean up the mess of zooming rects.

I'm naturally all for any approach to reduce the clutter, and while I think skipping the animation for obscured windows is a great way to achieve that, I've actually also found it to be a useful cue for making one aware of which windows are open (sort of making the windows transparent for a moment). If you activate Exposé when say a document window is covering two Finder windows and it only shows the animation for the front window it makes you think there aren't any windows open in the Finder. But, I still think it's smart and useful feature for reducing clutter. While I'm for a clean and minimalistic control panel, perhaps it could be justified to add this as an option.

 

[PB170]

Some feedback on the new beta after two days of testing (numbered for easier reference ):


Visual stuff:

#1 Something has changed in the new algorithm that makes some lines get drawn in white and some in black when blending with the background pattern.



#2 Upon closer inspection, there seem to be a couple inconsistencies in the animation:
#2.1 Sometimes some windows are not animated even though they're only partially covered
#2.2 Sometimes only the end of the animation is drawn
#2.3 Occasionally windows don't get redrawn after they've been moved to the edge of the screen

#3 I'm using a Macromind Player app to cover the desktop and easily change backgrounds. Initially, I was a bit concerned about how the extension would deal with this, but it's been working fine all up through beta 4. However, now it does this: (first live footage, btw! )

View attachment Exposé 1.mp4


With windows behind the app:

View attachment Exposé 2.mp4


Functionality:

#4 Some nasty bug seems to have sneaked into the new beta It showed up almost directly, but didn't turn out to be as frequent as it seemed at first. Unfortunately, it seems to be pretty random. It first occurred after I had been playing around in amazement with the new animation for a while and went on to start up TeachText and was greeted by a bomb alert stating "TeachText. unimplemented trap". Restarted, tried it again, and the same thing happened. After that, it went away but showed up in other situations instead. It's fairly infrequent. This far it has happened six times during about 10 hours of use.

I realize this probably doesn't offer much insight, but here's a list of situations when it's showed up:

1. Starting TeachText. Bomb alert when the new window is about to be displayed. ("TeachText" unimplemented trap)
2. Ditto
3. Creating a new window in Style (a word processing app) ("Style" unimplemented trap)
4. Resizing a window in Finder ("Finder" unimplemented trap)
5. Quitting Photoshop 2.5 ("Photoshop" unimplemented trap)
6. Resizing a window in Finder ("Finder" unimplemented trap)


Continuing with a summary of some old and new feedback/requests/ideas:

#5 The order in which the redrawing takes place makes a big difference on the perceived speed. I'm not sure if maybe you already commented on this, and I realize it's not intentional and probably tricky to fix, but is it possible to make the redrawing occur in the same order when the Finder is active as when an app is in the foreground? That is, hide all windows, display the animation, redraw the desktop and finally draw the windows at their new positions.

In particular, having the windows redraw as the last step would be great. If a window contains more complex graphics that need to be redrawn after the window has been moved, it could result in a substantial delay before the icons are displayed (time that could be used for the comparatively slow process of locating the item one is looking for).

#6

Fixed another item @PB170 pointed out that could cause WindowShaded windows that zoomed to the top edge of the screen to be 1 pixel too high.

Great that this has been fixed! Didn't realize it only happened with windowshaded windows.

#7 I still can't get the CDEV's icon to show up in the Finder (not usually a problem on my setup)

#8 In the OS X original, while dragging an item, one has the option to undo the action by pressing the escape key to release the item back to its original position. Would this be possible to add?

#9 A small adjustment that I missed in my original outline of the algorithm: could we change the algorithm so that menubar is excluded when the center of the screen is calculated? This would match the OS X implementation. At present, windows somewhat unintuitively move downward when they're closer to the menubar than to the bottom of the screen.

Biggest requests on my part, apart from the bug, would be number 1 and 5

Thank you for your continued efforts and interest in the project!

I look forward to the next update!

 

[PB170]

#2.2 Sometimes only the end of the animation is drawn

I realize now after I've reviewed the thread that this actually is one of the changes you described you added to reduce the clutter. I'm not sure if I'm a fan of this though. I find it makes the animation look inconsistent at times. I would prefer to space out / reduce the total number of rects in the animation instead (maybe we're already doing that?).

 

[PB170]

Photoshop 6.0 is a bit weird too. For my next test, I opened up Photoshop 6.0 with a document window, and tried invoking Exposé. The document window zoomed like it was supposed to, but the tool palettes didn't, behaving more or less as the IE window did (ie, appearing active, but unresponsive). A key difference, however, is that when I click to the desktop, they disappear, unlike the IE window, which sort of just got stuck.

Palettes actually haven't worked in any of the betas. I intentionally didn't comment on that, mainly since I learned, after doing some research into palette windows for my own projects, that they are not part of the system software but basically custom hacks with a range of different implementations. Also not that big of a deal, I think (though it would be great if all window types could be covered of course!).

 

[PB170]

I didn't realize it at first (it all happens so fast, ha! ) but the optimizations to the window hiding part is also super cool. It’s indeed instant (literally changes from one frame to another even when recording the screen at 60 fps!).

Not that the display itself updates at 60 fps but guess the change lined up well with the frames

 

[galgot]

Hi,
Just tested your Exposé 1.0b5 on Mac OS 8.6 :

Seems to work only with the Finder in foreground, But it is very cool.
Now going to test on System 7.6.1... Thanks !

 

[Crutch]

Thanks for the feedback and especially @PB170 for the ongoing extremely helpful feedback and testing … I’m glad you like the optimizations in the latest beta! I will work on all of your comments and think I have fixed (some of?) the bugs you pointed out already.

Real life has gotten much busier so pace of work has slowed down but I’m still very much working on this. At the moment trying to get floating palettes … which should be possible! … and a few rogue apps (like MacPaint 2.0 but also quite a few others it seems) working correctly, since some of those guys insist on “remembering” where their windows were before I moved them and blit bitmaps to open patches of desktop sometimes ….

Thanks @galgot for testing under OS 8! I haven’t tried that at all yet but will try to clean it up once I wrap up my long list of System 7 issues …. It should be possible to get it working smoothly.

 

[PB170]

That’s great. Take your time!

(But not too long since I had to revert back to beta 4 because of the crashes and now miss the speed of beta 5 )

By the way, after some further testing I noticed that some windows no longer are affected. Seems to be happening mostly to interface windows (such as FindFile and a couple of others). These all worked fine before.

 

[galgot]

...

Thanks @galgot for testing under OS 8! I haven’t tried that at all yet but will try to clean it up once I wrap up my long list of System 7 issues …. It should be possible to get it working smoothly.

Btw, installed it on a 7.6.1 system, it's very useable, works fine with any apps I tried.

 

[CC_333]

@galgot That's similar to what I observed during my testing on Mac OS 8.5.1. It only really seemed to work reliably with Finder windows, plus maybe some relatively simple applications.

More complex ones (I tried IE 4 and Photoshop) seemed to only partially work.

I'm inclined to think maybe window handling is slightly different for applications beyond the Finder. Maybe due to the Appearance Manager? Or multithreading, because the Finder in Mac OS 8.0 and up, i believe, is multithreaded. Not sure if it matters, but it's something to look at.

c