freenode/#clim - IRC Chatlog
Search
8:30:07
scymtym
loke: i made this for configuration: https://github.com/scymtym/configuration.options . while it is probably too heavyweight for your use case, maybe it has some ideas you could steal
8:34:39
scymtym
loke: i prototyped graphical editors with one of the cl-gtk systems at one point, so it is likely possible. but not built-in
8:37:08
scymtym
but i really doubt using the system as-is would be a good idea. as i said: it is probably too heavyweight w.r.t. scope and dependency footprint
8:48:15
scymtym
loke: https://github.com/scymtym/configuration.options/blob/wip-gtk/src/gtk/editor.lisp#L107 is the old GTK prototype
14:31:23
oleo
when i have a field like :background and i try to put a space after it my whole listener window moves with it....
15:19:31
loke
Or should I simply add a MEDIUM argumen insted? It makes sense all of it is available.
15:20:09
jackdaniel
usually font-draw-glyphs is called from (draw-text sheet), which calls (medium-draw-text medium), which calls some internal cruft, like (font-draw-glyphs :transformation (medium-transformation medium))
15:20:40
loke
jackdaniel: Right, that's what it does now, after I added that :TRANSFORMATION argument ot FONT-DRAW-GLYPHS
15:21:20
loke
The alternative would be to simply pass theMEDIUM itself to FONT-DRAW-GLYPHS, so that FONT-DRAW-GLYPHS can do whatever it wants.
15:22:05
loke
Right, but in the case of FONT-DRAW-GLYPHS, the actual low-end implementation needs access to the transformation.
15:22:37
loke
So the only question is, should MEDIUM-DRAW-TEXT pass the medium or just the trnasformation to the low-level function (FONT-DRAW-GLYPHS)
15:22:49
jackdaniel
my point is: it is up to the internal implementation and medium-draw-text* to decide, how it passes and where
15:23:14
loke
jackdaniel: It's not, since MEDIUM-DRAW-TEXT* is the higher-level functionb, and only FONT-DRAW-GLYPHS is part of the font rendering protocol.
15:23:53
loke
I.e. when implementing a font renderer, you implement FONT-DRAW-GRLYPHS specialised on the font type.
15:24:20
jackdaniel
medium-draw-text* is specialized on medium type which is usually backend-specific
15:24:23
loke
This function needs the transformation now, but the question is if it makes more sense to make this protocol simply pass the entire medium.
15:26:28
jackdaniel
it looks more like sibling-level, but whatever. I'd pass just transformation unless you really need more from the medium
15:27:08
jackdaniel
sibling-level, because render may be reused in other backends, so it is not lower, rather orthogonal moving part
15:27:31
jackdaniel
not really, truetype has some code for clx integration, but in principle it may be used anywhere
15:27:41
loke
I gouess it would be possible to somehow break out the CLX_specific parts, but I feel it would be much more work than it's worth.
15:29:14
jackdaniel
I'd like to see more code share between truetype and freetype (at least on higher abstraction level), it seems to me like you are implementing similar thing in different directory. I didn't look at code hard enough to be sure yet though
15:30:25
jackdaniel
more lines of code to maintain is a bigger hassle for me, and fixing the truetype renderer would be a double gain
15:31:00
loke
The problem is that I'm relying very much of the interactions between harfbuzz, fontconfig and freetype.
15:31:38
loke
All my code is separated into two packages (harfbuzz and fontconfig). The entirety of the freetype renderer is in a single file, freetype.lisp.
15:33:43
jackdaniel
from the lisp-unrelated topics, I've just heard that rhinos are in fact a war-unicorns, and this name is amusing :-) I need to grab something to eat and record the gadget screencast. be back later o/
15:33:46
loke
I guess it would be possible to take the existing rendering code, and then plug in simpler (or even stubbed) version of the shaper and fontmanagement stuff so that the rendering loop is using the same code.
15:34:30
loke
That's certainly something that could be considered, and that would get rid of the old truetype renderer alltogether.
15:35:32
jackdaniel
as I have mentioned (multiple time) unless we have portable CL implementation of truetype which is better than the current one, we won't get rid of it - as in - we won't rely by default on ffi bindings for that
15:35:48
loke
But even if I were to do that, the truetype renderer would have no transformation, no hinting, no subpixel sampling, no shaping (i.e. composite characters will be empty boxes), no right-to-left rendering, etc...
15:36:46
loke
But sure, I can look into that, once everything works as well as possible with the FFI renderer.
15:37:20
jackdaniel
sure, that's fine. having simple implementation and extension providing better functionality sounds like a good plan (maybe by class inheritance? or having the same protocol and general algorithm working on this protocol)
15:38:00
loke
jackdaniel: I don't know. I'll have to spend some time prying these things apart first.
15:39:01
loke
This is the core rendering loop: https://github.com/lokedhs/McCLIM/blob/freetype2/Extensions/fonts/freetype.lisp#L241
15:49:00
slyrus_
loke, the other place it would be nice to have transformed text (and shouldn't be too hard) is the PDF backend.
16:15:08
pelle
trying to load McCLIM in CLisp via Quicklisp, but getting this: SYSTEM::%FIND-PACKAGE: There is no package with name "ASDF-USER"
16:15:54
slyrus_
or a quicklisp problem. have you deleted the quicklisp/local-projects/system-index or whatever it's called?
16:17:12
loke
However, one thing does not make sense... What is CLIM:TEXT-SIZE supposed to return for transformed text.
16:17:30
jackdaniel
clisp has old asdf bundled, and our beloved build manager changes every two years beyond repair
16:18:46
loke
pelle: And easier solution is to change to a different CL. You can't go wrong with SBCL, but abong the others that works very well is CCL and ECL.
16:19:59
loke
jackdaniel: The CLIM spec doesn't address the results of TEXT-SIZE on transformed text.
16:20:22
pelle
@loke: I'm on Alpine Linux (because of a weird laptop that wouldn't install Debian or anything mainstream) and the SBCL in Alpine can't install Quicklisp. So just trying some other ones out
16:22:18
loke
jackdaniel: Well... the question is if TEXT-SIZE should return the dimensions of the resulting text box after transformation?
16:22:55
jackdaniel
you are interested in text-size, not text-size after (For instance) clipping, or scaling etc
16:23:31
pelle
jackdaniel: cool. ... and finally - why I'm bringing it up here on this channel - ECL is fine with CLIM also?
16:25:38
pelle
jackdaniel: cool. ok, Alpine Linux has some weird packages. In ECL when loading Quiclisp, it says: COMPILE-FILE-ERROR while compiling #<cl-source-file "quicklisp" "package">
16:27:33
jackdaniel
so it makes sense to install only library (if you don't plan to develop, just deploy already compiled modules)
16:36:27
beach
jackdaniel: So shall we ask the Common Lisp foundation for money for McCLIM development?
16:53:37
jackdaniel
beach: I think that one fundriser at the time is better for CLF, and they are working on ASDF atm
16:54:21
jackdaniel
also we have some funds on bountysource with a steady stream of $288/month (and we have around $1800 at our disposal atm), so we have plenty for bounties at the moment
19:03:22
fittestbits
jackdaniel - earlier you were talking with loke about architectural levels (medium vs font rendering) - is there a diagram/drawing that shows the architecture of mcclim?
19:10:16
jackdaniel
I've build some intuition around that, but it is not complete yet. when I'll be certain about some things (probably *after* finishing charming-clim and adaptable sheets), then I'll write such documentation