<d1b2>
<azonenberg> Ok well i think i'm going to work on that shortly. But before i do that, i'm gonna work on implementing the progress callbacks for VICP so i can get progress bars on my lecroy scopes
<d1b2>
<azonenberg> Which are nice and fast at shallower memory but with tens of megapoints get slow enough a progress bar would definitely be nice
<d1b2>
<azonenberg> @josHua @fredzo_72653 Let's start thinking about splitting up the render method in StreamBrowserDialog a bit to make the code a bit easier to follow
<d1b2>
<azonenberg> i don't like having thousand-line functions 🙂
<d1b2>
<azonenberg> And there's gonna be a lot more content being added to it soon
<d1b2>
<azonenberg> I might work on that tomorrow before i do 775
<d1b2>
<josHua> could be nice. I am sure there is some kind of C++ shenanigan that would allow this to be defined in an overloadable way without having to explicitly write every overload-possible type somewhere
_whitenotifier has quit [Ping timeout: 276 seconds]
<d1b2>
<azonenberg> yeah i'm gonna think about it
<d1b2>
<azonenberg> splitting instruments and filters will be the first step
pirate has quit [Ping timeout: 252 seconds]
pirate has joined #scopehal
<d1b2>
<josHua> @azonenberg this reminds me of a few other things that I was thinking about yesterday. for one, now that not everything in the stream browser is actively draggable, it brings me back to the idea of having an interfacebuilder-style metaphor of 'outlets' and 'actions', where there are visible icons (usually) for 'this thing can be dragged as a source', and 'this thing is a target that you can drag to'
<d1b2>
<josHua> in the back of my mind, I was thinking that everything that created a stream should have a representative icon of the stream in question, and everything that accepted a stream might want to have such an icon too. consider:
<d1b2>
<josHua> in the back of my mind, I was thinking that everything that created a stream should have a representative icon of the stream in question, and everything that accepted a stream might want to have such an icon too. consider the following icons, where the stream behavior is represented by the icon. any Hz-> could be dragged onto any ->Hz icon, for instance.
<d1b2>
<josHua> the other thing that I was thinking about was that it was sort of nonobvious to me that waveform viewers were not represented in the filter graph
<d1b2>
<azonenberg> Sooo
<d1b2>
<azonenberg> that is acutally something i am thinking of changing
<d1b2>
<azonenberg> Making a WaveformArea be a FlowGraphNode
<d1b2>
<azonenberg> i think there is a ticket for it
<d1b2>
<azonenberg> it's not a v0.1 issue, and i'm not 100% i want to do it
<d1b2>
<azonenberg> or how
<d1b2>
<azonenberg> (in particular WRT the amount of clutter it would cause displaying different signals in one plot)
<d1b2>
<azonenberg> But i think at least on the back end it would make more sense
<d1b2>
<azonenberg> So right now internally
<d1b2>
<azonenberg> streams can be of type analog waveform, digital waveform, analog scalar (digital scalar doesnt exist, but will soon), eye pattern, waterfall, spectrogram, or protocol
<d1b2>
<josHua> and also things can arbitrarily reject streams that you try to drag to them, IIRC
<d1b2>
<azonenberg> Correct. That is something i want to redo too
<d1b2>
<azonenberg> right now the only way to know what datatypes an input wants is to call ValidateChannel with a proposed stream
<d1b2>
<azonenberg> and you get a go/no go answer
<d1b2>
<azonenberg> there is no visibility into why it rejected it, or what it wants
<d1b2>
<azonenberg> i want to switch to a more data driven model where an input advertises what it accept
<d1b2>
<azonenberg> again, not a v0.1 issue
<d1b2>
<josHua> it is a shame gstreamer is not a compatible license for your goals. it pretty effectively provides a framework to solve most of this
<d1b2>
<azonenberg> We can still borrow high level architecture from it
<d1b2>
<josHua> yeah, it is worth thinking about
<d1b2>
<azonenberg> anyway, there's a bunch more work to do on the sidebar for sure