freenode/#clim - IRC Chatlog
Search
10:05:38
beach
scymtym: It may need to be more modular as well. As I recall from Second Climacs, it was hard to use only some of the features.
10:13:18
beach
scymtym: What I am trying to say is that you should not look at the ESA code as being set in stone. As far as I know only two applications use it, namely (first) Climacs and Gsharp, both of which are kind of obsolete.
10:16:41
jackdaniel
ck_: please do (next time just ask, in the worst case scenario I'll tell you that you weren't allowed to ask ,-)
10:17:37
ck_
I meant, "is now a good time". OK here goes: you repeatedly say in your comments to "use defvar" -- I don't think we have the same perspective or reasoning
10:18:12
ck_
I wanted to preserve semantics locally while changing or moving as little code around as possible
10:19:01
scymtym
ck_: did you have time to look at my commit? i think moving code around may be the right thing in one of the two cases
10:19:06
ck_
also you comment "yes, people usually look for where the variable is defined, if it is only declared then it may be confusing.."
10:19:54
ck_
scymtym: I did and I thought I commented on it here -- also thought that you had that in the pipeline so I'd remove the part you already covered when I continued with my pr (which is right now)
10:20:43
jackdaniel
ck_:it is like with always use EQL camp on my side: it makes code simpler to read
10:21:03
ck_
jackdaniel: re/people look for the definition: I agree of course, but I didn't remove the defvar/defparameter definitions. the special declaimations I put in because those forms occur at a later time in the asdf order; anybody M-.'ing will arrive at that form
10:21:36
jackdaniel
I'd rather move defvars earlier than declare them beforehand but this is fine too I suppose
10:23:43
scymtym
ck_: sorry for the miscommunication. i thought since you were taking charge, you could incorporate my change into your pull request
12:03:09
scymtym
jackdaniel: thanks. i haven't thought about it. i guess, as long as credit is given and the content is not framed inappropriately, i have no objections
12:05:21
scymtym
jackdaniel: now i'm curious, though. would you provide a link to the social media post?
12:08:58
scymtym
the protocol and client side are already a little different from the original GTK version, but your description is still accurate
12:14:33
no-defun-allowed
Whoa, that was quick...weren't you just drawing boxes not long ago, scymtym?
12:17:08
scymtym
no-defun-allowed: yes. check https://techfak.de/~jmoringe/mcclim-broadway-{1,2,3,4,5,6}.ogv for progress over time. however, those don't show the whole story, since you can't see the protocol spoken between client and server
12:22:27
no-defun-allowed
It still seems magical that someone could write a backend for a graphics toolkit in less than a month.
12:24:14
scymtym
the protocol or protocols rather are one of the harder parts. especially since GTK changed their approach (and protocol) entirely at one point and still called it "broadway 2.0"
12:24:59
jackdaniel
no-defun-allowed: CLIM's protocol complexity is overestimated while an effort to bring a prototype to a usable shape is usually underestimated
12:26:21
scymtym
regarding implementation speed: keep in mind that i didn't have to write the javascript client from scratch - i just adapted it a bit. also, the backend uses off-screen rendering, then transfers pixels in a smart way, so i didn't have to implement rendering, "just" what amounts to a streaming video codec
12:27:53
scymtym
jackdaniel is totally right. if what i have now is one unit of work, getting to a usable backend is probably five or more units of work
12:41:59
jackdaniel
we could create a medium-crutches-mixin which draws everything using medium-draw-point* method unless specialized further :-)
12:42:55
scymtym
i think i made a significant improvement to the render backend's speed, but i haven't benchmarked it
12:43:19
ck_
wow, I think that working on that issue has left some scars. I just caught medium-draw-something* and my pulse went up
12:46:54
scymtym
not recompute the foreground "ink" unnecessarily: https://github.com/scymtym/McCLIM/commit/7ec10701c86c8c7a75b10f0806106b71eca526ab
12:48:10
jackdaniel
my main focus last time I've worked on this code was to reduce insane macrology used there without caring much about performance at the moment
12:49:02
scymtym
i'm prepared to throw that work away. i just needed the thing to be faster so i could work properly on the backend
12:51:12
jackdaniel
just saying that I might have degraded performance significantly while removing #1=(writing-code . #1#) macros
12:57:56
jackdaniel
scymtym: 1ae81284184dd6d5eabd53b2d6ede6493fcce2c5 (branch origin/medium-transformation-fixes -> origin/master)
12:59:12
jackdaniel
ck_: n.b this very merge impacted the osx performance, namely implementing transformed-patterns
15:36:19
ck_
hmm, M-x whitespace-cleanup also converted the tabs. I guess someone will complain about that -- better revert that part of the changes.
15:43:58
beach
My personal thinking is that I will (over time) convert all my code so that there are no more TABs in it. And I set the Emacs flag that makes TABs no longer used, so all new source code I write is TAB free.
15:55:32
jackdaniel
I know it makes git history somewhat polluted otoh our "official policy" is to not use tabs
19:35:14
ck_
I think the xlib macro that was supposed to be mentioned was WITH-STATE -- if you wrap code manipulating a drawable in it, there's this alist *window-attributes* that caches the value for a whole bunch of things.
20:05:45
scymtym
|3b|: i think it is similar to the X root window, i.e. the parent of top-level sheets. i have seen the hierarchy visualized as port -> graft -> top-level-sheet -> other-sheets
20:05:47
|3b|
i guess mostly just an CLIM thing, not a backend thing. should it map to entire desktop or to a specific monitor?
20:10:43
|3b|
i guess theoretically it should map to monitor since it has physical dimensions, but in practice probably to entire desktop, since i don't see anything to specify monitors, or handle windows spanning them
20:13:08
scymtym
i don't know whether that works in practice with frame sheets spanning multiple grafts and whatnot
20:35:01
jackdaniel
but in principle they should provide a transformation from the sheet coordinates to the native coordinates
20:36:33
jackdaniel
and transformation associated with that graft transform coordinates to whatever is assumed by medium as input
20:37:19
jackdaniel
in practice though in McCLIM grafts are only used for probing screen properties (i.e pixels per mm)
20:57:56
|3b|
jackdaniel: how should "screen properties" be interpreted with multiple monitors on 1 port?
21:00:56
jackdaniel
that's a hard one. I did think about that when I was looking for a consistent model with multiple monitors with different dpi (I want to make dp a default native unit)
21:01:58
jackdaniel
one could stipulate, that each screen has a separate graft, but what about sheets which are moved between screens (and i.e part is on one and the other is on another)
21:03:23
jackdaniel
you would have to duplicate frame panes (as in: regenerate them) with different pane and render frame twice with a clipping region until we move onto one
21:03:57
jackdaniel
then you'd have a funny effect of the same window on different monitors with the same physical size but with a different resolution
21:05:19
|3b|
not sure 2 os-level windows would work well, would be hard to keep them synchronized, and borders at screen edge would be odd, + extra decoractions etc
21:06:29
jackdaniel
either way I did not come with anything yet with this regard except: take the first screen and pretend all have the same properties
21:07:39
|3b|
so for graft size in MM/inches, calculate PPI of primary monitor and then multiply by total size of desktop?
21:10:56
jackdaniel
currently McCLIM assumes pixels, so it doesn't matter (you are not interested in mm/inches)
21:11:07
jackdaniel
when we switch to dp (density independent pixels) then it will make a difference
21:11:55
jackdaniel
and given how fast things move in open source world it will assume pixels for quite a while ,)