<d1b2>
<aleksorsist> Can someone tell me how to delete a node in the filter graph? Going to do a demo of ThunderScope+ ngscopeclient later today and don't confuse people with a bunch of nodes
<d1b2>
<johnsel> You can delete the corresponding channel in the normal UI
<d1b2>
<johnsel> that will make the filter graph node go away
<d1b2>
<johnsel> I agree that that should also be possible in the filter graph itself
<d1b2>
<johnsel> but it's not as of yet, @azonenberg ?
<d1b2>
<aleksorsist> I've had that not happen while playing around last night
<d1b2>
<aleksorsist> Deleted window filter in the normal UI and it kept the node and deleted the connections
<d1b2>
<johnsel> oh right it doesn't always do that
<d1b2>
<johnsel> that's annoying
<d1b2>
<johnsel> probably going to have to modify the file itself then
<d1b2>
<johnsel> remove it there
<d1b2>
<aleksorsist> The file? Like the scope session?
<d1b2>
<johnsel> aye
<d1b2>
<johnsel> hmm or not
<d1b2>
<johnsel> looks like it's in the waveform files themselves
<d1b2>
<johnsel> can you recreate it?
<d1b2>
<johnsel> that seems like your only option really
<d1b2>
<aleksorsist> Now that I've got a video capture setup, I'll be doing a lot more testing with ngscopeclient so I'll see if I can get a video showing this
<d1b2>
<azonenberg> So the node should go away once all consumers of its output are removed
<d1b2>
<johnsel> it doesn't
<d1b2>
<azonenberg> i.e. no other nodes using it as input, no views displaying it
<d1b2>
<azonenberg> If it doesn't that's a bug where refcounting is off
<d1b2>
<azonenberg> I know we have a few of those. This is something I'd like to solve longer term by having channels be STL smart pointers rather than us using explicit refcounting
<d1b2>
<johnsel> I also think this should be possible from the graph ui itself
<d1b2>
<azonenberg> but that is going to take a lot of refactoring
<d1b2>
<azonenberg> Forcibly deleting a channel is on the longer term todo but making it fully go away is going to require some means of identifying all of these loads and disconnecting them to avoid dangling references
<d1b2>
<azonenberg> It's nontrivial
<d1b2>
<azonenberg> All of the data structures we have now go in the other direction
<d1b2>
<azonenberg> i.e. from input to source
<d1b2>
<johnsel> yeah the data model doesn't allow easy traversal of those relations
<d1b2>
<azonenberg> It's meant to go the other way around, you start with the output and you figure out what inputs are required to create it
<d1b2>
<azonenberg> not impossible, but a fair bit of work
<d1b2>
<azonenberg> So it hasn't been a priority
<d1b2>
<azonenberg> the other thing that has to be solved as part of this is better handling of sink nodes like export filters
<d1b2>
<azonenberg> which, right now, are impossible to delete once created because i essentially create a dangling reference on purpose to cheat the refcounting since they don't have any output channels to display
<d1b2>
<johnsel> yeah that's not great
<d1b2>
<azonenberg> Just a question of limited time and dev resources
<d1b2>
<johnsel> Ofcourse
<d1b2>
<azonenberg> And so far these annoyances have always got kicked further down the road
<d1b2>
<azonenberg> long term i want instruments and channels to all be std::shared_ptr's
<d1b2>
<azonenberg> But this refactoring isn't gonna be easy
<d1b2>
<azonenberg> It's also going to basically have to happen all at once
<d1b2>
<azonenberg> because we can't really mix shared_ptr's and manual memory management
<d1b2>
<azonenberg> i might be able to do instruments one time and channels another
<d1b2>
<azonenberg> but it's going to be a huge, sweeping refactoring that will touch every filter, every driver, all over the gui
<d1b2>
<azonenberg> As part of that I'm also going to be transitioning away from the current model we have for some instruments in which the properties dialog "owns" the instrument and when closed it disappears from the session, etc
<d1b2>
<azonenberg> there's a lot of work to do
<d1b2>
<johnsel> yeah I was going to say that
<d1b2>
<johnsel> you want some kind of virtual objects
<d1b2>
<azonenberg> Yeah. It's all planned, but i don't think it will happen in time for v0.1
<d1b2>
<azonenberg> For v0.1 my focus is going to be getting all of the docs and packaging and known crashes taken care of and basically shipping what we have
<d1b2>
<azonenberg> On that note, what's the status of the CI?