The Inbox: Graphics-dtl.335.mcz

David T. Lewis uploaded a new version of Graphics to project The Inbox:
http://source.squeak.org/inbox/Graphics-dtl.335.mcz

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

Name: Graphics-dtl.335
Author: dtl
Time: 11 May 2016, 11:25:12.450775 pm
UUID: df71df68-b235-49be-b4a5-bebb84cb420a
Ancestors: Graphics-mt.334

DisplayScreen class>>hostWindowExtent: uses the host window plugin to set the size of the main Squeak display window. Add the complementary #hostWindowExtent to query the plugin for display size. Requires VM support for HostWindowPlugin.

Assuming required support from VM HostWindowPlugin:
        Display width @ Display height = DisplayScreen hostWindowExtent ==> true

Recategorize methods for plugin access, and add a method comment to explain the convention of treating host window index 1 as a reference to the Squeak display window.

=============== Diff against Graphics-mt.334 ===============

Item was added:
+ ----- Method: DisplayScreen class>>hostWindowExtent (in category 'host window access') -----
+ hostWindowExtent
+
+ ^ self primitiveWindowSize: self hostWindowIndex
+ !

Item was changed:
  ----- Method: DisplayScreen class>>hostWindowIndex (in category 'host window access') -----
  hostWindowIndex
+ "By convention, the reference to the primary Squeak display window is 1.
+ The host window plugin may use different conventions for references to
+ windows. In general, the handles for references to host windows should be
+ considered as meaningful only to the VM plugin, with host window index 1
+ being a special case of a well known handle value."
 
  ^ 1!

Item was changed:
+ ----- Method: DisplayScreen class>>primitiveWindow:title: (in category 'primitives - host window access') -----
- ----- Method: DisplayScreen class>>primitiveWindow:title: (in category 'host window access') -----
  primitiveWindow: id title: titleString
 
  <primitive: 'primitiveHostWindowTitle' module: 'HostWindowPlugin'>
  ^self primitiveFailed!

Item was changed:
+ ----- Method: DisplayScreen class>>primitiveWindow:width:height: (in category 'primitives - host window access') -----
- ----- Method: DisplayScreen class>>primitiveWindow:width:height: (in category 'host window access') -----
  primitiveWindow: id width: width height: height
 
  <primitive: 'primitiveHostWindowSizeSet' module: 'HostWindowPlugin'>
  ^self primitiveFailed!

Item was added:
+ ----- Method: DisplayScreen class>>primitiveWindowSize: (in category 'primitives - host window access') -----
+ primitiveWindowSize: id
+
+ <primitive: 'primitiveHostWindowSize' module: 'HostWindowPlugin'>
+ ^self primitiveFailed!

Marcel,

Could you please check if this works on Windows and/or Mac, and if so consider
moving to trunk?

In particular, check if this works on Windows:

    Display width @ Display height = DisplayScreen hostWindowExtent ==> true


I have the HostWindowPlugin primitives working on a unix VM but will need to
clean it up and post the patches.

I think that we had an earlier question as to whether the host window
decorations (title bar etc) should be included in window size calculations.
Based on the above test I would say that the answer should be no, neither
the VM nor the image should be aware of the size of any window decorations
that are added by a window manager. I expect that this policy should make
sense on Windows, OS X, and Risc OS, although I do not know for sure because
I am only looking at the X11 case.

Dave


On Thu, May 12, 2016 at 03:25:16AM +0000, [hidden email] wrote:

Hi Dave,

no, the host window extent includes title bar and shadows in Windows 10. That's why I implemented DisplayScreen class >> #setNewScreenSize: with the two passes.

I copied this version over to trunk and adapted the calculation of the new screen size to use #hostWindowExtent and a single call.

Best,
Marcel

On 12.05.2016, at 09:03, marcel.taeumel <[hidden email]> wrote:
>
> Hi Dave,
>
> no, the host window extent includes title bar and shadows in Windows 10.
> That's why I implemented DisplayScreen class >> #setNewScreenSize: with the
> two passes.
>
> I copied this version over to trunk and adapted the calculation of the new
> screen size to use #hostWindowExtent and a single call.

I agree with Dave: We do not need or want to read hostWindowExtent. For the main window we already have actualScreenSize which gives us the extent.

We should set the window size to the expected value, check actualScreenSize, and adjust if needed to work around the Windows VM’s bug (and fix the Windows VM).

- Bert -

On Thu, May 12, 2016 at 10:56:35AM +0200, Bert Freudenberg wrote:
Thanks Marcel and Bert,

I added the DisplayScreen>>hostWindowExtent method in Graphics-dtl.335.
If it is not needed, should I remove it? It is useful for exercising the
HostWindowPlugin, but maybe it does not belong in trunk.

Dave

Sorry, please disregard. I see that Marcel has already handled it :-)

Thanks,
Dave

On Thu, May 12, 2016 at 08:00:32AM -0400, David T. Lewis wrote:

It is needed and used in HostWindowProxy. But for the main window we have actualScreenSize. That’s why I deleted it.

- Bert -

> On 12-05-2016, at 5:12 AM, Bert Freudenberg <[hidden email]> wrote:
>
> It is needed and used in HostWindowProxy. But for the main window we have actualScreenSize. That’s why I deleted it.

For actual screen size we ought to be using the pseudo-proxy and using the hostwindow primitive

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Loyalty oaths.Secret searches.No-fly lists.Detention without legal recourse.Remind me - who won the cold war?

Note that the HostWindowPlugin does not work properly if the window is minimized. At least in Windows 10.

Best,
Marcel

On Fri, May 13, 2016 at 04:12:49AM -0700, marcel.taeumel wrote:
> Note that the HostWindowPlugin does not work properly if the window is
> minimized. At least in Windows 10.
>

What symptoms do you see? FWIW, it does seem to be working properly now
on my Ubuntu + V3 "trunk" image + interpreter + local plugin hacks.

Dave
 

Hi Dave,

nothing happens. I tried it via

(DisplayScreen future: 5000) hostWindowExtent: 1024@768.

which gives you 5 seconds to minimize the window.

Best,
Marcel

On Fri, May 13, 2016 at 07:27:52AM -0700, marcel.taeumel wrote:
> Hi Dave,
>
> nothing happens. I tried it via
>
> (DisplayScreen future: 5000) hostWindowExtent: 1024@768.
>
> which gives you 5 seconds to minimize the window.
>

Hi Marcel,

I get the same result on unix/X11, so it is not a Windows thing. The
window stays minimized, and when I reopen it the dimensions are 1024@768.

I'm not sure that this is a bug. The window extent is being set correctly,
but the new dimensions have no effect until we tell the the window manager
to reopen the window.

Are you seeing the same thing? If you reexpand the window after waiting
for more than 5 seconds, does it open with the new window extent in
effect? If yes, then I would say that this is reasonable behavior, and
not a bug.

Dave

Hi Dave,

it's okay that the window stays minimized. But when I open it again, it still has the old resolution, which was 800@600 in my experiment.

Best,
Marcel

On Fri, May 13, 2016 at 11:19:36PM -0700, marcel.taeumel wrote:
> Hi Dave,
>
> it's okay that the window stays minimized. But when I open it again, it
> still has the old resolution, which was 800@600 in my experiment.

It must be a Windows plugin issue then.

Dave