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

[Eliot Miranda]

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



> - 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.


> - 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.


> 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.
> >>
> >> Best regards
> >>   -Tobias
> >>
> >>
> >>> On 13.06.2017, at 10:50, GitHub <noreply at github.com> wrote:
> >>>
> >> […]
> >>> Log Message:
> >>> -----------
> >>> Merge remote-tracking branch 'origin/Cog' into krono/highdpi-v2
> >>>
> >>> * origin/Cog: (61 commits)
> >>> CogVM source as per VMMaker.oscog-eem.2242
> >>> CogVm source as per VMMaker.oscog-eem.2241
> >>> CogVM source as per VMMaker.oscog-eem.2240
> >>> CogVM source as per VMMaker.oscog-eem.2237
> >>> Fix regression in recent system attribute 1002 (OS Version) change on
> Mac OS X. Answering e.g. 10.10.5 breaks everyting that uses Smalltalk
> osVerison asNumber. So answer e.g. 1010.5 insteads so that Smalltalk
> osVerison asNumber = 1010. Typical image code looks like Smalltalk
> osVerison asNumber >= 1000 to identify Mac OS X over MacOS 9 et al.
> >>> cosmetic: fix weird alignment
> >>> Fail primitiveFileOpenNew with PrimErrInappropriate if file already
> exists
> >>> added a flag pointer parameter to sqFileOpenNew() for failure being
> caused by the file already existing
> >>> Make recent FilePlugin changes MSVC compatible
> >>> Fix plugin compilation for Win64 PharoVM
> >>> Fix int */sqInt * mismatch for Win64 FilePlugin
> >>> Regenerate Unix OS ProcessPlugin from oscog-dtl.56
> >>> CogVM source as per VMMaker.oscog-eem.2232
> >>> Use the NSProcessInfo API to get an accurate OS verison string on Mac
> OS X.
> >>> CogVM source as per VMMaker.oscog-eem.2229
> >>> CogVm source as per VMMaker.oscog-eem.2228
> >>> Make pharo deploy work for both WIN64 stack and cog
> >>> Build Win64 squeak.cog.spur FFI & Alien plugins
> >>> Add Win64 pharo.cog.spur configuration
> >>> Win32OSProcessPlugin MUST be regenerated from latest source
> >>> ...
> >>>
> >>>
> >>> Compare: https://github.com/OpenSmalltalk/opensmalltalk-
> vm/compare/4181d8e8872f...8044775ccbb1
> >>
> >>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170615/7dddb993/attachment.html>