libera/#shirakumo - IRC Chatlog

6:20:12 Colleen <shinmera> glenneth: you didn't pull yet :v

6:42:45 Colleen <glenneth> Could have sworn I had. Pulled now - spec subtree is updated in lichat-js (the data-fields clarification). Also saw ex-lichat master move (0.3.5 + the user-notes error text fix) local master updated.

6:43:53 Colleen <glenneth> PR #14 now includes the DATA-FIELDS implementation plus ExUnit tests, and I verified it end-to-end with a probe client: signed upload

6:44:20 Colleen <shinmera> you still haven't pulled, idk what to tell ya.

6:44:35 Colleen <shinmera> master has the text field and data fields implementation stuff

6:45:01 Colleen <shinmera> https://codeberg.org/shirakumo/ex-lichat/commit/f3f17395555c6c356ae9afb49cc70814c67f0712

6:45:20 Colleen <glenneth> WTH??

6:45:43 Colleen <glenneth> OK. Investigating. Something not right on my end

6:52:04 Colleen <glenneth> Not quite sure how I wound up on a stale checkout. Fixing the mess now

6:53:15 Colleen <shinmera> probably from me doing my weird force pushing/tag moving

6:55:08 Colleen <glenneth> who knows? It's git doing git things lol

6:56:41 Colleen <glenneth> Pulled, rebuilt, and re-verified against master - my probe client's #12 reconstruction and signature verification pass against your implementation. PR #14 retargeted to the ephemeral-profile fix + tests. One issue though: the converted message still carries the data update's signature on the wrapper, which can't verify - clients will show failed-verification shields on signed uploads. Clear it server-side, or should clients ignore the wrapper signature when DATA-FIELDS is present?

6:57:26 Colleen <shinmera> ah, good catch. No, the server should clear it.

6:57:39 Colleen <shinmera> didn't think about that when I implemented this at like midnight lol

6:57:54 Colleen <shinmera> let me fix that real quick

6:58:31 Colleen <shinmera> done

6:58:51 Colleen <glenneth> rapid. Thank you

7:21:25 Colleen <shinmera> I cherry picked your other commits and pushed those

7:22:00 Colleen <shinmera> gonna go to the office now, bbl

7:33:32 leppard|2 ** NICK Inline

7:33:59 Inline ** NICK leppard

7:48:14 Colleen <glenneth> ok. be safe :)

9:03:51 Colleen <shinmera> wow

9:04:11 Colleen <shinmera> just discovered this PR from... 2 months ago, which I do not at all remember??? https://codeberg.org/shirakumo/lichat/pulls/3/files

9:56:06 Colleen <shinmera> god I can't concentrate at all today

10:01:57 Colleen <Hugo> I just tried an interesting game called the Council, the first episode is free

10:02:10 Colleen <shinmera> scymtym: so we've got about two months to get the IDE done, tested, and uh, rolled out.

10:02:21 Colleen <shinmera> less than that, really, since I need to also prepare the actual course material and all

10:12:29 Colleen <shinmera> god I wish I could focus

10:41:30 scymtym Shinmera: right, what is the most immediate task i can help with?

10:41:52 Colleen <shinmera> uuuuh, getting the branch to a state where it can be merged with master

10:44:43 Colleen <shinmera> meaning ironing out any regressions with the previous text system

10:46:13 scymtym should we make a list of issues that prevent merging at the moment, for example in a pull reqest? as an example of such issues, i know about the problem with menu items not showing up immediately

10:46:46 Colleen <shinmera> If you prefer a PR, that's fine. Otherwise there's the todo list: https://feedback.tymoon.eu/trial/alloy?message=Feedback%20submitted#$2xr

10:47:34 Colleen <shinmera> Meantime I'll try to unblock my brain by getting started on the course material

10:48:13 scymtym oh good, i didn't know the list was fleshed out to this extent

10:48:39 scymtym i did something for line number and am on undo in the meantime

10:48:51 scymtym but i can "feature freeze" and work on the problems for now

10:48:57 Colleen <shinmera> sounds good

10:49:25 scymtym i would still prefer pull out and submit separately a few things

10:49:42 Colleen <shinmera> that's fine

10:49:54 Colleen <shinmera> from my end I just want an easy place where I can report issues that I might encounter

10:50:08 Colleen <shinmera> I'm used to the Feedback system, but I can adapt

10:50:41 scymtym sure. it is very helpful to have this list

10:51:00 Colleen <shinmera> you can also mark items as resolved if you've made progress

10:52:12 scymtym is there a state for "i think the issue is solved but the submitter should check"?

10:53:02 Colleen <shinmera> Not explicitly, no

10:53:22 scymtym i will just ask in such cases, then

