freenode/#clim - IRC Chatlog
Search
7:30:19
scymtym
jackdaniel: should i make my commits for the ieh-2 pull request available? you could cherry-pick them on top of the current commits
7:34:43
scymtym
most commits are self-contained and shouldn't be squashed, i think. but i'll have to rebase and reorganize a bit first
7:39:09
jackdaniel
I'll switch the context then. I may be unavailable between 12-13cet, and then I'll be around until 4pm, tomorrow I'm leaving for a few days (but it is possible that I'll have internet access there)
7:40:04
scymtym
jackdaniel: i wrote the exact same code for SHALLOW-COPY-OBJECT :) but we both missed that there is no need to cons up the list of slot names
7:43:32
scymtym
oh, i suggested that code in the review comment. my brain is clearly not made for discussions that last several days
8:41:17
scymtym
while waiting for my meeting to start, i found a something in my changes that can probably be simplified further. i'm also writing comments and proper commit messages. so will take a little while
10:57:04
scymtym
jackdaniel: i added https://github.com/McCLIM/McCLIM/commit/3c0fd1ce47341e5135f409d8e00fd63219e1a4e5#r35018969 . i don't know whether you got notified since i couldn't add i as a review comment
11:05:53
jackdaniel
scymtym: the intention was to handle nil (previously it was just (or new-class (class-of event)) what worked fine with change-class
11:06:17
jackdaniel
I will make it just (if (null new-class) (class-of event) (find-class new-class))
11:09:18
scymtym
thanks. i'm busy with something else now. i'll try to finish cleaning up my commits after that
12:13:19
ck_
when expanding something in clousau, the scroll panes are not updated and still seem to reflect a smaller display. Is that something to do with a mangled state wrt. my cache, again? Or is it a known issue
12:46:40
scymtym
there is a McCLIM-wide failure mode in which moving scroll bars does not move/repait the contents of the viewport properly. this problem can be fixed by deleting all McCLIM-related files from the ASDF cache. the issue you describe sounds a bit different, though
12:54:44
ck_
ah, but I'm talking about the other way around: the viewport grows, the scrollbar doesn't shrink. same thing?
12:56:59
scymtym
i'm not sure. i'm trying to reproduce i now. which branch are you seeing this with?
12:58:20
scymtym
yeah, just making sure. that branch shouldn't have any changes related to scrolling or stream panes
13:25:45
jackdaniel
if I may suggest something, implementing make-design-from-output-record would be cool
13:26:04
ck_
one is at night though, so go easy on the deep-thought requiring tasks for that one :-)
13:31:21
ck_
oh which reminds me, I wanted to maybe get a triangulation algorithm as a printout, in case there's more time. I will probably be offline until the end of the week
13:32:00
ck_
oh, and after that: new job / less mcclim. Thanks for taking me in, jackdaniel and everyone. It has been fun.
14:40:33
jackdaniel
I will push one small thing to master (I'm absolutely certain about it, it is argument order typo)
14:44:01
jackdaniel
open question: do we have a way to specify text-style size to have a specific width/height in pixels?
14:45:54
ck_
scymtym: you're really remarkably fast with this. My compliments. When we were looking at that draw-pattern slowdown, I spent hours on it. You took one look.
14:49:40
scymtym
ck_: thanks. i try to always use the right tools (TRACEing the working and the broken versions and comparing in this case) and if they don't exist, make them
14:55:42
scymtym
in the failing case, *INHIBIT-DISPATCH-REPAINT* is bound to T where it is NIL in the working case. that explains the symptoms perfectly. now the question is where that binding is coming from
14:56:24
scymtym
since this happens after reloading, i bet this is some DEF{VAR,CONSTANT,PARAMETER} thing
14:57:23
scymtym
yeah, shouldn't be too hard to track down from here unless something really weird is happening with thread-local vs. global values or something like that
14:59:26
scymtym
we still have to find he culprit and arrest them from illegally binding a special variable
15:35:53
jackdaniel
as mentioned before, I probably won't be around for another few days. I don't have objections if you push to my branches and merge the changes, but if you'd rather like me to do it then I'll attend to it when I'm back
15:37:37
scymtym
jackdaniel: thank you. i have a few more things o investigate in that branch so i might not be done before you get back either way
15:40:13
scymtym
the repaint thing seems pretty crazy. i am now almost convinced that the "working" case only works because we load our source files in the wrong order. if i'm right, loading sheets.lisp after repaint.lisp will make the problem appear always
15:40:57
jackdaniel
I think there were pretty big changes to these parts when clx-fb backend was introduced
15:41:39
jackdaniel
I don't know that changes well since I didn't write them, so I won't be able to comment on particular changes
15:47:19
scymtym
this could be a cascade of bugs. inhibiting the repaint at one point could be fine since there seem to be provision for repainting in a different place, but that one doesn't seem to repaint either
15:48:45
jackdaniel
I gather tht a preferable fix is to introduce a bug covering the topmost one? :)
15:50:11
scymtym
jackdaniel: the current state was introduced in 7381436e84be202bebfe01053f47a3f4688616bd, 2018-03
15:50:55
scymtym
what i don't understand is why we don't get SBCL warnings for binding a lexical variable that looks like a special variable
15:52:27
scymtym
once you know where to look: "caught STYLE-WARNING: using the lexical binding of the symbol (CLIM-INTERNALS::*INHIBIT-DISPATCH-REPAINT*), not the dynamic binding, even though the name follows the usual naming convention (names like *FOO*) for special variables"
15:57:26
jackdaniel
I can only provide my best guess: when you have resized the top-level sheet regions were changing in a cascade what have triggered addtional repaints
15:57:59
jackdaniel
(in case of unmirrored hierarchies that would lead to repainting the same sheet multiple times)
16:15:36
scymtym
jackdaniel: i see. maybe restricting the inhibition to a smaller region would be a proper solution but i don't understand the situation very well yet
16:42:29
scymtym
maintaining a list of delayed repaints (sheet and regions) and executing them as a batch after leaving the inhibited region seems o work pretty well
18:13:06
scymtym
when inhibiting around LAYOUT-FRAME, it can easily collect 10 sheets with up to 5 repaint regions for each sheet
18:14:23
jackdaniel
but do we want these repaints? did inhibiting made repaint miss some damaged region?
18:15:27
scymtym
yes, changing the mechanism added in 7381436e84be202bebfe01053f47a3f4688616bd so that it actually works causes sheets to not be repainted when they should be
18:17:38
jackdaniel
sometimes I have an impression that I'm improving McCLIM, but then I look at all regression I've introduced and I have doubts about the netto value of that
18:17:45
scymtym
when i was bored last night, i started recreating my GTK theme: https://techfak.de/~jmoringe/mcclim-dark-theme.png
18:18:55
scymtym
jackdaniel: well, McCLIM can be a difficult codebase to modify. not as difficult as SBCL, though
18:19:46
jackdaniel
I have some notes for abstraction for theming which will align well with material guidelines
18:20:22
scymtym
jackdaniel: also, i doubt that others (including myself) would have become interested in contributing to McCLIM without your work
18:21:12
scymtym
don't worry, i'm not seriously working on themes. i was just playing around and hacked everything instead of doing it properly
18:21:30
jackdaniel
color-wise it uses indirect inks (possible we could think of a similar protocol for line styles and such)
18:24:19
jackdaniel
but what mostly accounts for a theme are line styles, colors, text styles and such
18:25:26
jackdaniel
and if we had used for all that things like +primary-foreground-ink+, +primary-line-style+ etc (and secondary), then changing the visual appearance could be done without touching any gadgets
18:30:12
scymtym
if a "theme" controls colors, line styles, border widths, etc. maybe a separate "look" is needed since things like 3d vs flat or [x] vs ( O) for toggle buttons cannot be controlled by simple scalar parameters
18:32:06
jackdaniel
like you may use any ink for drawing rectangle (not necessarily +foreground-ink+, but say +red+) gadgets may use what they prefer, the thing with theme is to provide some defaults which application can (but doesn't have to) use
18:34:09
scymtym
yes, that would be useful. don't the current gadgets do that to some extent with *3D-LIGHT-COLOR* and friends?