GUI crash when scrolling output window
Closed this issue · 8 comments
Hi, I got some very annoying GUI crashes when scrolling the output console window.
Seems related to imgui.
Do you have any workaround ?
Thx
error logs below :
panic: Assertion failed!
File: imgui.cpp, Line 3618
Expression: draw_list->_VtxCurrentIdx < (1 << 16) && "Too many vertices in ImDrawList using 16-bit indices. Read comment above"
goroutine 1 [running, locked to thread]:
github.com/inkyblackness/imgui-go.glob..func1(0xc00009e000, 0x73, 0xc0002d4540, 0x9, 0xe22)
/home/nico/go/pkg/mod/github.com/inkyblackness/imgui-go@v1.7.0/Assert.go:18 +0x179
github.com/inkyblackness/imgui-go.iggAssert(0x0, 0xcff5e8, 0xcfe741, 0xe22)
/home/nico/go/pkg/mod/github.com/inkyblackness/imgui-go@v1.7.0/Assert.go:31 +0xad
github.com/inkyblackness/imgui-go._cgoexpwrap_52ca0b464ede_iggAssert(0x7fff00000000, 0xcff5e8, 0xcfe741, 0xe22)
_cgo_gotypes.go:2462 +0x45
github.com/inkyblackness/imgui-go._Cfunc_iggRender()
_cgo_gotypes.go:2029 +0x41
github.com/inkyblackness/imgui-go.Render(...)
/home/nico/go/pkg/mod/github.com/inkyblackness/imgui-go@v1.7.0/imgui.go:56
main.main()
/home/nico/work/go/lds/main.go:388 +0x421
Hey, I remember I saw this a long time ago but can't recall why I wasn't able to fix it. This related issue should give some hints: ocornut/imgui#1188
@starsky35 @iegomez The issue looks like a IMGUI limitation. The only suggestion I have to the date is to limit the size of the log in a window, and duplicate output to console.
I've been wanting to try Fyne and others, so I'll check them out next week and consider porting the UI.
@iegomez Instead of creating porting to another desktop based UI, why not create an HTTP server and use JS based UI that'll work everywhere with minimal setup.
For starters, to have fun! The current project I'm working on at work has a Go backend, but it's coming to an end and I'm switching languages soon, so I'd like to have an excuse to keep using Go.
Now, if you're suggesting a JS "desktop" app, e.g. Electron based, I don't like them. If you're instead thinking it could actually be hosted at some server so it's freely available for anyone, that'd make sense, but would also mean a lot more work would need to be done to manage and isolate users.
To be honest, I built this thing in a few days with no real requirements (less so quality) whatsoever, just needed a quick working solution and it was enough. Nowadays being away from LoRaWAN development I don't know that I can justify going on a much needed refactor and cleanup for it to be really useful, let alone creating an actual web app for it, while on the other hand I'm always interested in trying new GUI libraries.
I'll give this a thought, but at this point it's probably better if you guys fork it or take over, or we decouple lds core and have it as a separate package and then any client may use it. I'd be happy to help if I have the time.
Sorry for the long answer to a quick question!
As for me, I'm no JS programmer, and frankly not much eager to dive into it. As for Electron etc. I'm here with Ignacio. However, these approaches are not exclusive.
Even now, there is a CLI (might be requires some updates) and a GUI client. And one guy is already using lds as a library. Creating an backend service for JS front-end is doable, I think, without discarding ported GUI client.
These is no need to fork, we better work on a clearer decomposition.