2015-12-30 06:41:46 +00:00
|
|
|
#if defined(Hiro_Monitor)
|
2014-01-05 09:59:17 +00:00
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
namespace hiro {
|
|
|
|
|
|
|
|
auto pMonitor::count() -> uint {
|
2014-01-05 09:59:17 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
return [[NSScreen screens] count];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Update to v104r13 release.
byuu says:
Changelog:
- nall/GNUmakefile: build=release changed to -O2, build=optimize is
now -O3
- hiro: added Monitor::dpi(uint index) → Position [returns logical
DPI for x, y]
- Position is a bad name, but dpi(monitor).(x,y)() make more sense
than .(width,height)()
- hiro: Position, Size, Geometry, Font changed from using signed int
to float
- hiro: Alignment changed from using double to float
- hiro: added skeleton (unused) Application::scale(), setScale()
functions
Errata:
- hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues
with macOS' automatic scaling.
- hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI
scaling
- hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this,
but I still use Qt 4.x)
- and just to get global DPI, hiro/qt's DPI retrieval has to use
undocumented functions ... fun
The goal with this WIP was basically to prepare hiro for potential
automatic scaling. It'll be extremely difficult, but I'm convinced that
it must be possible if macOS can do it.
By moving from signed integers to floats for coordinates, we can now
scale and unscale without losing precision. That of course isn't the
hard part, though. The hard part is where and how to do the scaling. In
the ideal application, hiro/core and hiro/extension will handle 100% of
this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware
of what's going on, but ... to even make that possible, things will need
to change in every per-platform core, eg the per-platform code will have
to call a core function to change geometry, which will know about the
scaling and unscale the values back down again.
Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
|
|
|
auto pMonitor::dpi(uint monitor) -> Position {
|
2019-07-07 09:44:09 +00:00
|
|
|
//macOS includes built-in HiDPI scaling support.
|
|
|
|
//it may be better to rely on per-application scaling,
|
|
|
|
//but for now we'll let macOS handle it so it works in all hiro applications.
|
|
|
|
#if 0
|
Update to v104r13 release.
byuu says:
Changelog:
- nall/GNUmakefile: build=release changed to -O2, build=optimize is
now -O3
- hiro: added Monitor::dpi(uint index) → Position [returns logical
DPI for x, y]
- Position is a bad name, but dpi(monitor).(x,y)() make more sense
than .(width,height)()
- hiro: Position, Size, Geometry, Font changed from using signed int
to float
- hiro: Alignment changed from using double to float
- hiro: added skeleton (unused) Application::scale(), setScale()
functions
Errata:
- hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues
with macOS' automatic scaling.
- hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI
scaling
- hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this,
but I still use Qt 4.x)
- and just to get global DPI, hiro/qt's DPI retrieval has to use
undocumented functions ... fun
The goal with this WIP was basically to prepare hiro for potential
automatic scaling. It'll be extremely difficult, but I'm convinced that
it must be possible if macOS can do it.
By moving from signed integers to floats for coordinates, we can now
scale and unscale without losing precision. That of course isn't the
hard part, though. The hard part is where and how to do the scaling. In
the ideal application, hiro/core and hiro/extension will handle 100% of
this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware
of what's going on, but ... to even make that possible, things will need
to change in every per-platform core, eg the per-platform code will have
to call a core function to change geometry, which will know about the
scaling and unscale the values back down again.
Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
NSScreen* screen = [[NSScreen screens] objectAtIndex:monitor];
|
2017-09-24 01:01:48 +00:00
|
|
|
NSDictionary* dictionary = [screen deviceDescription];
|
Update to v104r13 release.
byuu says:
Changelog:
- nall/GNUmakefile: build=release changed to -O2, build=optimize is
now -O3
- hiro: added Monitor::dpi(uint index) → Position [returns logical
DPI for x, y]
- Position is a bad name, but dpi(monitor).(x,y)() make more sense
than .(width,height)()
- hiro: Position, Size, Geometry, Font changed from using signed int
to float
- hiro: Alignment changed from using double to float
- hiro: added skeleton (unused) Application::scale(), setScale()
functions
Errata:
- hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues
with macOS' automatic scaling.
- hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI
scaling
- hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this,
but I still use Qt 4.x)
- and just to get global DPI, hiro/qt's DPI retrieval has to use
undocumented functions ... fun
The goal with this WIP was basically to prepare hiro for potential
automatic scaling. It'll be extremely difficult, but I'm convinced that
it must be possible if macOS can do it.
By moving from signed integers to floats for coordinates, we can now
scale and unscale without losing precision. That of course isn't the
hard part, though. The hard part is where and how to do the scaling. In
the ideal application, hiro/core and hiro/extension will handle 100% of
this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware
of what's going on, but ... to even make that possible, things will need
to change in every per-platform core, eg the per-platform code will have
to call a core function to change geometry, which will know about the
scaling and unscale the values back down again.
Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
|
|
|
NSSize dpi = [[dictionary objectForKey:NSDeviceSize] sizeValue];
|
|
|
|
return {dpi.width, dpi.height};
|
|
|
|
}
|
2019-07-07 09:44:09 +00:00
|
|
|
#endif
|
|
|
|
return {96.0, 96.0};
|
Update to v104r13 release.
byuu says:
Changelog:
- nall/GNUmakefile: build=release changed to -O2, build=optimize is
now -O3
- hiro: added Monitor::dpi(uint index) → Position [returns logical
DPI for x, y]
- Position is a bad name, but dpi(monitor).(x,y)() make more sense
than .(width,height)()
- hiro: Position, Size, Geometry, Font changed from using signed int
to float
- hiro: Alignment changed from using double to float
- hiro: added skeleton (unused) Application::scale(), setScale()
functions
Errata:
- hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues
with macOS' automatic scaling.
- hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI
scaling
- hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this,
but I still use Qt 4.x)
- and just to get global DPI, hiro/qt's DPI retrieval has to use
undocumented functions ... fun
The goal with this WIP was basically to prepare hiro for potential
automatic scaling. It'll be extremely difficult, but I'm convinced that
it must be possible if macOS can do it.
By moving from signed integers to floats for coordinates, we can now
scale and unscale without losing precision. That of course isn't the
hard part, though. The hard part is where and how to do the scaling. In
the ideal application, hiro/core and hiro/extension will handle 100% of
this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware
of what's going on, but ... to even make that possible, things will need
to change in every per-platform core, eg the per-platform code will have
to call a core function to change geometry, which will know about the
scaling and unscale the values back down again.
Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pMonitor::geometry(uint monitor) -> Geometry {
|
2014-01-05 09:59:17 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
NSRect rectangle = [[[NSScreen screens] objectAtIndex:monitor] frame];
|
2018-07-16 06:16:26 +00:00
|
|
|
return {
|
|
|
|
(int)rectangle.origin.x,
|
|
|
|
(int)rectangle.origin.y,
|
|
|
|
(int)rectangle.size.width,
|
|
|
|
(int)rectangle.size.height
|
|
|
|
};
|
2014-01-05 09:59:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pMonitor::primary() -> uint {
|
2019-07-07 09:44:09 +00:00
|
|
|
//on macOS, the primary monitor is always the first monitor.
|
2014-01-05 09:59:17 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-16 06:16:26 +00:00
|
|
|
auto pMonitor::workspace(uint monitor) -> Geometry {
|
|
|
|
@autoreleasepool {
|
|
|
|
NSRect size = [[[NSScreen screens] objectAtIndex:monitor] frame];
|
|
|
|
NSRect area = [[[NSScreen screens] objectAtIndex:monitor] visibleFrame];
|
|
|
|
return {
|
|
|
|
(int)area.origin.x,
|
|
|
|
(int)area.origin.y,
|
|
|
|
(int)area.size.width,
|
|
|
|
(int)area.size.height
|
|
|
|
};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-05 09:59:17 +00:00
|
|
|
}
|
2015-12-30 06:41:46 +00:00
|
|
|
|
|
|
|
#endif
|