freenode/#clim - IRC Chatlog
Search
9:39:21
jackdaniel
I'm going to merge the cleanup panes PR, it is not controversial and will reduce number of pr's by one
9:40:30
|3b|
yeah, cl-opengl works with cl-sdl, glop, glfw, direct OS calls etc (just not things like CLX that skip ffi completely)
9:52:39
scymtym
jackdaniel: shouldn't *DOUBLE-CLICK-DELAY* be in events or input? the description sounds like it is intended to be used when producing (the currently unimplemented) POINTER-DOUBLE-CLICK-EVENT
10:06:59
jackdaniel
I was contemplating removing the parameter whatsoever and inlining the value in the gadget implementation, but that would involve semantic changes (so to speak), while I've tried hard to make it only a cleanup of file organization
10:10:32
scymtym
i assumed as much, but it seems like the intention was using it for POINTER-DOUBLE-CLICK-EVENT which we should implement at some point (it is in the specification)
10:11:27
jackdaniel
I do not contest that, when it is implemented then the parameter may be moved and options-pane implementation properly adjusted
10:24:59
jackdaniel
n.b we have an internal generic function frame-schedule-timer-event without 1) any implementation, 2) nobody uses it; I've just noticed that
10:27:26
scymtym
i don't know what the right way forward with respect to CI is. i can generate a very good setup for Jenkins which catches this sort of thing, tracks warnings, runs and asses tests and even builds the documentation, but the barrier seems to be too high for people to at it at all. GitHub's stuff, on the other hand, is convenient and accessible but cannot (without insane hoop jumping) do nearly as much
10:30:01
scymtym
because things stop working properly if GitHub doesn't work OR the Jenkins stuff doesn't work
10:30:36
jackdaniel
sure, but being able to see warnings directly in the pull request (or being referred to do so) greatly improves experience of using CI
10:30:57
scymtym
maybe nisar wants to extent his recipe based on the one i made available. that would give us something in between
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