CMD + Scroll Up/Down to Pinch In/Out [FR]

[iaurman]

Currently PinchBar changes pinch action to scroll action. But how about the other way around?

There are other apps like Mac Mouse Fix to change normal mouse scroll events into pinch events. But it cannot do the smooth scrolling events of magic mouse. This app could do that.
(Seamouse doesn't count because it's buggy and doesn't work anymore.)

Pinch in & out is the only function magic trackpad has that magic mouse doesn't. Enabling this function, you could kill some people's wish to buy magic trackpads. It would be so cool.

[pnoqable]

Hi iaurman,

thx for bringing this up to my attention! I was not aware that this could be usefull to somebody but I see this feature's relevance to Magic Mouse owners. I did not know about Mac Mouse Fix but I'm glad to see it's MIT licenced as well. I'll have a deeper look into its source some day. But until then, could you plz tell me:

In what way does Mac Mouse Fix not achive the desired behaviour? Is it that it lacks smoothness when zooming via CMD + Scroll with a Magic Mouse? If so, I guess it just uses line scroll data but ignores per-pixel scroll data of scroll events.

Are you in some way connected to MMF developers/comunity? I am a lone dev and this is my very first own open source project, so I feel a little shy to reach out to and connect with other github contributors x'D My own goal is to promote PinchBar on Steinberg's user forum for Cubase (in some weeks) and see, if it gets any attention there. Im really not great at marketing my ideas nor at connecting with strangers on social media...

But I think this kind of extension could easily be integrated into PinchBar in the form of just another preset which maps scroll to pinch events. Downside would be, that presets (in my current design) are assotiated with a set of (foreground) applications and only one preset is active at a time. But if I understand you correctly, you would like this feature to be enabled for all (foreground) apps. Am I right? ATM this would imply that all other presets are disabled at all time contradicting the initial use case of PinchBar. Maybe I should consider extending my design for global and multiple active presets.

I you wanna have a look: I just generalized event mapping a few weaks ago on the development branch. It's not yet merged into master because I'm working on generalizing the app as a whole. I still have to experiment with ui desgin a little to get the code clean enough for my satisfaction. Sadly, the easy ux of NSStatusItem is part of Cocoa which does not integrate very well into Swift. This makes ui development much bulkier, so I'm looking for an easy work-around as I don't intend to implement a full featured gui. I.e. till people actually start using PinchBar and explicitly ask for this ;)

[iaurman]

Thanks for replaying!

In what way does Mac Mouse Fix not achive the desired behaviour? Is it that it lacks smoothness when zooming via CMD + Scroll with a Magic Mouse? If so, I guess it just uses line scroll data but ignores per-pixel scroll data of scroll events.

It turns out that the scrolling events from normal mice are different from the fluid touch scrolling events from magic mouse. And MMF deliberately choose not to deal with the latter for reason discussed here.

Are you in some way connected to MMF developers/comunity? I am a lone dev and this is my very first own open source project, so I feel a little shy to reach out to and connect with other github contributors x'D My own goal is to promote PinchBar on Steinberg's user forum for Cubase (in some weeks) and see, if it gets any attention there. Im really not great at marketing my ideas nor at connecting with strangers on social media...

Unfortunately no, I'm just a college student who knows a little bit python and have no experience in macOS development. However, the owner of MMF said in the link above that If anyone wants to do this, I think I have a decent idea how to go about it and I can give you tips and advice if you like. And since the goal of MMF is very different from your app and the feature we are discussing here. I'm sure there is no conflict.

That's pretty much all the information I can provide...

[pnoqable]

I just checked out the download of Mac Mouse Fix (not yet the source) on my Nucintosh on which I just have a Microsoft mouse with 5 buttons. Very neat tool indeed! I previously used Sensible Side Buttons and configured two hot corners for Mission Control and Application Windows, but being able to do all this with just holding and dragging the middle mouse button feels very intuitive. So I switched to MMF without second thought ;)

But CMD+scroll to zoom doesn't seem to work on my system and so-called smooth scrolling messes up not only rapid scroling but also common browsers' zoom behaviour with CMD/CTRL+scroll. Good thing it is an optional feature which I disabled right away.

At this point I'm absolutely with you that trackpad UX is one important feature ahead and maybe PinchBar could fit this gap at least temporarily until noah or somebody else got that fixed in-app.

