Giter Club home page Giter Club logo

cimgui-go's Introduction

cimgui-go GoDoc

This project aims to generate go wrapper for Dear ImGui.

It comes with a default backend with GLFW 3.3 and OpenGL 3.2.

It works on macOS(arm64/x86), windows(x64), Arch Linux/KDE and Fedora Workstation 36, idealy other linux GUI should works but I don't have a linux machine to test it. Check out examples, cd in and go run ..

Current solution is:

  1. Use cimgui's lua generator to generate function and struct definition as json.
  2. Generate proper go code from the definition (via manual crafted go program /cmd/codegen).
  3. Use the backend implementation from imgui (currently glfw and opengl3).
  4. Use github workflow to compile cimgui and glfw to static lib and place them in /lib folder for further link.

Naming convention

  • For functions, 'Im/ImGui/ig' is trimmed.
  • If function comes from imgui_internal.h, Internal prefix is added.
  • Struct fields (if any exported) are prefixed with word Field

Function coverage

Currently most of the functions are generated, except memory related stuff (eg. memory allocator, storage management, etc...). If you find any function is missing, report an issue.

Generate binding

Install GNU make and run make to re-generate bunding.

Update

To update to the latest version of dependencies, run make update. After doing this, commit changes and navigate to GitHub. In Actions tab, manually trigger workflows for each platform.

How does it work?

  • cimgui/ directory holds C binding for C++ Dear ImGui libraries
  • generator bases on cimgui/{package_name}_templates and generates all necessary GO/C code
  • libs/ contains pre-built shared libraries. cimgui.go includes and uses to decrease building time.

cimgui-go's People

Contributors

allendang avatar asmaloney avatar dependabot[bot] avatar eliasdaler avatar eszdman avatar gucio321 avatar hallum avatar lzytaro avatar neclepsio avatar pgzxb avatar ptxmac avatar supergod avatar tenten8401 avatar wieku avatar winpooh32 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

cimgui-go's Issues

module: build failure

Hi, I'm having trouble building the latest code

cd examples
go run .
# github.com/AllenDang/cimgui-go
In file included from ./cimplot_wrapper.h:3,
                 from ./cimplot_structs_accessor.h:3,
                 from ../cimplot_funcs.go:4:
./cimplot/cimplot.h:7:10: fatal error: cimgui.h: No such file or directory
    7 | #include "cimgui.h"
      |          ^~~~~~~~~~
compilation terminated.

Renaming of some functions? (e.g. GetCursor, SetCursor)

What are the reasons for renaming these two functions? While I understand that "GetDrawCursor" and "SetDrawCursor" are more descriptive, I think it'll be better to avoid as much renaming as possible because then it'll be easier for people to look at imgui_demo.cpp and other Dear ImGui code and be able to port it 1-to-1 without changing much of the naming in the process.

