This is an effort to provide a table selection API as was suggested in libui#413.

I have made some alterations to the original proposal.

This introduces 5 different table selection modes:

uiTableSelectionModeNone,       //!< Allow no row selection.                                
uiTableSelectionModeZeroOrOne,  //!< Allow zero or one row to be selected.                  
uiTableSelectionModeOne,        //!< Allow for exactly one row to be selected.              
uiTableSelectionModeZeroOrMany, //!< Allow zero or many (multiple) rows to be selected. 

With a get/set function:

uiTableSelectionMode uiTableGetSelectionMode(uiTable *t);
void uiTableSetSelectionMode(uiTable *t, uiTableSelectionMode mode);

And then three functions to set a selection changed callback and get/free the actual selection:

void uiTableOnSelectionChanged(uiTable *t, void (*f)(uiTable *t, void *data), void *data);
uiTableSelection* uiTableGetSelection(uiTable *t);
void uiTableSetSelection(uiTable *t, uiTableSelection *selection);
void uiFreeTableSelection(uiTableSelection* s);

uiTableSelection struct:

struct uiTableSelection
{
    int NumRows;
    int *Rows;
};

I did some testing with the big tables (100k rows). Selecting all rows at once and having the tester print the rows on the terminal still has IMO very acceptable performance. Only minimal lag on my system. An iterator style API would be nice in the future though.

~~There is still one inconsistency across platforms remaining as far as I can tell:~~ ~~Windows and unix both emit a selection changed when clicking on an already selected row on uiTableSelectionModeZeroOrMany, darwin will not. ~~Should be try to suppress this?~~ I've managed to suppress this for all other modes, for multi select I fear we might need to cache the entire selection and compare possibly on each selection change. Not sure what that would mean for performance.~~

~~All other edge cases should be documented in the API docs.~~

Otherwise this works for me on all officially supported platforms. Wine sadly does not work, ~~see upstream bug report. I've sent in patches for fixing wine, so far no luck.~~

I've kept my commits intact, if need be I can squash.

~~There are a few things I am not quite happy about:~~

• ~~Inefficiencies in the unix & darwin code. We need to iterate over the selection multiple times to convert formats~~
• ~~Should uiTableSelectionCurrentSelection return a value to indicate malloc errors? assert is not acceptable. Or is the current note in ui.h sufficient, requiring users to check BOTH rows != NULL and numRows > 0?~~

~~My question is: are these inefficiencies acceptable? I was wondering if it would be possible to provide some type of iterator API? I am however not sure if it is even possible or if it would really lead to any significant gains.~~

~~Then there seems to be a bug on windows (win7). Can anybody reproduce? Go to tester, page16, click Multiple Selection, try to edit a cell in the editable column. On many occasions the cell will loose focus by itself and editing will be stopped. Interestingly enough this does not happen on wine. Can anybody reproduce this on newer windows versions?~~

~~Edit: Windows default behavior when clicking an already selected/focused row seems to be: Send a deselect signal to for all items nm->iItem == -1 and then send another select signal for the row that was already selected/focused. I replicated this with the windows sample virtual list~~

Old PR libui#514

Proposal to add API functions to get and set table column widths:

int uiTableColumnWidth(uiTable *t, int column);
void uiTableColumnSetWidth(uiTable *t, int column, int width);

Same as in #24 we need a way to identify columns. I used the same mechanism of identifying columns by index position when added for the time being.

Implementations provided for all platforms (darwin, unix, windows) with a test bed in page16.

I decided to add a more complete uiTable testing suite:

This adds two uiTables backed by the same uiTableModel. Additionally it provides functions to insert and delete rows manually.

Issues like the one in #17 libui#507 can be nicely exhibited through the upgraded tester.

As I mentioned in #74 I would like some way of automatically testing at least some of the library code.

This is a first proof of concept, testing getters/setters, out of bounds values etc. I find this especially useful in making sure the API claims, eg. here #96 actually hold true.

~~You will need to install cmocka... via your package manager. Most repos seem to have it. For mingw, install the appropriate mingw package. Otherwise this will fail horribly.~~

Current state:

• [x] unix
• [x] darwin
• [x] windows
  • [x] mingw
  • [x] msvc

Update

Meson now force compiles cmocka locally, installed versions of cmocka should be ignored completely. This sadly requires bumping the meson version to 58.To test, run the resulting unit executable or meson test -C build --verbose.

~~macOS still fails after the first test due to #118.~~

~~unix~~

~~Install cmocka. Run the resulting unit executable.~~

