>> Crutch said:

It's not the 68000 that's tripping you up, it's the ROM. The Plus ROM doesn't have the Graphics Devices calls in it, so you can't call GetMainDevice. Pre-Device Manager, you can check the QuickDraw global variable screenBits.bounds to get the bounding rectangle of the display. (You meant 512x342 above, not 512x384, but anyway that would be wrong on a Portable.) Click to expand...

Quick question @Crutch. Why does
GetNewCWindow() crash the old rom machines? In addition to not calling devicemanager stuff the last thing I had to do was instead call
GetNewWindow() if the machine was one of these old machines.
Meanwhile my Se/30 was cool with calling GetNewCWindow() despite not having a color screen.

lastly- when I tried calling the Gestalt(gestaltQuickdrawFeatures) the mac plus would still claim true for gestaltHasColor. Which may make sense in that the version of quickdraw I'm running has color support despite my monitor not having it-- but then again why would GetNewCWindow crash.

For now, I just looked at either the processor type or the machine type to decide what to do. But I feel there has to be a better determiner. Or perhaps, looking at the ROM version is really the correct move?

>> MacOfAllTrades said:

@lilliputian , try this branch ! It should fix the issue with the older Macintoshes: I have it up as a pre-release on the releases page too On the plus side (no pun intended) this also includes the dynamic sizing stuff I've been talking about - all wrapped into the beta release. Give it a whirl - thanks for all the great feedback. Yeeesh can't believe I broke compatibility without knowing it with the color stuff. Click to expand...

Lookit that!

>> lilliputian said:

Lookit that! Click to expand...

Nice. ((That extra blank spot on the right end has me worried... should never be a blank unless you were in the middle of launching or quitting a program when you took the photo?))

amazing that the code I was writing this morning is now executing on a 40 year old machine who-knows-how-far away.

That beta has the funsies/non-release zoom ++ and - - feature. Fun to see it all big and goofy

if you have applescript and the finder scripting extension installed you can also command click on items. Enjoy and let me know of any (more) issues!!

After fiddling with it, it appears that the "blank" spot (which was present at launch) is MacDock itself. Clicking on it from another program switches to make MacDock active in the Application Menu.

>> lilliputian said:

After fiddling with it, it appears that the "blank" spot (which was present at launch) is MacDock itself. Clicking on it from another program switches to make MacDock active in the Application Menu. Click to expand...

Hm that is a bug, obviously. It should show its icon, for one, but there is a menu option to opt into showing it (default is no show at start). Geez i swear it wasn't doing that on my test setups of my physical SE and mini vMac.
Mo code mo bugs... :p

edit: retried it on my SE with 7.0.1 and couldn't reproduce the blank square. Are you running any interesting programs or sophisticated extensions. macdock goes through all the processes and for any that are of type APPL (or whatever the application type designator is) it will put it in the dock. The two exceptions are the finder which is not technicaly of type appl instead it is 'MACS' and macDock itself which I filter out by its signature and only include it if the menu option is set to "Show self in Dock".

however, I have noticed if you have two macdock copies running it will produce one excess blank spot like you see in yours.

@lilliputian does that blank spot BLINK when you click it? That would help clue me in whether you are clicking on a mal-plotted macdock app icon or if its just (incorrect) extra wide dock border.

>> MacOfAllTrades said:

Thanks for the tips as always. I implemented the window redraws by hiding the window before the resize+move. Tradeoff being that it technically disappears momentarily while it resizes+moves in the background before drawing it again in the new size+position but on my SE/30 it was unnoticeable. I should try it on my SE to see a slower system try it. I also added a dynamically-sizing dock over the weekend! @Sideburn def thanks for posting which got my mental juices flowing enough to get excited to buckle down on this some more. The core of the graphics is nice and modular to support all sorts of icon sizes though I don't think it's worth letting the user customize the dock size ((this little internal build does have a Size++ and Size-- menu option so I could visually try different sizes and even faux-animate by holding a key stroke to see how slow the redraw would be -- it's not bad but probably not worth it. Here's a video of me using the internal updates including Small Dock toggle and dynamic resizing. It's actually surprisingly satisfying but most people love their own babies no matter how good or bad they are : View attachment 13650 What I really want to try next, and prior to releasing updates, is adding apps that aren't running to the Dock as discussed above. And if I'm doing that I'll probably try letting the user add documents or folders etc because it probably won't take much to add that too. This sort of "favorites" would be great because it would make MacDock not just an app switcher but also your app launcher and documents favorites all in one. Perhaps above all else - the modern Dock lets you do it, too.. Click to expand...

Nice updates. Yeah non running apps would tie it all together and then no more need for alias's on the desktop.

>> MacOfAllTrades said:

Quick question @Crutch . Why does GetNewCWindow() crash the old rom machines? In addition to not calling devicemanager stuff the last thing I had to do was instead call GetNewWindow() if the machine was one of these old machines. Meanwhile my Se/30 was cool with calling GetNewCWindow() despite not having a color screen. lastly- when I tried calling the Gestalt(gestaltQuickdrawFeatures) the mac plus would still claim true for gestaltHasColor. Which may make sense in that the version of quickdraw I'm running has color support despite my monitor not having it-- but then again why would GetNewCWindow crash. For now, I just looked at either the processor type or the machine type to decide what to do. But I feel there has to be a better determiner. Or perhaps, looking at the ROM version is really the correct move? Click to expand...

Right -- the Plus and the SE don't have Color QuickDraw at all (hence you can't call GetNewCWindow), whereas the SE/30 does (it just can't show any of those colors on the internal monitor). This has tripped me up before!

gestaltHasColor shouldn't be true on a Plus I'm pretty sure -- are you certain you're checking the right bit? Anyway yes I usually check the ROM version for this because I'm too lazy to call Gestalt :)

#define COLOR_QD (ROM85 >= 0x3FFF) // checks for IM Vol 5 8-bit (not 32-bit) Color QD if (COLOR_QD) w = GetNewCWindow(...); else w = GetNewWindow(...);

>> Crutch said:

Right -- the Plus and the SE don't have Color QuickDraw at all (hence you can't call GetNewCWindow), whereas the SE/30 does (it just can't show any of those colors on the internal monitor). This has tripped me up before! gestaltHasColor shouldn't be true on a Plus I'm pretty sure -- are you certain you're checking the right bit? Anyway yes I usually check the ROM version for this because I'm too lazy to call Gestalt C: #define COLOR_QD (ROM85 >= 0x3FFF) // checks for IM Vol 5 8-bit (not 32-bit) Color QD if (COLOR_QD) w = GetNewCWindow(...); else w = GetNewWindow(...); Click to expand...

Argh! Double checked and you're right! I should re-enable my human brain's memory check at startup...

Sure enough, the Mac Plus reports no color with
Gestalt(gestaltQuickdrawFeatures, &result);

The bit gestaltHasColor (bit 0) sure enough is a 0. No color.

I hope you never get tired of being right or knowledgable. I know I appreciate it!!

edit to add that my masking method is probably not the most straight forward. Better to do if(result&(1<<gestaltHasColor)) so it more clearly reads as bhtshifting a 1 to the right bit spot.

Update made to MacDock. Released what was in beta almost a year ago and fixed a few more things. See release notes in the README.md!

Enjoy!

Glad to be back on the wagon with this thing. This will be the last update before I (hopefully) make the major changes I spoke about a year back in my previous posts about suppporting storing non-running apps and aliases as dock items.

Super excited to share that the v2.0 is coming along! -- Big thanks to all who supported past and present!

A lot of replacing the old 1.x way of storing the dock items internally so that it can support the necessary dynamics of apps that are running, or not running (like Keep In Dock on modern macOS) but the internal core rework is done.
TODO: add contextual menu to offer choices like KEEP IN DOCK, but for now I have it hooked up to a hotkey (ctrl click) so it's hard to tell in the video when I'm ctrl+clicking to KEEP IN DOCK but you can see it by when an icon triple blinks for now.

Also, I added the little dot on the bottom of the running apps (again, like in modern macOS).

Lots of to dos such as:

1. Saving your KEEP IN DOCK items to a preferences file or something so that they persist between app launches.
2. Contextual menu that lets you choose the same things macOS does today (Keep in Dock, Show in Finder, Open at Login) -- currently this is done by ctrl+click, cmd+click, (and no way to launch at startup currently but easy enough)
3. Dragging dock items to rearrange their position
4. Drag + Drop support so you can drag items from the Finder onto the Dock like adding a new app
5. Drag + Drop support so you can drag items from the finder onto an app in the dock i.e. to open a document you've dragged onto an app with that app.
6. Maybe: the Trash as a permanent last item on the Dock

alpha 2.0 release.
favorites that persist btw app launches via Preferences file!! Super psyched about this
Will post a video soon for viewing pleasure -- super pleased with the progress given my busy life! Needs fixes before calling it a final 2.0 :)

Wonderful job!

I just realized from your notes on the latest Alpha release from the 11th that in order to keep an item in the dock you have to Ctrl-Click its icon when it's open. Unfortunately, pre-ADB Macintosh keyboards don't have a Ctrl key!

>> lilliputian said:

I just realized from your notes on the latest Alpha release from the 11th that in order to keep an item in the dock you have to Ctrl-Click its icon when it's open. Unfortunately, pre-ADB Macintosh keyboards don't have a Ctrl key! Click to expand...

Wowsers never thought of that. I hope to do away with ctrl click to add to favorites anyway.. but not sure what's best for that. Any ideas??

Perhaps Opt-Shift-Click? Having two modifiers would also ensure that it's a deliberate action and isn't invoked accidentally by the user. You could also add a preference for customizing which modifier(s) is/are used, but obviously that's extra work for you on the back-end.

FYI, https://macintoshgarden.org/apps/macdock

thankyou for making MacDock. good job, well done!

Is it possible to build this as a System Extension?

>> nilobject said:

FYI, https://macintoshgarden.org/apps/macdock thankyou for making MacDock. good job, well done! Is it possible to build this as a System Extension? Click to expand...

We can put an alias of it in the Startup Items folder, and it should be functionally the same. Plus, the modern dock is its own application as well.

I must say I have dreamed of extending it to be an extension. Maybe I just want to see it load as a little puzzle piece during startup. But anyway I'd love to add to it and the system extension would be a great idea - I do keep it in my startup folder as liliputian suggested but what I'd do with it as an extension is aim to keep it floating atop of all apps permanently (like modern macOS dock).
Thank you for following up and nice feedback all.

That's true! I forgot about that part, that would definitely be handy. :)