(Doesn't apply to what's discussed in #20 since package name will acts as "ImGui/Im" prefix and will be easy to map)

implot internal support?

I want to draw candlestick. In the implot example, some internal functions must be used.

I tried to modify a little code. It seems to work normally, but I'm not sure whether there is a bug.

Cannot use GetTexDataAsAlpha8

If I use C.uchar, as stated in docs, I get: cannot use &pixels (value of type *_Ctype_uchar) as *cimgui._Ctype_uchar value in argument to io.GetFonts().GetTexDataAsAlpha8; while cimgui._Ctype_uchar is not exported.

Naming conventions?

Hello, I have a proposal.
The readme says:

For functions, 'Im/ImGui/ig' is trimmed. 'GetCursorPos' is renamed to 'GetDrawCursor', same with "SetCursor...".

Maybe we should do the same for various enums/constants/flags and even types as well? For example:

cimgui.ImGuiKey_Tab // before
cimgui.Key_Tab // after
cimgui.KeyTab // even better!
cimgui.ImGuiWindowFlags_NoCollapse // before
cimgui.WindowFlags_NoCollapse // after
cimgui.WindowFlagsNoCollapse // even better!
cimgui.ImVec2 // before
cimgui.Vec2 // after

and so on... If you agree, I can do the work and later submit the PR.

P.S. And another question - why is the package named cimgui, not imgui? I feel like naming it "imgui" will make end-user experience better, for example you could call imgui.Text instead of cimgui.Text and so on. I know that you can import cimgui-go as "imgui" and do the same, but it's better to be convenient for user by default, imo.

Also see imgui-rs as the example. It uses cimgui as well, but doesn't call itself "imgui", because after all the end user is more interested in "imgui" part more than "cimgui" part.

float* arg wrapper error

The "float *" of some method's arg represents a float array, but the current code is represented as the address of a float number. This wrapper is incorrect. I have seen the following functions, but there may be some I don't see:

// rows is array length and row_ratios is row array,cols is array length and col_ratios is column array
CIMGUI_API bool ImPlot_BeginSubplots(const char *title_id, int rows, int cols, const ImVec2 size,
                                     ImPlotSubplotFlags flags, float *row_ratios, float *col_ratios);

The current code is:
wrapFloat

func wrapFloat(goValue *float32) (wrapped *C.float, finisher func()) {
	if goValue != nil {
		cValue := C.float(*goValue)
		wrapped = &cValue
		finisher = func() {
			*goValue = float32(cValue)
		}
	} else {
		finisher = func() {}
	}
	return
}

The following simple modifications will work, but it may not be a good idea to directly access the go value addr from c code

func wrapFloat(goValue *float32) (wrapped *C.float, finisher func()) {
	if goValue != nil {
		wrapped = (*C.float)(unsafe.Pointer(goValue))
		finisher = func() {}
	} else {
		finisher = func() {}
	}
	return
}

Cannot call imgui.CurrentIO().SetIniFilename

SetIniFilename is a method of *IO, while CurrentIO() returns IO.
This is not true for IniFileName, which is a method of IO even if it has almost the same signature.

ImGuiIO_SetIniFilename(ImGuiIO *ImGuiIOPtr, const char* v)
ImGuiIO_GetIniFilename(ImGuiIO *self)

become:

func (self *IO) SetIniFilename(v string)
func (self IO) IniFilename() string 

Plot_GetPlotMousePos got panic

add Plot_GetPlotMousePosV or Plot_GetPlotMousePos got panic info:

Exception 0xc0000005 0x1 0x0 0x7ff6347ef0a8
PC=0x7ff6347ef0a8
signal arrived during external code execution

runtime.cgocall(0x7ff6347be090, 0xc00011dc28)
C:/Program Files/Go/src/runtime/cgocall.go:157 +0x4a fp=0xc00011dc00 sp=0xc00011dbc8 pc=0x7ff6346e3f8a
github.com/AllenDang/cimgui-go._Cfunc_Plot_GetPlotMousePosV(0x0, 0x0, 0x0)
_cgo_gotypes.go:46246 +0x52 fp=0xc00011dc28 sp=0xc00011dc00 pc=0x7ff634796532
github.com/AllenDang/cimgui-go.Plot_GetPlotMousePosV(...)
E:/go_project/src/pkg/mod/github.com/!allen!dang/[email protected]/cimplot_funcs.go:13
main.showImPlotDemo()
E:/go_project/src/giu_widgets/main.go:93 +0x125 fp=0xc00011dc68 sp=0xc00011dc28 pc=0x7ff63479bea5
main.loop()
E:/go_project/src/giu_widgets/main.go:107 +0x25 fp=0xc00011dc78 sp=0xc00011dc68 pc=0x7ff63479bf85
github.com/AllenDang/cimgui-go.glfwWindowLoopCallback(...)
E:/go_project/src/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:90
_cgoexp_c837ec952769_glfwWindowLoopCallback(0x2e15824c220?)
_cgo_gotypes.go:53313 +0x23 fp=0xc00011dc88 sp=0xc00011dc78 pc=0x7ff63479a8c3
runtime.cgocallbackg1(0x7ff63479a8a0, 0xc00011de48?, 0x0)
C:/Program Files/Go/src/runtime/cgocall.go:314 +0x2ca fp=0xc00011dd58 sp=0xc00011dc88 pc=0x7ff6346e452a
runtime.cgocallbackg(0xc000050000?, 0x300000002?, 0xc000050000?)
C:/Program Files/Go/src/runtime/cgocall.go:233 +0x106 fp=0xc00011ddf0 sp=0xc00011dd58 pc=0x7ff6346e4166
runtime.cgocallbackg(0x7ff63479a8a0, 0xf3625ff61f, 0x0)
:1 +0x36 fp=0xc00011de18 sp=0xc00011ddf0 pc=0x7ff63473ffd6
runtime.cgocallback(0x7ff6346e3feb, 0x7ff63479c430, 0xc00011dea8)
C:/Program Files/Go/src/runtime/asm_amd64.s:971 +0xd7 fp=0xc00011de40 sp=0xc00011de18 pc=0x7ff63473ddf7
runtime.systemstack_switch()
C:/Program Files/Go/src/runtime/asm_amd64.s:436 fp=0xc00011de48 sp=0xc00011de40 pc=0x7ff63473bce0
runtime.cgocall(0x7ff63479c430, 0xc00011dea8)
C:/Program Files/Go/src/runtime/cgocall.go:167 +0xab fp=0xc00011de80 sp=0xc00011de48 pc=0x7ff6346e3feb
github.com/AllenDang/cimgui-go._Cfunc_igRunLoop(0x2e1581f9da0, 0x7ff63479c190, 0x7ff63479c1d0, 0x7ff63479c210, 0x7ff63479c290)
_cgo_gotypes.go:53270 +0x52 fp=0xc00011dea8 sp=0xc00011de80 pc=0x7ff634797532
github.com/AllenDang/cimgui-go.GLFWwindow.Run.func1(0xc00000e1b0?)
E:/go_project/src/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:72 +0x9b fp=0xc00011df08 sp=0xc00011dea8 pc=0x7ff6347978fb
github.com/AllenDang/cimgui-go.GLFWwindow.Run(0xc000068040?, 0xc000012300?)
E:/go_project/src/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:72 +0x37 fp=0xc00011df20 sp=0xc00011df08 pc=0x7ff634797837
main.main()
E:/go_project/src/giu_widgets/main.go:131 +0x178 fp=0xc00011df80 sp=0xc00011df20 pc=0x7ff63479c158
runtime.main()
C:/Program Files/Go/src/runtime/proc.go:250 +0x1fe fp=0xc00011dfe0 sp=0xc00011df80 pc=0x7ff6347174de
runtime.goexit()
C:/Program Files/Go/src/runtime/asm_amd64.s:1571 +0x1 fp=0xc00011dfe8 sp=0xc00011dfe0 pc=0x7ff63473e061
rax 0xf3625ff460
rbx 0x0
rcx 0x0
rdi 0xc00011dc28
rsi 0x7ff634c24160
rbp 0xc00011dbf0
rsp 0xf3625ff440
r8 0x0
r9 0x0
r10 0x0
r11 0x1
r12 0x7ff634b1e8b0
r13 0x10
r14 0xc000050000
r15 0x2e17d73ffff
rip 0x7ff6347ef0a8
rflags 0x10202
cs 0x33
fs 0x53
gs 0x2b

source code:

`var p cimgui.ImPlotPoint
var x,y cimgui.ImAxis

func showImPlotDemo() {
basePos := cimgui.GetMainViewport().GetPos()
cimgui.SetNextWindowPosV(cimgui.NewImVec2(basePos.X+400, basePos.Y+60), cimgui.ImGuiCond_Once, cimgui.NewImVec2(0, 0))
cimgui.SetNextWindowSizeV(cimgui.NewImVec2(500, 300), cimgui.ImGuiCond_Once)
cimgui.Begin("Plot window")
if cimgui.Plot_BeginPlotV("Plot", cimgui.NewImVec2(-1, -1), 0) {
cimgui.Plot_PlotLine_S64PtrInt("Line", barValues, int32(len(barValues)))

	cimgui.Plot_GetPlotMousePosV(p, x, y)
	//cimgui.Plot_GetPlotMousePos(p)
	
	cimgui.Plot_EndPlot()
}
cimgui.End()

}`

crash with go-findfont package

go version go1.19.3 linux/amd64
gcc (GCC) 12.2.0
system: archlinux

When I use the go-findfont package, if I call it too many times, the program will crash.(In the actual code, of course, I only call setupFont once, but sometimes it still crashes when mixed with other codes)
If I set GOGC=off, the program can run normally,.
So I think maybe the c code incorrectly references some memory in go

crash log:

setupFont
setupFont finished
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x840 pc=0x7f32172c4c29]

