tynet-lichat/shirakumo

7:42:46 shinmera zyd: it looks like you're catching a bad first frame before the camera is fully set up or something

9:18:26 shinmera scymtym: switched the trial-ide parts to not use trial as a backend, should be faster to start up now

9:53:19 Hugo morning

10:49:21 Colleen Shinmera: i haven't used feedback before. should the todo items be entered into the ide track?

10:49:21 scymtym Shinmera: i haven't used feedback before. should the todo items be entered into the ide track?

10:49:42 shinmera scymtym: alloy track, unless it's specific to the IDE's features

10:49:53 shinmera I haven't added stuff to the IDE track yet

10:57:34 Colleen ok. but simple issues and prs still go to codeberg?

10:57:34 scymtym ok. but simple issues and prs still go to codeberg?

10:59:02 shinmera scymtym: if you like, though you have push access to all the shirakumo repos

10:59:28 shinmera feedback is just a lot faster to manage things with, especially smaller items that you might notice here and there and want to communicate or note down so you don't forget about them

11:01:34 Colleen ok, let me try

11:01:34 scymtym ok, let me try

11:22:17 shinmera I'll take a look at the keybinds next, since changing stuff like DEL to a keybind (that's broken) now makes it impossible to delete text and whatnot

11:53:28 shinmera scymtym: for example, the palette system thing was already a ticket here: https://feedback.tymoon.eu/trial/entry/$2xc

11:53:41 shinmera you can add comments and long descriptions and so on, so it's a fully fledged bug tracker

12:09:29 Colleen i see. i will focus on the code for a bit. i still aim to push my changes today

12:09:29 scymtym i see. i will focus on the code for a bit. i still aim to push my changes today

12:19:39 shinmera it's creating the action events but they're not being handled for some reason, what the heckkkkk

12:23:55 Colleen i don't know the context but for text-input-component there is handle vs. handle-using-state

12:23:55 scymtym i don't know the context but for text-input-component there is handle vs. handle-using-state

12:24:02 shinmera oh, cause of -- yes

12:24:15 shinmera I didn't realise the :around method was redirecting *everything*

12:25:01 Colleen yeah, that part is not great. if you have a better solution, feel free to change it

12:25:01 scymtym yeah, that part is not great. if you have a better solution, feel free to change it

12:27:28 shinmera okey, pushed a preliminary fix

12:29:37 shinmera not sure during which states the action mappings are correct or not

12:30:17 shinmera will take a look at the animation system later today

12:38:11 Colleen yeah, there will be some churn in text-input.lisp. i added preliminary classes for separating "actual" text input like the code editor from things like wheel. the difference is that "actual" text input classes cannot update the component value for every keystroke

12:38:11 scymtym yeah, there will be some churn in text-input.lisp. i added preliminary classes for separating "actual" text input like the code editor from things like wheel. the difference is that "actual" text input classes cannot update the component value for every keystroke

12:38:35 shinmera right

12:38:52 Colleen rebase is done. let's see what broke

12:38:52 scymtym rebase is done. let's see what broke

12:43:34 shinmera regarding undo/redo, do you already have stuff for that in the underlying buffer system?

13:11:14 Colleen yes, but it's not quite ready

13:11:14 scymtym yes, but it's not quite ready

13:11:38 shinmera ok

14:28:42 Colleen Shinmera: pushed to alloy code-editor branch and trial-ide main branch. most things should work but i'm there will be regressions from combining the mostly uncoordinated changes. i /think/ the other libraries don't need updating but who knows

14:28:42 scymtym Shinmera: pushed to alloy code-editor branch and trial-ide main branch. most things should work but i'm there will be regressions from combining the mostly uncoordinated changes. i /think/ the other libraries don't need updating but who knows

14:29:06 Colleen *i'm sure

14:29:06 scymtym *i'm sure

14:32:19 shinmera ok, I'll also check with Kandria & Weiss

15:04:32 shinmera scymtym: I pulled, but now the buttons aren't centred or scaled properly anymore, is that intended?

15:18:31 shinmera scymtym: also, it seems you fixed the animation thing? I at least don't get any errors when I just do

15:18:31 shinmera (presentations:define-animated-shapes alloy:button (:background (simple:pattern :duration 0.2)) (:label (simple:pattern :duration 0.2)))

15:18:37 shinmera animates fine

16:50:39 Colleen i don't think i fixed anything about animations. let me check

16:50:39 scymtym i don't think i fixed anything about animations. let me check