I also figured out how to handle the Cocoa interfacing mismatch I wrote about yesterday. So the current big step for me is to merge my generalized app design back into the master. I will then try to implement your FR on a new feature branch. When that's done, could I ask you politely to test that feature on your device and give me some first feedback? :) First version will definitely not be to your full satisfaction as it will just add one single preset you will have to activate for each app.

But when this does what you asked for, I will try to make global and multiple presets work simultaniously as I think this feature is a reasonable extension for other use cases of PinchBar as well.

[iaurman]

Of course! I'm glad to help. That would be so cool.

[pnoqable]

ok, i just managed to consolidate the development branch, merged that into master and released a version 0.2 based on that. since i do not own a magic mouse anymore, i start developing the new feature against trackpad scroll + CMD. when this works, i'll try it with my microsoft mouse which does not support continous, i.e. per-pixel scolling. But till now, i always saw the same kind of scroll events, just with a differing flag set when pixel data is sent. so i see no reason what could stop the show.. but i definetely invested enough hours in PinchBar for today. maybe i have some spar time tomorrow. we'll see

[pnoqable]

Hi iaurman,

i'm having kind of a crazy horse of a week as i just started with a new job and a new musik project at the same time. Luckily both of these are just side projects, so I was able to turn my attention back to stuff that really matters: Nerd stuff :D Yesterday evening, I finally found some time to dig deep into the lower levels of Core Graphics for which Apple doesn't provide documentation (aka private api) and with my recent results I can assure you: we're on the right track. That is: Success!

It's not yet ready to the point that I could give you a working copy of PinchBar with our feature to test. But I am now able to record and replay pinch events I produced with my Macbook's touchpad so that other apps react accordingly zooming in and out on playback. Not only that: The playback of these recorded events is even possible on my Nucintosh which doesn't have a trackpad attached!!!

So, when I scrolled the mouse wheel, my prototype discarded the scroll events playing back the pinch events instead, so when viewed from far away and having eyes half-closed, it looked like our goal: zooming with just the mouse wheel and a modifier pressed - i.e. it completely ignores the speed and direction you scroll.. xD

So by now, it's mostly just a matter of reconfiguring the event tap, reading the real data out of the scroll events and finding a good mapping from these to the (undocumented) pinch events. I have already done some analysis of the pinch data the trackpad creates, so this doesn't seem too hard to me.

The last open question I have for you: What would your test setup be? From what I understood so far, you are using a Magic Mouse on a Mac. What kind of Mac would this be? Which version of macOS are you using? Do you also have different machines / input devices to test possible unwanted interactions / edge cases, etc.? As I am running macOS Ventura with OpenCore Legacy Patcher on MacBook pro 2015 and on the Nucintosh my own test device pool is really not very conventional and my own test results might therefore not be universally valid...

[iaurman]

Glad to hear the progress. Looks like you've been having a colorful week.

What would your test setup be?

• MacBook Pro 2018 running Ventura 13.1 (trackpad fully functional)
• Magic Mouse 2
• Another normal non-apple mouse (Though I do not have another apple device.)

Thanks again for your time and energy put into this project! As before I'm happy to test the feature for you.

[pnoqable]

Hi iaruman,

it's been a while since my last message to you, as I was busy and at least somewhat successful with promoting PinchBar to Cubase users.

And today, I finally finished my first prototype with your requested feature which I now like to share with you for testing. Since this version is quite a hack and therefore definitely no release candidate, I don't wanna upload it here and instead give you a link to the app on my google drive.

This version has an extended event tap that maps scroll events with CMD+ALT held down to pinch events. This first version only takes pixel scroll data into account (but no row scroll data of conventional scroll wheels), so it presumably won't work with other mice than Magic Mice and Trackpads as they also produce pixel scroll data. This extended event tap is hard coded in this version and always active independently of active apps and if they have presets configured in PinchBar.

Please feel free to test this version in any way you can imagine. I would just ask you politely to not share this version online with other users as I want to fully integrate this feature in PinchBar's config structure first and than upload it here as an official new release.

[iaurman]

I would just ask you politely to not share this version online with other users as I want to fully integrate this feature in PinchBar's config structure first and than upload it here as an official new release.

I understand. Of course.

However, I cannot open it. I tried look into System Settings -> Privacy & Security. But there isn't any kind of notice.

[pnoqable]

I see. Apparently Google Drive messes with file attributes. I reuploaded it as a zip file and tested it on my nuc. Now it works.