~~darwin~~

~~Install cmocka. I did this via brew. Sadly brew does not install fat binaries, so I need to remove the arm64 targets from the meson.build:~~

-       libui_project_compile_args += ['-arch', 'arm64', '-arch', 'x86_64']
-       libui_project_link_args += ['-arch', 'arm64', '-arch', 'x86_64']
+       libui_project_compile_args += ['-arch', 'x86_64']
+       libui_project_link_args += ['-arch', 'x86_64']

~~Again, run the resulting unit executable. It currently only runs the first test, then fails. I guess the uiUnInit() does not correctly do its job.~~ ~~Can you open and close an cocoa app twice from the same process? I will try come up with some simpler test to verify and open an issue.~~

In theory we could probably reuse the same window over and over. But I think this might be a bug, so I'm leaving it in the POC.

~~windows~~

~~mingw~~

~~Install mingw-w64-cmocka, or whatever the naming convention is on your system. Build. See it fail.

~~Currently meson decides to pull in the dynamic library of cmocka. The magic we need is in test/unit/meson.build where we actually want:~~

-cmocka_deps = dependency('cmocka', version : '>=1.0.0')
+cmocka_deps = dependency('cmocka', version : '>=1.0.0', static: true)

~~which sadly fails on my system. Cmocka seemingly does not produce a libcmocka.a but instead a libcmocka-static.a. I am unclear if this is a cmocka upstream issue or a problem with the Archlinux package I use. Could somebody on another Linux distribution confirm?.~~

~~Or is there some way to coerce meson to go looking for a lib-static.a as well? Unclear. There seem to be quite a few open meson tickets regarding static linking.~~

~~Linking manually to libcmocka-static.a does work though, from the build directory:~~

x86_64-w64-mingw32-g++  -o meson-out/unit.exe meson-out/test_unit_resources.rc_resources.o meson-out/unit.exe.p/main.c.obj -flto -Wl,--allow-shlib-undefined -Wl,-O1 -static -static-libgcc -static-libstdc++ -Wl,-O1,--sort-common,--as-needed -fstack-protector -Wl,--start-group meson-out/libui.a -luser32 -lkernel32 -lgdi32 -lcomctl32 -luxtheme -lmsimg32 -lcomdlg32 -ld2d1 -ldwrite -lole32 -loleaut32 -loleacc -luuid -lwindowscodecs -L/usr/x86_64-w64-mingw32/lib -l:libcmocka-static.a -luser32 -lkernel32 -lgdi32 -lcomctl32 -luxtheme -lmsimg32 -lcomdlg32 -ld2d1 -ldwrite -lole32 -loleaut32 -loleacc -luuid -lwindowscodecs -Wl,--end-group -mconsole

~~and then running ./meson-out/unit.exe does work with wine! Great.~~

~~msvc~~

~~I have no idea where to even start.~~

~~Conclusion~~

~~A lot to still be done. I am happy for any pointers. Looking at all the issues, I am wondering if pulling in cmocka via a git submodule and building it... might not be easier. As much as I had submodules, maybe it would keep the library more cohesive. especially with msvc in mind? Again: open for suggestions.~~

I know there have been numerous attempts at annotating the library, here is another one.

Instead of dumping everything into one commit, I decided to go by component.

Documented (missing proper callback formatting)

• [x] uiWindow
• [x] uiButton
• [x] uiBox
• [x] uiCheckbox
• [x] uiEntry
• [x] uiLabel
• [x] uiTab
• [x] uiGroup
• [x] uiSpinbox
• [x] uiSlider
• [x] uiProgressBar
• [x] uiSeparator
• [x] uiCombobox
• [x] uiEditableCombobox
• [x] uiRadioButtons
• [x] uiDateTimePicker
• [x] uiMultilineEntry
• [x] uiOpenFile() uiOpenFolder() uiSaveFile() uiMsgBox() uiMsgBoxError()
• [x] uiImage
• [x] uiGrid
• [x] uiColorButton
• [x] uiForm
• [x] uiFontButton
• [x] uiMenuItem
• [x] uiMenu
• [x] uiTable & friends

TODO

• [x] Annotate all uiWindow functions that are merely hints on unix as such
• [x] Document callbacks

Supercedes #64 Related to #3 #92

• hello-world: Display a window. Using as few statements as possible may not be the best practice.
• hello-window: Display a window and add a label to the window, using best practices where possible.

TODO: Add more standalone hello-widgets examples.

