ComboRow does not use selection binding #28

New Issue

2024-05-08T10:30:29+02:00

lambdaclan commented

2024-05-08 10:30:29 +02:00

(Migrated from github.com)

Describe the bug

Hello there, thank you very much for putting this library together. It has rekindled my interest in GTK development (gtk-rs is pretty rough, and I refuse to use dynamic languages so not many other options out there…) and made me start learning Swift, which is truly a great language, too bad Linux support is not on par with macOS, but it seems to be getting better and better.

Now for the issue itself. It seems like ComboRow does not use the selection binding as such the first item in the list is the one that is always selected. To be clear, using the combo row correctly changes and updates the selection binding but upon revisiting a menu the selection although correct is not used and the ComboRow just pre-selects the top item. I tried using both selection binding and the selected function to force set the correct item, but it does not make any difference.

Using different starting values for other widgets such as SpinRow and SwitchRow correctly uses the binding.

For example (samples from your FormDemo):

Note the selection value is correct, so the subtitle is set to "World"

I am not sure if this is expected behaviour but if not there is something wrong with ComboRows. If this is indeed expected behaviour are there any workarounds for the ComboRow to remember its selection?

Thank you for your support!

PS: I have some other questions/issues, but I will open separate issue/discussion for them ;)

To Reproduce

Go to the FormDemo source file
Modify the selection state variable to change the ComboRow's initial value from Hello to World
Run the application
Note the pre-selected value of the ComboRow does not reflect the selection value

Expected behavior

The ComboRow should correctly pre-select the value indicated by the selection binding and not the top item from the value list. For example if I have a ComboRow with values 1,2,3,4,5, and I select value 4, I want value 4 to be pre-selected with a checkmark when I close and revisit the view holding the ComboRow.

Additional context

Edit1: Upon further testing, seems like even the widgets that use the correct starting value do not remember their new value on consecutive visits. For example if I create a SpinRow inside a menu, set its initial value to 3 and open the menu then its value is 3 but changing it will not be reflected if I close and re-open the menu, its value will be set to its initial 3.

Maybe is because I try to use the widgets inside separate dialogs like menus, preferences and not the main window? Not sure.

Edit2: I tried sending the value to the menu holding the SpinRow as a @Binding (instead of directly using @State in the menu) and then it correctly remembers its value upon consecutive visits. The issue still persists with ComboRows. Using a similar approach the ComboRow never remembers its value and always pre-selects the top item.

### Describe the bug Hello there, thank you very much for putting this library together. It has rekindled my interest in GTK development (gtk-rs is pretty rough, and I refuse to use dynamic languages so not many other options out there…) and made me start learning Swift, which is truly a great language, too bad Linux support is not on par with macOS, but it seems to be getting better and better. Now for the issue itself. It seems like [ComboRow](https://aparokshaui.github.io/adwaita-swift/documentation/adwaita/comborow) does not use the selection binding as such the first item in the list is the one that is always selected. To be clear, using the combo row correctly changes and updates the selection binding but upon revisiting a menu the selection although correct is not used and the ComboRow just pre-selects the top item. I tried using both `selection` binding and the `selected` function to force set the correct item, but it does not make any difference. Using different starting values for other widgets such as SpinRow and SwitchRow correctly uses the binding. For example (samples from your FormDemo): ![image](https://github.com/AparokshaUI/adwaita-swift/assets/47409392/9cce4574-4d13-4add-a232-f5c33f7c1655) Note the selection value is correct, so the subtitle is set to "World" ![image](https://github.com/AparokshaUI/adwaita-swift/assets/47409392/2855c98b-4cd0-4d0e-9aa0-d45b3d7fed31) I am not sure if this is expected behaviour but if not there is something wrong with ComboRows. If this is indeed expected behaviour are there any workarounds for the ComboRow to remember its selection? Thank you for your support! PS: I have some other questions/issues, but I will open separate issue/discussion for them ;) ### To Reproduce 1. Go to the [FormDemo](https://github.com/AparokshaUI/adwaita-swift/blob/main/Tests/FormDemo.swift) source file 2. Modify the [`selection`](https://github.com/AparokshaUI/adwaita-swift/blob/main/Tests/FormDemo.swift#L33) state variable to change the ComboRow's initial value from Hello to World 3. Run the application 4. Note the pre-selected value of the ComboRow does not reflect the selection value ### Expected behavior The ComboRow should correctly pre-select the value indicated by the selection binding and not the top item from the value list. For example if I have a ComboRow with values 1,2,3,4,5, and I select value 4, I want value 4 to be pre-selected with a checkmark when I close and revisit the view holding the ComboRow. ### Additional context Edit1: Upon further testing, seems like even the widgets that use the correct starting value do not remember their new value on consecutive visits. For example if I create a SpinRow inside a menu, set its initial value to 3 and open the menu then its value is 3 but changing it will not be reflected if I close and re-open the menu, its value will be set to its initial 3. Maybe is because I try to use the widgets inside separate dialogs like menus, preferences and not the main window? Not sure. Edit2: I tried sending the `value` to the menu holding the SpinRow as a @Binding (instead of directly using @State in the menu) and then it correctly remembers its value upon consecutive visits. The issue still persists with ComboRows. Using a similar approach the ComboRow never remembers its value and always pre-selects the top item.

