libera/#clim - IRC Chatlog
Search
8:17:47
lisp123w
jackdaniel: Thanks, yeah I noted that too. Just trying to read from different angles for now to understand things better, but not using it as a 'reference'
8:41:32
jackdaniel
mind that lispworks clim guide is also a good read with better separation between "programmer" abstractions and "if you really want to tinker with clim" chapters
8:42:18
jackdaniel
loke: I'm working on incremental redisplay and your issue reports (from 2018!) provide valuable test cases, thanks
10:18:03
moon-child
approximately. Some of them may have made their way there by mistake, and some of them I think I have already read
10:22:18
lisp123w
beach: It's not too bad, I'm 55 pages in on the Franz manual, so will probably finish in about 2-3 days (don't need to memorize all the generic functions listed, just understand the main topics). Then probably skim through the LW equivalent. Apart from that, I have one book on my list that will take some time and PAIP is sort of there, but I'm not really motivated to do that right now
10:24:48
lisp123w
One issue with Lisp is that its intellectually stimulating, so its easy to get into the trap of reading all the wonderful material out there
10:31:30
lisp123w
It's a bitt off-topic (but on-topic at the same time), but a McCLIM based Emacs, sans IDE, could be a big hit
10:32:21
lisp123w
Since McClim supports graphics and other advanced functionality, but has a lot of the core concepts from Emacs. I know that the IDE part is quite hard to do, but "McClim Org Mode" might prove valuable
10:34:01
lisp123w
I was thinking outside of the IDE, just basic text editing, markdown preview (as shown a few days ago), IRC, Web Browser
10:34:48
moon-child
not that something useful would be less effort than an IDE. Quite the opposite, in fact
10:36:04
beach
lisp123w: I don't think it is reasonable to have applications such as a web browser or an IRC client as part of the editor. It is done that way in Emacs because Emacs is also a Lisp system. But we have a better Lisp system, so the editor could be but one component.
10:37:03
lisp123w
I see, so better to do LispOS then McClim-Emacs (although LispOS will presumably use McClim)
10:37:36
beach
lisp123w: No need for a LispOS. Just a Common Lisp image running McCLIM and various applications.
10:38:35
lisp123w
Okay. I guess as long as there is a window manager (like moon-child noted), that's sort of the glue IMO that makes all the parts of Emacs work well together
10:38:49
jackdaniel
well, mcclim (and common lisp in fact) is a great device for big balls of mud, defining a separate irc client and a separate text editor doesn't make it unfeasible to adopt both in a single frame
10:41:53
jackdaniel
(ftr some people call these big balls of muds a "melleable software", but the former has a nice ring to it:)
12:23:47
scymtym_
i can't think of any way to automatically decide whether the gadget output record closes over "obsolete" variables
12:24:40
jackdaniel
well, imo gadget should be always replaced unless it is wrapped in with-updating-output :cache-value t
12:27:11
scymtym_
certainly more orthogonal since gadget output records and incremental redisplay wouldn't be conflated
12:30:34
scymtym_
i have one final™ question regarding the interaction of clipping regions and "formatting" output records like tables and graphs: should the clipping region that was established around the creation of the formatting output record affect 1) the internally stored geometry information (e.g. line endpoints) 2) the bounding region of the output record 3) the sensitive region 4) the graphics visible on the screen? i think clear are
12:40:13
jackdaniel
bounding rectangle is used to determine things like record overlapping and to test for sensitivity (at least initially, later it may be precised more)
12:43:00
jackdaniel
also, regarding "internally stored geometry information", I wonder whether if the output record falls outside of the clipping area it should be recorded or not
12:43:47
jackdaniel
(after a thought, 2) is indeed quite complex, i.e it may be outside of the clipping region, because its bounding rectangle influenced other records and that's why it was moved outside)
12:51:09
scymtym_
i said it should affect the sensitive region in my opinion, so that seems clear (and this already works since GS-CLIP-MIXIN restricts the sensitive region to the clipping region)
12:52:10
scymtym_
yeah, 2) is difficult because of the effects on the placement of other output records and the cursor position
12:55:04
scymtym_
i tend to think that not affecting the bounding region is more predictable, but i can be more difficult in terms of achieving a result desired by the user (for example, producing an excerpt from a larger graph without lots of space around it)
12:55:40
scymtym_
other output records do not clip the bounding region. for example, (with-drawing-options (s :clipping-region (make-rectangle* 50 50 100 100)) (draw-line* s 0 0 100 100)) creates an output record of size 100x100
12:56:30
jackdaniel
yes, I think that bounding region of the output record should be part of its internal state after all
12:58:46
scymtym_
something like (with-drawing-options (s :clipping-region …) (format-graph-from-roots …)) "take up" as much space as the unclipped graph in terms of the bounding region
12:59:44
scymtym_
so, for example, letting F-G-F-R move the cursor and outputting text might produce a "gap"
13:00:34
jackdaniel
if it is some arbitrary clipping region, then you could translate coordinates to match imaginary 0,0 insider with-room-for-graphics with specified height and width (can we specify width? we should certainly)
13:00:38
scymtym_
maybe you format the graph twice and capture the bounds of a certain node of interest in the first pass. it's just an example
13:01:03
jackdaniel
then I think that having it "bounding-rectangle-wise" stable would be actually less difficult for the user
13:02:32
scymtym_
sure, one can do the required record positioning and cursor movement manually. that's why i said "difficult" not "impossible"
13:02:40
jackdaniel
because if bounding rectangles change depending on the clipping region then offsets in the graph change as well
13:03:30
jackdaniel
it will be difficult, but at a glance it seems that it would be even more difficult if bounding rectangles change depending on the visual appearance
13:04:29
jackdaniel
when you have nodes, then bounding rectangles are used to determine the width (or the height) of the gap between edges
13:05:30
scymtym_
i think nodes should be recording without respecting the clipping region that is active around the surrounding F-G-F-R call
13:06:04
scymtym_
similar to ignoring the clipping region within table cells in the original example i presented a few days ago
13:06:36
jackdaniel
so then clipping region would affect only the compound output record bounding rectangle
13:08:10
scymtym_
since nodes, cells, etc are produced in a "void" before their final placement can be computed, things like cursor position, page margin and clipping region should be reset in my opinion
13:09:10
scymtym_
but cursor position, page margins and clipping region /should/ affect the created compound output record
13:09:12
jackdaniel
sure that makes sense. perphaps a page margin could be set to something sensible for wrapping
13:10:04
jackdaniel
well, compound output records are special either way, because they must compute their bounding rectangle based on children
13:10:21
scymtym_
well, "void" is probably too strong since other things like current drawing options should be respected
13:12:17
scymtym_
one of the alternative, let's call it the DWIM alternative, creates the compound output record and as the final action of the formatting function restricts the bounding regions of all records in the output record tree to the clipping region, then calls TREE-RECOMPUTE-EXTENT
13:13:03
scymtym_
but as DWIM tends to do and as we discussed, this is less predictable overall and introduces complex side effects
13:13:48
jackdaniel
also it kind of breaks the clipping metaphore, you clip to some part (i.e hide the rest), so it is not conceptually the same as "cut and move to 0"
13:14:41
scymtym_
putting a paper with a clipping region-shaped whole over the output is certainly easier to understand
13:15:09
scymtym_
so i will not change the bounding regions since other output records already work like that and since it is easier to understand and predict
13:20:45
jackdaniel
during redisplay note-output-record-lost-parent is suppressed, and gadgets under the hood are adopted sheets that are disowned on that note
13:21:36
jackdaniel
this is still problematic, because say you drag a slider and call redisplay like you did in the demo and that slider is not cached - you get an error
13:22:38
jackdaniel
but that could be considered as the programmer error I suppose (i.e that they must wrap properly in with-updating-output the gadget that calls redisplay-output-record)
13:22:57
scymtym_
isn't that analogous to :value-changed-callback (lambda (gadget …) (sheet-disown-child … gadget))?
13:25:05
scymtym_
i'm assuming the problem comes from the gadget attempting to repaint itself after being disowned?
13:25:44
jackdaniel
no, that comes from delivering events to it (i.e you are dragging the slider) after being disowned
13:27:57
scymtym_
i wouldn't argue in favor of implementing it, if it negatively affected any other aspect even a little bit
13:30:14
jackdaniel
hm, the problem didn't reproduce now (without further code changes), I'll restart the image
13:33:09
jackdaniel
well, "WINDOW-ERROR in current request Code 20.0 [GetProperty] ID #x4600175" if I disable the sheet first :), let's try with deactivate
13:34:45
jackdaniel
ah, we can't deactivate it really, because it may be i.e a tabling pane over the gadget ^_^
13:43:41
scymtym_
in the worst case, the user would have to queue an event from the callback and do the redisplay when the event is handled
13:49:42
jackdaniel
also the gadget-output-record's sheet is not properly repainted when disowned and then adopted again
14:02:02
jackdaniel
the suppressed notifications were ought to be broadcasted after whole redisplay was done
14:10:31
jackdaniel
somewhat incomplete notes: https://gist.github.com/dkochmanski/05e9d80335ddafe713369954528ea1af
14:32:48
scymtym_
can anyone try what happens when evaluating (restart-bind ((crash (lambda () #P"foo"))) (error "bar")) and selecting the CRASH restart in the SLIME debugger?
14:41:32
scymtym_
it seems SLIME-EVAL just tries to read the result produced on the common lisp side as an emacs lisp expression :(
15:00:22
jackdaniel
http://turtleware.eu/static/paste/incrm.mp4 now this video exhibits behaviors with and without disarming the gadget
15:00:41
jackdaniel
if it is disarmed then the focus is immedietely lost, when it is not disarmed, then we have a flickerfest :)
15:20:13
jackdaniel
(defmethod note-sheet-disowned ((gadget basic-gadget)) (deactivate-gadget gadget))
15:49:07
jackdaniel
ind that wrapping it in updating-output may cause it to capture some "old" variable if it is shared with other records, that depends when and from where they are redisplayed
15:57:05
jackdaniel
yes, it is expected behavior. the old reference may be captured in a callback that is stored in the record, and the record does not change so the callback does not change either
17:36:06
jackdaniel
slyrus: I'm around for another hour, so if you want to go through some issues then we can go now
17:37:07
slyrus
one minor-ish issue that I've run across in the clim-listener is described here: https://github.com/slyrus/clorg/issues/1
17:37:50
slyrus
my larger issues resolve around how to get decent zooming/scrolling - and one day perhaps - more "interesting" drawing behavior based on the scrolling/zoom settings.
17:38:16
slyrus
one approach to scrolling/zooming and the immediate problem I run into is described here: https://github.com/slyrus/zoom-viewer/issues/1
17:40:22
slyrus
if I manage the scrollbars myself, rather than using a scroller-pane, I get "better" results: https://github.com/slyrus/zoom-viewer-2
18:07:53
jackdaniel
you may test this code. notice that I'm not changing the sheet-native transformation only the sheet-transformation
18:34:18
slyrus
ok, I'm reluctant to remove to much as it is likely in the present methods where McCLIM or I go wrong, but a slimmed down version of clorg that doesn't have any external dependencies can be found here: https://github.com/slyrus/standalone-clorg
18:34:56
jackdaniel
OK, and here is zoom with working scrollbars: https://plaster.tymoon.eu/view/2733#2733
18:34:57
slyrus
as for the zoom-frame, ok, I'll try to remove my use of sheet-native-transformation.
18:36:08
jackdaniel
it resets requirements without accounting for the transformation, so don't resize the frame - otherwise scroll bars will be re-set
18:37:17
slyrus
hmm.... it sort of works with scroll bars but changing the zoom still resets the zoom
18:49:34
slyrus
if I zoom in, then, say, scroll down so (that only) the middle portion of the zoomable area is shown, if I then adjust the zoom, the displayed area resets to 0,0 at the upper left
19:00:52
jackdaniel
this tangentially resembles this: https://github.com/McCLIM/McCLIM/issues/658 but I don't think that the underlying issue is the same
19:03:26
jackdaniel
I've got to go now, but I have something to work with - I can reproduce both issues; I'll let you know if I learn something
19:04:36
slyrus
and I've managed to remove my calls to internal climi routines with no loss of functionality, so that's good!
19:05:26
jackdaniel
keep in mind that resizing the frame will invoke the layout protocol and it doesn't take into account the sheet transformation, so scroll bars will get wrong again
19:06:31
jackdaniel
and here is a fix for mouse scroll in scroll bars: https://plaster.tymoon.eu/view/2734#2734