runtime stack:
runtime.throw({0x8b9e6d?, 0x2031?})
        /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0x7f31ee5e3cb8 sp=0x7f31ee5e3c88 pc=0x50c0fd
runtime.sigpanic()
        /usr/lib/go/src/runtime/signal_unix.go:819 +0x369 fp=0x7f31ee5e3d08 sp=0x7f31ee5e3cb8 pc=0x520289

goroutine 1 [syscall]:
runtime.cgocall(0x58bb10, 0xc000075ea0)
        /usr/lib/go/src/runtime/cgocall.go:158 +0x5c fp=0xc000075e78 sp=0xc000075e40 pc=0x4dca3c
github.com/AllenDang/cimgui-go._Cfunc_igRunLoop(0x17123b0, 0x58b770, 0x58b7e0, 0x58b850, 0x58b930)
        _cgo_gotypes.go:53150 +0x45 fp=0xc000075ea0 sp=0xc000075e78 pc=0x588065
github.com/AllenDang/cimgui-go.GLFWwindow.Run.func1(0x0?)
        /home/super/code/go/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:76 +0x9b fp=0xc000075f00 sp=0xc000075ea0 pc=0x58849b
github.com/AllenDang/cimgui-go.GLFWwindow.Run(0x8d7778?, 0xc000014018?)
        /home/super/code/go/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:76 +0x37 fp=0xc000075f18 sp=0xc000075f00 pc=0x5883d7
main.main()
        /home/super/code/gocode/imguitest/main.go:36 +0x18b fp=0xc000075f80 sp=0xc000075f18 pc=0x58b6cb
runtime.main()
        /usr/lib/go/src/runtime/proc.go:250 +0x212 fp=0xc000075fe0 sp=0xc000075f80 pc=0x50e952
runtime.goexit()
        /usr/lib/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000075fe8 sp=0xc000075fe0 pc=0x537d61

......

code:

package main

import (
	"fmt"

	"github.com/AllenDang/cimgui-go"
	"github.com/flopp/go-findfont"
)

func afterCreateContext() {
	cimgui.Plot_CreateContext()
}

func beforeDestoryContext() {
	cimgui.Plot_DestroyContext()
}

func loop() {
	cimgui.Begin("Hello")
	cimgui.Text("Hello world")
	cimgui.End()
}

func main() {
	cimgui.SetAfterCreateContextHook(afterCreateContext)
	cimgui.SetBeforeDestroyContextHook(beforeDestoryContext)

	cimgui.SetBgColor(cimgui.NewImVec4(0.45, 0.55, 0.6, 1.0))
	window := cimgui.CreateGlfwWindow("hello", 800, 600, 0)
	fmt.Println("setupFont")
	for i := 0; i != 200; i++ {
		setupFont()
	}

	fmt.Println("setupFont finished")
	window.Run(loop)
}

func setupFont() {
	fontPath, err := findfont.Find("wqy-microhei")
	if err != nil {
		fmt.Println("found font failed")
		return
	}
	_ = fontPath
}

float32 array arguments

ColorPicker?V functions take a [?]*float32 arguments. I think a *[?]float32 would be a more practical choice. Compare:

color := [3]float32{}
col := [3]*float32{&color[0], &color[1], &color[2]}
imgui.ColorPicker3V(id, col, cpFlags)

With:

color := [3]float32{}
imgui.ColorPicker3V(id, &color, cpFlags)

Crash when using glyph ranges when using AddFonts

There's a crash when using glyph ranges because in extra_types.go you define Wchar as C.uint, while cimgui.h defines it as C.ImWchar32.

Also, if IMGUI_USE_WCHAR32 is not defined the type should be C.ushort. Looking at GitHub Actions and cimgui.h, it seems to me that IMGUI_USE_WCHAR32 is indeed used.

Changing Wchar to C.ImWchar in extra_types.go the crash is not solved.

Changing Wchar to C.ImWchar16 in extra_types.go and typedef ImWchar32 ImWchar to typedef ImWchar16 ImWchar in cimgui.h the crash is solved. So it seems that there is a mismatch between cimgui.h and imgui.a (only testend on Windows).

idea: add comment on top of auto-generated files

Sometimes it is hard to find out whether we can edit the file or after the next re-generation our changes will just disappear

IMO it shouldn't be hard to add a code in cmd/codegen that puts the comment like that below on top of auto-generated files

// This file is auto-generated by cmd/codegen. DO NOT EDIT

GitHub repository setup

Hi @AllenDang
thank you for inviting me to collaborating on this repository!

I've a proposal about setting up a branch-protection-rules.
In my opinion the protection rule should now enforce at least one PR review. This way, one person would give approval, and another one will merge. This will reduce a possibility of merging bugged code to master 😄

we should also add some auto-tests. e.g. a simple workflow file that will run go test ./... to ensure the code isn't buildable

Algebra for ImVec2 and ImVec4

Please, provide algebraic functions for ImVec2 and ImVec4, e.g.:

