freenode/#clim - IRC Chatlog
Search
10:33:03
jackdaniel
given no reply in the issue thread regarding ci, I think that he would not oppose replacing it with something else either. if it were me doing that (I'm not planning to; it would take ages for me to setup that), I'd try to integrate github and your jenkins setup
10:33:24
scymtym
by the way, i revived the stopwatch demo in some branch. not sure which timer event scheduling method i used
10:35:43
scymtym
which seems more idiomatic than the timed-condition-waiting-in-a-thread stuff it does
10:36:33
jackdaniel
schedule-event did not work until august last year when I've refactored input module
11:19:23
scymtym
jackdaniel: is STREAM-READ-LINE implemented for extended output streams? or is it inherited from gray stream defaults?
11:42:58
scymtym
should this work, then? (stream-read-line (allocate-instance (find-class 'clim:extended-input-stream)))
11:43:48
scymtym
ok, same result for (stream-read-line (allocate-instance (find-class 'climi::standard-extended-input-stream)))
11:45:04
scymtym
in any case, wouldn't the inherited method attempt to construct a vector of CHARACTERs, not INPUT-GESTURE-OBJECTs?
11:45:12
jackdaniel
as I've noted in the comment, fact that seis implements stream-read-char and strema-unread-char is due to accept methods making invalid assumptions
11:47:17
jackdaniel
in other words, accept methods should call stream-read-gesture and deal with the input-gesture-object by either rejecting it or utilising in some other way
11:47:53
jackdaniel
(and a method stream-read-char on eis does exactly that -it rejects non-character gestures stored in the input buffer)
11:48:21
jackdaniel
previously it was even worse, because events which were not characters, were simply rejected without calling handle-event on them
11:48:43
jackdaniel
right now it is not the case, each event which is enqueued for a stream is handled, and only after that appears (or not) in the input buffer
11:50:23
scymtym
can we fix ACCEPT as the first commit in the pull request and sidestep the problem?
11:53:54
jackdaniel
two things: that will require reviewing carefully all accept methods and there may be existing code which is not part of McCLIM codebase which does that
11:54:25
jackdaniel
so these methods will stay at least for a while, and fixing accept methods is not the gist of this architectural change
11:55:07
jackdaniel
the part which required actual fixing was input-wait-test/handler and pointer-button-press-handler
11:56:07
scymtym
sounds like ACCEPT and scigraph also require actual fixing since they violate the protocol. but ok, later then
11:57:04
scymtym
so STREAM-READ-LINE not being implemented for extended input streams shouldn't be a problem because they are not supposed to be character input streams, right?
12:03:34
jackdaniel
I agree that we should fix accept and scrigraph at some point; what I'm saying is that refactoring input streams only made some issues explicit and some solutions possible - fixing/implementing is something what comes after
12:09:23
scymtym
that's ok as long as we remember/have documented the required information when we get to it
12:10:41
jackdaniel
I'm defining now few smoke tests, but they do not check interactions with the event queue
12:23:12
jackdaniel
I've pushed a change to the stream-process-gesture on standard-input-stream to allow also appended characters
12:24:05
scymtym
jackdaniel: i would like to put DEFINE-APPLICATION-FRAME and code related to the macro into a separate file. does that sound ok?
12:28:17
jackdaniel
stream-process-gesture, when returns NIL, signals that stream-read-gesture should try to read the gesture again
12:28:41
jackdaniel
previous version worked like this: (if (keyboard-event-which-is-the-character) return-character return-nothing)
12:29:04
jackdaniel
current version is (if (character-or-the-keyboard-event-which-is-the-character) return-character return-nothing)
12:29:35
jackdaniel
so when someone does: (climi::stream-append-gesture stream #\d) it won't block (because process-event will reject the character)
12:30:08
jackdaniel
this could happen also without using internals, i.e if someone had called stream-unread-gesture - then it could not have been read from the character input stream
12:31:26
scymtym
nitpick regarding the test (which i generally greatly appreciate, of course): fiveam's IS wants the expected value as the first argument to the predicate
16:22:00
scymtym
jackdaniel: in the accepting values test in accepting with gadgets, the text editor gadget no longer works. i think it used to work. seems like a possible regression caused by the stream input changes
16:31:45
scymtym
still able to reproduce but with local changes which i thought were unrelated. let's see whether they really are
16:45:01
scymtym
still narrowing it down, but i found something else in the process: start av test, right-click into text editor => nothing happens. start stream test and just leave it there, start av test, right-click into text editor => av test closes, stream test behaves as if right-clicked
16:52:22
jackdaniel
indeed, interesting. If I had to make a wild guess, I'd blame drei for doing something "clever"
16:53:42
jackdaniel
one of my next steps is to replace drei-based default input-editing with something more mundane. as it happens, I'm currently investigating drei. in its display function it tries to replay the cursor without adding it to the stream first, what break if we first display, then replay the content
16:55:35
scymtym
could also be related to running multiple frames in the same command loops. there are tons of bugs with that
16:57:14
scymtym
some problems are due to *APPLICATION-FRAME* being bound to the wrong frame in certain contexts
16:59:15
scymtym
frame redefinition stuff is ready with one unsolved problem, but i guess i can leave that unsolved for now
18:44:40
jackdaniel
I'm still not enthusiastic about introducing a new metaclass for application frames, but I'll try to take a fresh look tomorrow
19:29:10
ferada
hi all, so for mcclim, is there anything i can set to have no flickering / double buffering on for everything?
19:31:47
jackdaniel
ferada: you may use unsupported interface climi::with-double-buffering, there is no advertised interface
19:35:15
scymtym
WITH-DOUBLE-BUFFERING is a hack though. there is unfinished work for double buffering, but it is not ready yet
19:43:35
ferada
layout-wise, i'm kind of missing the ability with the tiling to change the size of one part from the initial ratio
19:45:33
scymtym
change manually as in during runtime of the program or as in via something in the DEFINE-APPLICATION-FRAME form
19:46:42
ferada
change manually as in hover over the small area between the two widgets and, well, resize it with a mouse
19:47:53
scymtym
add (make-pane 'clime:box-adjuster-gadget) between the pane declarations in the layout
19:48:13
scymtym
like (vertically () FIRST-GADGET (make-pane 'clime:box-adjuster-gadget) SECOND-GADGET)
20:16:49
ferada
mhm the list-pane displays a list of items, but there's no grid-pane that can do the same in a grid layout, is there? i see there's a grid-pane, but it's doing something different
20:18:35
ferada
actually i was more looking for something like gtk's iconview, taking a model (well, list of things) and display it grid-like
20:19:08
ferada
but the list-pane has the presentation-type-key, which would be really cool for that
20:23:23
ferada
apropos model, to update the list in a list-pane, you've to set it again, there's no notification to tell the gadget the list was modified, is there?