[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 5afa7a: Fix travis tests for squeak after app rename

[Tobias Pape]

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 at gmail.com> wrote:
> 
> Hi Tobias,
> 
> On Thu, Jun 15, 2017 at 6:50 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> 
> > On 13.06.2017, at 16:06, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> >
> >> On Jun 13, 2017, at 4:38 AM, Tobias Pape <Das.Linux at 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-x11/
> 
>     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/77b57ad8decb1a5835baa23405057b72bdf39db7#diff-e6a3e805182bc4de3d9ba3acdcf20c4dR380
(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/c07df4f3a4c3b5bceeecbe8ee1e5a0e9d26eb9c5