freenode/#clim - IRC Chatlog
Search
5:25:13
slyrus1
and, for what it's worth, I'm trying to build up the gadgets in my pane manually, not spelling them out in the :panes section of my frame
5:58:49
slyrus1
if anyone's curious about the broken-ness I mentioned, check out: https://github.com/slyrus/clim-input-test
7:32:26
jackdaniel
this brokeness comes from the fact, that using these fields in :panes section gives them a separate mirror, while when you use with-output-as-gadget you squeeze them into the stream. I didn't investigate yet how to fix it properly
7:35:25
jackdaniel
I've tried to have the same gadget outputted twice, so I thought it was due to identity, but your example is a good data point that it doesn't matter, it is enough that we have two input gadgets
7:41:52
jackdaniel
and as of kludges: sometimes a well-placed kludge is worth more than whole module which addresses the issue (I don't know if this is that kind of kludge, just saying that this word doesn't necessarily mean red flag)
7:43:22
jackdaniel
slyrus1: regarding your desire to have #.(make-point* …), afair Nisar said that he is willing to merge your PR when you address the issues mentioned in the PR
7:55:50
jackdaniel
https://files.mastodon.social/media_attachments/files/008/350/509/original/09baa41f5212cffd.png (this is how it looks right now)
8:02:30
jackdaniel
btw, I've found a wonderful resource with a well-made descriptions of many state of the art geometry algorithms: http://geomalgorithms.com/algorithms.html
8:30:30
jackdaniel
we have an inconsisten behavior in do-sequence (one of utilities we have) wrt handling lists vs handling vectors
8:31:53
jackdaniel
I want it to be consistent and I wonder which behavior should be taken (binding to NIL or erroring).. do you guys have opinions?
8:33:33
jackdaniel
argument for binding to NIL: we can go through the sequence and peek at the next element if it is eql
8:34:43
jackdaniel
i.e (do-sequence ((x y x* y*) coordinate-sequence) (unless (and (eql x x*) (eql y y*)) (collect-point x y)) ;<- that would remove duplicate consecutive points
9:27:38
slyrus1
jackdaniel: is there another way to get multiple gadgets on a pane (not made via the :panes argument of make-application-frame) that doesn't use with-output-as-gadget?
9:35:20
slyrus1
OK. It doesn't have to be a stream pane (as far as I'm concerned, but there may be other good reasons why).
9:37:08
jackdaniel
well, in that case you may create horizontal pane with your gadgets being its :contents sequence
9:37:54
jackdaniel
exactly, for instance it is perfectly fine to do :pane (horizontally () (make-push-button …) (make-clim-application-pane)))
9:41:21
jackdaniel
only composite panes have children and I don't think CLIM provides protocol to modify contents of layout pane after its creation
9:43:15
slyrus1
For my clim-paint application, I have three panes -- 1) the "painting", 2) the interactor, and 3) some sort of properties editing pane. I'd like to build the gadgets that make up the properties editing pane on the fly so that, for instance, if a user has selected an ellipse, an appropriate set of properties for an ellipse show up in the properties editor.
9:44:04
jackdaniel
then you want to output gadgets as part of a display (hence, you want to put them on a the output-recording stream)
9:44:40
jackdaniel
and if it is broken, then you need to either fix it or wait for someone else doing that
9:46:33
jackdaniel
put things like :panes (ellipse-toolkit (horizontally () gadget-1 gadget-2)) … in panes section
9:47:35
jackdaniel
(:layouts (ellipse-editing (vertically () painting ellipse-toolkit interactor) (rectangle-editing (vertically () painting rectangle-toolkit interactor)) etc
9:48:14
jackdaniel
not the prettiest solution, I'm sure you could also hack your way through generate-panes method somehow, but I wouldn't recommend that unless you know what you're doing
10:05:31
slyrus1
Well, properties will have to wait for another day then. But the bezier curve editing stuff works, at least.
15:34:44
loke`
I was wondering... Is there a way to open more than one frame that are managed by the same event loop?
15:35:06
loke`
(what I want to do is when I can accept a presentation type X, I want to be able to select it from a different window)
15:37:14
jackdaniel
this is a known feature request. it won't work in principle, maybe there is a hack you could apply to have it working t hough
15:38:39
loke`
This is specifically about my documentation window i climaxima. Right now, I keep the documentation in the same frame (just popping open a new pane that partially overlays the main frame) just to be able to display documentation and the interactor at the saem time.
15:38:56
loke`
It's annoying though, and being able to keep it in a separate frame would be so much nicer.
15:39:30
loke`
I mean, is there some fundamental design problem that prevents it from being implemented?
15:42:08
jackdaniel
I don't know, my intuition is that it will be a major task (most of it would be understanding what's exactly going on), but I doubt there is a design issue which would make such feature unfittable to implement