pos := cimgui.ImVec2{}
pos = pos.Plus(cimgui.ImVec2{}).Minus(cimgui.ImVec2{}).Times(2)

Support *Scalar functions

I was looking for a DragDouble widget, but imgui has been implementing new datatypes using the *Scalar widgets instead.

These work just like DragInt/Float/Etc but takes an enum declaring the type and a void pointer to the data.

For this to work from go we need a way to manually wrap the go pointer, i.e. make wrapNumberPtr public.

Or perhaps implement DragScalar with a switch that will type-cast based on the DataType.

something like:

func DragScalar(label string, data_type DataType, p_data unsafe.Pointer) bool {
	labelArg, labelFin := wrapString(label)
	defer labelFin()

        switch (data_type) {
        case DataType_Double:
             	vArg, vFin = wrapNumberPtr[C.double, float64](v)
        } 

      	defer vFin()

	return C.DragScalar(labelArg, C.ImGuiDataType(data_type), vArg) == C.bool(true)
}

InputText(...) may have wrong arg types

InputText may have wrong arguments with InputText(label string, buf string, buf_size uint64).
Should be InputText(label string, buf *string) ?

My demo now panic with following code:

var inputString string

func showImDemo() {
	cimgui.SetNextWindowPos(cimgui.GetMainViewport().GetPos())
	cimgui.SetNextWindowSize(cimgui.GetMainViewport().GetSize())

	cimgui.Begin("mainwindow")
	cimgui.InputText("input something", inputString, 100)
	cimgui.End()
}

extra_types.go: trim Im* prefix

Hi,
there are still Im* prefixes in type declarations in extra_types.go (ImVec2, ImVec4 e.t.c.)
These files are not auto-generated, but the prefix should be probably removed.

cmd/codegen: `returnWrapper`'s type

type returnWrapper func(f FuncDef) (returnType string, returnStmt string)

takes FuncDef as an argument, but as far as I can see, it is never used in ret_wrapper.go

shouldn't it be removed?

Maybe use go tpl go generate code?

Hi, I have tried to use the go template to implement the go binding of cimgui, but of course I haven't finished(Because there are some complex C callback functions).
But I still think that template is more simpler, so why not use template to implement it?

Another of my projects uses templates to implement: https://github.com/ztrade/ctpgen/blob/main/tpl/api.tpl

If you need, I can give you my unfinished template or provide some help

Improved readme: works on (at least some) linux distributions, too :heart_eyes:

README.md says right now:

It works on macOS(arm64/x86) and windows(x64) now, idealy linux should works but I don't have a linux machine to test it. Check out examples, cd in and go run ..

Just did with some latest Arch Linux/KDE distribution, worked fine out of the box... will checkout on Pop! OS/Gnome in the upcoming few days, too... gonna comment that here, too.

Thank you all for your work regarding imgui+golang... really appreciate all that effort... makes my "learning Go while fiddling with some cross-platform UI" really, really fun and enjoyable ❤️

Screenshot_20220924_113630

array args: automatically determine len of array

Hi there!
There are some functions, e.g.

CIMGUI_API bool igCombo_Str_arr(const char* label,int* current_item,const char* const items[],int items_count,int popup_max_height_in_items);

or in go

func Combo_Str_arrV(label string, current_item *int32, items []string, items_count int32, popup_max_height_in_items int32) bool { ... }

These functions takes an array of strings as well as its length (if I understand the code correctly 😄)
However, in go we can handle array's length with len(...) built-in function that isn't possible in C iirc.

Is there any way in cimgui JSON defs to recognize such a function like it ws for #11 ?

CC @sonoro1234

data race

STATUS

output of -race build of examples/ for c134d03284e7663121db54071010751d5e2de168
[examples (0) ]$ go run -race .
fatal error: checkptr: pointer arithmetic computed bad pointer value

goroutine 1 [running, locked to thread]:
runtime.throw({0x93d1da?, 0x5465f9?})
	/usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0xc0000a3a68 sp=0xc0000a3a38 pc=0x51785d
runtime.checkptrArithmetic(0x623dc0?, {0x0?, 0x1c309f8?, 0x0?})
	/usr/local/go/src/runtime/checkptr.go:52 +0xbb fp=0xc0000a3a98 sp=0xc0000a3a68 pc=0x4eae1b
github.com/AllenDang/cimgui-go.ImageV.func1(0x1, {0x5cd5cc?, 0x0?}, {0x3ce1d00?, 0x0?}, {0x3ce1d00?, 0x0?}, {0x0?, 0x0?, 0x0?, ...}, ...)
	/home/mszeptuch/git/cimgui-go/cimgui_funcs.go:3892 +0xae fp=0xc0000a3b28 sp=0xc0000a3a98 pc=0x5c9f6e
github.com/AllenDang/cimgui-go.ImageV(0xc00001a1e5?, {0xb?, 0x0?}, {0xa3c20?, 0xc0?}, {0x1?, 0x0?}, {0x1?, 0x0?, 0x1c30ac0?, ...}, ...)
	/home/mszeptuch/git/cimgui-go/cimgui_funcs.go:3892 +0xf6 fp=0xc0000a3bb8 sp=0xc0000a3b28 pc=0x5c9dd6
main.showPictureLoadingDemo()
	/home/mszeptuch/git/cimgui-go/examples/main.go:80 +0x1aa fp=0xc0000a3c40 sp=0xc0000a3bb8 pc=0x5d11aa
main.loop()
	/home/mszeptuch/git/cimgui-go/examples/main.go:104 +0x2a fp=0xc0000a3c58 sp=0xc0000a3c40 pc=0x5d146a
github.com/AllenDang/cimgui-go.glfwWindowLoopCallback(...)
	/home/mszeptuch/git/cimgui-go/backend.go:95
_cgoexp_3a92ce97b578_glfwWindowLoopCallback(0x0?)
	_cgo_gotypes.go:58033 +0x51 fp=0xc0000a3c70 sp=0xc0000a3c58 pc=0x5cde31
