It's not considered fully RESTful, but it sounds like you are describing IPP, which came out in 1997.
Compatibility marks/certifications like AirPrint (2010) define how to advertise your IPP printer and its features, such as whether you can directly send a PDF. IPP Everywhere is perhaps the most notable open alternative to AirPrint.
IPP Everywhere and AirPrint are virtually identical AFAIK, it's just that AirPrint uses a slightly different proprietary raster format because Apple is gonna Apple.
> Is C++ more performant than C? I find this hard to believe.
At the compiler level, no. But as you write projects, you will for instance run into things you can do with templates which are infeasible to attempt with macros.
One example might be qsort() - a C compiler _could_ catch cases where it could create an intrinsic qsort based on the data type and function pointer being passed. However, in C++ you have the facilities to create a type safe, genericized sort that will be inlined based on the data structure.
IMHO, both are a mode of progressively penalizing developers as a mode of API obsoletion. It doesn't feel like the opportunity to fix a degradation of user experience really motivated app developers in either case.
The difference is Apple is much more likely to progressively make these legacy feature compatibility more difficult for users to configure over time, and to remove them eventually.
Valve hasn't committed to making a mixed reality computing platform, and Apple hasn't come out with a gaming VR headset. Neither company wants to directly compete.
Apparently Apple can't commit to making mixed reality either. If they're going to sell an inside-out headset, they should at least support the software people buy for it.
The "WebXR + iPad apps" library is very clearly a joke to most customers, especially at the price point Apple demands.
On macOS, it is ultimately the app developer who is responsible for persisting and using state for windows, such as size and position. Think several terminal sessions - the terminal app needs to be the one to determine if it is representing the same 'session' as before after a restart.
If you are talking about remote display in a 3D space, the application would need to understand how to track and reopen a window in a particular location, and also there would need to be policy on how say a resize on the Vision Pro relates to the native window size once the Vision Pro is turned off.
This puts a lot of responsibility in the app developer's hands, where it is most likely not going to be accepted. So I would expect the experience to be sub-par.
There could be interesting workarounds for full-screen windows, since there are already the concepts of multiple heterogenous displays and display resolution changes on macOS. So you might have a screen, but the 'full screen' button is replaced by one which breaks the window out. The challenge would be making these persistent across connections to the Mac in a way that apps work well by default without picking up odd heuristics.
I have never got into macros, so missing a row of function keys didn't impact me. A row of system integration actions (like dynamic volume and brightness controls) was nice.
However, a capacitive touch surface should not be so close to tactile buttons. This made it way more likely to falsely register actions.
Move it a half key width farther up and make it taller to have greater flexibility on how it uses the space and I think it would have been a much better feature.
IMHO the big problem is that the five year hardware cycle of the MBP is not conducive for revolutionary improvements. They had the MacBook back then, which would have been a great platform for faster design iterations.
Compatibility marks/certifications like AirPrint (2010) define how to advertise your IPP printer and its features, such as whether you can directly send a PDF. IPP Everywhere is perhaps the most notable open alternative to AirPrint.
reply