freenode/#clim - IRC Chatlog
Search
20:57:56
|3b|
jackdaniel: how should "screen properties" be interpreted with multiple monitors on 1 port?
21:00:56
jackdaniel
that's a hard one. I did think about that when I was looking for a consistent model with multiple monitors with different dpi (I want to make dp a default native unit)
21:01:58
jackdaniel
one could stipulate, that each screen has a separate graft, but what about sheets which are moved between screens (and i.e part is on one and the other is on another)
21:03:23
jackdaniel
you would have to duplicate frame panes (as in: regenerate them) with different pane and render frame twice with a clipping region until we move onto one
21:03:57
jackdaniel
then you'd have a funny effect of the same window on different monitors with the same physical size but with a different resolution
21:05:19
|3b|
not sure 2 os-level windows would work well, would be hard to keep them synchronized, and borders at screen edge would be odd, + extra decoractions etc
21:06:29
jackdaniel
either way I did not come with anything yet with this regard except: take the first screen and pretend all have the same properties
21:07:39
|3b|
so for graft size in MM/inches, calculate PPI of primary monitor and then multiply by total size of desktop?
21:10:56
jackdaniel
currently McCLIM assumes pixels, so it doesn't matter (you are not interested in mm/inches)
21:11:07
jackdaniel
when we switch to dp (density independent pixels) then it will make a difference
21:11:55
jackdaniel
and given how fast things move in open source world it will assume pixels for quite a while ,)
2:43:39
|3b|
how do i make a backend use simple-event-queue? (or otherwise force it to check events on same thread that created windows)
3:25:05
|3b|
yeah, better with that... now have a single window i can click on that maybe makes other windows pop up
6:15:06
TMA
jackdaniel: microsoft windows do the "most of the window" trick |3b| mentioned. moreover they do not render for each dpi, the other part of the window is interpolated