runtime.cgocallbackg1(0x5cdde0, 0xc0000a3e28?, 0x0)
	/usr/local/go/src/runtime/cgocall.go:316 +0x2ce fp=0xc0000a3d40 sp=0xc0000a3c70 pc=0x4e79ae
runtime.cgocallbackg(0xc0000061a0?, 0x300000002?, 0xc0000061a0?)
	/usr/local/go/src/runtime/cgocall.go:235 +0x109 fp=0xc0000a3dd0 sp=0xc0000a3d40 pc=0x4e7629
runtime.cgocallbackg(0x5cdde0, 0x7ffc195f1c4f, 0x0)
	<autogenerated>:1 +0x2f fp=0xc0000a3df8 sp=0xc0000a3dd0 pc=0x54778f
runtime.cgocallback(0x4e74b2, 0x5d1bd0, 0xc0000a3e88)
	/usr/local/go/src/runtime/asm_amd64.s:994 +0xb4 fp=0xc0000a3e20 sp=0xc0000a3df8 pc=0x544c54
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:459 fp=0xc0000a3e28 sp=0xc0000a3e20 pc=0x542c60
runtime.cgocall(0x5d1bd0, 0xc0000a3e88)
	/usr/local/go/src/runtime/cgocall.go:168 +0x92 fp=0xc0000a3e60 sp=0xc0000a3e28 pc=0x4e74b2
github.com/AllenDang/cimgui-go._Cfunc_igRunLoop(0x346bb80, 0x5d1950, 0x5d1990, 0x5d19d0, 0x5d1a50)
	_cgo_gotypes.go:15724 +0x79 fp=0xc0000a3e88 sp=0xc0000a3e60 pc=0x5c6fb9
github.com/AllenDang/cimgui-go.GLFWwindow.Run.func1(0x346bb80)
	/home/mszeptuch/git/cimgui-go/backend.go:77 +0xf4 fp=0xc0000a3ee8 sp=0xc0000a3e88 pc=0x5c90d4
github.com/AllenDang/cimgui-go.GLFWwindow.Run(0x93767b?, 0x93e0e8)
	/home/mszeptuch/git/cimgui-go/backend.go:77 +0x66 fp=0xc0000a3f08 sp=0xc0000a3ee8 pc=0x5c8fa6
main.main()
	/home/mszeptuch/git/cimgui-go/examples/main.go:130 +0x298 fp=0xc0000a3f80 sp=0xc0000a3f08 pc=0x5d1798
runtime.main()
	/usr/local/go/src/runtime/proc.go:250 +0x212 fp=0xc0000a3fe0 sp=0xc0000a3f80 pc=0x51a0b2
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc0000a3fe8 sp=0xc0000a3fe0 pc=0x544e81

goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000060fb0 sp=0xc000060f90 pc=0x51a476
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.forcegchelper()
	/usr/local/go/src/runtime/proc.go:302 +0xad fp=0xc000060fe0 sp=0xc000060fb0 pc=0x51a30d
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000060fe8 sp=0xc000060fe0 pc=0x544e81
created by runtime.init.6
	/usr/local/go/src/runtime/proc.go:290 +0x25

