{"action":"created","issue":{"url":"https://api.github.com/repos/dsi-icl/ove/issues/83","repository_url":"https://api.github.com/repos/dsi-icl/ove","labels_url":"https://api.github.com/repos/dsi-icl/ove/issues/83/labels{/name}","comments_url":"https://api.github.com/repos/dsi-icl/ove/issues/83/comments","events_url":"https://api.github.com/repos/dsi-icl/ove/issues/83/events","html_url":"https://github.com/dsi-icl/ove/issues/83","id":365441757,"node_id":"MDU6SXNzdWUzNjU0NDE3NTc=","number":83,"title":"OVE Ideal Coordinate System","user":{"login":"davidbirchwork","id":11289564,"node_id":"MDQ6VXNlcjExMjg5NTY0","avatar_url":"https://avatars3.githubusercontent.com/u/11289564?v=4","gravatar_id":"","url":"https://api.github.com/users/davidbirchwork","html_url":"https://github.com/davidbirchwork","followers_url":"https://api.github.com/users/davidbirchwork/followers","following_url":"https://api.github.com/users/davidbirchwork/following{/other_user}","gists_url":"https://api.github.com/users/davidbirchwork/gists{/gist_id}","starred_url":"https://api.github.com/users/davidbirchwork/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/davidbirchwork/subscriptions","organizations_url":"https://api.github.com/users/davidbirchwork/orgs","repos_url":"https://api.github.com/users/davidbirchwork/repos","events_url":"https://api.github.com/users/davidbirchwork/events{/privacy}","received_events_url":"https://api.github.com/users/davidbirchwork/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-10-01T12:39:12Z","updated_at":"2018-10-01T23:36:08Z","closed_at":null,"author_association":"MEMBER","body":"**Current Situation**:\r\n - Everything in OVE works in pixels\r\n - Configurations for spaces and screens are specified in pixels\r\n - We have a bezel correction service which creates new configurations specified in pixels \r\n\r\n**Issues**:\r\n - When applying bezel correction sections specified in pixels may now \r\n      - lose content between monitors\r\n      - no longer start at bezels \r\n\r\n\r\n\r\n**Proposed solution**:\r\n - Introduce an idealised coordinate space (e.g. 0..1 or better 0..360 for easy divisibility) - \"Viz coordinate system\"\r\n - Specify spaces with \r\n       - ideal pixel width and height\r\n       - the idealised \"Viz Coordinates\" they represent (e.g. 0.25 to 0.50 in X) (can be calculated from uncorrected pixels)\r\n       - the bezel correction offset  parameters \r\n- Users should never specify their sections in pixels but rather in \"Viz\" space\r\n- Within OVE core a mapping is made between \"Viz\" space and pixel space. \r\n- This mapping should be done within OVE core .js to respect certain rules which can be set default per app and overridden by users. \r\n    - snap this section to ideal percentage (so small slivers of apps are not on odd screens)\r\n    - do not lose pixels (so that letters in title images are not lost)\r\n    - respect aspect ratio\r\n    - this mapping may require a solver \r\n- States should be saved in idealised coordinates \r\n    \r\n"},"comment":{"url":"https://api.github.com/repos/dsi-icl/ove/issues/comments/426098456","html_url":"https://github.com/dsi-icl/ove/issues/83#issuecomment-426098456","issue_url":"https://api.github.com/repos/dsi-icl/ove/issues/83","id":426098456,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNjA5ODQ1Ng==","user":{"login":"senakafdo","id":3415383,"node_id":"MDQ6VXNlcjM0MTUzODM=","avatar_url":"https://avatars3.githubusercontent.com/u/3415383?v=4","gravatar_id":"","url":"https://api.github.com/users/senakafdo","html_url":"https://github.com/senakafdo","followers_url":"https://api.github.com/users/senakafdo/followers","following_url":"https://api.github.com/users/senakafdo/following{/other_user}","gists_url":"https://api.github.com/users/senakafdo/gists{/gist_id}","starred_url":"https://api.github.com/users/senakafdo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/senakafdo/subscriptions","organizations_url":"https://api.github.com/users/senakafdo/orgs","repos_url":"https://api.github.com/users/senakafdo/repos","events_url":"https://api.github.com/users/senakafdo/events{/privacy}","received_events_url":"https://api.github.com/users/senakafdo/received_events","type":"User","site_admin":false},"created_at":"2018-10-01T23:36:08Z","updated_at":"2018-10-01T23:36:08Z","author_association":"COLLABORATOR","body":"I was thinking about this in detail.\r\n\r\n**Improvements to Clients.json**\r\nSo, first of all, we have a clear limitation in the way we define bezel corrected and non-bezel corrected client configurations. We cannot be having 2 separate spaces for these, we need to be having one, because they both refer to the same space, to start with.\r\n\r\n**viz coordinates - not convinced that this works**\r\nThat said, while the idea of `viz coordinates` is great, if the end user wants to perfectly snap their content to grids, they should either configure a rule, or they should know precisely what the percent-wise or 0...360-vise coordinates they should be using to ensure their content is loaded at the right locations. The apps are not space-dependent, so they should never need to be requesting viz coordinates from a space or client etc. This is why the pixel-space works perfectly for content, since there is nothing that binds a visualisation to a specific-space. Therefore, what the viz coordinates seem to achieve is providing the users with an alternative numbering system that is 1:x with the pixel coordinates from the bezel-uncorrected range. And, therefore, I don't see any advantage in doing this.\r\n\r\n**rules**\r\nI fully support the idea of the rules. The starting point for the end user would be a space which has two sets of coordinates, bezel corrected and bezel-uncorrected. First of all, they can chose what they want on a section-section basis. Once they chose, they can request what they specifically want and then a solver would produce an ideal configuration.\r\n\r\n**laying out content - GUI tool**\r\nEven though the concept of viz coordinates is out, the end user must not be burdened with regards to knowing precisely where to place their content and do calculations based on pixel heights/widths. They should instead be able to work with a grid and select (a) where on that grid they would place significant blocks of what they are building and then (b) subsequently overlay that with additional sections that do not perfectly fit that grid. They will never use any kind of coordinate system for (a) in my opinion, but use the rows/columns to decide on how/where to place things. But, for (b), they will certainly want very precise placement and that's where they would opt for pixel coordinates, because that's exactly what they are after at that point. \r\n\r\nWe must keep in mind that the users will not be typing any of this. They will be using a GUI that will help them position their content on the space, and the DO has sections that will move back and forth based on where the user wants to place their content.\r\n\r\n**SDKs**\r\nUsers need not always use the GUI once they have put together a template, since they should at that point be able to load it into an SDK and then arrange their content within those sections or re-position them with a few lines of Python code.\r\n\r\nSo, apart from a 'service' (I mean the combination of UI/API/SDK etc) to evaluate the rules and help OVE produce a layout, there is really no end-user involvement in deciding on how and where to place their content.\r\n\r\n**Coordinates within an app - is already properly dealt with**\r\nAll alignment of content within an app is relative to section height/width and uses viewport-based coordinates (vw/vh). This makes the content fit any device or any size of section. We should not be replacing this with our own coordinate system or a grid - if we do that, apps (same applies to visualisations) will only work in specific layouts.\r\n\r\n**Summary**\r\nFirst of all, we need to improve the Clients.json to support both bezel-(un)corrected layouts. Then,\r\nI think that we should not be debating about this before we have seen what the GUI tool will be doing."}}
{"actor":{"display_login":"senakafdo"}}