Fields of some types are not exported

[mnurzia]

I tried to change the background color of a window: ctx.style.window.background = nk.NkRgb(0,120,215) and when building, Golang stopped with an error saying that style was not exported. I'm not sure how you would go about this in cgogen, but I think that the underlying c structs in nuklear.h need to be extracted or modified in some way so that they are exported or capitalized.

[xlab]

Hi! Structs in Nuklear have too much inner state, I decided to avoid binding them, except cases when they are simple. Also sometimes it's not good for performance of tiny structs that rarely get changed.

See https://github.com/golang-ui/nuklear/blob/master/nk/etc.go I usually write setters and getters for stuff I need to change. You can contribute yours for public fields of nk_context struct.

ctx.Style().Window().SetBackground(nk.NkRgb(0,120,215))

I think both setters/getters generation can be next feature of cgogen, but that's another story.

[mnurzia]

Thanks! I will probably write a few and submit a pull request later on.

[erkinduran]

illinoisjackson did you write code about styling window? Could you give example to us?

[dryaf]

I'm stuck here: http://i.imgur.com/mCnbQcL.png I think this is related right? Any hint how I could get the begin value?

[erkinduran]

Thanks.

[xlab]

@rand99 At this moment, all strings must be NULL-terminated, like "foo\x00".

Regarding the NkListView, an "unstuck" piece of Go code would look like

func (l *ListView) Begin() int {
    return (int)(l.begin)
}

func (l *ListView) End() int {
    return (int)(l.end)
}

func (l *ListView) Count() int {
    return (int)(l.count)
}

I added it to etc.go, all other things must be done that way, until generator will be able to generate getters/setters..

[dryaf]

Thank you for the example. I got it "kinda" working.

        var view nk.ListView
        var alist = []string{"asdf", "asdf2", "asdf3"}
        nk.NkLayoutRowDynamic(ctx, 90, 1) {
            if nk.NkListViewBegin(ctx, &view, "test", nk.WindowBorder, 25, int32(len(alist))) > 0 {
                nk.NkLayoutRowDynamic(ctx, 25, 1)
                {
                    for i := 0; i <= view.Count(); i++ {
                        nk.NkLabel(ctx, alist[view.Begin()+i], nk.TextAlignLeft)
                    }
                }
                nk.NkListViewEnd(&view)
            }
        }

It crashes easily and the memory is written in the list :-) http://i.imgur.com/q2TlakL.png

I will stick with https://github.com/nelsam/gxui at the moment. The examples work and are easy to understand although its really ugly. I'm sure your repo will become pretty popular when there are working examples for common use-cases. 👍

[xlab]

It crashes easily and the memory is written in the list :-)

Like because you ignored my advice to NULL-terminate the strings and are passing them into C without termination. That's a C library either way, the safest way will always be to use native Go packages.

The reason why I personally don't stick with GXUI is because I won't commit my time and effort in frozen and unfinished projects, had some bad experience doing that in the past.

[xlab]

UPD: c-for-go now support safe strings (automatic NULL-termination of all strings), the bindings for Nuklear were updated, so all strings are automatically terminated now.

[dryaf]

I didnt ignore it on purpose. i just didnt get it at 3am after 13 hours of work. last time i looked at c++ code was 2003. then java, php, ruby, chsarp and now go :-) people forget things.

i understand your position on gxui. One guy is working on it and I m just using it for software that is for me only. everything (tree, list, btns, layouting, panels) works fine . only the text selection is a bit choppy. the event handler are really nice.

you will attract people and contributers with the same working examples as gxui. so your time and effort will be worth it.