goroutine 3 [GC sweep wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000061790 sp=0xc000061770 pc=0x51a476
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.bgsweep(0x0?)
	/usr/local/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000617c8 sp=0xc000061790 pc=0x50740e
runtime.gcenable.func1()
	/usr/local/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000617e0 sp=0xc0000617c8 pc=0x4fc2e6
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc0000617e8 sp=0xc0000617e0 pc=0x544e81
created by runtime.gcenable
	/usr/local/go/src/runtime/mgc.go:178 +0x6b

goroutine 4 [GC scavenge wait]:
runtime.gopark(0xc000088000?, 0x95f2a8?, 0x1?, 0x0?, 0x0?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000061f70 sp=0xc000061f50 pc=0x51a476
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.(*scavengerState).park(0xad7a20)
	/usr/local/go/src/runtime/mgcscavenge.go:389 +0x53 fp=0xc000061fa0 sp=0xc000061f70 pc=0x5054d3
runtime.bgscavenge(0x0?)
	/usr/local/go/src/runtime/mgcscavenge.go:617 +0x45 fp=0xc000061fc8 sp=0xc000061fa0 pc=0x505a85
runtime.gcenable.func2()
	/usr/local/go/src/runtime/mgc.go:179 +0x26 fp=0xc000061fe0 sp=0xc000061fc8 pc=0x4fc286
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000061fe8 sp=0xc000061fe0 pc=0x544e81
created by runtime.gcenable
	/usr/local/go/src/runtime/mgc.go:179 +0xaa

goroutine 5 [finalizer wait]:
runtime.gopark(0xc000007860?, 0x0?, 0x0?, 0x5?, 0xc000060770?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000060628 sp=0xc000060608 pc=0x51a476
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.runfinq()
	/usr/local/go/src/runtime/mfinal.go:180 +0x145 fp=0xc0000607e0 sp=0xc000060628 pc=0x4fb405
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc0000607e8 sp=0xc0000607e0 pc=0x544e81
created by runtime.createfing
	/usr/local/go/src/runtime/mfinal.go:157 +0x45
exit status 2

If I remember correctly, here was the fix: AllenDang/giu#30

webgl support?

Hi there!
IT IS AWESOME!!!!!!! Finally there is some imgui wrapper that is 100% automatic ;-)

What should be done to support WebGl? for now, the build output looks as follows:

[examples (0) ]$ GOOS="js" GOARCH="wasm" go build -o main.wasm main.go 
# github.com/AllenDang/cimgui-go
../texture.go:18:9: undefined: ImTextureID
../texture.go:24:11: undefined: CreateTextureRgba
../texture.go:43:2: undefined: DeleteTexture
../texture.go:46:24: undefined: ImTextureID

let me know if I can help ;-)

GLFW Backend and it’s place within the library

Currently, we have a GLFW backend as a part of "main" repo, but should it stay that way?

I think it might be better to move it to "examples" directory, because you can use cimgui-go without it by implementing another backend with a lib of your choice.

For example, I managed to get cimgui-go working with Ebitengine. I even believe it might be a "better" example, because it’s (almost) a pure Go library, plays better with Go ecosystem, and doesn’t require you to use CGo (so the only CGo code left is between your program and Dear ImGui itself).

So, my proposal is this:

A. Move glfw backend to "example/glfw" directory.

OR

B. If you want to make glfw backend a reusable package, I believe that making it a separate repo might be better (kinda like imgui-go did with [this repo](https://github.com/inkyblackness/imgui-go-examples, but don’t make backend impl "internal")

go vendor does not work

I feel like I'm missing a piece of the puzzle 🧩 to getting started with this...

Edit: In case you don't want to read this whole thread:

It's a go vendor issue (which they won't fix). go vendor won't vendor any directories unless they contain a go file (which C/C++ libraries obviously won't) and there's no way to request that it do so.

--

I'm trying to use it like any other go package.

go get "github.com/AllenDang/cimgui-go"
go mod vendor

I import:

import (
	"github.com/AllenDang/cimgui-go"
)

It shows up properly in my go.mod:

require github.com/AllenDang/cimgui-go v0.0.0-20221118092040-698de0565142

But when I go build my application:

% go build
# github.com/AllenDang/cimgui-go
In file included from vendor/github.com/AllenDang/cimgui-go/backend.go:20:
In file included from ./backend.h:3:
./cimgui_wrapper.h:3:10: fatal error: 'cimgui/cimgui.h' file not found
#include "cimgui/cimgui.h"
         ^~~~~~~~~~~~~~~~~
1 error generated.

If I clone this repo separately and go build it seems to build fine.

I'm guessing it has to do with the way vendored modules work? Any idea how to fix it?

How can i use ImGuiWindowFlags?

Hello,
Where do i put my ImGuiWindowFlags like ImGuiWindowFlags_NoResize, ImGuiWindowFlags_NoTitleBar or ImGuiWindowFlags_NoCollapse?

I tried here but no luck:
cimgui.CreateGlfwWindow("Hello from cimgui-go", 1200, 900, cimgui.ImGuiWindowFlags_NoResize)

Thanks

Avoiding race conditions with multiple threads and live update

I want to make a background thread that will update a structure and have it displayed with imgui at the same time. What can I do to achieve this? Will values "automagically" update or should I call loop function myself each time I want to update frame?

All my attempts with multiple gorutines ended up having race over random variables.

Also more general glfw question: how to safely quit from inside of loop function? (aka exit button)

Reasons for using "just" build system?

Hello again.
I was wondering why "just" was used as a build system.
I see that GNU Make was previously used, so what are the reasons for going with a non-standard build system? (especially seeing how Makefile wasn't that complicated)

I also see that cimgui-go depends on CMake for building, so maybe it should go with it instead? (I can implement CMake build if you agree)

ImGuiInputTextCallbackData.GetEventKey() always returns 0.

Hi, i can't get last pressed char with this function. Returns always 0.

...
cimgui.InputTextWithHint("##label1", "", &var1, cimgui.ImGuiInputTextFlags_CallbackEdit, callback)
...

func callback(data cimgui.ImGuiInputTextCallbackData) int {
	fmt.Println(data.GetEventKey())
	return 0
}

Idea: move implot functions to a separate package

Hello. When working on #20, I've noticed that some enum names can clash if we remove prefixes, e.g. ImAxis from implot and ImGuiAxis from Dear ImGui.

This got me thinking... what if we move all implot things to a directory called "implot" and call this package "implot as well"? This way, people would be able to do this:

import "github.com/AllenDang/cimgui-go/implot"

// later in code
implot.SomeFunc()

and people who don't use implot won't get their autocomplete suggestions polluted by implot funcs/enums/structs if they don't want to use them.

Example: image not working

  • macOS 12.6.1
  • Radeon Pro 580X 8 GB

Using the code (and the test.jpeg file) in the example directory, I get this:

Screen Shot 2022-11-23 at 15 17 38 PM

Tried with a PNG - same result.

The rest works though - cool!

PlotLines have wrong signature

PlotLines_FloatPtr takes a float pointer instead of a slice.
This would be fine if the pointer was forwarded to imgui, but instead it's dereferenced which means PlotLines only gets a single value

Convenience functions with sensible defaults

Hello, I've recently encountered this #9 after not finding imgui.InputText anywhere. Of course, I can make something like this:

func InputText(label string, buf *string) bool {
	return imgui.InputTextWithHint(label, "", buf, 0, nil)
}

... but wouldn't it be convenient to have this in cimgui-go for many others as well?

Same goes for not having cimgui.Image and using cimgui.ImageV instead and so on.

So, what's your opinion on adding various helpers like that? imgui-go had lots of them and it made writing Dear ImGui code in Go as good as in C++ if not better.

cimplot doesn't work

Hi!
cimplot wrapper doesn't seem to work at all:

package main

import (
	"github.com/AllenDang/cimgui-go"
	"github.com/AllenDang/giu"
)

func loop() {
	giu.SingleWindow().Layout(
		giu.Label("my plot"),
		giu.Custom(func() {
			if cimgui.Plot_BeginPlot("my plot") {
				//cimgui.Plot_PlotBars_FloatPtrInt("my plot!", []float32{50}, 1)
				//c := cimgui.Plot_GetPlotDrawList()
				//cmds := c.Commands()
				//cr := cmds[len(cmds)-1].GetClipRect()
				//out := cimgui.ImVec2{}
				//cimgui.Plot_PlotToPixels_double(&out, float64(cr.X), float64(cr.Y))
				//fmt.Println(out)
				cimgui.Plot_EndPlot()
			}
		}),
	)
}

func main() {
	wnd := giu.NewMasterWindow("Labels on plot", 640, 480, 0)
	wnd.Run(loop)
}
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x58 pc=0x69a504]

runtime stack:
runtime.throw({0x97f25e?, 0xc0000061a0?})
	/usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7fff8b400210 sp=0x7fff8b4001e0 pc=0x50d97d
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:819 +0x369 fp=0x7fff8b400260 sp=0x7fff8b400210 pc=0x5233a9

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x646f90, 0xc00015fb60)
	/usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc00015fb38 sp=0xc00015fb00 pc=0x4dcb5c