david-swift commented

2024-05-08 18:31:51 +02:00

(Migrated from github.com)

The bug is caused by ComboRow initializing the selection before the choices (I'll fix that).

Currently, only apps and views support state. I'll expand this to menus.

Thanks for the detailed writing!

The bug is caused by `ComboRow` initializing the selection before the choices (I'll fix that). Currently, only apps and views support state. I'll expand this to menus. Thanks for the detailed writing!

👍 1

david-swift commented

2024-05-08 18:40:33 +02:00

(Migrated from github.com)

if I create a SpinRow inside a menu, set its initial value to 3 and open the menu then its value is 3

What do you mean by a menu in this context?

Anyways, yes, State only saves state from the creation of the view until it is "destroyed". Depending on what you mean by the menu, it does redraw the UI when navigating. State that should be saved even though a view is destroyed and recreated should be saved in its parent view.

> if I create a SpinRow inside a menu, set its initial value to 3 and open the menu then its value is 3 What do you mean by a menu in this context? Anyways, yes, `State` only saves state from the creation of the view until it is "destroyed". Depending on what you mean by the menu, it does redraw the UI when navigating. State that should be saved even though a view is destroyed and recreated should be saved in its parent view.

lambdaclan commented

2024-05-09 03:06:34 +02:00

(Migrated from github.com)

if I create a SpinRow inside a menu, set its initial value to 3 and open the menu then its value is 3

What do you mean by a menu in this context?

Sorry for not being clearer, I meant exactly what you have described in the comment above. Basically a child view that uses @State which gets destroyed when exited, so things like menus, extra dialogs etc. I figured out that to maintain the state then I need to move it to the parent view so no worries.

The bug is caused by ComboRow initializing the selection before the choices (I'll fix that).

Thank you for confirming the bug and taking the time to fix it! 🙏

> if I create a SpinRow inside a menu, set its initial value to 3 and open the menu then its value is 3 >> What do you mean by a menu in this context? Sorry for not being clearer, I meant exactly what you have described in the comment above. Basically a child view that uses @State which gets destroyed when exited, so things like menus, extra dialogs etc. I figured out that to maintain the state then I need to move it to the parent view so no worries. > The bug is caused by ComboRow initializing the selection before the choices (I'll fix that). Thank you for confirming the bug and taking the time to fix it! 🙏

david-swift commented

2024-05-09 08:23:19 +02:00

(Migrated from github.com)

So the ComboRow bug is fixed, I'll now add support for state in menus.

So the `ComboRow` bug is fixed, I'll now add support for state in menus.

❤️ 1

lambdaclan commented

2024-05-09 11:49:01 +02:00

(Migrated from github.com)

Hello @david-swift I can confirm that the ComboRow bug is now fixed, thanks for that!

I am not sure if the new commit caused a regression, but now I am having issues with ListBox selection. Setting an initial selection value is causing a crush. Weird thing is that if the initial view being presented is the one containing the ListBox then it works as expected but if you are navigating from a different view then it crushes.

To reproduce:

Update ListDemo as follows:

Run your demo application (it is important for the ListDemo not to be the last view during the last run)
Select ListDemo from the list of demos and application should crush

Now if you restart the app it will work as expected since ListDemo will be the first view that will be active.

Maybe it is something on my end, so I will keep looking into it.

Hello @david-swift I can confirm that the ComboRow bug is now fixed, thanks for that! I am not sure if the new commit caused a regression, but now I am having issues with ListBox selection. Setting an initial selection value is causing a crush. Weird thing is that if the initial view being presented is the one containing the ListBox then it works as expected but if you are navigating from a different view then it crushes. To reproduce: 1. Update ListDemo as follows: ![image](https://github.com/AparokshaUI/adwaita-swift/assets/47409392/00bddd87-3ab9-4108-bea9-b5323e1638a4) 2. Run your demo application (it is important for the ListDemo not to be the last view during the last run) 3. Select ListDemo from the list of demos and application should crush Now if you restart the app it will work as expected since ListDemo will be the first view that will be active. Maybe it is something on my end, so I will keep looking into it.

david-swift commented

2024-05-18 14:59:35 +02:00

(Migrated from github.com)

@lambdaclan Thanks for reporting! I fixed this in c07b071.

@lambdaclan Thanks for reporting! I fixed this in c07b071.

🎉 1

lambdaclan commented

2024-05-20 03:22:37 +02:00

(Migrated from github.com)

Hello @david-swift, thank you very much for looking into the issue and fixing it, I can now continue working on my app ;)

Sign in to join this conversation.