<d1b2>
<azonenberg> @fredzo_72653 for your stream browser PR
<d1b2>
<azonenberg> did you draw the waveform shapes as bitmaps or is there a vector version somewhere
<d1b2>
<azonenberg> I'm also not super thrilled at the way that the stream browser controls arent actually making the voltages and stuff editable. i need to think about how to improve on this
<d1b2>
<azonenberg> also when i make changes via the FunctionGeneratorDialog the values shown in the stream browser don't update
<d1b2>
<azonenberg> I think i'm gonna try and improve on this locally
<d1b2>
<azonenberg> the waveform type seems to be grayed out which is confusing
<d1b2>
<azonenberg> other thoughts: having the PSU badge be red for off i dont like
<d1b2>
<azonenberg> red means something is wrong
<d1b2>
<azonenberg> switched off is a normal state
<d1b2>
<azonenberg> gray vs green makes more sense there
<d1b2>
<azonenberg> But i want to make a bunch more extensive changes to this over the next few days and see how it shakes out
<d1b2>
<fredzo_72653> Sorry no, I made them directly as bitmaps, I have no tools nor skills to make vertor versions 😅
<d1b2>
<fredzo_72653> That's strange, they should: the state flag "needsUpdate" should be set to true whenever you change a value, making the InstrumentThread get a fresh value from the instrument
<d1b2>
<azonenberg> well i'll debug it before i merge
<d1b2>
<azonenberg> i have it in my working copy
<d1b2>
<azonenberg> i want to actually retire FunctionGeneratorDialog entirely
<d1b2>
<azonenberg> which means making the stream browser include all of the missing functionality
<d1b2>
<azonenberg> this will include figuring out the best way to get high density control widgets there
<d1b2>
<fredzo_72653> OK no worries, just let me know when you're done, I have other fixes to make in StreamBrowserDialog and TimebasePropertiesPage (for specans), I'll wait untill your finished.
<d1b2>
<azonenberg> ok that's fine, i'll work with somebody else to make cleaned up vector versions eventually. this is better than nothing
<d1b2>
<fredzo_72653> Yes that's what I thought too 🙂
<d1b2>
<azonenberg> and ok i'll see how far i get tonight. i'm gonna be traveling for work sunday into next week and won't have physical access to myl ab
<d1b2>
<azonenberg> so i'm gonna try and wire up some testbeds i can use remotely to continue dev
<d1b2>
<azonenberg> i'll have the thunderscope with me
<d1b2>
<azonenberg> should have a bunch of free time in the evenings
<d1b2>
<fredzo_72653> Yep that might be a bit challenging !...
<d1b2>
<azonenberg> basically i like the general direction things are going
<d1b2>
<azonenberg> but i dont like the idea of having all the things that look like controls just spawn a separate properties dialog
<d1b2>
<azonenberg> i want to make them more directly interactive
<d1b2>
<azonenberg> if we need a separate dialog for advanced stuff on e.g. a scope channel we can do that
<d1b2>
<azonenberg> but i want to minimize how often that's the case
<d1b2>
<azonenberg> The other thing i want to do, i think i filed a ticket
<d1b2>
<azonenberg> is add badges for invert and bandwidth limiter state on scope channels
<d1b2>
<azonenberg> but none of that is cached right now
<d1b2>
<azonenberg> and i was thinking this might be something to push untuil v0.2
<d1b2>
<azonenberg> in particular, because i wanted to think about redoing how we cache instrument settings
<d1b2>
<fredzo_72653> Yep saw that, and maybe Input Impedance for scope channels too ?
<d1b2>
<azonenberg> move caching out of the drivers
<d1b2>
<azonenberg> make the base oscilloscope method have cached query methods
<d1b2>
<azonenberg> oscilloscope class*
<d1b2>
<azonenberg> and then all the driver apis will be uncached
<d1b2>
<azonenberg> and we wont need 30 subtly different caching layers floating around different drivers
<d1b2>
<azonenberg> but that's not something to do a month before feature freeze :p
<d1b2>
<fredzo_72653> Yep I was thinking the same, we should not have to handle caching in drivers
<d1b2>
<azonenberg> Yeah
<d1b2>
<azonenberg> anyway, there's a few tickets related to this tagged for v0.2
<d1b2>
<azonenberg> we can refine that as the time gets closer
<d1b2>
<azonenberg> but i think we should avoid doing any stream browser work between now and v0.1 release that involves any new caching layers
<d1b2>
<azonenberg> given the intent to redo caching
<d1b2>
<fredzo_72653> yep makes sense
<d1b2>
<azonenberg> I'm also going to try and schedule a developer call for some time after i get back from my trip
<d1b2>
<azonenberg> to make sure we're all geared up for freeze and everyone is on the same page about what's left to do
<d1b2>
<fredzo_72653> Anyway how did you like the function generator rendering apart from what you mentioned ? I think it looks nice doesn't it ?
<d1b2>
<azonenberg> I think it's certainly a lot better than what we had beforhenad
<d1b2>
<fredzo_72653> you mean better then nothing ?! 😉
<d1b2>
<azonenberg> well i meant just the floating function generator dialog
<d1b2>
<azonenberg> the two things that caught my eye initially were that the cardiac waveform looked all wrong, and that it wasn't syncing properly with the floating dialog
<d1b2>
<azonenberg> but i am planning to fix that broken sync by just removing the other dialog and making the stream browser implement all of the necessary functionality
<d1b2>
<azonenberg> i also need to check how it works with the filter graph
<d1b2>
<azonenberg> iirc function generator channels can take some config from filter graph blocks
<d1b2>
<azonenberg> so we have to make sure that syncs properly with the stream browser if a filter changes the frequency or something
<d1b2>
<azonenberg> That's all on my agenda for tonight or tomorrow morning
<d1b2>
<azonenberg> We'll see how far i get
<d1b2>
<azonenberg> anyway, thanks a lot for all of this, it's quite refreshing to not be the only one touching the gui 🙂
<d1b2>
<fredzo_72653> You're very welcome !
<d1b2>
<azonenberg> i just want to make sure we dont lose sight of the deadlines and also fix all of the other things that need to be done before release
<d1b2>
<azonenberg> so i dont want to get too bogged down on new features and miss bugs or packaging stuff
<d1b2>
<azonenberg> This is all good work but at some point we're gonna have to say push whatever is left to v0.2
<d1b2>
<azonenberg> because we need to ship something soonish, and it needs to be reasonably stable and usable
<d1b2>
<azonenberg> As of right now we have eight open tickets tagged for v0.1, i may push some of them to later due to lack of criticality / resources
<d1b2>
<azonenberg> for scopehal
<d1b2>
<azonenberg> and 19 open for scopehal-apps
<d1b2>
<azonenberg> most of which are packaging/portability related
<d1b2>
<azonenberg> What OS are you developing on?
<d1b2>
<fredzo_72653> @azonenberg just checked again, SteamBrowserDialog and FuctionGeneratorDialog sync well for me with both Siglent SDS siggen and my Owon XDG (even though that last one is outrageously slow at responding to SCPI commands...):
<d1b2>
<azonenberg> it looks like a bunch of the weird issues i've had with window management and drag-and-drop are the result of a Linux GLFW bug that's been unfixed since 2020
<d1b2>
<fredzo_72653> One thing that doesn't sync well though is the other way around (StreamBrowserDialog -> FG Dialog, same goes for PSU dialog)
<d1b2>
<azonenberg> tl;dr it tracks mouse state in a window variable which means that spawning a new OS-level window creates a false mouse up event
<d1b2>
<azonenberg> which breaks drag-and-drop
<d1b2>
<azonenberg> (as well as dragging windows out of the application window)
<d1b2>
<azonenberg> it's too late to do this right now, but it looks like the easiest path forward is going to be porting our backend from GLFW to SDL
<d1b2>
<fredzo_72653> @azonenberg I think you can close that one too : https://github.com/ngscopeclient/scopehal-apps/issues/748 I added a section i the documentation to explain how to create the MSI installer that will ship all the DLLs in the right place.
<d1b2>
<azonenberg> yes, except the CI scripts don't actually do this. we don't actually even generate a working MSI
<d1b2>
<azonenberg> we generate a tarball of the build directory
<d1b2>
<azonenberg> It seems like we have a lot of breadcrumbs but nothing pieced together
<d1b2>
<azonenberg> Getting working, automatically built MSI's is IMO one of the biggest blockers to a v0.1 release
<d1b2>
<azonenberg> I dont use windows and haven't dev'd on it in over a decade, i just have a few VMs i use from time to time to test things\
<d1b2>
<azonenberg> I'm gonna let you and @david.rysk collaborate to figure out a path forward on this
<d1b2>
<azonenberg> but it needs to happen asap
<d1b2>
<azonenberg> CPack apparently has a means to generate MSI's, we also have some separate MSI packaging flow elsewhere
<d1b2>
<azonenberg> i dont have strong feelings as to which we use, it just has to get done
<d1b2>
<fredzo_72653> OKay
<d1b2>
<azonenberg> but i will not consider these issues complete until i can pull up the github actions artifact list, grab a MSI, shove it in a virgin windows VM with no msys2 or other scopehal-specific setups on it, and have it install and run
<d1b2>
<azonenberg> And then I am planning to sync up with @lainpants in the next couple days and figure out macos packaging
<d1b2>
<azonenberg> at that point the only remaining todos will be RPM packaging (which CPack can do, its a fairly minimal extension to the existing stuff i have to generate debs - i think we just have to give it a list of package names to make the rpm depend on)
<d1b2>
<azonenberg> and then some other ancillary linux stuff like making a .desktop file so we can install it and have it show up on your applications menu
<d1b2>
<azonenberg> (and also making sure we have proper launcher icons for other platforms)
<d1b2>
<azonenberg> we still need an application icon as welll
<d1b2>
<azonenberg> afaik at least macos requires an icon to package properly
<d1b2>
<azonenberg> like, we can ship a solid colored image for early dev builds or whatever
<d1b2>
<azonenberg> but there has to be an image file