Implement uiTable

[mischnic]

🙈

[parro-it]

Good news! I'm invacation rightnow. Will be back on end of august, I will start toadd tables to bindings.

[parro-it]

I'm back on the road again, and I started to work on the new implementation. As a first step, I did a PR where I changed the download process of libui binaries in order to use @andlabs repo

[mischnic]

The icon in the table has bits of green at the top and bottom (on right is the original png file), are you handling transparency incorrectly (somehow?) or is this a libui bug?

[mischnic]

libui issue: andlabs/libui#425

[mischnic]

How is the progress? Did you implement all libui table features?

---

Regarding this todo:

libui-napi/src/image.c

Lines 8 to 11 in e3848cf

	static void on_img_gc(napi_env env, void *finalize_data, void *finalize_hint) {
	uiImage *img = (uiImage *)finalize_data;
	/* TODO: uiFreeImage when? */
	}

I guess the only way is reference counting when using an image in a table.

[andlabs]

uiTable does not copy images; they are used as soon as you give it to them, and then forgotten about.

[mischnic]

That's true. The images are only used in the modelCellValue callback, so when the JS object gets garbage collected, the image can be deleted (no reference is stored inside native code).

[andlabs]

Oh. I thought I documented the guarantee on lifetime, but basically by the top of the next main loop iteration uiTable will have finished using it. I'm not sure whether creating a new uiImage each time you extract data is a good idea, but eh.

[mischnic]

I'm not sure whether creating a new uiImage each time you extract data is a good idea, but eh.

What do you mean by extracting data? There is a javascript image wrapper which forwards the calls to the actual uiImage and when the wrapper would get gc'ed, the uiImage is freed as well. This underlying uiImage also gets passed to libui in the table callback.

[parro-it]

How is the progress? Did you implement all libui table features?

Almost, I have to finish the abstraction layer on top of models.
But basic libui methods binding should be all there. There are some memory management to improve on.... one is the one you discovered here, the other is in order to keep model instances alive while they are used by any or more tables.

I guess the only way is reference counting when using an image in a table.

I was thinking the same, we can increment the reference when an image is returned by the model handler, and someway decrements it in next loop step, as @andlabs suggested...

Another strangeness to solve is here:

libui-napi/src/table-model.c

Line 234 in e3848cf

// free(cell_value);

AFAIK that string should be freed immediately, but if I do it there, the program SEGFAULT.

[mischnic]

AFAIK that string should be freed immediately, but if I do it there, the program SEGFAULT.

Doesn't segfault for me, but according to ui.h:

uiTableValueString() returns the string stored in v. The returned string is owned by v.

So it's not copied and shouldn't get freed.

[jbrodriguez]

I'm about to build a desktop app and deciding wether to use electron or proton-native.

The only thing missing from a workable proton-native poc is lists/tables (as mentioned in kusti8/proton-native#99)

So I was wondering when do guys think this could become available ?

Early next year ? Or before the end of the year ?

[parro-it]

@jboodriguez : I definitely think before the end of the year.

Anyway, please be aware that I'm doing this in my spare time, for free.
So it greately depends on how I'll be tired/motivated/busy on other stuff.

Don't take that date as strict deadline, only as an informed guess...

[benbucksch]

If this helps as motivation: I'm trying out Proton Native, and without a table widget with selection (single and multi), I have no chance to build my app.

[benbucksch]

@parro-it : Here's how an email client without tables looks like: :-)