16:50:59 shinmera well it doesn't error for me, so

16:51:03 Colleen regarding the scaling, that is problem i mentioned. i think the issue is just that the scaling is no propagated

16:51:03 scymtym regarding the scaling, that is problem i mentioned. i think the issue is just that the scaling is no propagated

16:51:08 shinmera not sure how to repro your problem with animations

16:51:54 Colleen the animation problem wasn't an error, just that the change in pattern wasn't detected and thus not animated. i will check again whether it still occurs

16:51:54 scymtym the animation problem wasn't an error, just that the change in pattern wasn't detected and thus not animated. i will check again whether it still occurs

16:52:48 shinmera in the trial-ide with that above snippets buttons animate just fine

16:53:07 shinmera but I think I know what you mean, so hold on

16:55:55 Colleen i saw the problem in the alloy example for animations. i just retried and the the transitions still seem instant, i.e. not animated, to me. last time i instrumented the code, the problem was that the change in pattern wasn't picked up by the animation tracker as i mentioned

16:55:55 scymtym i saw the problem in the alloy example for animations. i just retried and the the transitions still seem instant, i.e. not animated, to me. last time i instrumented the code, the problem was that the change in pattern wasn't picked up by the animation tracker as i mentioned

16:56:26 shinmera right, I understand now

16:56:45 shinmera since it sees the same name it thinks there's nothing to tween-- it has to resolve the name

16:58:37 Colleen maybe it's just that. i thought there was an additional issue with the state changing before the update and not within the scope of the change tracker. but i may have interpreted that behavior incorrectly

16:58:37 scymtym maybe it's just that. i thought there was an additional issue with the state changing before the update and not within the scope of the change tracker. but i may have interpreted that behavior incorrectly

17:07:17 shinmera hrmmmm no, actually, the extracted palette is already resolved correctly. so whadda hecc....

17:11:23 Colleen Shinmera: when i tried to understand the issue, i had the impression that https://codeberg.org/shirakumo/alloy/src/branch/master/animation/change.lisp#L31 was always false because the symbolic pattern name resolved to the same color before and after because the focus state was changed earlier, not within the changed tracking scope

17:11:23 scymtym Shinmera: when i tried to understand the issue, i had the impression that https://codeberg.org/shirakumo/alloy/src/branch/master/animation/change.lisp#L31 was always false because the symbolic pattern name resolved to the same color before and after because the focus state was changed earlier, not within the changed tracking scope

17:13:41 shinmera that was my guess just now too, but it's wrong. the extractor returns a COLOR value, not the palette name.

17:14:04 shinmera I'm still trying to make better instrumentation atm, this stuff is pretty hard to debug

17:14:31 Colleen yes and i think the issue is that the old and new colors are the same

17:14:31 scymtym yes and i think the issue is that the old and new colors are the same

17:14:57 Colleen so it thinks no tweening necessary

17:14:57 scymtym so it thinks no tweening necessary

17:15:09 shinmera that shouldn't be the case, since the first fetch is done *before* the change is applied

17:15:35 shinmera so eg for focus stuff, the focus should still be the old value

17:16:35 Colleen right, it would work in that case. but i had the impression that that focus/state change happened entirely before update

17:16:35 scymtym right, it would work in that case. but i had the impression that that focus/state change happened entirely before update

17:16:47 Colleen let me check whether i have my instrumentation stashed somewhere

17:16:47 scymtym let me check whether i have my instrumentation stashed somewhere

17:16:57 shinmera ah... wait, no, you're correct

17:17:26 shinmera the previous system worked because the change of the pattern was computed in update, rather than being computed in the pattern fetch.

17:17:28 shinmera hrmmmmmh

17:17:47 shinmera ugh, how the heck can I fix this

17:22:11 shinmera I'm honestly struggling to come up with a way to do this

17:23:54 Colleen i have no idea either. would have suggested something otherwise

17:23:54 scymtym i have no idea either. would have suggested something otherwise

17:24:27 shinmera even if I change the system around to return pattern names, we'd still have the state already updated by the time the change tracker "grabs on"

17:25:03 shinmera best I can think of is to actively cache the values somewhere so we don't have to do a double-fetch

17:25:59 shinmera hmm, ok. will think more on this

17:26:09 shinmera currently distracted by a space documentary

17:29:42 Colleen no need to rush. i have plenty of other things to work on

17:29:42 scymtym no need to rush. i have plenty of other things to work on