[iaurman]

It works!!!! I didn't except it to be so smooth and easy. Works with both the on-board MacBook Trackpad and the Apple Magic Mouse 2. No bugs found at all. You just saved me a lot of money and hopefully a lot of other people's, too. Great work!!!

[pnoqable]

Thank you for confirming that! You're right, the real-time mapping these low-level events feels very responsive, even on old Macbooks like mine. As I got my very first prototype of PinchBar working for Cubase zoom (around spring last year), I was very impressed of the ease of movement, too. This is why I felt like I have to make a real (open source) project out of it and share it with the community!

[iaurman]

On that note, PinchBar is going to be an all-time background app for people wanting this feature. So it would be even better if PinchBar can Start at login. Another FR for you;)

Again, thank you so much for your time and beautiful work.

[pnoqable]

Yeah, there is plenty of room for usability improvements like this. But this is easy to setup by now just using System Settings, so integrating this into PinchBar won't become top priority. Maybe I think of it when I consolidate development branch for the next release..

But first, I gonna integrate scroll event mapping into PinchBars configuration as there is already a Cubase user with another nearby usecase for scroll events. This seams to me like a perfect milestone for now as both of your feature requests depend on scroll event mapping.

[pnoqable]

I am currently thinking about possible further development of PinchBar, which I would be interested in your opinion on:

When I originally switched from a ThinkPad to a MacBook, the first thing that bothered me the most was the missing middle click for closing tabs, etc. At the same time, I was working on a Mac mini with a Magic Mouse and really loved the gesture control, but also missed the middle click. Like many I bought a licence for BetterTouchTool, which now has expired long ago. I don't want to spend the money again, as I don't need any of its other features either.

That's why I just use MiddleClick since then. In fact, my very first PinchBar prototype was a local MiddleClick feature branch. Because its ObjectiveC codebase sucks, I started porting it to Swift. And since it has a standalone use (for Cubase users and such), I started this repo here independently of MiddleClick.

In the meantime, it seems to me that with this new feature, PinchBar could develop into some kind of universal Magic Mouse and Trackpad tool for various use cases. That's why I'm now wondering weather to reintegrate the middle-click function (with two/three fingers on the Magic Mouse/Trackpad).

This would make PinchBar something like Mac Mouse Fix's sister project, but specifically for Magic Mouse and Trackpad users.

Do you think that makes sense?

[iaurman]

The only app I encountered that requires middle click is AutoCAD which can be replaced by just using space bar. Other than that, I'm afraid that I'm not familiar with the concept of middle click function. I didn't even know you could middle click on tabs to close them. I do have some thoughts:

If PinchBar is to become something like Mac Mouse Fix's sister project, but specifically for Magic Mouse and Trackpad users. I think the idea of PinchBar being simple with no UI and no configuration would have to change because how powerful it would be. It means that one can configure one event of Trackpad/Magic Mouse into something else. And there can be a lot of events and final executions. What I can think of at the moment:

Events/Triggers:

1. Trackpad's Three Finger Click, Tap with or without modify keys
2. Trackpad's Three Finger Scroll-Down(because this one is basically useless) with or without modify keys
3. Trackpad's Four Finger Click, Scrolls with or without modify keys
4. Magic Mouse's Two Finger Click, Tap, Scroll with or without modify keys (hack, you can even restore the original way of Magic Mouse to open Mission Control back when Apple announced Magic Mouse which is two-finger scroll down or up? I wonder why they got rid of it though)
5. Magic Mouse's Three Finger Click, Tap, Scroll with or without modify keys
6. Magic Mouse's Four Finger Click, Tap Scroll with or without modify keys
7. Draw a pattern like a "L", a "O"?

Final Executions:

1. Pinch of course(Command or Option+Command or Shift. Control + scrolling seems to make the most sense to me. All you have to notice is to change the System Accessibility zoom trigger to something else. Two-finger scroll to pinch also makes sense. You can leave that for the user to configure.)
2. Scroll
3. Open apps
4. Mapping the trackpad three-finger swipe up to slowly open Mission Control (to implement Magic Mouse two-finger to open mission control.)
5. Show desktop
6. Open Launchpad
7. Command + Tab (to implement scroll to switch app)
8. Switch focus of apps on Dock (imagine not having to move your cursor to dock to choose and open an app on dock by some weird three-finger scrolling and tap)
9. Execute shell command / apple script / apple shortcuts (image using a weird scroll to turn off your light)

