-
Dec
30Logitech MX3S MacOS Stutter with Universal Control
Posted in : macos, ventura, logitech, and mx3s
We recently bought a new Logitech MX3S mouse to use on MacOS. It’s a nice mouse and while it works most of the time, recently we experienced cursor stutter. It looks like the cursor lags behind the mouse movements.
After switching from using the Bolt receiver to Bluetooth, installing, re-installing the Logitech app. Trying the mouse on a Windows machine (no issue there). We finally found a way to make it work properly on MacOS Ventura:
Step 1:
Go to the Apple menu > System Settings > Displays and click on the Advanced… button at the bottom:
Step 2:
There disable Universal Control by checking off Allow your pointer and keyboard to move between any nearby Mac or iPad.
Your brand new mouse should finally work as expected all the time.
One last thing, if you’re wondering why the
Logitech Firmware Update Tool
never find your mouse… the reason is simply there is no firmware update available… Thanks to their wonderful UX for making us loose time trying to figure out what we did wrong. -
Oct
23Cancellable apollo-client queries
Posted in : apollo-client and typescript
If you ever had to work with a GraphQL API featuring a few slow queries, you’ll probably understand the need to be able to cancel
apollo-client
queries. I’m usingapollo-client
3.2.5, the latest at the time of writing. Sinceapollo-client
usesfetch
, my first attempt to cancel a query was usingabortController
:interface CancellablePromise<T> extends Promise<T> { cancel: () => void } export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const abortController = new AbortController() let promise = apolloClient.query({ ...options, context: { fetchOptions: {signal: abortController.signal} } }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => abortController.abort() return promise }
It partially works: the request is cancelled, and the promise doesn’t complete. However there’s a big issue: subsequent calls of the same query with the same variables don’t work anymore, no attempt is being made. You can follow this pull request since it might one day be resolved: handle external fetch abort.
Not discouraged, I tried another method using
watchQuery
and theunsubscribe
method:interface CancellablePromise<T> extends Promise<T> { cancel: () => void } export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const observable = apolloClient.watchQuery(options) let subscription: ZenObservable.Subscription let promise = new Promise((resolve, reject) => { subscription = observable.subscribe( (res) => resolve(res), () => reject() ) }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => subscription.unsubscribe() return promise }
The logic behind it is that the call to
unsubscribe
should cancel the request when the browser supports it. However, that just doesn’t happen for me using Google Chrome (version 86.0.4240.111), the promise doesn’t complete however the request isn’t cancelled and subsequent calls of the same query with the same variables don’t work. It seems like I’m not the only one to have noticed, you can track the progress on this issue in the hope that it get fixed at some point: Unsubscribing from a query does not abort network requests.You can find a few more opened issues related to cancelling apollo-client requests:
- Unmounting Query component no longer cancels network request in v2.6.0 & v3 beta
- updateQuery merging different data when changing query while fetchMore is not yet finished
- Cancel fetchMore network requests
After searching more about it, I found out about queryDeduplication, it’s apparently the reason why subsequent calls to cancelled queries don’t work anymore: the request is still considered to be “in-flight” and thus no further attempt is being made. Thus our code can become:
interface CancellablePromise<T> extends Promise<T> { cancel: () => void } export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const abortController = new AbortController() let promise = apolloClient.query({ ...options, context: { fetchOptions: {signal: abortController.signal}, queryDeduplication: false } }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => abortController.abort() return promise }
This time it finally works: the request is cancelled, the promise doesn’t complete, the next call of the same query with the same variables can complete successfully and subsequent calls will be retrieved from cache.
It’s also possible to combine
watchQuery
,abortController
andqueryDeduplication
disabled:export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const abortController = new AbortController() const observable = apolloClient.watchQuery({ ...options, context: { fetchOptions: { signal: abortController.signal }, queryDeduplication: false } }) let subscription: ZenObservable.Subscription let promise = new Promise((resolve, reject) => { subscription = observable.subscribe( (res) => resolve(res), () => reject() ) }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => { abortController.abort() subscription.unsubscribe() } return promise }
The result is the same as the previous version, with no further benefit that I could see. Finally, I also tried to change the
fetchPolicy
tonetwork-only
but as far as I could see it only prevents the completed queries from being retrieved from cache, which isn’t something which I need. -
Mar
12Better network performance in Docker/Test Kitchen with Virtualbox on Mac
Posted in : virtualbox, docker, test-kitchen, and mac
If you’ve experienced really slow downloads from within VirtualBox on Mac, chances are you’re using the default NIC for your NAT interface.
I’ve seen docker’s pull taking ages when a layer size is more than a couple MB and chef installer taking more than 10mn to download the package…
Here’s how to fix it in docker-machine and test-kitchen.
For docker-machine
Check what’s your
docker-machine
VM’s name:docker-machine ls
it will give you something like the following (could be different depending of your config):
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS default - virtualbox Running tcp://192.168.99.100:2376 v1.12.5
if it’s
Running
, then stop it first:docker-machine stop default
then change the NIC to use the
PCnet-FAST III (Am79C973)
instead of the defaultIntel PRO/1000 MT Desktop (82540EM)
:VBoxManage modifyvm "default" --nictype1 "Am79C973"
And finally start it, it will now use the new NIC with “hopefully” improved speed:
docker-machine start default
For test-kitchen
Update your
kitchen.yml
orkitchen.local.yml
to have your vagrant driver include thecustomize
config below:driver: name: vagrant customize: nictype1: "Am79C973"
Enjoy using all your available bandwidth!!
-
Nov
18Senlima - Knight Animation
Posted in : senlima, game, preview, unity, 3d, animation, and knight
This article has been moved over our dedicated Openhood Games blog.
-
Nov
17Senlima - Upcoming Game Preview
Posted in : senlima, game, preview, unity, and 3d
This article has been moved over our dedicated Openhood Games blog.