(unposting)
anyone got a clue what's going on here?
i know what the error message means, but i don't understand what causes `'static` lifetime to be required, considering I've explicitly specified the `'a`.
there's this answer https://users.rust-lang.org/t/box-with-a-trait-object-requires-static-lifetime/35261/2 but it's from 2019 - did the language change?
what am i overlooking?
esmevane, sorry
@unspeaker er. that is weird.
disclaimer: i would fumble around on this, i'm not confident i know what is causing this
does it have anything to do with deconstructing the box interior? since it's on the heap? is it possible you could pop something out of `Collection::Box` as a separate function or in a bracket expression so rustc knows that the box is out of scope when it goes for the interior value?
(unposting)
hmm, i'm not sure i'm parsing your suggestion. is "pop something out" something that i should try doing, or is it a possibility that i need to account for?
the goal is to compose `Render`able widgets inside the `render` method of other widgets
Collected::Box is for when they are ephemeral (owned by the render method) and Collected::Ref is for when they are stateful (owned by the parent struct), if that makes sense
esmevane, sorry
@unspeaker It totally makes sense! I think, but I'm not fully sure, that the Box interior to one of those variants might be introducing an opaque lifetime?
what I'm suggesting is an `impl Collection` method that is apart from the trait, with fewer lifetimes to worry about, that gets the value inside the box somehow? Maybe that'll convince the compiler that ownership has changed.
(A self invoking block might cause `Drop` to take things out of scope in the same way too)
(unposting)
and this is based on some old code that used to work quite nicely for that purpose ... but i can't reuse it because reasons :(
which is a damn shame because i liked it way better than #ratatui :(
esmevane, sorry
@unspeaker haha I've been using ratatui a bit, it definitely is more of a tool kit than a framework, lots of boilerplate left on the table imo
esmevane, sorry
@unspeaker you honestly can't trust the randosphere! i exercise a lot of caution too, any given day i'm not sure if it's too much or not enough lol
(unposting)
yeah.. the only thing I like about ratatui really is the double buffering
a couple years back i wrote my own framework on top of crossterm, was quite happy with how it let me compose things
generic over backend too (business logic could theoretically be reused with a gui backend instead of tui)
but i put it on github. and then something something trauma ostracism paranoia so now i can't reuse stuff that i've published on github because it's too connected with my past identity
(unposting)
on one hand who's gonna doxx me over reusing my old code, and what's the chance they're gonna do anything to me - on the other even if the chance is minuscule the consequences would be beyond what i can deal with currently - so let's rewrite everything from scratch but worse 🤣
esmevane, sorry
@unspeaker I feel much the same way! I have so many private repos. My god. I've skimmed through your stuff a lot for reference though! I appreciate that you've shared it
(unposting)
yeah... sucks innit... some days i think i've got legit reasons to be like that, some days i think it's just self-defeating behavior i should reject
like if this project is just something to facilitate my own music making, i'd just develop in private and get it done sooner :(
but i also want to use it to connect with people over a shared interest in programming and art, like having this conversation for example :)
hell of a tradeoff, i want my work to have results already :x
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.