As you can see, this has become too complicate to manage simply by toggling a preset in the menu bar. You have to develop a whole UI or use some kind of config file(~/.config/xxxx/xxxx.json) to avoid it.

Also that's a lot of work, almost too much. And when it's complete, the project name PinchBar does not signify it's functionality anymore because it has went beyond just modifying pinch events. So it would even need a name change for christ's sake.

So yeah, it definitely makes sense if you are to go down this route. You will change Magic Mouse. But it would also make sense if PinchBar just remains simple for the price to develop the above features is too high or maybe there just isn't a very large amount of people that uses Magic Mouse so it's not really worthy it. But either way, I'll leave the decision to you.

For me, Pinch-to-Zoom is all that matters. And I'm just happy to have that.

[pnoqable]

You have to develop a whole UI or use some kind of config file(~/.config/xxxx/xxxx.json) to avoid it.

Actually, PinchBar already has a configuration mechanism which I'm extending for remapping scroll events right now. I've just not documented that as SwiftGUI is my next victim to take down and then there will be some kind of settings view, so defaults configuration won't be necessary for end users. You see, I like to learn and adapt Apple's technologies whereever applicable and ATM SwiftGUI is the biggest elephant in the room for me...

BUT: You're right in the sense that it would be asked way too much to develope PinchBar into some kind of open source BetterTouchTool. After all, if someone is looking for a tool like that, there already is a professional solution which is developed by a professional dev that has professional ressources. This is by no means my plan to sabotage.

So, my idea of what PinchBar might become is more like: Just filter mouse and trackpad events (clicks, scrolls, zooms) and map them according to modifier state and number of fingers involved. But no features like key press events, gesture 'pattern' recognition, and most importantly: no triggering of external OS events as this is the domain of several other tools.

So I see PinchBar not as a tool to extend interaction with macOS, rather than to close the gap between all different pointing input devices such as Magic Mouse/Trackpad and other mice. Well, the last one is already the domain of Mac Mouse Fix, so there would be a border to define. But since both are MIT licensed, there is probably no war to fight and maybe both could marry someday in the future..

Btw. do you know Reactangle? It's MIT licensed, too. Ah and there is Fluor being in the same pot for me as well.

All, very neat and functional and the user just can pick what he needs..

[iaurman]

Bug report: Pinch Operation Still In Effect When Not Supposed To

Sometimes, when you have release the modify key(option + command) and left your fingers off the surface of the Magic Mouse and move on to the next operation, the pinch operation seems to be still in effect.

https://user-images.githubusercontent.com/46162162/216245473-17c48b63-8b4a-4e6d-b14b-d7bd42c068b4.mov

Or, if you right click while option + command scrolling, the bug will 100% reappear.

https://user-images.githubusercontent.com/46162162/216246902-9db34d36-da2b-46fb-94b7-1269c79b1522.mov

However the latter is not a bug of PinchBar since pinch using Apple's own trackpad while right click on any other mouse will cause this.

This could be macOS's fault. Could be tricky to resolve.

[pnoqable]

Hm, I can't reproduce the issue yet. Maybe it's because I only use the touchpad. I don't have a Magic Mouse yet to test 'harder'. But I've just messaged someone who's selling one in town for 19 bucks, so I might be able to reproduce this later (this weekend).

Meanwhile, could you please reproduce the issue with this new version on Google Drive. It streams debug output to Apple System Log. To grab it, just open Console, start streaming and reproduce the issue with PinchBar. After that, please enter PinchBar into Console's search field, change 'Any' to 'Process' and copy-pasta the whole listing here.

However the latter is not a bug of PinchBar since pinch using Apple's own trackpad while right click on any other mouse will cause this.

I noticed that the trackpad's click function is disabled while zooming. I guess Apple is aware of this edge case and circumwent it that way. Interestingly, the behaviour is different when scrolling: While doing so, it's disabled as well, but turned on immediately after stopping without releasing the touchpad. I guess, here this is a small time window where things can get messed up when using other input devices / methods.

But as I said, I can't break anything just using the trackpad. So I'll have to rely on your logs for now.

[iaurman]

!!! Forget about the log. I know what happened. The first case above is not "sometimes". This is how to reproduce it with Trackpad or Magic Mouse:

