freenode/#clim - IRC Chatlog
Search
4:02:04
loke
Now, I want to make sure the child always has the same size as the bboard itself (at least initially, until I've implemented the drawers)
4:03:39
loke
I can see that the resize happens, but the interactor window itself is never actually reszed
4:04:35
loke
What I mean is, that the resize happens because the entire window is repainted, and is now black (instead of the bboard background white), but the area in which I can type commands to the interactor is still tiny
4:05:05
loke
What seems to happen is that the interactor pane consists of a parent and a child, and the toplevel interactor pane is resized, but the inner pane is not
4:31:05
loke
I'm clearly doing something wrong, since if I put the interactor pane directly in the layout (i.e. not inside the bboard) then a resize propates correctly
4:33:19
beach
In about 3 hours or so, I'll shut down my computer and take it to the guy who sold it to me. I hope he is going to be able to fix the crashes I have been having since the beginning.
4:34:31
beach
The reason I got a new computer is that the old one was crashing as well. But I think I can work with the old one for a while.
4:34:54
beach
Though now that I am saying this, maybe my colleague is right that it has to do with power surges.
4:36:35
loke
That fixed the problems we had during very heavy lightning storms (which are very common here). I lost two TV's, one Playstation, a couple of cable boxes and routers and some other stuff I lost track of, until I bought surge protectors wheverwhere
4:48:02
loke
At first I thought that I needed to call CHANGE-SPACE-REQUIREMENTS, but that didnt' do anything
5:37:34
jackdaniel
loke: changing-space-requirements works on frame. bboard-pane (since it is bigger or equal to its child) works in this scenario more-or-less similar to restraining-pane
5:40:07
jackdaniel
after longer analysis of patterns and McCLIM code I've reinforced my original conclusion, that patterns are aligned to XY by definition and if we want to have transformable images, they should inherit directly from design, not from pattern
5:40:53
jackdaniel
after some experimentation I've found, that clx backend doesn't support (yet) non-uniform ink for (i.e) medium-draw-rectangle*, something what needs to be fixed
5:41:30
jackdaniel
I want to clean up a little class hierarchy in image extension and renderer extension
5:42:32
jackdaniel
loke: also (you may find it in yesterday-pushed branch), I'm reverting medium-draw-text* interface to its original form
5:43:54
jackdaniel
another change I want to perform is removal of medium-draw-pattern* (which is part of climi) in favour of draw-rectangle with ink set to the pattern
5:45:09
loke
I haven't had time to look at it (I did allocate time for it last weekend, but I ended up sleeping, and then going out for dinner instead :-/ )
9:45:01
jackdaniel
so here's the plan: shake image extension implementation; add support for image-design in design-gcontext / medium-gontext; add support for transformed-design in said functions
9:48:33
jackdaniel
transformed design is a class inheriting from design which members are transformation and any region design – pattern, image, bezier curve etc
9:49:03
jackdaniel
we could add another slot "transformed-design", so if the transformation is changed, we recompute from the original one to prevent loss of precision
10:44:23
loke
However, just swapping trhese two leaves the issue that the most recently added child ends up on the bottom of the stack, which is non-intuitive