<d1b2>
<hansemro> @azonenberg ngscopeclient/scopehal-apps/src/imgui submodule does not point to a valid commit in the local fork of imgui. Local fork has an older docking branch compared to upstream.
<d1b2>
<azonenberg> huh i thought i had updated that. gimme a min
<d1b2>
<azonenberg> fixed now i think?
<d1b2>
<hansemro> yup, fixed
<d1b2>
<hansemro> I did some basic testing with SwiftShader software-based vulkan renderer and it does seem to work. Unlike llvmpipe/lavapipe which hangs when drawing waveforms.
<d1b2>
<azonenberg> oh that's good to know, i think we have a ticket for investigating swiftshader so you can comment your findings there
<d1b2>
<azonenberg> and yes i know llvmpipe fails, i haven't had time to investigate why
<d1b2>
<hansemro> We should probably update doc to state that llvmpipe is broken.
<d1b2>
<hansemro> Although it wouldn't really meet hardware reqs
<d1b2>
<azonenberg> did we ever say it worked?
<d1b2>
<hansemro> No, but users may find it broken when running in an non-accelerated VM
<d1b2>
<azonenberg> We can add a more explicit note to that effect, saying running in VMs without full pcie GPU passthrough is not supported, but that swiftshader might work
<d1b2>
<azonenberg> @hansemro So i'm working on adding a "lab notes" feature and wanted to bounce some things off you
<d1b2>
<azonenberg> the primary goal is to make it so that when you open a scopesession you have the opportunity to view some text attached to the session that says how stuff should be wired
<d1b2>
<azonenberg> (this is important if you're moving instruments between multiple experiments and don't want to miswire it when you reconnect)
<d1b2>
<azonenberg> Make sense?
<d1b2>
<azonenberg> The plan is to have two text fields supporting basic Markdown syntax, the first is displayed on the "speed bump" screen when loading the session before it commits changes to hardware (if you put any text there, skipped if no content)
<d1b2>
<azonenberg> the second is freeform text you can use for whatever you want and only displayed when you open the notes window
<d1b2>
<hansemro> Yes, something like this will be helpful when moving between sessions.
<d1b2>
<azonenberg> the idea for the first field is you can add stuff like "psu-left channel 1 on 12V rail, dmm-right on 3V3 test point" etc
<d1b2>
<azonenberg> and you can verify the wiring before loading the sesison and realizing your 12V supply and 3.3V supply got swapped
<d1b2>
<azonenberg> Anyway, so that's the easy part (mostly a solved problem, just have to write the code)
<d1b2>
<azonenberg> the physical embodiment will be a .md file in the data directory
<d1b2>
<azonenberg> seems silly to put it in yaml and waste effort escaping it
<d1b2>
<azonenberg> (also lets you edit/view your notes outside of ngscopeclient if the session isn't open)
<d1b2>
<azonenberg> Anyway, my question is about how to actually structure the GUI around this. There's a total of four different things the user may want to see
<d1b2>
<azonenberg> wiring information and general lab notes
<d1b2>
<azonenberg> and rendered both as editable text input and as pretty-printed markdown
<d1b2>
<azonenberg> some combination of collapsible headings and tabs and splitters seems right
<d1b2>
<azonenberg> ideas?
<d1b2>
<azonenberg> (side note: integrating markdown support means we also have the potential of adding a very lightweight in-app documentation browser in the future)
<d1b2>
<azonenberg> it's ultra lightweight, 1k lines of single header file
<d1b2>
<azonenberg> it may or may not be able to reasonably render a subset of the full app docs, e.g. some glue code is needed to support images and we may have to extend the library to support tables using imgui's native tabling
<d1b2>
<hansemro> Sorry, I'll need to spend more time on this. Considering the markdown is separate from the session file, I'd like to better understand how ngscopeclient can better integrate/view the docs compared to an external viewer.
<d1b2>
<azonenberg> The main point is that a) if you move the session the file goes with it and b) the wiring notes, if present, are forcibly displayed to the user prior to reconfiguring instruments
<d1b2>
<azonenberg> to provide a chance to double check things are cabled right
<d1b2>
<azonenberg> adding general note taking is a freebie at that point, and an in-app doc browser is more of a "we could do this" than "we should"
<d1b2>
<azonenberg> i'm not saying that's something we would want to pursue, more that it is possible
<d1b2>
<azonenberg> i will definitely be forking and sending some PRs to the markdown lib if i end up using it more, it's pretty basic and there are things i'd like to improve
<d1b2>
<azonenberg> But it was low effort and looks nicer than my original plan of plain unformatted text :p
<d1b2>
<hansemro> I do like the editor and viewer look so far. Are things updated in real-time?
<d1b2>
<azonenberg> Yes
<d1b2>
<azonenberg> it updates live, with reasonable sized demo text i've noticed no slowdowns whatsoever
<d1b2>
<azonenberg> (it actually re-renders the markdown every frame)
<d1b2>
<azonenberg> i wouldn't want to try and put a full novel in it
<d1b2>
<azonenberg> but it seems perfectly adequate for the scale of content i envision using it for
<d1b2>
<hansemro> When the window size is smaller, I think it make sense to have the editor and viewer in tabs.
<d1b2>
<azonenberg> the splitter is draggable so you can move to one or the other
<d1b2>
<hansemro> ok
<d1b2>
<azonenberg> then there's a tab bar up top to go between the setup notes and whatever other notes you want to take
<d1b2>
<hansemro> slider could also work to move between the two
<d1b2>
<azonenberg> that was one of the things i wnated feedback on
<d1b2>
<azonenberg> having the tabs and then the split view in each tab
<d1b2>
<azonenberg> it was the obvious way to me but i wasnt 100% sure it was the right way
<d1b2>
<hansemro> I think having a viewer with an edit button that moves to editor could also work. Similar to editing github gists in a sense.
<d1b2>
<hansemro> Wouldn't take advantage of live view though
<d1b2>
<azonenberg> yeah i'm open to that as well, i might even add a preference as it'd be pretty trivial to implement both in the code
<d1b2>
<azonenberg> the notes dialog is 148 lines including comments and whitespace right now lol
<d1b2>
<azonenberg> (have i mentioned i love how concise imgui code is compared to GTK? lol)
<d1b2>
<azonenberg> just a few weeks ago ngscopeclient surpassed glscopeclient in terms of number of lines of code
<d1b2>
<azonenberg> but it's so much more powerful
<d1b2>
<azonenberg> simply because the code is less excessively verbose
<d1b2>
<azonenberg> there's less boilerplate
<d1b2>
<hansemro> Guess I should be glad I started contributing after glscopeclient became deprecated.
<d1b2>
<hansemro> Not exactly sure how much gtk was used though
<d1b2>
<hansemro> scopehal dev work should almost be the same
<d1b2>
<azonenberg> yeah but the frontend was all gtk
<d1b2>
<azonenberg> all of the dialogs and ui chrome and protocol analyzer and everything was gtk
<d1b2>
<azonenberg> the only GL (and later vulkan) was actual waveform drawing
<d1b2>
<azonenberg> we did all of the decode overlays and cursors and other annotations in cairo
<d1b2>
<hansemro> How is imgui documentation?
<d1b2>
<azonenberg> which is why there's still vestiges of that in the eye pattern mask hit testing
<d1b2>
<azonenberg> doing that with cairo was natural at the time, now its clunky and brings in a bulky dependency
<d1b2>
<azonenberg> as far as imgui docs, the code is reasonably well commented and there is also an excellent demo application built in
<d1b2>
<azonenberg> that exercises basically every feature of every widget
<d1b2>
<azonenberg> debug | imgui demo
<d1b2>
<azonenberg> click around, explore
<d1b2>
<azonenberg> then open imgui_demo.cpp
<d1b2>
<azonenberg> its super easy to just string search to find any of the examples in the code and see how it was implemented
<d1b2>
<hansemro> I see
<d1b2>
<azonenberg> That demo is honestly the best reference out there for figuring out what can be done and getting a feel for interactivity and various settings
<d1b2>
<azonenberg> then the header comments have some details on exactly what specific things do
<d1b2>
<azonenberg> it's certainly a smaller, less extensive documentation set than e.g. GTK but i found it very easy to navigate and learn my way around
<d1b2>
<azonenberg> (i say that having come from a native windows API, MFC, and GTK background plus a small amount of exploration of wxwidgets)
<d1b2>
<johnsel> yeah imgui is great, super easy to work with
juri_ has quit [Ping timeout: 252 seconds]
bvernoux has joined #scopehal
juri_ has joined #scopehal
<d1b2>
<johnsel> hey when did we plan the dev call again?
<d1b2>
<johnsel> nvm got it
<d1b2>
<azonenberg> oh speaking of which i dont remember if i poked @aleksorsist about the dev call? 9AM Pacific next Monday if you didn't see already