<d1b2>
<Aleksorsist> @azonenberg Moving our Twitter dm convo here. Looking for contract devs to get ThunderScope glscopeclient support up and running
<azonenberg>
@aleksorsist see DM
<d1b2>
<louis> Oh yeah, speaking of glscope... I got fed up of screwing with flow control stuff without better diagnostics, so I've put together a window for scope info / diagnostics
<d1b2>
<louis> After an ... illuminating ... introduction to C++ GUI programming
<d1b2>
<louis> I'm thinking I'm going to extend Oscilloscope now to allow it to report more useful diagnostics to show there.
<azonenberg>
Great. yes, that would likely be useful
<azonenberg>
also freeform text debug logs
<azonenberg>
just a text box with N recent log messages the bridge provides
<d1b2>
<louis> Probably Oscilloscope a ->GetDiagnosticParameters() that yields a vector<string> meant to contain entries like "Hardware FPS: 400 (320 dropped)" to be displayed directly, and then give it a ->GetDiagnosticLogs() that pops from an internal freeform debug queue into a scrolling box
<azonenberg>
So rather than a vector<string>
<azonenberg>
what about instead having a vector<enumeration> list of attributes the scope provides
<azonenberg>
then a get call for each one that returns a string
<azonenberg>
that way you can separate attribute name/value etc
<d1b2>
<louis> Sure, that works too
<azonenberg>
also, you may be interested in libgraphwidget for the debug dialog
<azonenberg>
it's a purely software rendered graph (included in the project already but not used for anything visible at the moment) as a gtk widget
<azonenberg>
that is meant for displaying trends over time of a parameter for monitoring applications
<azonenberg>
(since putting a full opengl accelerated waveform view in the debug dialog would be overkill)
<azonenberg>
this is easier to set up and would let you plot e.g. wfm/s or flow control parameters over time
<azonenberg>
live
<d1b2>
<louis> Yeah; I saw that in the multimeter dialog code
<azonenberg>
ah yeah i implemented that i forgot
<azonenberg>
thats why i pulled it in
<azonenberg>
incidentally, right now we support multimeters and func gens that are part of a scope
<azonenberg>
and while the APIs allow you to interact with ones that are not
<azonenberg>
there is no way to put those in a glscopeclient session
<azonenberg>
that's on my list of things to do soonish
<azonenberg>
e.g. we have a driver for my R&S benchtop multimeters
<azonenberg>
but i cannot use them in glscopeclient because i have no way to add them to a session
<azonenberg>
the same is true of my power supplies
<azonenberg>
i have a libscopehal driver but there is no gui for them
<azonenberg>
there is a standalone psuclient app
<azonenberg>
but i'd like it integrated
<d1b2>
<louis> This seems like it might be overkill / become thorny managing all the different parameters; how about just a vector<pair<string, string>> ?
<azonenberg>
For now, sure
<d1b2>
<louis> That way we can put them in a nice GTK table
<azonenberg>
we can always refactor it later
<d1b2>
<louis> and punt on trying to define a shared datamodel for diagnostic values
<azonenberg>
actually, here we go
<azonenberg>
Use the FilterParameter model
<azonenberg>
you have a map<string, parameter>
<azonenberg>
each parameter has a type and value
<azonenberg>
(like, literally use FilterParameter objects)
<azonenberg>
then you can reuse the existing code to pretty print numeric values
<azonenberg>
and since they're identified by strings, no need to make a shared list of all possible attributes
<azonenberg>
you can still render them in a table but having them as FilterParameter's allows you to graph them and such too
<azonenberg>
since the raw value is numeric and includes an associated unit
<monochroma>
(in the past for free-form debugging text debug windows, i have had applications pop up a urxvt terminal, and use the -pty-fd option to talk directly to/from it)
<d1b2>
<louis> Sure
<azonenberg>
because for flow control debug in particular
<azonenberg>
i really think trending over time will be valuable
<d1b2>
<louis> yes
<azonenberg>
this isnt just printf debugging, we want to understand the dynamics of the systme
bvernoux has quit [Read error: Connection reset by peer]