• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

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

cheesestraws

Well-known member
I can't think of a way of doing it without having to recompute all the visible subsets of every rect every time, at least off the top of my head...
 

Crutch

Well-known member
Agreed, I keep wondering if there is a way to use an approximate algorithm to do it quickly but “almost correct” since the whole thing takes 1/4 second anyhow ….

One day perhaps I will add a “beautiful but slow” mode which actually moves each window, in its entirely, to the edge of the screen, preserving their ordering, one pixel at a time, and it just takes however long it takes. :D
 

cheesestraws

Well-known member
One day perhaps I will add a “beautiful but slow” mode which actually moves each window, in its entirely, to the edge of the screen, preserving their ordering, one pixel at a time, and it just takes however long it takes. :D

"If this mode animates too slowly for you, take a moment to consider that beauty operates on its own timescales, and cannot be hurried"
 

Crutch

Well-known member
An alert box appears:

”Your mouse movements and frantic clicking suggests you are failing to appreciate the beauty of this mode. The animation will now continue at one-half the previous speed.”
 

PB170

Well-known member
Haha, having fun here I see (y)😄:ROFLMAO:

Moving the actual windows is pretty much out of the question, I'd say. Then we're not in the millisecond range anymore, at least not on 68k processors :D Like I mentioned in the beginning of the thread, I tried an extension that enables live dragging of windows a long time ago, and while cool, it's definitely a more pleasant experience with just outlines. Can't imagine how much slower it would be to move several windows at the same time 😄

It’s certainly possible I just think it will be slow. (I agree it would look good.) The issue is that as we erase an “old” rect (like the top right one in your image) do we then have to compute all the other bits of “old” rects from other windows (like in your example the four just below it) that now have extra parts revealed?
Cool, I assumed it would be difficult or not possible at all (not all that acquainted with QuickDraw yet). I'm not sure if full precision would be needed. The animation might be quick enough that you don't notice smaller imperfections. If it's not too difficult to implement, it would be fun to see how it looks both ways. But yeah, it seems it would require more computation and slow it all down. Speed I think should be the first priority, so the idea I described above (or your suggestion) would probably be the best way to go.
 

Crutch

Well-known member
Yeah I’m just messing around about moving the actual windows …. Not possible on a 68k sadly. Even if everything were precomputed the bit blitting would be too slow.

I’ll try to prototype some stuff with enhanced animations. I will probably take a look at some of the INIT conflicts you mention first to see if they are pointing to any actual bugs in my cod
 

Crutch

Well-known member
After spending probably too much time on this and considering or rough-testing lots of other approaches, including most of those mentioned above, I changed the zoom animation in a bunch of ways:
  • I tweaked the number and acceleration of rects
  • I now only show a "stub" animation (the part when the window is near the edge of the screen) for windows that are either (1) quite small or (2) mostly or entirely obscured by another window
  • I use a thicker pen for the "newest" rect throughout (most of) the animation to draw the eye toward it, so that the screen doesn't look like a mess of equal-thickness rects (an alternative would have been to use a "lighter" pattern for the older rects). Note the thicker pen breaks complete visual analogue to the typical Finder "zoom open" case, but I'm solving a different problem here -- making a batch of overlapping rects all moving at once give the right visual impression. (Nothing Finder normally does ever entails multiple overlapping zoom rects going different places.)
Here's what it looks like in slo-mo. Curtailing (most of the) animation for the obscured windows turned out to be the biggest aspect of cleaning things up:

View attachment Screen Recording 2021-12-12 at 10.27.31 AM.mov

I think I will consider this portion good enough for now, leave the animation like this and move back to debugging extension conflicts and doing some screen refresh cleanup.
 

Crutch

Well-known member
Oh almost forgot ... the other thing is I automatically reduce the number of rects in the "Trail" too just 2 if here are more than 7 windows open. This also helps de-clutter a lot.
 

PB170

Well-known member
I was just about to post a comment about the latest version, so I'll begin with that :)

I've been using beta 4 for a couple of days now, and it works great! With a bit of touch up on the animation it feels like we're close to a final version.

I can report that not only do opening a folder that's been hidden bring it back; selecting hidden windows from the Windows menu in most apps to bring them back – including with the WinMenu icon menu extension that I have installed and that's available in all apps – also works like a charm. So superb work on the programming there 👌(y)

Now that activation while dragging works, I came to think of a kind of essential feature that we're missing though 😬 While dragging an item one should be able undo the action by pressing the escape key to release it back to its original position. Would this be possible to add? Might require to somehow simulate a mouseUp/mouseDown event…? 🤔


Now for the new stuff!

First of all, thanks for your efforts with improving the animation.

Interesting approach with varying the line thickness! Might not be a bad idea. Curious to see how it looks on real hardware.

I'm a bit sceptical about using varying the animation between windows though, and also a bit so about deviating from the animation in the Finder, but I get your point, and it will be interesting to see how it looks.

Would it still be possible to put together a version with the modifications we discussed earlier, and a version where the number of rects and the number displayed simultaneously is editable? I'm still curious to see how it would look and to be able to play around with it a bit.

Your solution with increasing the line width for the newest rect could be a good way to simulate the lack of actual moving windows though! Look forward trying it out.
 

