The Trunk: Kernel-eem.1351.mcz

Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.1351.mcz

==================== Summary ====================

Name: Kernel-eem.1351
Author: eem
Time: 12 October 2020, 10:01:07.200133 pm
UUID: 16ddb529-e8ff-4c75-87cc-9b05ea9a23f2
Ancestors: Kernel-mt.1350

Rename EventSensorConstants WindowEventStinks to WindowEventScreenChange.  (Why is EventSensorConstants still in Kernel?).

=============== Diff against Kernel-mt.1350 ===============

Item was changed:
  SharedPool subclass: #EventSensorConstants
  instanceVariableNames: ''
+ classVariableNames: 'BlueButtonBit CommandKeyBit CtrlKeyBit EventKeyChar EventKeyDown EventKeyUp EventTouchCancelled EventTouchDown EventTouchMoved EventTouchStationary EventTouchUp EventTypeComplex EventTypeDragDropFiles EventTypeKeyboard EventTypeMenu EventTypeMouse EventTypeMouseWheel EventTypeNone EventTypeWindow OptionKeyBit RedButtonBit ShiftKeyBit TouchPhaseBegan TouchPhaseCancelled TouchPhaseEnded TouchPhaseMoved TouchPhaseStationary WindowEventActivated WindowEventClose WindowEventIconise WindowEventMetricChange WindowEventPaint WindowEventScreenChange YellowButtonBit'
- classVariableNames: 'BlueButtonBit CommandKeyBit CtrlKeyBit EventKeyChar EventKeyDown EventKeyUp EventTouchCancelled EventTouchDown EventTouchMoved EventTouchStationary EventTouchUp EventTypeComplex EventTypeDragDropFiles EventTypeKeyboard EventTypeMenu EventTypeMouse EventTypeMouseWheel EventTypeNone EventTypeWindow OptionKeyBit RedButtonBit ShiftKeyBit TouchPhaseBegan TouchPhaseCancelled TouchPhaseEnded TouchPhaseMoved TouchPhaseStationary WindowEventActivated WindowEventClose WindowEventIconise WindowEventMetricChange WindowEventPaint WindowEventStinks YellowButtonBit'
  poolDictionaries: ''
  category: 'Kernel-Processes'!

Item was changed:
  ----- Method: EventSensorConstants class>>initialize (in category 'pool initialization') -----
  initialize
  "EventSensorConstants initialize"
  RedButtonBit := 4.
  BlueButtonBit := 2.
  YellowButtonBit := 1.
 
  ShiftKeyBit := 1.
  CtrlKeyBit := 2.
  OptionKeyBit := 4.
  CommandKeyBit := 8.
 
  "Types of events"
  EventTypeNone := 0.
  EventTypeMouse := 1.
  EventTypeKeyboard := 2.
  EventTypeDragDropFiles := 3.
  EventTypeMenu := 4.
  EventTypeWindow := 5.
  EventTypeComplex := 6.
  EventTypeMouseWheel := 7.
 
  "Press codes for keyboard events"
  EventKeyChar := 0.
  EventKeyDown := 1.
  EventKeyUp := 2.
 
  "Host window events"
  WindowEventMetricChange := 1.
  WindowEventClose := 2.
  WindowEventIconise := 3.
  WindowEventActivated := 4.
  WindowEventPaint := 5.
+ WindowEventScreenChange := 6.
- WindowEventStinks := 6.
 
  "types for touch events"
  EventTouchDown := 1.
  EventTouchUp := 2.
  EventTouchMoved := 3.
  EventTouchStationary := 4.
  EventTouchCancelled := 5.
 
  "iOS touch phase constants"
  TouchPhaseBegan := 0.
  TouchPhaseMoved := 1.
  TouchPhaseStationary := 2.
  TouchPhaseEnded := 3.
  TouchPhaseCancelled := 4.
  !

> On 2020-10-12, at 10:01 PM, [hidden email] wrote:
>
> Rename EventSensorConstants WindowEventStinks to WindowEventScreenChange

Dude! No fair! That is a crucial aspect of the system design that hasn't been altered since '04.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BLI: Branch and Loop Infinite

https://2.bp.blogspot.com/-nrM5BrNbi3Q/UVMSCv5cGrI/AAAAAAAADF4/CdbDEL43f2k/s1600/PeepsReading.jpg


-C

***

     On 13/10/20 13:28, Eliot Miranda wrote:

--
Craig Latta :: research computer scientist
Black Page Digital :: Berkeley, California
663137D7940BF5C0AFC  1349FB2ADA32C4D5314CE

> On 2020-10-14, at 6:03 AM, Marcel Taeumel <[hidden email]> wrote:
>
> Hmm... fresh paint stinks, right? So WindowEventPaint and WindowEventStinks were related then. :-D

Exactly.

It really was a little easter egg to see if anyone would ever read the code; when John & I originally wrote it we suspected that despite all the claims of "we must have host windows!" nobody would ever use it.

In the slightly more serious end of this conversation, I would like to think that we can completely dump the 'main window' concept from the core VM code and only open a window when the image wants one. I can't see why we would want to save window dimensions in the image header rather than just having the image work it out at window-opening time.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His shared libraries aren't installed.

> On 2020-10-14, at 11:41 AM, Eliot Miranda <[hidden email]> wrote:
>  But it ain't that trivial given the desire to maintain backward compatibility in the VM.  See this thread: http://forum.world.st/Installing-high-dpi-support-and-backwards-compatibility-of-the-VM-tc5123176.html

Yeah, it's a mess and has been a mess since 1996.

For RISC OS right from the beginning I only created  a window when something actually wrote to the display,  a sequence that appears to be rooted in ioShowDisplay(). Creating the window in the ioSizeOfWindow() seems a bit premature but I do vaguely recall we had a lot of 'fun' with the strictures of the various platforms of those ancient days - at one era Windows had to have an actual window in order to be able to get any events at all, I think. I know that it is/was possible to make a unix vm that acted the same as RISC OS because that's what I did when I spent some time at DEC WRL working for Alan and built the 'Itsy' VM for Disney. Or... something like that; complicated.

I imagine we could leave most of the old behaviour alone for a while in the VM (maybe with a bit of simplifying?) and start having the image take more responsibility for finding the desired and required screen metrics with appropriate platform calls and then use the HostWindowPlugin to make the window if an when required. Would that satisfy enough  backwards compatibility for everyone? We could include the actual desired window origin as well as size, something that has always annoyed me to have lacking. Finding the full display metrics in one go instead of a scattered bunch of prims might be nice; we could even return an array of metrics to handle multiple displays.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If what you don't know can't hurt you, she's practically invulnerable.