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

[PB170]

Wonderful! I hope my comments will make sense.

First of all: the algorithm for moving the windows, as well as the overall functionality, is already spot on – behaves just like the original! Really amazing work!


My impressions after some further testing:

Now that I see it in action, the animation quickly gets pretty messy with more than a few windows open. I’m wondering, would it be an easy thing to add some temporary interface elements to the control panel (or variables that can be accessed through ResEdit) to control the number of rects and how many of them are displayed together, so that I can play around with it a bit? That would be great In general though, I think it would look better with fewer rects and fewer of them on the screen at the same time, maybe with some extra logic added.

By the way, the already pretty snappy animation and more or less instant window hiding makes you realize how slow redrawing the desktop and windows actually is Already, it’s sort of the main thing that drags down the snappiness of it.

I’ve done a lot of switching back and forth between hiding the windows from an app and from the Finder to try to evaluate which of the two implementations work best (completely ignoring the technical difficulties for the moment ) and I feel the best solution would be one that lies between the two.

In the Finder, there’s a quite substantial delay until the desktop icons are redrawn when there are many windows open. Since the focus during normal use will be on what one is trying to access on the desktop, redrawing the desktop I feel should be the top priority. At the same time, the delay between when the windows are hidden and when the animation starts in apps makes the process feel less snappy. With this in mind, I’m wondering if it would be possible to do it in this order universally:

1. Hide all windows
2. Display the animation
3. Redraw the desktop
4. Draw the windows in their new positions

This order also matches the average duration of the steps with a couple of windows open and a handful of icons on the desktop, from the fastest to the slowest (at the moment the animation is generally slower than redrawing the desktop, but if we manage to optimize it a bit we could bring it up to the second place).

This would hopefully make the animation feel snappy while still displaying the icons reasonably fast, saving the slow redrawing of windows till the end.

As and aside, do you think it would be feasible to add an option to speed up the redrawing of the desktop by using a screen buffer like you mentioned earlier, or would that just add more overhead? If the desktop redrawing could be removed/hidden, it would make a huge difference. But of course, the way it works now is in line with the system in general, so I have no problem with that. But more speed is always nice

On a related note, is it possible to somehow have the active application redraw its windows before the desktop and the Finder’s windows are redrawn? At the moment, the Finder’s windows are redrawn first followed by the application’s, even if the windows in the application cover all of the Finder’s windows.


A few quirks I’ve found (present also with all other extensions removed):

Main things:
– Activating while dragging an icon doesn’t work on my setup (nothing happens)
– Windows minimized with WindowShade get redrawn un-minimized immediately after they are hidden (that is, while the other windows are still hidden)
– The active corners sometimes react slowly or doesn’t respond at all until after several attempts. Seem to happen mostly/only after repeated use over a short time frame, but I’m not sure. The keyboard shortcut is always instant, as is clicking the screen edges to bring back the windows.

Strange stuff:
– The resize handle in open windows sometimes gets distorted in various ways when windows are brought back (standard window on the left):


Small things:
– Windows on the left side sometimes are drawn four pixels into the screen and sometimes three (would prefer three here). (Also, could we bring the windows at the bottom of the screen one pixel up? )

Smaller things:
– The CDEV’s icon isn’t displayed in the Finder (only a generic document icon)

Probably tricky stuff:
– Sometimes the contents of windows is not updated when they are brought back (has only happened two or three times during my testing – and only initially it seems…)
– The keyboard shortcut didn’t have any effect at first so I assumed it didn’t work, but soon after it started working without problem. Might have been after the first restart, not sure.

Exotic stuff:
– Clicking the window’s zoom area in ClarisWorks sometimes moves the window to its previously ’hidden’ position. Doesn’t seem to happen in any other app


On the control panel:

– Really cool that the desktop representation displays the actual desktop pattern! Great addition!