I'm not sure if it is better etiquette to make individual PRs for each of my suggested changes, but there are multiple small changes so I decided to group them into a single PR.

https://github.com/norepimorphism/libui-ng/blob/7b9380b17692807bb5a4164213d01018ab2f7c6c/windows/entry.cpp#L16-L23

Here, I made a small refactor to make the branches taken a little more clear. I made the same change in multilineentry.cpp.

https://github.com/norepimorphism/libui-ng/blob/7b9380b17692807bb5a4164213d01018ab2f7c6c/windows/entry.cpp#L71

Here, I replaced a PostMessageW call with the corresponding macro: in this case, Edit_SetSel. I believe switching from PostMessageW to macros where possible was mentioned previously as an issue.

https://github.com/norepimorphism/libui-ng/blob/7b9380b17692807bb5a4164213d01018ab2f7c6c/windows/entry.cpp#L89-L90

This should be equivalent to the original code but is a little less verbose.

https://github.com/norepimorphism/libui-ng/blob/7b9380b17692807bb5a4164213d01018ab2f7c6c/windows/multilineentry.cpp#L84-L107

I made a few changes here. Mainly, I addressed the comments left previously by preserving the current text selection after appending text. I also made a few macro replacements where possible, and I introduced a new function windowTextLen in text.cpp that returns the text length of an edit control. I noticed we were querying text length manually in some places, so I decided to make a dedicated function.

Proposal to add two new API functions to set a callback for when a user clicks and double clicks a table row.

void uiTableOnRowClicked(uiTable *t, void (*f)(uiTable *t, int row, void *data), void *data);
void uiTableOnRowDoubleClicked(uiTable *t, void (*f)(uiTable *t, int row, void *data), void *data);

Implementations provided for darwin, unix, and windows. A small sample usage is provided on page16.

Two platform inconsistencies I found while testing:

1. Unix will send two uiTableOnRowClicked events when double clicking before the uiTableOnRowDoubleClicked event. Windows and Mac will only send one.
2. Mac will not select a row when ticking a checkbox, hence no uiTableOnRowClicked is sent. Unix and Windows select the row (first), send a uiTableOnRowClicked event and then send a uiTableValueChanged event.

My suggestions:

1. Can be ignored for now, as this will be automatically fixed once we switch to GtkGesture based events Gtk >= 3.14 or at the latest Gtk4. A working fix that requires Gtk >= 3.14 can be found here.
2. Not sure what to do about the differing behavior for mac in general, this should possibly be raised as an issue on its own? Comments welcome.

This would supersede #44, adding a differentiation between single and double click and fixing all problems related to keyboard events on the unix side as well (by not implicitly adding any handlers). Supersedes old PR libui#516

Is it possible to add function uiSliderOnReleased? In Qt, I can use SIGNAL(sliderReleased()) to detect when user finishes dragging the slider. Thanks!

I think we need a way of properly assigning copyright, similar to how other open source projects handle this.

I would suggest either an AUTHORS file or IMO even better: listing contributors at the bottom of the LICENSE file.

The copyright in the LICENSE file has already been changed to Copyright (c) 2022 libui-ng authors. How about adding a list of authors at the bottom of said file?

Copyright (c) 2022 libui-ng authors
....

Authors
=======

First Last

Somebody would have to go through the git log and add the names. New contributors would add their name themselves (remark in CONTRIBUTING.md needed).

Old PR libui#512

Proposal for two new API additions to un/hide table headers:

int uiTableHeaderVisible(uiTable *t);
void uiTableHeaderSetVisible(uiTable *t, int visible);

This was one of the requests in the table master issue.

--

Added API functions: uiTableHeaderVisible() to determine whether the table header is visible. uiTableHeaderSetVisible() to set the visibility of the table header.

Implementation provided for unix, darwin, and windows.

Notes: as darwin does not provide an API for hiding or recreating the table header I opted for saving a reference and restoring that when the visibility is set back to true. Setting the header to nil to hide it is the suggested method for hiding the header according to the docs.

This may be rare in practice, but the behavior of the library is kind of funky when not creating a window and running uiMain(). First, the application can not be terminated. The menu item for Quit is disabled and doing an alt click on the application itself and pressing quit results only in a NSLog 2022-12-22 16:14:57.866 window[43519:1828200] in applicationShouldTerminate:.

The other thing it triggers is a memory leak when running uiInit(); uiUninit(); uiInit(); uiUninit() in succession, as is done in the unit tests

Run leaks --atExit -- ./build/meson-out/unit:

