freenode/#clim - IRC Chatlog
Search
22:38:30
fiddlerwoaroof
The other day, I was thinking about the various sorts of designators in CLHS: string designators, pathname designatores, etc. and I was thinking there might be a DESIGNATE protocol for them.
22:39:21
fiddlerwoaroof
Which made me wonder if it would make sense to package some of these things in their own systems that are consumed from McCLIM and other CLIM implementations
2:50:50
lonjil
I decided to make my own canvas animation: https://www.youtube.com/watch?v=I6nVHTYqifc
2:57:54
lonjil
cool. The way I did it is terrible and hacky, so I look forward to a much better solution.
2:59:31
lonjil
Every time #'draw-canvas-object is called on my pen, it compares the coordinates that the expressions eval to to the previous coordinates, and if they differ the new coords are added to the end of a list of coords.
3:05:10
lonjil
Inside draw-canvas-object, it starts by evaling the coord expressions, then if the list is nil, it just stores those coords. Otherwise, it draws lines for everything in the list, and at the end of the list, if the evaluated coords are unequal to the last pair of coords in the list, it adds the new coords to the end of the list.
3:06:43
loke[m]
draw-canvas-object shouldn't be tracking state. It should only draw a representation of what is available in Maxima variables.
3:07:19
loke[m]
The animation variables are just plain Maxima variables, with the difference that they are only defined within the execution of the animation functions.
3:08:10
loke[m]
So if you want to plot a set of raw coordinates, you should define an animation variable, and put the coordinates in that variable.
3:10:23
loke[m]
Add Animation Variable: foo. Initial value: []. Expression: foo : append(foo,[new-coordinate-here])
3:10:55
loke[m]
Then your draw-canvas-object will simply take the list stored in its dependent variable (foo) and plot it.
3:11:44
lonjil
Last time I tried to learn how to use it I got stuck not being able to ever find anything I needed in the manual.
3:13:40
loke[m]
The manual is quite good in my mind, but it's mostly a reference. I have been told there is a book though that is quite good. This one is recommended: https://www.cambridgescholars.com/product/978-1-5275-1117-0
3:22:40
lonjil
D'oh, I just realised that the altgr problem is still present, so I can't actually input [] haha
3:24:11
lonjil
For now I wonder if I could extend the completions listed with meta-s with chars like []. Annoying, but workable for testing.
3:25:29
loke[m]
The alt-gr part might be doable though, because that information isn't in the overly complicated part of xkeyboard. However, it still requires reimplementing a decent chunk of the keyboard management client-side.
3:39:34
lonjil
Happen to know where-abouts in Drei I would do that? If not you don't have to waste your time looking for it, I already added the characters I need to climaxima's character-picker.
3:40:50
loke[m]
lonjil: You're in luck. I do exactly that to make shift-return insert a newline. You can use the same trick: https://github.com/lokedhs/maxima-client/blob/master/src/maxima-syntax.lisp#L132
3:42:44
loke[m]
You might want to use a different command-table than maxima-table though. Just look for other calls to SET-KEY in the McCLIM code to see what the default one is called.
5:32:15
ck_
most recent commits were done by jackdaniel, but anyway I'd say that the whole sharplispers group is maintaining the repository
5:33:29
ck_
well -- maintaining it "occasionally" anyway, according to the group description https://github.com/sharplispers
5:36:36
beach
I would so like to see a version of CLX that is more CLOS-y and that emphasizes the render extension over the core X functionality.
6:23:59
fiddlerwoaroof
One strategy for CLX might be to look at generating code from the XCB xml files
6:25:08
fiddlerwoaroof
IIRC, that's how the newer C client libraries are generated, but it's been a while since I've looked into it: it might make more sense, at this point, to switch to a wayland compositor or something.
7:05:39
jackdaniel
I suspect that generating the code from xml could be encoded directly in a readtable too;
7:06:19
jackdaniel
either way using xcb files was discussed here in the past at least two times and the conclusion was: sounds good and seems like a good path forward if someone has time for that
7:08:23
jackdaniel
beach: re reusability of the clx frontend for different display servers, I think that is what we have the "silica" part of CLIM (and it is a better abstraction than x11-derived protocol)
7:27:43
loke[m]
The API simply gives you a way to download the keyboard definitions. All the event handling (simulated keyboard events) and keyboard lookup is client-side.
7:44:06
fiddlerwoaroof
loke[m]: if I remember correctly, the keycode -> character mappings are all in xml files
7:45:17
loke[m]
If you check the source code for xlib you'll see just how much code they have dedicated to keyboard stuff.
7:45:44
loke[m]
When you use xev to show keyboard events, those events are synthetically generated on the client side actually.
8:05:38
loke[m]
fiddlerwoaroof: That is correct. There is an X request that effectively sends that data (in a special, undocumented, mostly) format and then tells the client to deal with it.