1. Pinch in in a safari page.
2. Press and hold Option and Command
3. (using trackpad or Magic Mouse)Scroll all the way back til you see the black under layer of Safari(even if you don't pinch all the way back, the bug still exists. doing this way is more obvious.) but do not release your finger off the surface of the trackpad or Magic Mouse
4. Release Option and Command
5. Then release your finger off the trackpad or MM.
6. *the bug happens*
7. If you don't move the cursor and then pinch back in, it's not that annoying. But if you move the cursor around and then pinch back in, the web page or whatever the app may be will be buggy for a second and you lose track of where you are in the web page which is really annoying. I just discovered that the location of cursor also will be broken if you try to select text or something when the bug happens.
8. Or when I'm in some other app like Pixelmator Pro. When the bug happens, some shortcuts of the app won't work unless the bug disappears when I pinch back in.

https://user-images.githubusercontent.com/46162162/216752119-f573d8f9-ea53-4a59-aa48-c21f1f69f6e4.mp4

[pnoqable]

Ok, I got it now. The key point is to use Safari, to zoom in a bit before zooming out and then release modifier keys or right click. Yesterday, I tried to reproduce it using Firefox, but it is much more robust to inconsistencies in zoom events than Safari.

I had some time in the evening to analyse the issue and found the root cause. It's not really a bug, rather than a missing refinement of this zoom feature. You see, ATM, this new feature is hacked into PinchBar in a way that scroll events are mapped to zoom events one by one, always checking if according modifiers are pressed. On the other hand, macOS treats zooming as a transaction, ie. it expects the first zoom event with phase=Began, the next ones with phase=Changed and the final one with phase=Ended. So, when you release the modifiers before you take your fingers of the trackpad, macOS still waits for the final zoom event with phase=Ended as the final scroll event was not mapped to zoom.

So, our feature logic has to be extended in the way, that PinchBar keeps track of this so called transaction. I.e. when scrolling starts with according modifiers, it has to remember that it is now in said transaction state and therefore has to map all scroll events to zoom events until scrolling has finished, independently of modifier state.

The very first issue you found is bit more advanced. I found that if you 'right click' (= two finger click on trackpad) before finishing CMD+ALT+scroll, this right click event comes before the final zoom event with phase=Ended which Safari can't handle. As I wrote yesterday, Apple circumvents this issue with pinch zoom on trackpad by disabling click function in said transaction: Try to click while pinch zooming, it won't even make the 'tick'. This is different while scrolling: Click is activated again as soon as you stop with scrolling (i.e. while your fingers still rest on the pad). I think there is no (open) interface to deactive that 'tick' as this is presumably handled on driver level. And, speaking for the Magic Mouse, the tick is an actual physical click, which can't be supressed at all.

But PinchBar could tap click events, too, and discard or delay them while in zoom transaction. I tested this in an even hackier test version of PinchBar's and it successfully circumwent your first issue. But I need a bit more time to implement actual transaction logic in PinchBar.

Not that much time though, so please feel curious to get and test the next version of your feature request :)

---

PS: I just got the Magic Mouse I wrote about yesterday and testing all that again, I have now several ideas for improving UX of zooming. I think, there's no actual need for modifier keys. I'm just contemplating of a nice architecture to combine all these aspects into PinchBar's event tap...

[pnoqable]

Hi iaurman, a new test version on my google drive fixes all issues (AFAIK). Logging is left intact if you find any further issues. Plz feel free to try to break it. I wonder if the new app logic is rigid..

[iaurman]

Hmm, it seems that neither of the right click or pinch out problem is solved.

[pnoqable]

Huh? Please confirm you are indeed testing the new version 0.2.3: (plz see PPS)

---

PS: Ah, lol. I put the new zip file in the sync folder and messaged you here on github but apparently closed the lid before google drive finished uploading. Sry for the inconvenience. 0.2.3 is now uploaded.

---

PPS: I just remembered that I didn't change the version tag with the current build. So, you may see a version 0.2.3 but that is not the build I just uploaded but the last one with just logging enabled. So plz redownload this new version. Again, sry for the inconvenience... 😬

[iaurman]

Ha, it's fine. All the issues above are resolved. The bugs are cleared.

Funny story, I just found that PinchBar can fix a bug of macOS.

You see, once in a while the pinch in and out gesture stops working with trackpad. It can still do other things fine, scrolling, clicking, even the smart zoom. But it just cannot pinch in and out anymore.

