openframeworks
ofOrientation, does it need to exist?
I suspect it can be all removed from OF Core All usages I know can be handled by the OS, at least in iOS / macOS removing this would simplify lots of I suppose unneded things and make it easier to have retina working for ex. opinions? @openframeworks/core @openframeworks/2d-3d
enum ofOrientation: short{
/// \brief Represents the default screen orientation.
OF_ORIENTATION_DEFAULT = 1,
/// \brief Represents a screen rotated 180 degrees, also known as upside-down.
OF_ORIENTATION_180 = 2,
/// \brief Represents a screen rotated 90 degrees clockwise.
OF_ORIENTATION_90_LEFT = 3,
/// \brief Represents a screen rotated 90 degrees counter-clockwise.
OF_ORIENTATION_90_RIGHT = 4,
/// \brief Represents an unknown orientation.
OF_ORIENTATION_UNKNOWN = 5
};
I know ofSetOrientation can be used to get an OF App working on a vertical screen when OS rotation isn't available. As you mentioned not sure if its needed anymore?
I think on iOS ofGetOrientation can be used to determine the device orientation, so that might still be needed? cc @danoli3
If we did remove it, we'd still want to have it deprecated for a release or 2.
@ofTheo vertical screens and projectors have OS level rotation. I think iOS has it too, automatic or set in the project. I suspect Android is the same, so if there is no need of flipping mouse coordinates in 2025 it is a great way of reducing code (and maintainers headaches) What do you think? @2bbb @artificiel @NickHardeman @openframeworks/ios
@dimitre i'm all for simplification, but just to be sure: beyond working around tech debt, what does the OF_ORIENTATION stuff currently hinder?
for instance the iOS rotation stuff is broken. is that related to OF_ORIENTATION as such? or is it purely ofxIOS? it's a higher priority to solve the iOS problems than to remove OF_ORIENTATION, and iOS rotation handling should not require OF_ORIENTATION concepts — if it's the case it should be fixed (and that does not require removing OF_ORIENTATION).
@ofTheo i get the idea of forcing a render's orientation, but the surface management is an OS problem and getting a physical display to work properly in portrait mode needs to be solved at the OS level (or maybe hardware level if a portrait-installed display self-detects and emits a 1080x1920 EDID). the OF app should be rendering (and track pointers) in the coordinates of the rest of the OS.
querying the iOS rotation is maybe usefull, but as long as windowResized() is emitted when the rotation occurs, and that pointer touches matches the screen coordinates, we're good (the actual orientation itself does not really matter. to that effect iOS's own viewWillTransition only reports the upcoming new size, not how it correlates with device orientation. more important with the evolving multi-window iPadOS support, where windows are slowly being reborn).
Yes any dead code hinder development or if it is useful it can be done in a better way it was useful in 2012, ios 6 not sure if relevant in 2025
It is used for sure in some addons always worth searching Github to see where it is used. https://github.com/search?q=ofOrientation&type=code
My feeling is we could potentially keep the data type around but deprecate some of the functions.
That said it would be worth checking how orientation notifications currently work in OF + iOS.
related thread with suggestions from @artificiel
- https://github.com/openframeworks/openFrameworks/issues/6965
other related thread showing issues with orientation
- https://github.com/openframeworks/openFrameworks/issues/6076
- https://github.com/openframeworks/openFrameworks/issues/6965