Process:         unit [43429]
Path:            /Users/USER/*/unit
Load Address:    0x100773000
Identifier:      unit
Version:         ???
Code Type:       X86-64
Platform:        macOS
Parent Process:  leaks [43428]

Date/Time:       2022-12-22 16:06:03.144 -0500
Launch Time:     2022-12-22 16:05:52.450 -0500
OS Version:      macOS 11.7.1 (20G918)
Report Version:  7
Analysis Tool:   /Applications/Xcode.app/Contents/Developer/usr/bin/leaks
Analysis Tool Version:  Xcode 13.2.1 (13C100)

Physical footprint:         8888K
Physical footprint (peak):  8932K
----

leaks Report Version: 4.0
Process 43429: 21566 nodes malloced for 3496 KB
Process 43429: 21 leaks for 1488 total leaked bytes.

    21 (1.45K) << TOTAL >>

      3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe518bf0> [112]
         2 (80 bytes) _title --> <CFString 0x7fcefe514590> [48]  length: 9  immutable non-inline Unicode:  "Quit unit"
            1 (32 bytes) <CFString (Storage) 0x7fcefe5136c0> [32]

      3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe5199c0> [112]
         2 (80 bytes) _title --> <CFString 0x7fcefe504550> [48]  length: 10  immutable non-inline Unicode:  "About unit"
            1 (32 bytes) <CFString (Storage) 0x7fcefe521570> [32]

      3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe6076f0> [112]
         2 (80 bytes) _title --> <CFString 0x7fcefe60b4b0> [48]  length: 9  immutable non-inline Unicode:  "Quit unit"
            1 (32 bytes) <CFString (Storage) 0x7fcefe604d90> [32]

      3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe60b0e0> [112]
         2 (80 bytes) _title --> <CFString 0x7fcefe60af00> [48]  length: 10  immutable non-inline Unicode:  "About unit"
            1 (32 bytes) <CFString (Storage) 0x7fcefe60b070> [32]

      3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe705d20> [112]
         2 (80 bytes) _title --> <CFString 0x7fcefe705c50> [48]  length: 10  immutable non-inline Unicode:  "About unit"
            1 (32 bytes) <CFString (Storage) 0x7fcefe705d00> [32]

      3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe706740> [112]
         2 (80 bytes) _title --> <CFString 0x7fcefe705ef0> [48]  length: 9  immutable non-inline Unicode:  "Quit unit"
            1 (32 bytes) <CFString (Storage) 0x7fcefe706720> [32]

      1 (112 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe51ac20> [112]
      1 (112 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe60b610> [112]
      1 (112 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe705fd0> [112]

The leaked strings are easily fixes (see #172) by adding autorelase. Somehow some other references stick around though.

And I would expect the application to be closable, even with no window. This may not be too interesting of a use case right now, but sure will be moving forward with applications running in the background that can be opened via the system tray or similar.

• Fixes presented in #169 for all platforms pertaining uiMenu re-initialization
• Cmocka test cases for uiMenu #170
• Darwin: refactoring removing global state and uiprivMap() #165
• Darwin: fix memory leak of strings "About unit", "Quit unit"

The existing memory leak around the NSObjects for About, Preferences and Quit still exists however. Run leaks --atExit -- ./build/meson-out/unit to see what objects remain. Interestingly enough test case triggering the problem is initUninitTwice. I haven't been able to figure out who still holds a reference, I assume it has to do with the mixing of ARC, MRR and @autoreleasepool. But maybe the problem lies somewhere else, as the problem seemingly disappears when creating a window.

Reset the global variables on uiprivUninit() for all platforms. This will should allow for re-initializing an application that contains menus.

From preliminary testing the code seems to work on all platforms. I tested Window7, Linux (gtk 3.24.35), macOS Big Sur. Hope I did not miss something.

Fixes #169

Edit: Branch That combines the fixes here with the tests in #170.

Edit: I must have pressed the wrong PR button. I would still like to add more tests to this. But here you go.

Add unit tests for uiMenu. Depends on #171

Edit2: Branch That combines the fixes in #171 with the tests here.

Similar to #118, another uiUninit() followed by uiInit() problem: Any application creating a menu and hence possibly calling uiNewMenu() after a reset (uiUninit(); uiInit();) will refuse to work the second time around.

You can check it out by running meson test on this branch

Does anyone know why the menu needs to be finalized in the first place? Why can we not modify the menu after creating the first window? Is this related to a limitation of one of the underlying platforms or just a library quirk?