My solution used to be just to sleep the mac and re-login. Then I found that you can disable and re-enable the "Zoom in or out" option in System Preference to fix it so that you don't need to re-login. Then after that I even wrote an AppleScript to automate the process.

Today I ran into this bug again. And I thought I could give PinchBar a try. So I did the option+command+scroll thing. And, the bug goes away! Hooray!!! No more doing the whole System Preference dance. Long live the PinchBar!!!

[pnoqable]

Haha! 😄 This is a nice anecdote that slightly brightens up my heart 👍

Also glad to here that everything now works for you!

I just adverticed this feature request on a somewhat related thread on Steinberg's forum (the manufacturer of Cubase) to get some users over here for testing. Don't know if it works, we'll see...

But again, same as last time: This is still a very hacky prototype of PinchBar in which I hard-coded the logic for this new feature. It's not ready to be handed around. So, plz feel free to use and try to break it. But it's not meant to go productive.

In the meantime, I'm gonna extend PinchBar's configuration logic to this new transaction model and then integrate this feature into PinchBar's main logic. This would be a good place to consolidate dev and master for a version 0.3.

Also, be prepared for the next test version: I have a prototype on my machine that is able to detect two finger scroll on Magic Mice: With this feature you won't need to hold modifier keys to zoom with your Magic Mouse :)

[pnoqable]

Ok, after a 10 day battle with first frequent, later sporadic crashes of Safari's renderer, I'm finally done glitch hunting and now just happy to give you this new version of PinchBar to test. No other app I've tested PinchBar with is as susceptible to timing inconsistencies as Safari... But tonight I finally identified and fixed the last known issue (to me) that made Safari unstable and caused it to lose and reload its active tab. I am confident now that with this version of PinchBar (0.2.4) you can browse (and zoom) the web without such issues.

What's new: This version utilizes macOS's private framework 'MultitouchSupport' to identify the currently used multitouch device and read its current touch count. This information is now used instead of modifier flags (i.e. CMD+ALT in 0.2.3). PinchBar 0.2.4 now maps two finger scroll events of Magic Mice to pinch events. Additionally, I added my own favorite feature to map two finger clicks of a Magic Mice and three finger clicks of (Magic) Trackpads to middle clicks. This opens links in new tabs, lets you close them easily and might even give you more direct control in AutoCAD (does it work though? PinchBar does not map drag events yet)...

That said, all changes are still just vertically prototyped and thus pretty hacked into PinchBar. None of the new features can be configured and the data model is yet to be adapted before that will be possible. Also, I'm still unsure what a light-weight settings gui should look like and how many controls an average user would want to see or even really need to adjust...

[iaurman]

Sorry for the delay, college school coming could be overwhelming.

1. I don't think the two-finger scroll to pinch function is working... (Yes, it is 0.2.4)
2. "Three-finger click to middle click" on magic mouse and trackpad is working. That means I don't need the MiddleClick app anymore, yayy.
3. "Two-finger click to middle click" on magic mouse is not working. And honestly I don't think you should map the two-finger click to it at all because I think the way most people use magic mouse to click is to rest their two fingers on the magic mouse and click. Two-finger click should just be a normal left click and stay that way.

[pnoqable]

N.p. and heads up! I felt very similar at the beginning of my studies and still managed to graduate well. Besides, I was very busy the last two weeks, so good timing ;)

2. "Three-finger click to middle click" on magic mouse and trackpad is working. That means I don't need the MiddleClick app anymore, yayy.

Nice 👍

1. I don't think the two-finger scroll to pinch function is working... (Yes, it is 0.2.4)

Huh.. This version was supposed to implement different touch counts for Magic Mouse (2) and Touchpad (3) for middle clicks. If three-finger clicks are mapped to middle clicks on both devices, I guess there is a flaw in the code for device identification. I'll try a different approach...

3. "Two-finger click to middle click" on magic mouse is not working. And honestly I don't think you should map the two-finger click to it at all because I think the way most people use magic mouse to click is to rest their two fingers on the magic mouse and click. Two-finger click should just be a normal left click and stay that way.

I can follow your logic, tought personally, I prefer using max. two fingers for anything Magic Mouse related. Three fingers just don't feel right to me on such a small surface. Right clicking also implies lifting one finger, so I immediately got used to left clicking with one finger as well. BUT: Everybody is different and so I'll make every feature configurable.

Thx for your Feedback. I'll upload a fixed version soon.

[pnoqable]

Hi Iaurman,

