freenode/#clim - IRC Chatlog
Search
16:11:45
beach
I can see how this complication happened. We made the mistake very early on to think that pretty much all panes should be mirrored, thinking that all display servers supported that.
16:11:48
beach
Then, gilberth ran into the 16-bit limit of X11 coordinates, so he invented coordinate swizzling.
16:11:55
beach
Then, to support display servers without nested windows, it had to be possible to alter the class hierarchy so that panes were not mirrored.
16:13:21
beach
All this, because the specification was not sufficiently clear about what panes and what gadgets should be mirrored, and because of our naivete as CLIM implementers.
16:14:58
jackdaniel
regarding your earlier question - I will do that anyway because that sounds like an improvement, but if you want to hire me to do that, then I think that 1000 euro greatly benefit me
16:15:58
jackdaniel
as of the price to pay for gaining knowledge, I find having clim-tos sources available as a reference very informative
16:16:12
jackdaniel
even if we disagree with some implementation choices, that gives some other perspective
16:20:26
jackdaniel
(answering my question from before: the initial position of the mirror should be the sheet-region transformed by a delta transformation between the newly created mirrored sheet and its mirrored ancestor)
16:30:32
jackdaniel
by mirrored ancestor I mean a result of calling sheet-mirrored-ancestor on its parent (because said function may return the argument itself if it is mirrored)
16:34:34
loke
jackdaniel: I'm working on a new plotting system for Climaxima. Do you know how stable the double buffering support is?
16:58:25
scymtym
we could soon have double buffering as a port option if loke wants to experiment with it
17:01:15
jackdaniel
btw, I'm thinking about adding a new backend function and extend existing interfaces: https://github.com/McCLIM/McCLIM/pull/1102
17:01:56
jackdaniel
most notably there is graft-pixel-aspect-ratio which allows us to work with non-rectangular device units
17:05:16
scymtym
pixmaps and pixel aspect ratio seem orthogonal to double buffering or am i misunderstanding?
17:06:33
jackdaniel
aspect ratio is orthogonal, however pixmaps - not so much. double buffering at least could be implemented by having the drawable default to a pixmap and copying area as the buffer swap operation (or flush)
17:10:11
scymtym
at least on windows using pixmaps would complicate things. i think my X double buffering also uses X concepts directly
17:17:10
loke
OK, I need to go to sleep now. I will be working on this animation stuff tomorrow night (so far nothing is actuall ymoving on my screen :-) )
4:06:03
loke
I need advice: What is the actual "proper" way to do animation in CLIM? My needs are simple: A few circles and lines needs to be redrawn so as to create an animation. I odn't even know if I should add these objects as output records and then change them, or do I do it on a lower level and take over the drawing altogether by overriding HANDLE-REPAINT?
4:06:35
loke
Doing it wih output records/presentations would be nice becuase of some interactivity features I'd get for free.
4:09:29
beach
I don't know the answer, but I would use the first method, i.e. use output records, and either modify them destructively or replace some of them.