github.com/AllenDang/cimgui-go._Cfunc_Plot_BeginPlot(0x19af0a0)
	_cgo_gotypes.go:45509 +0x45 fp=0xc00015fb60 sp=0xc00015fb38 pc=0x596e85
github.com/AllenDang/cimgui-go.Plot_BeginPlot({0x9752fd?, 0x3000000030?})
	/home/mszeptuch/go/pkg/mod/github.com/!allen!dang/[email protected]/cimplot_funcs.go:1660 +0x4b fp=0xc00015fb90 sp=0xc00015fb60 pc=0x5999cb
main.loop.func1()
	/home/mszeptuch/git/giu/examples/label-on-plot/main.go:12 +0x25 fp=0xc00015fbb0 sp=0xc00015fb90 pc=0x629325
github.com/AllenDang/giu.(*CustomWidget).Build(0xc0002227a0?)
	/home/mszeptuch/git/giu/ExtraWidgets.go:308 +0x1f fp=0xc00015fbc0 sp=0xc00015fbb0 pc=0x626b1f
github.com/AllenDang/giu.Layout.Build(...)
	/home/mszeptuch/git/giu/Layout.go:28
github.com/AllenDang/giu.(*WindowWidget).Layout(0xc000177dc0, {0xc00015fc48?, 0x2, 0xc00015fc50?})
	/home/mszeptuch/git/giu/Window.go:114 +0x1ca fp=0xc00015fc08 sp=0xc00015fbc0 pc=0x628f8a
main.loop()
	/home/mszeptuch/git/giu/examples/label-on-plot/main.go:9 +0x105 fp=0xc00015fc78 sp=0xc00015fc08 pc=0x629465
github.com/AllenDang/cimgui-go.glfwWindowLoopCallback(...)
	/home/mszeptuch/go/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:94
_cgoexp_fd25f527374f_glfwWindowLoopCallback(0x8?)
	_cgo_gotypes.go:53206 +0x23 fp=0xc00015fc88 sp=0xc00015fc78 pc=0x59a583
runtime.cgocallbackg1(0x59a560, 0xc00015fe40?, 0x0)
	/usr/local/go/src/runtime/cgocall.go:316 +0x2c2 fp=0xc00015fd58 sp=0xc00015fc88 pc=0x4dd082
runtime.cgocallbackg(0xc0000061a0?, 0x300000002?, 0xc0000061a0?)
	/usr/local/go/src/runtime/cgocall.go:235 +0x109 fp=0xc00015fde8 sp=0xc00015fd58 pc=0x4dcd09
runtime.cgocallbackg(0x59a560, 0x7fff8b40040f, 0x0)
	<autogenerated>:1 +0x2f fp=0xc00015fe10 sp=0xc00015fde8 pc=0x53de4f
runtime.cgocallback(0x4dcb85, 0x629750, 0xc00015fea0)
	/usr/local/go/src/runtime/asm_amd64.s:994 +0xb4 fp=0xc00015fe38 sp=0xc00015fe10 pc=0x53b954
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:459 fp=0xc00015fe40 sp=0xc00015fe38 pc=0x539960
runtime.cgocall(0x629750, 0xc00015fea0)
	/usr/local/go/src/runtime/cgocall.go:168 +0x85 fp=0xc00015fe78 sp=0xc00015fe40 pc=0x4dcb85
github.com/AllenDang/cimgui-go._Cfunc_igRunLoop(0x1138b80, 0x6294d0, 0x629510, 0x629550, 0x6295d0)
	_cgo_gotypes.go:53150 +0x45 fp=0xc00015fea0 sp=0xc00015fe78 pc=0x597da5
github.com/AllenDang/cimgui-go.GLFWwindow.Run.func1(0x1138b80?)
	/home/mszeptuch/go/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:76 +0x9b fp=0xc00015ff00 sp=0xc00015fea0 pc=0x5980fb
github.com/AllenDang/cimgui-go.GLFWwindow.Run(0x1e0?, 0x0?)
	/home/mszeptuch/go/pkg/mod/github.com/!allen!dang/[email protected]/backend.go:76 +0x37 fp=0xc00015ff18 sp=0xc00015ff00 pc=0x598037
github.com/AllenDang/giu.(*MasterWindow).Run(0x97716e?, 0xe?)
	/home/mszeptuch/git/giu/MasterWindow.go:89 +0x46 fp=0xc00015ff48 sp=0xc00015ff18 pc=0x627c26
main.main()
	/home/mszeptuch/git/giu/examples/label-on-plot/main.go:28 +0x3d fp=0xc00015ff80 sp=0xc00015ff48 pc=0x6294bd
runtime.main()
	/usr/local/go/src/runtime/proc.go:250 +0x212 fp=0xc00015ffe0 sp=0xc00015ff80 pc=0x5101d2
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc00015ffe8 sp=0xc00015ffe0 pc=0x53bb81

goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000060fb0 sp=0xc000060f90 pc=0x510596
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.forcegchelper()
	/usr/local/go/src/runtime/proc.go:302 +0xad fp=0xc000060fe0 sp=0xc000060fb0 pc=0x51042d
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000060fe8 sp=0xc000060fe0 pc=0x53bb81
created by runtime.init.6
	/usr/local/go/src/runtime/proc.go:290 +0x25