– The live preview of the keyboard shortcut in the dialog box was also a cool surprise! Really responsive, and impressive from a programming point of view! I have to say though, that I feel that it adds an unnecessary extra step, and it’s also quite uncommon to do it this way, so I would prefer it the way I designed the dialog box. Perhaps you would save the nifty implementation for some future project? (Or, if not, maybe you could make a separate version just for me? )

– The control panel already looks very good, but do you think you could bring it closer to my design later on? I spent quite a bit of time designing and tweaking the elements of the control panel and dialog box, and went through lots of standard and third party control panels and settings menus for reference in the process, both on classic Mac OS, OS X and even Windows and Linux. So pretty much every element in the layout is a conscious decision (such as ”Hot corners” (more common on classic Mac OS) vs. ”Active screen corners” (on Mac OS X), having an ”On” checkbox or not, etc. I’m not saying it can’t be improved, but at least there’s thought behind it I’d be happy to help fine tune the parts that are editable in ResEdit.

That’s all for now Sorry about the long post!

Again, amazing work!

This, I feel, will be the best birthday/Christmas present this year

 

[PB170]

- It would be handy to be able to hide the current windows even if there are already some hidden ones: If you would go into the hot corner while pressing the shift key, instead off all windows re-appearing, the new windows would get hidden as well.

Great idea – that would be a nice addition to the original! Certainly could come in handy!

- Further increase the animation speed (for slower machines). Instead of the "Zoom animation" checkbox, you could add some radio buttons in the control panel like Fast/Slow/No Animation, where "Slow" would be the current animation speed.

I would much prefer for this to be controlled automatically in code, so that the duration of the animation is constant around 0,25 s like in OS X, and the number of rects in the animation is reduced, if necessary, to maintain speed down to a limit of say 3 rects, and then just have the option to disable the animation in the control panel if that turns out to be too slow. (Maybe with a dialog prompting the user with something like "The speed of you system is limiting the performance of Exposé. Would you like to disable the animation to increase the speed?").

 

[Crutch]

Thanks for the very helpful and detailed feedback! I will tackle most of these things eventually.

Thoughts on a few:

What system version are you running? (asking to investigate while trigger during dragging doesn't work)

Forcing the active application (including if it's the Finder) to "redraw itself" is actually quite hard. I can force a background app (like the Finder) to redraw itself by calling WaitNextEvent, but I am running inside a WaitNextEvent call by the active application already (the INIT checks for a triggering event by patching GetNextEvent) so the only way to get the active app to redraw itself is to give up control, let the app process an update event (the next time it calls WaitNextEvent, which might take a little time), then get control back (maybe by patching EndUpdate) and finishing whatever I have to do.

... So, yeah, the answer would be to keep a screen buffer of the front window. The good news is, I want to still implement the "window view" part of Exposé which will require doing this anyway! In other words ... this will happen but not right away.

The WindowShade you referenced is the known problem I mentioned before. This is inherent to the way WindowShade operates (WindowShade appears to check if a windowshaded window moves and automatically expands it if so) and will be tricky to fix.

You should be able to fix the icon issue by rebuilding your desktop (restart with Command-Opt held down).

That grow icon issue is super weird. I don't even know what to do about that. I will do some general debugging this weekend that will hopefully fix some of the idiosyncrasies you helpfully pointed out!

I would be interested in discussing fine-tuned cdev DITL things down the road. As a small design note, omitting the "Show start-up icon" checkbox was a conscious choice, I believe that if an INIT is going to patch a whole bunch of traps it should always announce itself! (if someone really wanted to hack my INIT to not show its icon, it would be a 2-byte change to the INIT code in ResEdit but I don't like providing that as a standard option).

 

[Crutch]

For the grow icon issue you point out. Is it possible that window was "hidden" off to the top or left edge of the screen, such that part of that grow icon was "moved" and part was redrawn after the un-hiding? (It looks like part of the right or bottom edge of that icon was redrawn off by one pixel. Which still shouldn't happen but ... )

 

[PB170]

What system version are you running? (asking to investigate while trigger during dragging doesn't work)

I'm running System 7.1.1

Forcing the active application (including if it's the Finder) to "redraw itself" is actually quite hard. I can force a background app (like the Finder) to redraw itself by calling WaitNextEvent, but I am running inside a WaitNextEvent call by the active application already (the INIT checks for a triggering event by patching GetNextEvent) so the only way to get the active app to redraw itself is to give up control, let the app process an update event (the next time it calls WaitNextEvent, which might take a little time), then get control back (maybe by patching EndUpdate) and finishing whatever I have to do.

I understand. It's not a huge deal. Just thought I'd mention it after my first testing, even though I assumed you were already aware of it.

(I don't really follow along at the moment though. Don't the active application's windows already update when they are brought back? Wouldn't it then rather be a question of somehow preventing background applications from updating first? It's probably just I who lack knowledge here, in addition to not really understanding the implications of patching the event routines, and it's been a while now since I did any Toolbox programming, so no need to explain it if my questions don't make sense )

... So, yeah, the answer would be to keep a screen buffer of the front window. The good news is, I want to still implement the "window view" part of Exposé which will require doing this anyway! In other words ... this will happen but not right away.

Totally fine! A performance upgrade down the road would be cool!

The WindowShade you referenced is the known problem I mentioned before. This is inherent to the way WindowShade operates (WindowShade appears to check if a windowshaded window moves and automatically expands it if so) and will be tricky to fix.

Oh, I assumed that you meant that shaded windows aren't preserved when the windows are brought back. Well, that's a bit of a problem then... Would make it hard to use the extension in conjunction with WindowShade. Is there really no way around this? If moving the windows causes WindowShade to unshade them, couldn't a cheap fix be to just shift all windows by one pixel (maybe without redrawing them, if possible?) before they are "hidden"?

You should be able to fix the icon issue by rebuilding your desktop (restart with Command-Opt held down).

Hehe, yeah, after 25+ years of using System 7, that key combination isn't exactly new to me I did try to rebuild the desktop (haven't done so in a really long time) but it didn't make the icon show up, so I thought I'd mention it. I remember having problems with that myself when I worked with the control strip modules earlier this year. Didn't have enough time then to figure out how to set it up properly, but I'm sure that's easy stuff for you.

I would be interested in discussing fine-tuned cdev DITL things down the road. As a small design note, omitting the "Show start-up icon" checkbox was a conscious choice, I believe that if an INIT is going to patch a whole bunch of traps it should always announce itself! (if someone really wanted to hack my INIT to not show its icon, it would be a 2-byte change to the INIT code in ResEdit but I don't like providing that as a standard option).

Makes sense! I buy that.

For the grow icon issue you point out. Is it possible that window was "hidden" off to the top or left edge of the screen, such that part of that grow icon was "moved" and part was redrawn after the un-hiding? (It looks like part of the right or bottom edge of that icon was redrawn off by one pixel. Which still shouldn't happen but ... )

You're right. It appears that the grow icon gets shifted down by one pixel in all windows that are moved to the left side of the screen or the left half of the top side. So the second case in the image I included above is the result of restoring windows from the top of the screen, and the third and fourth the result of the varying 3 and 4 pixel placement on the left side of the screen. Kind of surprising that this is happening, I must say In particular that not the entire grow icon gets redrawn when the windows are brought back.


Thank you for your continued effort!

 

[robin-fo]

@robin-fo
Here's version beta 2. This is a little better with memory management and should display an error if it runs out of memory rather than just crashing terribly. I'm curious if this happens to you on your 7.6.1 setup?

Oh also it should do the thing you wanted, hold Shift when you mouse into a hot corner and it will always only hide windows (if possible) and never un-hide anything. Seemed liked a good idea so I just did it.,

Thanks! The shift-key feature is fantastic! Sadly, the problem on my CC is similar as before. Apparently, there is no problem with my System 7.6.1 installation, as I copied the System Folder to a BasiliskII setup where Exposé runs without any issue (even with 8MB of RAM, as on my CC). So I guess there must be something hardware related which prevents it from running in 7.6.1, even if it runs on 7.1 on the same machine.

 

[robin-fo]

Thanks! The shift-key feature is fantastic! Sadly, the problem on my CC is similar as before. Apparently, there is no problem with my System 7.6.1 installation, as I copied the System Folder to a BasiliskII setup where Exposé runs without any issue (even with 8MB of RAM, as on my CC). So I guess there must be something hardware related which prevents it from running in 7.6.1, even if it runs on 7.1 on the same machine.

I just did a clean install of 7.6.1 on my CC and Exposé now works on it, but it still crashes on the second or third activation.

 

[K Trueno]

Just wanted to say super excited to try it out, and you'll have another user

On my 7.1 on an SE/30 + Accelerator I get an instant bus error, but I haven't fiddled with other control panels/extensions and all that, will report back soon!

 

[Crutch]

Thanks everyone for all the feedback so far!

I will try to work out why some of you are seeing crashes soon. This is a tricky INIT that patches a bunch of traps so this is unfortunately to be expected across hardware and system versions pending tons of testing. I will keep at it.

Meanwhile here's a new beta @PB170 .... 1.0b3:

1. The WindowShade issue is fixed! (I check if a window is collapsed by seeing if its content region is empty. If so, I never actually hide it [since un-hiding it decollapses it], instead I move it off screen temporarily. This is slightly slower but necessary in the WindowShaded case.)
2. I took your advice and got rid of the OK button in the "set keystroke" dialog, while preserving my live keypress display
3. I couldn't replicate the issue you are seeing with the left-side windows sometimes inset by 4 vs. 3 pixels, but I think I figured out why it happens anyway (rounding error computing window centers) and believe I fixed it.
4. I raised the bottom-edge windows by 1 pixel as you request (you were correct, they were too low, thank you).

Hope you like, cheers.

 

[PB170]

Brilliant! Thanks for getting back with a new version so quickly! Will install it right away (though it's getting kinda late here, so I will have to test it more thoroughly tomorrow )

In the meantime, I made a few adjustments to the design for the control panel:

• Touched up the design of the icons for the modifier keys a bit and rearranged the ordering
• Removed the "Show icon" checkbox
• Added an info button for information and credits (only in black and white for now)
• A few minor tweaks

Hope you like it

I've included a new file with updated resources.

I haven't looked at your new version yet, but I put in a suggestion for placement of the live preview of the key combination in the dialog box. The one in your first version felt a bit dominant If we're going to keep it but remove the OK button, I think we need a bit of a delay between when a letter key is pressed and the dialog disappears, but perhaps you already thought of that.


I also put together a version with some measurements for easier implementation:

Everyhing open for discussion, of course

 

[Crutch]

That looks nice. I will incorporate this in the near future.

Your modifier key icons look great but I am not actually using them for now, you may have noticed … TrueType Chicago font actually includes the modifier key icons standard (but ONLY in the TrueType version, oddly, not in the screen font) so that is what you are seeing at the moment. I will switch to yours in a future version because they look better.

I like the info button!

Yes, I already added a delay before the dialog vanishes. 24/60 seconds if I remember right. I tried a few durations and that felt snappy yet still intentional. (Too short a delay and, paradoxically, it just starts to feel like the dialog is just a tad slow to disappear rather than intentionally pausing briefly.)

I like the giant keypress display in the dialog … though perhaps I can be persuaded to change it eventually. I have never seen a “enter a keystroke” dialog on classic Mac OS that displays modifier key presses live in this way, and I think it’s really the correct way to do it, so perhaps I’m just showing off a little …

 

[K Trueno]

It is working well now! The offending extension was Décor - lets you set a wallpaper. Since I have to choose, I choose Exposé for sure

I am also running into the issue where triggering again does not work while dragging. Neither by hotkey or by dragging to the corner again. System 7.1.

 

[Crutch]

Here's a new beta, 1.0b4:

1. Should work much better and feel much snappier under 7.1. With some MacsBugging I learned that the Finder under 7.1 calls _WaitNextEvent with sleep=60, i.e. a sleep interval of a full second (7.5.5 doesn't do this), meaning Exposé only gets to (1) check for a hot corner and, importantly, (2) notice the mouse is no longer in a hot corner just 1x/second. This means that in normal use, you could mouse to a corner, trigger Exposé (after a perceptible delay up to 1 second), then move the mouse out and quickly back again (within 1 more second) before Exposé notices you ever left the hot corner ... meaning the 2nd hot-corner touch is ignored (because Exposé thinks you're just still there from before!).

After a lot of deep Process Manager exploration I fixed this by patching _OSEventAvail to check the cursor location and (1) clear the hot corner flag instantly* if not in a hot corner or (2) return TRUE if in a hot corner, which forces the Process Manager idle loop (nexttask(), see Schedule.c) to wake up a sleeping process so my _GetNextEvent patch is triggered, running Exposé instantly. (This roundabout approach is needed because _OSEventAvail doesn't move or purge memory meaning I can't do much inside that patch other than indirectly trigger my GetNextEvent patch.)

*except I only run this max every 5 ticks to prevent wasting cycles.

2. OOPS ... it turned out the routine to trigger Exposé while dragging (_XorRgn patch) forgot to check hot corners and was still using old code that hardcoded a check for the top-left-corner only. This has now been fixed @PB170 I bet this is why you couldn't trigger while dragging ... please try again! (The top-left corner probably always worked.) I have tested this under 7.1 and 7.5.5 and it is good.

3. I fixed the issue discussed above resulting in corrupted grow icons under 7.1, which appears to be due to a bug in Apple's implementation of _DrawGrowIcon (always worked fine in 7.5.5).

Cheers

 

[PB170]

Fantastic! Your updates are coming faster than I can keep up with at the moment

Such amazing work on your part this far @Crutch. Already in its current form, it's incredibly useful. While the majority of the folks here probably tinker with their vintage Macs every now and then, like I mentioned, I'm using my PowerBook for actual work, and this is such a nice productivity gain. Indeed feels like getting new system update after 28 years – puts a big smile on my face every time I start using it!

Some feedback on the two latest beta versions:

The WindowShade issue is fixed! (I check if a window is collapsed by seeing if its content region is empty. If so, I never actually hide it [since un-hiding it decollapses it], instead I move it off screen temporarily. This is slightly slower but necessary in the WindowShaded case.)

Wonderful! I don't quite understand the explanation for how you solved it, but it works great!

I couldn't replicate the issue you are seeing with the left-side windows sometimes inset by 4 vs. 3 pixels, but I think I figured out why it happens anyway (rounding error computing window centers) and believe I fixed it.

Great! It seemed like it could be a rounding issue. I noticed though that it also happens with windows on the top of the screen, and that issue still remains.

I raised the bottom-edge windows by 1 pixel as you request (you were correct, they were too low, thank you).

Thanks! Looks more balanced now!

1. Should work much better and feel much snappier under 7.1. With some MacsBugging I learned that the Finder under 7.1 calls _WaitNextEvent with sleep=60, i.e. a sleep interval of a full second (7.5.5 doesn't do this), meaning Exposé only gets to (1) check for a hot corner and, importantly, (2) notice the mouse is no longer in a hot corner just 1x/second. This means that in normal use, you could mouse to a corner, trigger Exposé (after a perceptible delay up to 1 second), then move the mouse out and quickly back again (within 1 more second) before Exposé notices you ever left the hot corner ... meaning the 2nd hot-corner touch is ignored (because Exposé thinks you're just still there from before!).

Interesting! A bit odd though; in general, triggering it is pretty much always instant, so it doesn’t feel like a delay randomly distributed between 0 and 1 second. Also, the issues with it not responding, or responding slowly, only happened a few times. Regardless, great work! I'll keep testing it to see how it works now.

After a lot of deep Process Manager exploration I fixed this by patching _OSEventAvail to check the cursor location and (1) clear the hot corner flag instantly* if not in a hot corner or (2) return TRUE if in a hot corner, which forces the Process Manager idle loop (nexttask(), see Schedule.c) to wake up a sleeping process so my _GetNextEvent patch is triggered, running Exposé instantly. (This roundabout approach is needed because _OSEventAvail doesn't move or purge memory meaning I can't do much inside that patch other than indirectly trigger my GetNextEvent patch.)

Complicated stuff this…! I barely follow along… Once again, amazing work!

see Schedule.c

Oh wow! I haven't seen this before! Where does all this come from? Source code for the whole ROM? Even the .backlight driver that I never fully understood the workings of when I tried to communicate with it while making my backlight CSM module is there. Now I can just delve into the source code and see what they did! Completely blown away here!

2. OOPS ... it turned out the routine to trigger Exposé while dragging (_XorRgn patch) forgot to check hot corners and was still using old code that hardcoded a check for the top-left-corner only. This has now been fixed @PB170 I bet this is why you couldn't trigger while dragging ... please try again! (The top-left corner probably always worked.) I have tested this under 7.1 and 7.5.5 and it is good.

Works flawlessly! Fantastic!

3. I fixed the issue discussed above resulting in corrupted grow icons under 7.1, which appears to be due to a bug in Apple's implementation of _DrawGrowIcon (always worked fine in 7.5.5).

I'm starting to run out of superlatives here. Great that you were able to fix this! Only Apple's original bug remaining now


To end with, a somewhat confusing bug report (based on beta 3):

Like I mentioned before, the keyboard shortcut didn't work at first, but the problem quickly went away. Well, the issue reoccurred with the new version, so I thought I'd to some testing before it resolved itself again to see if there was some conflict with some of the other extensions (contrary to what I said before, I might not have tried this with extensions off the first time since the problem went away so quickly).

Before the problem eventually went away by itself again, I managed to narrow it down to two extensions:

The first one is "Inline Support" (part of the Japanese Language Kit that I have installed), which for some time seemed to prevent the keyboard shortcut from working.

The second one is a temporary extension that I've been evaluating for some time called "WindowMenu" (link). I don't plan to keep it, so I'm fine with it not being compatible, but I thought I'd mention it in case might provide some clues. With the first version of Exposé, it caused a 15–20 second delay after the Finder had loaded before the computer started responding. With beta 3, it first just prevented the keyboard shortcut from working, but after a couple of restarts it suddenly caused the computer to completely freeze as soon as the mouse pointer reached one of the active corners.

"Inline Support" no longer prevents the keyboard shortcut from working, but WindowMenu does not seem to be compatible at all.

I've attached "Inline Support" and what I believe are the core files needed here in case they're of any help (all in all it's a set of 19 extensions).

 

[PB170]

Yes, I already added a delay before the dialog vanishes. 24/60 seconds if I remember right. I tried a few durations and that felt snappy yet still intentional. (Too short a delay and, paradoxically, it just starts to feel like the dialog is just a tad slow to disappear rather than intentionally pausing briefly.)

I like the giant keypress display in the dialog … though perhaps I can be persuaded to change it eventually. I have never seen a “enter a keystroke” dialog on classic Mac OS that displays modifier key presses live in this way, and I think it’s really the correct way to do it, so perhaps I’m just showing off a little …

I think I might have dismissed your addition too quickly (may have been because of those giant letters )

It’s actually a very nice usability feature, making sure you enter the keys you intended. And also cool in itself – makes you want to play with it a for a while before setting the shortcut

Regarding the delay, I was actually thinking of one that’s a bit longer, say 1 second or so. That way you would have a chance to also correct the letter you typed without having to go back and start over. Now that we have the preview, that would be a good way make use of it I think.

But I do have to convince you to tone down the size of those characters Less is more, you know

Also, the Chicago typeface is quite hideous in anything but the 12 pt screen font The TrueType version is basically just a blown up version of the low resolution screen font. Normally you design typefaces the other way around, or keep them as just a bitmap font.

 

[PB170]

During the past dew days, I've done some further analysis of the animation, and tried thinking about and evaluate possible optimizations/simplifications.


Some observations:

When the paths of two nearby windows/rects intersect, they create an additional shape in between them, creating the impression of a third window that's shrinking in size:




And when more than a handful windows are open, we sort of get complete chaos:






While it's difficult to say for certain without being able to try it out, I think an algorithm like the following would create a cleaner result while hopefully not being too difficult to implement:

Let's begin with imagining the screen divided into ten sections like this, each 36 degrees apart, starting vertically:




Then we'll merge the two divisions at the top and bottom to create a distribution of divisions roughly corresponding to the eight sides and corners of the display:




Now, if the paths of two or more windows fall into the same section, let's combine all windows into one and calculate a single rect/path to be used in the animation by taking the two windows furthest to the left, top, bottom and right respectively and calculate the average points between them, like this:




This would hopefully make the overall animation cleaner while still maintaining the feeling of windows moving in their respective directions, as well as removing some of the secondary, shrinking rectangles.

@Crutch, do you think this would be a reasonably easy thing to try out?


Alternatively, the rect could be positioned so that it's aligned with the sides of the window that's closest to the center of the screen, or a rect enclosing the windows could be used instead (illustrated below). Difficult to say what would work best without seeing it in action (thought about doing a new mockup but felt it would be hard to cover all situations).






Also, @Crutch, would it be a quick thing to add some temporary controls to alter the number rects and how many of them are displayed at the same time, like I asked about before? It'd be great if I could play around with it a bit

By the way, it looks like we're currently drawing a total of 14 rects instead of 12 like with the original zoom rects. You also mentioned switching to 5 rects at a time instead of 3. I think it would be good to start with the original 12/3 and work our way down till we find a combination that looks clean and displays reasonably fast. Preferably matching the 0,25 s of the original if possible.


A final, completely separate, note: I would assume not, but does the Toolbox support drawing the rects so that they behave opaque but while preserving the background, so that we can just avoid the overlap? If so, that might be a much better solution than the one described above. Just throwing it out here.

Illustration:

 

[Crutch]

This is good stuff.

Great minds think alike and all that on the screen sectors, I basically tried this already but didn’t quite finish. My technique was slightly different. I combine all the overlapping rectangles in each screen sector into a QuickDraw region, so you only see the combined outlines of overlapping windows and they whoosh away to the sides of the screen.

I will play with it a bit more then look to share something that provides a couple options as you suggest!

Thanks for all the feedback!

 

[PB170]

Great!

I thought of that option too, but picked the ones above instead since I wasn’t sure if new, non-rectangular shapes would make sense. But if you’re already on the way of implementing it, let’s try it out!

By the way, how did you implement the sections? I played around a bit with different number of sections and also thought about just splitting the screen corner-to-corner and side-to-side, but I felt that a solution with equal sections like the one above probably would be easier to code.

Look forward to the next beta!

Do tell me if there is more that I can do. My patience is more or less unlimited with this project

In the meantime, I'll continue testing/using the latest version. So great that file/folder dragging now works! Truly makes it feel like there's a part of current day macOS in my PowerBook.

 

[PB170]

By the way, if you see any way at all to realize the last option in my post, I think that would be the best way to do it.

 

[Crutch]

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?