could you plz test the versions I uploaded yesterday? 0.2.5 already includes the mouse/trackpad identification fix, but you might need 0.2.6 as that fixes an erratic bug sometimes resulting in error messages instead of app startup.

error message:

Apperently I introduced this bug in 0.2.4, but for some reasons higher than me this error message shows up only on my MacBook and only after uploading the app to and downloading it from Google Drive, but never on my Nucintosh, no matter how I install the app there. This doesn't make sense to me at all. Did you get any error messages with 0.2.4? I can't be too sure as most of these signature issues can be bypassed by right clicking and opening the app from the context menu, and I don't know how experienced you are with this kind of macOS hassle... However, 0.2.6 should fix this issue for good.

---

I also re-uploaded version 0.2.3 as all the newer versions have hardcoded touch count (2) for middle clicking and zooming with Magic Mice, which is how I prefer it but know you don't. I'm still not finished with the configuration mechanism for the new features as I struggle a bit with health issues and had to put this project on hold for a bit. So, if you really dislike my hard-coded configuration for Magic Mice, you can switch back to zooming with CMD+ALT and using MiddleClick for the meantime.

[pnoqable]

While you may be stressed out from college preparation, I really encourage you to give version 0.2.6 a quick try. I think this version really maxes out the user experience of Magic Mice. You know I sold my last one just a few months ago but now I'm already back to using it every day and all the zoom features of PinchBar really do feel great with it!

Thank you for the great idea of pushing this project into Magic Mouse territory! I'm really looking forward to promoting Mouse support in Cubase's community once I've completed the configuration mechanism and released PinchBar 0.3.

[iaurman]

Yeah, been super busy these days. Sorry again for the delay.

And gosh, it's magical!!! The two-finger scroll to pinch works! And it's smooth and bug free as far as I'm testing. Recently I switched my browser from Safari to Arc. And it works here, too. (Though it's just such a shame that the zooming action on Chromium based browsers is not as natural feeling as Safari's. But it's just the nature of it. Has nothing to do with Pinchbar)

Still, I stand by my earlier opinion of the two finger click shouldn't be a middle click. The configuration mechanism is indeed needed.

Well done!

[pnoqable]

Thank you for your feedback especially with your limited time these days!

I just uploaded version 0.2.7 with hard coded touch count set to 3 for middle clicking with Magic Mice. It's still not configurable but take this as a small gift and motivation for your studies ;)

Is Arc any good? I wanted to test PinchBar with it but strongly dislike having to register with email just for the download..

PS: What are your Magic Mouse settings? Maybe you could quickly post a screenshot instead of describing it.. I'm now asking myself what other usability conficts might arise with PinchBar. I can't think of any as I've enabled and use literally every single feature frequently. But then again I would've never guessed somebody would not like to map two finger click to to middle click 🤷‍♂️

[iaurman]

🤔 Where are the previous messages? And how's things going recently?

[pnoqable]

Hi iaurman, what do u mean by "Where are the previous messages?". When I open this issue on a private tab (i.e. without an active github session), all messages are visible as they are in this tab in which i'm logged in right now. Does Arc handle this differently than Firefox? In case you're missing something, this was my last message to you:

Thank you for your feedback especially with your limited time these days!

I just uploaded version 0.2.7 with hard coded touch count set to 3 for middle clicking with Magic Mice. It's still not configurable but take this as a small gift and motivation for your studies ;)

Is Arc any good? I wanted to test PinchBar with it but strongly dislike having to register with email just for the download..

PS: What are your Magic Mouse settings? Maybe you could quickly post a screenshot instead of describing it.. I'm now asking myself what other usability conficts might arise with PinchBar. I can't think of any as I've enabled and use literally every single feature frequently. But then again I would've never guessed somebody would not like to map two finger click to to middle click 🤷‍♂️

After that I just set the development branch for this issue and assigned it to myself to prepare for a merge with the main branch. However, I think it would be best if all of these new features had a good way for end-users to configure them before I publish a new release. My idea is to migrate PinchBar's settings persistence from macOS's user defaults database (try defaults read com.pnoqable.PinchBar in a terminal) to a simple json file for better editability. I still have not decided which way to go though...

Did you try the latest test version with changed touch count? After changing to Art, does your workflow still rely on zooming with a Magic Mouse or is this feature not that important to you anymore?

[iaurman]