goroutine 3 [GC sweep wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000061790 sp=0xc000061770 pc=0x510596
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.bgsweep(0x0?)
	/usr/local/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000617c8 sp=0xc000061790 pc=0x4fcfee
runtime.gcenable.func1()
	/usr/local/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000617e0 sp=0xc0000617c8 pc=0x4f1ea6
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc0000617e8 sp=0xc0000617e0 pc=0x53bb81
created by runtime.gcenable
	/usr/local/go/src/runtime/mgc.go:178 +0x6b

goroutine 4 [GC scavenge wait]:
runtime.gopark(0xc000088000?, 0x9c53c0?, 0x1?, 0x0?, 0x0?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000061f70 sp=0xc000061f50 pc=0x510596
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.(*scavengerState).park(0xb938a0)
	/usr/local/go/src/runtime/mgcscavenge.go:389 +0x53 fp=0xc000061fa0 sp=0xc000061f70 pc=0x4fb093
runtime.bgscavenge(0x0?)
	/usr/local/go/src/runtime/mgcscavenge.go:617 +0x45 fp=0xc000061fc8 sp=0xc000061fa0 pc=0x4fb665
runtime.gcenable.func2()
	/usr/local/go/src/runtime/mgc.go:179 +0x26 fp=0xc000061fe0 sp=0xc000061fc8 pc=0x4f1e46
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000061fe8 sp=0xc000061fe0 pc=0x53bb81
created by runtime.gcenable
	/usr/local/go/src/runtime/mgc.go:179 +0xaa

goroutine 18 [finalizer wait]:
runtime.gopark(0xb93d60?, 0xc0001024e0?, 0x0?, 0x0?, 0xc000060770?)
	/usr/local/go/src/runtime/proc.go:363 +0xd6 fp=0xc000060628 sp=0xc000060608 pc=0x510596
runtime.goparkunlock(...)
	/usr/local/go/src/runtime/proc.go:369
runtime.runfinq()
	/usr/local/go/src/runtime/mfinal.go:180 +0x10f fp=0xc0000607e0 sp=0xc000060628 pc=0x4f0faf
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc0000607e8 sp=0xc0000607e0 pc=0x53bb81
created by runtime.createfing
	/usr/local/go/src/runtime/mfinal.go:157 +0x45
exit status 2

Panic when exiting with window manager help (e.g. ALT+F4) without SetBeforeDestroyContextHook after loading own fonts

cimgui-go 91ad638

Trying to add font from embed.FS like this:

	normalFontBytes, _ := assets.Assets.ReadFile("fonts/JetBrainsMono-Regular.ttf")
	_ = imgui.CurrentIO().Fonts().AddFontFromMemoryTTF(unsafe.Pointer(&normalFontBytes), 17, 1.0)

And got this:

panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 1 [running]:
github.com/AllenDang/cimgui-go.FontAtlas.AddFontFromMemoryTTF.func1(0xc00006de50?, 0x589339?, 0x6de60?, 0x3f800000)
        /home/pztrn/go/pkg/mod/github.com/!allen!dang/[email protected]/cimgui_funcs.go:4195 +0x5a
github.com/AllenDang/cimgui-go.FontAtlas.AddFontFromMemoryTTF(0x7fa7e424ba38?, 0x8bdb2e?, 0x1f?, 0x0?)
        /home/pztrn/go/pkg/mod/github.com/!allen!dang/[email protected]/cimgui_funcs.go:4195 +0x19

Memory is used after C.free call at SetIniFilename

func wrapString(value string) (wrapped *C.char, finisher func()) {
	wrapped = C.CString(value)
	finisher = func() { C.free(unsafe.Pointer(wrapped)) } // nolint: gas
	return
}

func (self IO) SetIniFilename(v string) {
	vArg, vFin := wrapString(v)
	defer vFin()

	C.wrap_ImGuiIO_SetIniFilename(self.handle(), vArg)
}

imgui internally stores pointer to the string and uses it when required, but it happens after C.free was called from GO wrapper.

Can be reproduced with this code:

...
	window = imgui.CreateGlfwWindow("Hello from cimgui-go", 1200, 900, 0)

	context := imgui.CurrentContext()

	io := imgui.CurrentIO()
	io.SetIniFilename("imgui.ini")
	
	window.Run(loop)

Invalid Vec2 wrapper

It seems a lot of top-level functions that return Vec2 are using invalid wrappers.

As an example lets look at CursorScreenPos():

func CursorScreenPos() Vec2 {
	pOut := &Vec2{}
	pOutArg, pOutFin := wrap[C.ImVec2, *Vec2](pOut)
	defer pOutFin()

	C.igGetCursorScreenPos(pOutArg)
	return *pOut
}

// pOutFin does something like this:

func() {
	*pOut = NewVec2(float32(vec2.x), float32(vec2.y))
}

The problem is that return is evaluated before defer, which means the value in *pOut have already been copied before pOutFin is run.

See https://go.dev/play/p/umxyz3I35hT for a minimal demonstration

One solution would be to call the pOutFin explicitly after the c call instead of using defer - this ensures the finalizer is completed before the return value is copied

CrossBuild Linux to Windows/Darwin

image

Linux to Linux 64/32 bit:
GOOS=linux GOARCH=amd64 go build -o bin/example-amd64 . = work
GOOS=linux GOARCH=386 go build -o bin/example-386 . = error

Linux to Windows 64/32 bit:
GOOS=windows GOARCH=amd64 go build -o bin/example-amd64.exe . = error
GOOS=windows GOARCH=386 go build -o bin/example-386.exe . = error

Linux to Darwin 64/32 bit:
GOOS=darwin GOARCH=amd64 go build -o bin/example-amd64-darwin . = error
GOOS=darwin GOARCH=386 go build -o bin/example-386-darwin . = error

Allready tested:
image

What i am missing?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.