freenode/#clim - IRC Chatlog
Search
4:42:18
loke
beach: I'l thinking about building a simple configuration system for mcclim that can be extended later.
4:44:27
loke
beach: In my case right now? Fonts, and hinting behaviour. Other things I've considered are things such as default colours, default sizer of things (fonts, buttons). Other things would be things like language settings, number formats. How being able to configure scrollbar locations, etc...
4:46:06
loke
I was thinking about doing a prototype implementation. Should I just build that as a stadnalone project?
4:47:41
loke
I don't know. I want to base it off of the ideas in the öcustomise” framework in Emacs. You define customisable variables. Emacs has a macro ‘defcustom’ for that purpose. A customiseable variable has some metdata, sych as validator functions, documentations and callbacks that are called when their values are changed.
4:48:13
loke
Customisable variables are grouped in, well, groups, so that you can browse all the settings.
4:49:16
loke
(clim:define-customisable-variable KEYWORD-COLOUR :type COLOUR :group SECOND-CLIMACS :documentation "The colour of keywords in a Lisp source file")
4:49:55
loke
and then a gui to choose the colour would be automatically provided by the :type thingy
4:50:52
beach
2. the group could use the Common Lisp package system for its name. Emacs Lisp does not have packages.
4:54:41
loke
So if a variable value is of type ‘font’, there should be a trsentaion method for customisable fonts that displays an example and provides a meny to choose a different value.
4:55:42
loke
The question then is: When using such a value, what should the API be? I have two choices:
4:58:45
loke
Or... should the config system manage this stuff, and load the valued on demand and stuff, and I simply use symbols to refer to the variables?
4:59:42
beach
However, keep in mind that Emacs Lisp does things in certain ways because it lacks features that Common Lisp has, such as packages, CLOS, etc.
5:00:43
loke
Using method 1 would make it easy to write custom method by specialising on (EQL 'NAME)
5:02:47
loke
But am I to assume you're OK with the idea of a universal config system, allowing you to have a program that visualises the settings and provides a single interface to perform this configuration?
5:03:14
loke
DEFINE-CUSTOMISABLE-VARIABLE would register the variable in a repository so you can get a list of all such values.
5:04:31
loke
This was all kicked off by me needeing a good way to store the HINTING preference. I can't just have it as a DEFVAR since the value needs to be set before any fonts are loaded. Setting it later have no effect. But, if I have a callback when the value is changed, I can flush the cache at that time.
5:04:58
loke
ALso, I realise that I need to make the font tyypes (:FIXED, :ROMAN, etc...) customisable. But to do that you need a graphical way to choose fonts.
5:07:13
loke
Another alternative would be to have the customisation system referring to an underlying DEFVAR. In other words, when reading the vfalue, you'd just read the value of the *FOO* variable normally, and the customisation system would simply do (SETF (SYMBOL-VALUE '*FOO*) ...) when setting it. The benefit of this would be that you could retrofit config editors on top of existing DEFVAR's without having to change the code that uses them.
5:10:24
loke
Yes, and I always struggle with them. Sometimes to the point where I need medication. :-)
5:11:11
loke
It's not too bad. But I can end up it a situation where the fear of maging a bad choice precludes me from making a choice at all.
5:13:35
loke
Wait a second... I realise a problem with the idea of purely using the symbols and pacakges... Maybe...
5:13:52
loke
What if I need to manpulate configuration values for a package which has not been loaded?
5:42:54
loke
panji: You can make it OVERRIDE-REDIRECT and make the dimensions the same as the screen
5:44:05
loke
panji: You override the function CLIM-EXTENSIONS:FIND-FRAME-TYPE for your application frame, and return :OVERRIDE-REDIRECT
5:51:12
loke
(defmethod clim-extensions:find-frame-type ((frame name-of-your-application-frame-here)) :override-redirect)
6:10:29
jackdaniel
loke: if such configuration is meant to be a lisp code then it is not a configuration file but a program
6:11:50
jackdaniel
and it looks more like you talk about some theming, not configuring McCLIM. I think that this kind of thing should be done on pane-realizer level
6:13:03
jackdaniel
then you are free to change abstract pane names (like push-button) with concrete implementation (like lokes-push-button or generic-push-button or material-push-button)
7:27:37
loke
I.e. not necessarily system-wide setting. There is nthing wrong with using the same framework for application-level configuration.
7:30:17
jackdaniel
well, I see a strict distinction between something executable and a configuration / description
7:30:43
jackdaniel
for instance: it is a great pita, that ASD require full Common Lisp and ASDF to be parsed
7:41:22
loke
jackdaniel: SInce there needs to be a way to manipulate the configuration without loading the packages that the config belongs to, I can't use packages. If it will use symbols, then they will have to belong to a different pacvkage (not really a problem)
7:42:06
loke
I.e. the datatypes will be limited to the basic atoms in sexprs, or combinations thereof.
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.