Hi All, Hi Eliot
I'm sorry for being a drag on progress here… [Also, replying to HTML-Mails messes up the quotes somehow… can we not use html? :/ but I digress already…]
On 15.06.2017, at 20:05, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tobias,
On Thu, Jun 15, 2017 at 6:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 13.06.2017, at 16:06, Eliot Miranda eliot.miranda@gmail.com wrote:
On Jun 13, 2017, at 4:38 AM, Tobias Pape Das.Linux@gmx.de wrote:
Any objections I merge this into Cog?
Provided the changes are optional so that the default behaviour is unchanged then no objections from me.
That's a stretch… So here's the thing:
- Opting in to highdpi ist typically necessary very early in a process startup (at least when you want to stay platform-independend)
[]
Which is why on Mac we can use a setting from Info.plist. Windows is already covered. When the issue becomes relevant in Linux we could use
- an environment variable
- an ini file, e.g. in the lib dir
- a command line switch set in the launch script
Yes.
- For our vm that means, the image cannot simply use a primitive to say, hey I'm high-dpi ready in order to change that later.
Understood. That's not what I'm talking about.
OK.
- We _can_ typically control the behavior via vm-specific files (Info.plist/ .exe.manifest)
- So, to avoid surprises because the image may not yet react to highdpi or dpi changes, the default vms should come with high-dpi off.
- but When we add the code soon-ish, we could switch-on by default for the next image format change that would nevertheless need a new vm. This would be *drummroll* sista.
So what I propose is:
- Trunk receives code updates to handle high-dpi changes very soon (i got stuff in the pipeline but not yet fully ready)
- Cog remains low-dpi (except people opt *in* the _vm_ via files)
- Sista becomes high-dpi-aware (except people opt *out* the _vm_ via files)
[]
All of that is fine policy, but none of it addresses the implementation, which must
not change the default behavior
hence select hide via some suitable mechanism. On Mac that means a setting in Info.plist. Hell, there might even be a standard Mac option. e.g. from http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-...
Enabling high-dpi for OS X Applications
High DPI mode is controlled by the following keys in the Info.Plist file:
<key>NSPrincipalClass</key> <string>NSApplication</string> <key>NSHighResolutionCapable</key> <string>True</string>
So please, let's make sure that the VM continues to function unchanged for existing images.
Ok. So what happens is that I have these exact lines in my commits: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/77b57ad8decb1a5835b... (and so forth…)
For now this all would be _enabled_ was this stuff being merged, which I understand does not meet your criteria of "not change the default behavior"
It is however hard to go forward without having a clear breakpoint. - There's no way for VM and image to communicate the hi-dpi-capablitiy without it being default-enabled in the VM. it is simply not enable-able at runtime (without extraordinary effort) nor disable-able at runtime (without fairly-more-than-ordianry effort). - Telling users to "please edit this file which actually belongs somewhat to the vm" is a no-go, I'd say…
Thats why I'm proposing:
- Have the High-DPI-VM-Switch DISABLED for: * newspeak.cog.spur * newspeak.stack.spur * pharo.cog.spur * pharo.cog.spur.lowcode * pharo.stack.spur * pharo.stack.spur.lowcode * squeak.cog.spur * squeak.cog.spur+immutability * squeak.cog.v3 * squeak.stack.spur * squeak.stack.v3 - Have the High-DPI-VM-Switch ENABLED for: * squeak.sista.spur
So, since sista requires an Image-format-chage, this could _at the same time_ communicate that image and vm know there's HighDPI.
In any case, changing the info.plist/manifest[1] would be possible for eg, people like us at HPI when producing custom All-in-ones.
So, does that meet your criteria? if not, I'm a bit lost…
HTH
best regards -Tobias
This would need only few changes to the code base.
Eliot, what's newspeak's stance on high-dpi?
Don't know. I'm sure they'll be happy to follow our lead.
Best regards -Tobias
Adds High-dpi for windows and mac.
[1]: that manifest thing is funny :( So, at some point mignw/cygwin crew decided to _always_ compile a mingw-specific manifest _into the binary_. Which means that a custom manifest will not be used. Which means, since its not possible to not use that manifest in a normal way, we have to do trickery like that: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c07df4f3a4c3b5bceee...