<wpwrak>
(select from A, then activate B) how would i do that ? if i select the point, TW changes to that point. to get back to the group list, i have to press Esc, and thus lose the selected point. what is the trick that i'm missing ?
<whitequark>
... oh right
<whitequark>
it would have worked
<whitequark>
if you could do it
<wpwrak>
;-))
<wpwrak>
the group order works great, though. also complains nicely if i mess up
<whitequark>
yeah, it should just be exposed in the UI
<whitequark>
I really dislike adding such options now because I'm trying to refactor the text window
<ohsix>
whitequark: word (re: smol) found shortly after, didn't expect it to be in rust :p
<whitequark>
ohsix: well what else?
<ohsix>
there's a bunch of work that's been done since i'd last looked in that area tho, someone built a bunch of stuff to target stm32 with it
<ohsix>
c
<whitequark>
idris? ivory/tower?
<whitequark>
lol
<whitequark>
good joke
<ohsix>
i got the impression that you would be competing with lwip
<whitequark>
correct
<ohsix>
if i were using c it wouldn't, and if i were using rust smol would be one of the only things, because it exists :p
<whitequark>
since when did the c toolchains lose the ability to link with static libs?
<ohsix>
i don't know enough about rust at this point
<whitequark>
smoltcp doesn't even use heap. this makes it *very* easy to export its interface via C ABI
<ohsix>
i did look at objdump -x for the stm32 stuff, i saw c link level names
<whitequark>
this is not currently done but this would take, like, one day
<whitequark>
personally i didn't do this because i consider writing new embedded code in c if you can avoid it insane
<ohsix>
don't disagree, but that's a big 'can avoid'
<ohsix>
this stm32 stuff will get me using rust and maybe teaching people about it, but not soon
<whitequark>
well, i could avoid it :)
<whitequark>
we used to have a c runtime in artiq. it was nasty
<wpwrak>
whitequark: (refactoring) yeah, big changes tend to cause queues :) but with the group order it's not so bad. especially since the sequence can have holes.
<ohsix>
right
<ohsix>
the reason i had asked is that lwip came up in conversation, i assumed the person could use it directly, they don't know rust either
<whitequark>
file an issue? i can just implement that interface...
<ohsix>
i may, but i'd like to know more about rust first
<ohsix>
if i can't tell someone else how to build then use it then it's not much different from how things are now :p
<wpwrak>
whitequark: btw, what's the status of evil-spirit's change at the end of https://github.com/solvespace/solvespace/issues/165 ? is this something that could go into mainline ? is it "work-in-progress" ? does it need testing ? i just read the patch (but haven't tried it yet) and it seems to do what i'm after
<wpwrak>
and regarding DISPLAY_TEXTWND, i've tried sending the TW to a vnc server without window manager. there, the difficulty with making it come up stably occurs as well. apparently the issue is some XGetImage, but the debug trace isn't too useful otherwise
<whitequark>
(#165) I need to read the patch, fix the grammar, and merge it
<whitequark>
maybe comb the UI a bit to make it consistent
<wpwrak>
given the surrounding events, i wonder if this might be a general race in the code that just never happens if both windows on the same screen
<whitequark>
maybe
<whitequark>
I'm not sure if anyone has ever tested GTK in this configuration
<wpwrak>
(#165) okay, so i'll just wait :)
<wpwrak>
(gtk) yeah. it's sometimes frightening how qickly you can veer off the beaten path. btw, that vnc setup has no opengl. so the issue isn't gl-related, just gtk
<whitequark>
it could still be gl-related
<whitequark>
gtk3 is gl-only, it uses mesa software renderer then on vnc
<whitequark>
but yeah, it doesn't sound too much like a gl-related issue in the first place