Migrating to v15 from v13

[Neil Morrison]

Hi all,

I've just started the process of preparing our application for the jump to v15.
All was as easy as usual - only issue so far has been a pile of methods that gone missing from OSShell

OSShell used to provide class methods to determine monitor handling, e.g. activeDisplayAre, desiredActiveMonitorPos:, etc

I looked at the likes of OSHMonitor to see if they had been relocated and found nothing - tried a general search to find methods that are similar but still nothing.

Can't see it mentioned in the migration guide

Anyone else stumbled over this?

Easy enough to resolve - I cloned them into my own class and changed our code to use that instead of OSWidget

Regards,

Neil Morrison

Principal Developer
New Zealand Police

[Marcus Wagner]

Hi Neil,

those (internal) class methods already went away in v14. Being internal (and OS specific) can be a reason not to be mentioned in the migration guide, as they are not thought to be used directly.

This correlates with changes of Windows to handle multi monitor environments with inhomogenous scales (e.g. in a common situation, working with a low resolution laptop in front of a high resolution screen).

It took quite a while that the OS handled this correctly - and consequently VAST had to adopt to this thereafter.

The internal VAST methods where thought also to support when a development image was saved and restarted later (with a potentially changed monitor landscapes and changed settings when restarted) or when a shell of a tool browser was moved between monitors of different scale or when scaling is changed dynamically while running the image.

The solution in VAST had also to respect consequences in other platforms (e.g. running under Motif). I found at least three different coordinate systems here and to carefully recalculate positions to navigate correctly, just also because of systematic differences between Windows and Unix, although the common widget implementation was thought to be a clever and stable answer to close this gap.

 

The point is some internal  methods just were faulty, concerning position calculations with more than one monitor with different sizes and scales.

The fixes after v13 then seemed to go hand in hand with a necessary redesign. 

Be careful in trusting the cloned code  - as this old code seems to work well as long as there are simple monitor situations but is failing in complex situations and when Windows fixes here are not respected.

Individual monitor scaling came up in Windows 8 and it took quite a while that handling this to become stable.

Kind regards

M.

[Mariano Martinez Peck]

Hi Neil, 

Maybe this is what you were looking for?

https://www.instantiations.com/vast-support/documentation/1500/#page/mi/migr1301-7.html

Best regards,

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/e5e9c081-80dd-41c2-96aa-0ad9d004727cn%40googlegroups.com.

--

Mariano Martinez Peck VAST Lead Consultant Senior Software Engineer  mp...@instantiations.com  @MartinezPeck  /mariano-martinez-peck  instantiations.com

[Neil Morrison]

My apologies, as usual you did cover it off (love the migration guides) - not sure why I hadn't spotted that.

Bit of background as to why we still want the methods - if you are looking to remove them completely at some point no issue - we can isolate them to be our own if needed.

The primary reason for this is related to the Abt layer - our app is now 27yrs old and been through many iterations of the VAST platform - still going strong.

When the app was first built, we used the Abt layer - has worked well until the arrival of multi-screens!!!

We have the problem that frame/shells that open in that layer are not opening on the active desktop but always on the Main display as configured in Window - this has become a major annoyance for users as the system keeps opening the windows on their main desktop/monitor rather than the desktop/monitor the application is running on.

I used those methods to determine the active monitor and its dimensions to reposition the newly opened window on the right desktop/monitor. Users love it - makes using the application so much better to use.

I have noticed that the tooling in the development tool (Inspectors etc) do actually open correctly (probably the widget layer) - if there is a trick to make the Abt layer to the same then that would be great otherwise I'll switch to the DesktopSupport classes/methods or clone appropriately for our own use.

Regards,

Neil

[Marcus Wagner]

Hi Neil,

hm, the initial Abt layer was not multi monitor aware, just because such scenarios were not even invented (you implicetly selected a single monitor first and the rest was strictly relative to that one).

Decoration decided later that the active monitor is determined by the intended coordinates (hence alternate terms like pop and transient shells evoked) and a universal desktop was invented to gain the necessary flexibility.

That matches exactly to your description (although there is no magic configuration or registry behind the scenes).

Now to these coordinates: initially they were 0@0 at the left top relative to the (initially single and only) monitor.

A subwindow had to say were it is going to open, naturally at x@y, and x/y had to be strictly positive and in range, e.g. less than the right@bottom margin of that monitor, simply to stay visible.

That does not hold anymore (Windows already deveated here from Motiv in not counting the configurable header/lable, even on a single monitor) so coordinates can be elsewere (also negative) to reflect multi monitor allocations.

Is there any (historic) active restriction in place to force coordinates to be positive (implies the described effect to stick to the main monitor)?

As monitors can be dynamically moved and placed at runtime,  any such hardcoded rules end up in such effects (that leads the need of a dynamic interface like DesktopBaseSupport and isPrimary).

E.g. such specs like start a subwindow at 10@10 absolute coordinates are wrong, it should be at 10@10 relative to the parent coordinates (or e.g. -20@-20 to be left an above...)?

Here we dive into that area that i meant with "mutiple coordinate" systems. If s.th. is specified wrong, that is referring to the wrong base cooordinates, you end up as observed.

My hint is to look if any part is handling coordinates as absolute values instead of being relative (in the meantime) related to another component?

[of course, you can also use absolute ones, but then you actively have to deal permanently with monitors, their dimensions all over the time, with the risk to be wrong (as just sth. has been moved underneath]].

Not to mix up: widget coordinates relate to their (one and only) single parent shell (here the historic restrictions still hold most of the time), no matter where the shell is placed [the third coordinate system]. 

Windows and Part builder still rely on this.

Kind regards,

M

[Mariano Martinez Peck]

Hi Neil,

We have improved MultiMonitor and HiDPI support in every recent release. I hope things improve for you after you migrate to VAST 15. If that's not the case, please open a support ticket in the portal and we will take a look:

https://vast-support.instantiations.com/

Thanks! 

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/34197521-a62e-42be-a9ab-a20456d4717bn%40googlegroups.com.