10:53:23 Colleen <shinmera> Just mark as resolved and I'll unmark if I find stuff

10:53:37 scymtym multiple issues are related to the text shape valign property. i wasn't sure how that is supposed to work

10:54:13 Colleen <shinmera> what's the confusion?

10:54:17 scymtym for the text input component, the component size and shape size should be identical so there doesn't seem to be any room for vertical alignment. is the issue about other situations?

10:54:46 Colleen <shinmera> the component size could be forced to be anything

10:55:18 Colleen <shinmera> so if the text doesn't fill that size, it needs to align somehow

10:55:28 Colleen <shinmera> for instance for an input line that's typically middle aligned

10:55:55 Colleen <shinmera> and even for multiline text, for a console it is sometimes preferred to be bottom aligned

10:57:06 scymtym ok. and for msdf text shape, the location slot would be the way to implemented that, right?

10:58:04 Colleen <shinmera> I think so

10:59:15 scymtym me too. i implemented 50 % of vertical alignment but wasn't sure i was doint it the right way

11:00:22 Colleen <shinmera> it should be conceptually very simple. The actual text lines create a box, and that box needs to be anchored to the size of the shape box

11:01:25 Colleen <shinmera> I think simple has the resolve-alignment function for that

11:05:40 scymtym yes. i remember the issue my now. i thought to align to the top of the component, the shape needs to know the height of the component. but i guess the issue revolves around being assigned a (vertical) size that is larger than the text content

11:06:24 scymtym although i'm not sure it happens like that with the text editor in a scrolling layout

11:06:29 Colleen <shinmera> yes. If the textual content is largerg than the box then there is no real alignment.

11:06:34 Colleen <shinmera> *larger

11:06:40 Colleen <shinmera> hmm

11:06:47 Colleen <shinmera> I guess there still is in terms of overflow direction

11:07:02 Colleen <shinmera> if alignment is top, it needs to overflow below and vice versa

11:35:55 scymtym is resolve-alignment correct? for example, :top gives 0 (assuming no margins). wouldn't that place the shape at the bottom (on screen) of the component with the actual content of the shape outside the bounds of the component?

11:36:53 scymtym sorry, :bottom gives 0. but i still think the shape would be out of bounds

11:37:12 Colleen <shinmera> why?

11:37:28 Colleen <shinmera> Y is up, so 0 offset means the lower edges coincide

11:40:28 scymtym ok

12:19:24 scymtym i'm making progress but there is one more issue. for pointer events on a text input component, the pointer location has to be mapped to the local coordinates of the text shape in order to look up glyphs at that location. but the text input component is not supposed to know about shapes

12:20:48 Colleen <shinmera> yyyessss....

12:21:11 scymtym the concrete issue is that the :label shape of the code-editor component has a left margin to form a "fringe" region for line numbers and other stuff. that margin has to somehow go into the mapping from the pointer location to shape coordinates

12:21:21 Colleen <shinmera> right

12:22:00 Colleen <shinmera> hmmmmh.

12:22:23 Colleen <shinmera> the presentations protocol already has a stealth mixin on renderables, so it could theoretically at least intercept the pointer events

12:22:31 Colleen <shinmera> but that seems gross

12:22:49 Colleen <shinmera> slightly less gross would be an extra stealth mixin on text-input-component

12:24:17 Colleen <shinmera> what do you think?

12:24:28 Colleen <shinmera> I can't really think of a way to do a protocol that flows "downward" as it were

12:24:45 Colleen <shinmera> this has to be something that the rendering backend intercepts

12:25:02 Colleen <shinmera> or as would be the case in a qt backend or whatever, just "automatically" handles

12:32:19 scymtym the last part of the mapping is done by the text info object. maybe the renderer could somehow inject the extra translation there since the renderer has access to the text info. but that wouldn't fit very well either since the text info is supposed to be self-contained

12:32:45 scymtym although there already is a way for renderers to attach extra information to the abtract text info

12:32:54 scymtym maybe that could be extended

12:33:26 scymtym will be a bit gross in any case, i'm afraid

12:34:28 Colleen <shinmera> not like text is ever not gross :)

12:36:03 scymtym it's pretty ok if you don't render it

12:36:24 Colleen <shinmera> heh

12:36:41 Colleen <shinmera> even then encodings and so on are a mess

12:36:42 scymtym well, not even then, if i think about it

12:36:47 Colleen <shinmera> yeha

12:36:48 scymtym yeah

12:36:58 Colleen <shinmera> ugh, bbl, gotta take care of some med stuff

12:37:13 scymtym sure, i can make more progress

14:55:05 Colleen <shinmera> glenneth: not sure if this is just my caches being weird or whatever but the lichat site still jumps to the iframe for me