freenode/#clim - IRC Chatlog
Search
6:55:50
loke``
beach: I'm not sure that would work. The lines are broken when word wrap is appled and split into multiple output records, one per line.
6:59:00
beach
slyrus: The redisplay function is synchronized with the command loop, not the event loop.
7:00:00
loke``
beach: but you don't want to reflow after every resize event. When resizing you get hundreds of resize events in quick succession.
7:08:33
slyrus
hmm... two separate issues here. beach's command loop vs event loop issue and loke's hundreds of resize event issue.
7:09:18
beach
The latter is probably not to hard to fix. Just check whether the next event is also a resize.
7:09:24
slyrus
Before tackling these, I should mention that i have an existence proof of at least a hackish way to make things sort of work.
7:10:18
beach
slyrus: For a particular application, you can do what you want of course, but it can't be part of the default way to invoke redisplay when the window is resized.
7:11:12
slyrus
Ok, it doesn't have to be the default, but it seems like it should be a reasonable thing for an application to do.
7:12:39
beach
The reasonable thing to do would be to provide pane types and output-record types that can be replayed differently when the window is resized.
7:13:54
slyrus
Sometimes you need to repeat yourself before it manages to make it through my thick skull
7:15:44
loke``
beach: Buf if the output-record replays differently, the size of said output-record will also change. That needs to trigger an update of subsequent output-recordss as well (the next one may need to move so it stays at the same point relative to the previous oen)
7:16:01
slyrus
beach: And are you implying that events don't have a way to influence the command loop?
7:16:12
loke``
I don't think there is a clean way to simply resize an output record and having everything else do the "right" thing.
7:22:17
beach
slyrus: Well, you can do some kludge of course, but normally, the event loop is at a lower level than the command loop.
7:31:01
slyrus
beach, I'm not saying your approach couldn't work, but it seems to me that the figure-out-how-to-redisplay-on-resize approach would be a simple, viable approach for many applications.
7:32:58
loke``
slyrus: One problem I had with redisplay was that the scroll positions of all scroll-panes were lost
7:33:43
slyrus
I'm beginning to think that our scroll-panes are rather useless except for trivial demos
7:36:02
slyrus
But scrolling (and other sliders) are another good example of where we might interaction between the event loop and the command loop. Right now we can repaint in callbacks but I think redisplaying would be a problem.
7:36:51
slyrus
And we might want, say, a slider that controls how much detail is to be drawn or some other parameter, that causes not just the repainting of existing output records but new records to be created.
7:42:07
beach
I am still convinced that stuff that triggers redisplay should be synchronous with the command loop.
7:46:16
slyrus
sure, but you said changing a slider should trigger a command. Couldn't a resize do the same?
7:48:11
beach
So I maintain that redisplay should not be called from the event loop, without triggering a command.
7:48:25
slyrus
Call it whatever we want. But I want to change how my application draws things when the window is resized.
7:50:30
beach
But, yes, it seems that my problem with the proposed solutions is that the command loop was bypassed.
7:51:59
slyrus
Ok. I may be overstating the obvious here, but to give an example of the sort of thing that I believe we should be able to support can be demonstrated by opening your favorite web browser to a given page and resize the window and watch as the page is (redisplayed/redrawn). I would imagine we might be able to support that kind of functionality in McCLIM/CLIM, but it isn't obvious how to do so.
7:54:53
loke``
(defun call-in-event-handler (frame fn) (clim:execute-frame-command frame `(funcall ,(lambda () (funcall fn)))) nil)
7:55:21
loke``
I think I needed it that way to make sure that local lexical binds gets captured correctly.
8:02:58
beach
I am convinced that there are many aspects of modern GUI applications that are not covered by the CLIM II specification. And I think we should try to accommodate such aspects. But I think it should be done by using the stratified design of CLIM to create new components that behave the way we want, rather than altering the behavior that the specification requires for specified components.
8:05:52
beach
So I see nothing wrong with creating new panes, new output records, new command loops, etc. that behave in new interesting ways.
8:10:06
slyrus_
back to my current hacky workaround... If I did want to call execute-frame-command with some sort of resize-window command, from where should I do that?
8:12:56
beach
Perhaps what is needed in this case is a new pane type that, when its region changes, triggers the execution of a command?
8:15:15
slyrus_
Yeah, but I'm not sure that my execute-frame-command approach really decouples the event and command loops they way you imply.
8:16:56
beach
You might want to check what happens when you click on an output record that has a presentation-to-command-translator.
8:30:31
slyrus_
Ok, but then I definitely don't want to be calling my resize-window command from note-sheet-region-changed
8:32:19
slyrus_
Not that it makes much difference, but we might want to call change-space-requirements with :resize-frame nil from window-clear
8:34:20
beach
Altering the behavior of specified components makes me nervous, which is why I keep suggesting specific components for specific behavior.
8:37:16
slyrus_
So, it looks like I have at least three problems: 1) figuring out how to (properly) trigger a command from an event, 2) figuring out which event should be triggering my resize command, 3) figuring out how to make the command do the right thing
10:55:22
john-a-carroll
slyrus: in my application, I synthesize a resize command (leading to a redisplay) from an :after method on allocate-space
10:57:04
john-a-carroll
slyrus: here's a gist - (defmethod allocate-space :after ((pane my-application-pane) width height) <check whether stream-text-margin is significantly different from last redisplay, and if so ...> (with-application-frame (frame) (execute-frame-command frame `(com-resize-panes ,frame))))
11:00:16
john-a-carroll
slyrus: I do this for a resizeable and reflowing file browser pane in a natural language processing research system called LKB - relevant source code at http://svn.delph-in.net/lkb/branches/fos/src/ACL_specific/selectfile.lsp
11:02:20
no-defun-allowed
Interesting technique. I should test it, but if I have scrolling, will the scrolling be reset?
11:02:37
john-a-carroll
In practice it seems to work reasonable well, and it also works in Franz Allegro CLIM
11:11:29
john-a-carroll
For me, the scroll position isn't reset - I'm happy with that behaviour but I don't recall whether I did anything special in that respect
11:14:42
john-a-carroll
I did have to explicitly call change-space-requirements to make the scroller update (either move to the correct position or prevent the pane being scrollable if the content ends up being smaller than the viewable region of the pane)
13:07:02
jackdaniel
regarding text reflow, I've linked a PoC video where text was rewrapped without redisplaying in realtime
13:47:22
jackdaniel
in general if we want to handle resizing gracefully, what we should do is to have outupt record replay more sensitive to its parent / previous sibling position
13:48:08
jackdaniel
also, as for "non-CLIM", we still have handle-event / handle-repaint which is implemented in lower level abstraction
13:48:22
jackdaniel
it is perfectly possible to use these to write applications which have nothing to do with a command loop
14:23:27
scymtym
froggey: i rebuilt and most things seem to work but i got a "Undefined function MEZZANO.COMPILER::%ARRAY-DIMENSION-KNOWN" from within the compiled function SWANK::RECURSIVELY-COMPUTE-MOST-COMPLETIONS
14:57:38
froggey
scymtym: oops, I'll investigate. for now you can just (defun mezzano.compiler::%array-dimension-known (array axis) (array-dimension array axis))
17:27:06
jackdaniel
https://github.com/dwmkerr/hacker-laws#kernighans-law [some cute laws, not necessarily something one should always agree with]
17:30:56
beach
My favorite is Hofstadter's law: It always takes longer than you expect, even if you take into account Hofstadter's law.
17:32:17
jackdaniel
Putt's Corollary is cheeky: "Every technical hierarchy, in time, develops a competence inversion."
17:34:23
jackdaniel
what explains completely and definetely how did I manage to have so much software under maintanance
17:45:36
slyrus_
john-a-carroll doesn't seem to be around at the moment but his approach is pretty much the same as a few variants I tried. The problem is you end up in a loop where the event loop keeps triggering the command loop, but he escapes out of it by checking to see if stream-text-margin hasn't changed. Not the most elegant. Will explore other approaches today.