PB170

Well-known member
Oh almost forgot ... the other thing is I automatically reduce the number of rects in the "Trail" too just 2 if here are more than 7 windows open. This also helps de-clutter a lot.
Great minds think alike, like you said ;):) I also had the idea to change the animation depending on the number of windows open, but thought it'd be good to try out combining the windows first.
 

CC_333

Well-known member
Any chance of this being compatible with PPC Mac OS 7.6.x, 8.x and 9.x?

Although the addition of Platinum in 8.x and beyond might complicate things, the window metrics seem to be the same, so I can't imagine things have changed so much that your software would be completely broken?

I have a Power Mac (PowerBase) that can run 7.6.x through 9.1, so I guess the only way for me to know for sure if it works -- without being a bothersome pest -- is to try it for myself! This isn't software I'd probably use much (I've never really used the modern Mac OS X equivalent except once in awhile I'll trigger it by accident), but I'm interested in trying it out simply for the fun of trying out brand new classic Mac OS software!

Can I be sign on as a beta tester? :)

c
 

Crutch

Well-known member
Very small update:

I have been optimizing the heck out of this thing. With some very deep dives into the Window Manager I was able to get Exposé to hide/show all windows instantly, like choosing “Hide Others” in the Application menu, only of course I hide all the non-minimized windows and/or show either one or all windows, not just the windows belonging to other applications. There is of course no documented way to do any of this so it was quite a trip.

A new beta including this and some other nifty things coming soon! And yes @CC_333 I would love more beta testers - thank you! Please watch this space.
 

PB170

Well-known member
Wonderful!

Isn’t it already instant though? :) I thought that was accomplished already from the start. But if it can be even more instant I’m all for it :)

During the past weeks I’ve left the more conscious testing and evaluation and returned to using the computer like I normally do, and I have to say that the extension already works very transparently and integrates well into the system, and my workflows, with just a slightly noticeable slowdown and somewhat cluttered animation with more windows open, like we’ve discussed earlier. In other words, it’s already a joy to use.

I look forward to the final, polished version. I’ve been thinking about doing some further tests/mockups of the animation part, while you’re working on the optimizations on your side. Will probably have time to play around with some ideas during the holidays.

Keep up the good work!
 

PB170

Well-known member
@Crutch, soon after I began experimenting with some new mockups for the animation, it struck me again that much of the clutter comes from the fact that we’re displaying five rectangles at the same time. Before we implement any of the other ideas, could we just try 12 rectangles and 3 of them displayed together, like in the original mockup I made? If it turns out that we need more speed, I think reducing the number of rectangles (like in OS 8+) rather than increasing the number of them displayed together is a better way to go.
 

Crutch

Well-known member
Hi @PB170 as mentioned earlier, in the new I scale down the number of rectangles in the “trail” based on the number of windows on screen, starting with a maximum of 4 rectangles and dropping to 3 or fewer if more than 4 windows are being zoomed. I also now skip zooming windows that are mostly obscured or too small. The overall effect is cleaner. You will see this version soon. 4 rects looks better than 3 to me if the number of windows is sparse.
 

Crutch

Well-known member
Tons. I have been so busy development that I haven't had time to share any updates! I'll get a new beta out with release notes within a week. Working on some weird/awesome features also, maybe ... at least, I think they're weird and I hope they're awesome!
 

CC_333

Well-known member
Excellent!

I'd probably not use it day-to-day, but I'm curious to see if it would work on a Power Mac running Mac OS 8.5 (assuming the various APIs it relies on haven't changed, it should at least mostly work, though for full compatibility, I suspect it'd need to be patched and/or modified to support the Appearance Manager, which is new to Mac OS 8.x).

Anyway, I'm looking forward to seeing what you've done!

c
 

Crutch

Well-known member
All right, I did a lot with this ... including adding most of a new feature which isn't quite ready yet and is therefore completely turned off :) oh well, soon!

However, it's been way too long since my last update so wanted to go ahead and share this anyway: here's version 1.0b5 (attached).
  • Totally redid hide/show window code for massive speed increase: now, like choosing "Hide Others..." from the Application menu, hiding windows happens all at once, not window-by-window. Showing windows is also vastly faster. This happened due to some ginormous hackage, completely avoiding the Window Manager for most window hiding/showing/moving. Check out these Before (1.0b4) and After (1.0b5) videos showing the difference running at 1x speed on Mini vMac emulating an original Mac II. (Note that this is just generally slow in 8-bit color on an original Mac II! It is much faster on newer machines, I ran it slow on purpose to clearly show the difference.)
Before (old version 1.0b4):
View attachment Before - 1.0b4.mov

After (new version 1.0b5):
View attachment After - 1,0b5.mov
  • 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.)
  • Lots of other visual optimizations like not zooming a window that's hidden behind other windows to clean up the mess of zooming rects.
  • 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.
  • Other things I probably forgot about.
Tons of changes in here so certainly possible something broke (the CDEV UI is entirely unchanged for now though). Please let me know.

Hope you like it!
 

Attachments

  • Exposé 1.0b5.bin
    43.5 KB · Views: 15
Last edited:
Top