freenode/#clim - IRC Chatlog
Search
20:05:45
scymtym
|3b|: i think it is similar to the X root window, i.e. the parent of top-level sheets. i have seen the hierarchy visualized as port -> graft -> top-level-sheet -> other-sheets
20:05:47
|3b|
i guess mostly just an CLIM thing, not a backend thing. should it map to entire desktop or to a specific monitor?
20:10:43
|3b|
i guess theoretically it should map to monitor since it has physical dimensions, but in practice probably to entire desktop, since i don't see anything to specify monitors, or handle windows spanning them
20:13:08
scymtym
i don't know whether that works in practice with frame sheets spanning multiple grafts and whatnot
20:35:01
jackdaniel
but in principle they should provide a transformation from the sheet coordinates to the native coordinates
20:36:33
jackdaniel
and transformation associated with that graft transform coordinates to whatever is assumed by medium as input
20:37:19
jackdaniel
in practice though in McCLIM grafts are only used for probing screen properties (i.e pixels per mm)
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