window fit on lower resolution screens

[mr-martian]

Originally posted by @jonorthwash at 2019-05-02T20:41:27Z (original issue)

The window should be able to display entire contents at screen with resolution down to 1366x768.

[mr-martian]

Originally posted by @jonorthwash at 2019-05-02T20:42:03Z

Related peripherally to #32.

[mr-martian]

Originally posted by @jonorthwash at 2019-05-16T20:57:39Z

A proposal:

Detect screen resolution at startup. If default window size is larger in vertical dimension than screen, then switch to low-res mode. Low-res mode would adjust the layout so that the controls, the ultrasound image, and the textgrid and spectrogram all take up horizontal space instead of vertical space.

Also, scrollbars on window when window is resized smaller than content.

[mr-martian]

Originally posted by @jonorthwash at 2019-05-30T18:18:58Z

The other issue will be making sure everything is visible on higher resolution screens.

[mr-martian]

Originally posted by @jonorthwash at 2019-06-07T03:51:48Z

I think the content should fit to the window size as it's resized (and the window size should be no bigger than the screen size at startup, cf. also #54).

Everything can collapse as needed as described in #51, and after that, the viewport for the ultrasound frame can shrink.

The viewport should probably remain the same proportions (4:3 in all the Philips-acquired data, I think), and can continue to allow zooming and panning. When the window is made bigger, the viewport should also stretch to fill the space.

Perhaps also by default the ultrasound frame should be zoomed out and in (respectively) to fit/fill the frame.

[mr-martian]

Originally posted by @BartholomaeusAstrum at 2019-07-02T21:19:14Z

Image spectrogram and tiers currently resize on window resize (at least on Mac.) Size isn't kept once frame is changed, and new size doesn't play well with zoom and trace functionality. (I might want to turn zoom related things over to Daniel.)

[mr-martian]

Originally posted by @BartholomaeusAstrum at 2019-07-03T15:55:10Z

@mr-martian I'm thinking about how to make the traces stay in the right place when the image size changes when the user resizes the window. I don't fully understand the code that's already there, so there may be a solution that I'm not seeing.

A solution I do see thought, is saving each coordinate of a trace as a number between 0 and 1, and then scaling based on window size. What do you think? Would that overwrite a lot of your work?

[mr-martian]

Originally posted by @mr-martian at 2019-07-03T18:29:47Z

I think I know how to fix the issue by on line 171 in ZoomFrame.showImage() dividing self.imgscale by the amount that it has to shrink due to window resizing, but I don't know how to determine that resizing factor. Do you?

I think saving traces as floats in [0,1] rather than pixels would be orthogonal to this issue, but I could be wrong.

[mr-martian]

Originally posted by @jonorthwash at 2019-07-04T02:33:59Z

The data I've already traced has half-pixel resolution. Most traces were traced at 2x zoom, so the data could be accurate to that level. Do these currently get levelled out on import? If so, a new issue should be opened for that. Also, we should continue to support sub-pixel resolutions if annotated when zoomed in.

[mr-martian]

Originally posted by @jonorthwash at 2019-07-04T02:49:52Z

It looks like non-integer traces are still supported.

Otoh, when I trace stuff zoomed in, I get coordinates like this in the metadata file:

                  {
                     "x": -9.143155902535481e-05,
                     "y": 0.00014240885150841275
                  },
                  {
                     "x": -9.141409283279912e-05,
                     "y": 0.00014235134963991666
                  },
                  {
                     "x": -9.140633008055216e-05,
                     "y": 0.00014229614784616045
                  },

[mr-martian]

Originally posted by @jonorthwash at 2019-07-05T21:18:06Z

Otoh, when I trace stuff zoomed in, I get coordinates like this in the metadata file:

@mr-martian fixed this in https://github.swarthmore.edu/PhonLab/dicom-annotator/commit/a94cdb07407536f7837071a1aad6f894446893ec .

[mr-martian]

Originally posted by @jonorthwash at 2019-07-05T23:46:58Z

...and https://github.swarthmore.edu/PhonLab/dicom-annotator/commit/4a02b13567e6ddcd969f33a0ae2fbf2d03480e96

[mr-martian]

Originally posted by @BartholomaeusAstrum at 2019-07-17T18:02:11Z

This is basically done except #51 and #52