I remember that I replied to the previous post. But now it's not there. Maybe there was something wrong with my network when I sent them. Or maybe it's just a Jamais vu...
(Also I have to admit that I'm a bit little worry with these versions I downloaded from google drive rather than github. After all they have enough permission to log my keyboard and ruin my life... I suggest we move to github soon so that we can view its source code and trust it)

Did you try the latest test version with changed touch count? After changing to Art, does your workflow still rely on zooming with a Magic Mouse or is this feature not that important to you anymore?

Yeah I did. But Arc is still just another browser. I still need PinchBar every day. And there has been no bugs whatsoever. Whether it's with Safari, Arc or Pixelmator Pro... Everything's been great with PinchBar.👍

Is Arc any good? I wanted to test PinchBar with it but strongly dislike having to register with email just for the download..

It is! I love the aesthetic of it. And the concept of vertical tab management is great. I said in my last post that it has some annoying bugs thus I think you can wait til it's more mature. But since the last time I post it's been better with a few updates. And I say you should try it. I can give you an invite code if you'd like to. You'll love Arc!

PS: What are your Magic Mouse settings? Maybe you could quickly post a screenshot instead of describing it.. I'm now asking myself what other usability conficts might arise with PinchBar. I can't think of any as I've enabled and use literally every single feature frequently. But then again I would've never guessed somebody would not like to map two finger click to to middle click 🤷‍♂️

Sure. There they are:

[pnoqable]

I suggest we move to github soon so that we can view its source code and trust it

Yes, that's the goal. Btw, you can view all the source of every test version here on github and check that there's still no event tap for keyboard events, only trackpad and mouse events (just including modifier flags for CMD, ALT and the like but no alphanumerical or symbol keys, white spaces, return, arrow keys, ...). I just didn't upload the binaries here as I didn't want to confuse other potentially curious testers (e.g. from Steinberg's forum) with unstable test versions of features they would not know about. But I totally understand your skeptism and - for us being strangers chatting on the internet - it's absolutely appropriate. Next version will be release candidate and thus 'official enough' for me to share directly via GitHub and invite other testers.

Btw: Did you know that even the binaries on the github releases page are just arbitrary uploads from me, the maintainer? There is no checking mechanism that they really coincide with the source tag they're assotiated with, not even this repository nor my own identity. The only way to be sure really is to download the source, review its content, build and test it all by yourself. I know, that's just theory and I would not find any tester wanting to do all that. But you know that's exactly how open source started its history.

Nowadays it is common practice and I adhere to sign all my uploads with my Apple developer certificate for which I pay 100 bucks every year. Should it ever be found to be related to malware, rest assured Apple has enough information about me to sue the hack out of me x'D

I still need PinchBar every day. And there has been no bugs whatsoever. Whether it's with Safari, Arc or Pixelmator Pro... Everything's been great with PinchBar.👍

Love to hear that!

I can give you an invite code if you'd like to.

Thanks. But I guess I'll wait for it being publicly available without the need to register for it. After all, it's a browser company dealing with highly sensible user data and I don't like my browsing data to be linked to any account / identity whatsoever. I guess, I'm an open source nerd on this one. :)

Sure. There they are:

Thx. Good to know the details of the test coverage!

[iaurman]

Hi, how's it going?

Some people like me has encountered this problem as well. And I wanted to share this project with them but it's not complete yet.

However I think we are so close. The last version has been perfect for me. I'm not rushing or anything. I'm content. But what you've accomplished here is wonderful and I want it to be shared by more people.

[pnoqable]

Hey Iaurman,

I've been on family vacation for the last two weeks, tried hard to get our pre-release out before that, but it still took me a few more days after return. Now I think it's good enough, so please read and test:

https://github.com/pnoqable/PinchBar/releases/tag/0.2.8

If this runs smoothly on your hardware, please feel free to share this link with other potentially interested people. It's still not yet tagged stable as I need testers with apple silicon hardware to confirm all the low level changes are backwards compatible. And I want to add a few menu entries for enabling/disabling the new global features.

Speaking of which: If you still prefer your middle clicks triggered by three fingers on Magic Mice, paste this into Terminal and hit return:

defaults write com.pnoqable.PinchBar middleClick -dict-add onMousepad -int 3

The new version of PinchBar does not need to be restarted after changing defaults. You can also inspect all the values you can modify by entering:

defaults read com.pnoqable.PinchBar

Feel free to ask if you need help!

Cheers!