Skip to content

Slider widget for options window #215

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Mar 9, 2025
Merged

Slider widget for options window #215

merged 16 commits into from
Mar 9, 2025

Conversation

bendoughty
Copy link
Contributor

Here’s a PR for a new “slider” widget type I have been working on. It is intended for use in the options window as the first part of an effort to make that area of the interface less cluttered and more intuitive for the user.

As is typically the case with UI sliders, the absolute value of the option is now no longer directly shown to the user within the interface. To make this a little more palatable to those who may miss it, I have added an extra line to the right-click context menu which displays the current value of the option. This change applies to slider options only.

I have updated some candidate options to use the new option type, these are very conservative changes based on Human Interface Guidelines from Gnome and Apple (thanks for the guidance, @pjbroad!). If the new widget type is approved I am happy to make adjustments to these selections as discussion progresses 😊

It would be useful if android folks could have a play around with the new widget, as I unfortunately do not possess a device capable of running the android client.

Screenshot 2025-02-26 at 08 19 07
Screen.Recording.2025-02-26.at.08.33.11.mov

@pjbroad pjbroad self-requested a review March 2, 2025 12:07
@pjbroad
Copy link
Collaborator

pjbroad commented Mar 2, 2025

Nice work @bendoughty, I really like it. A few initial comments:

  1. There is an issue if you have "User Interface Scaling Factor" anything other than 1.0. The scaling of the widget in the window is fine, but the slider does not move to the correct position when clicked, and lags when sliding. For > 1.0 value you cannot get to the most right side.
  2. The code works on Android (apart form the above issue), but:
  • the keyboard is opened when you click. You should just be able to remove the ANDROID #defs that call SDL_StartTextInput() in the el_config.c handler functions.
  • the scaling is too wide, overlapping the option text. I tested removing the 2 x scaling just for the width and start position, keeping the 2 x height. That looks fine to me.
  1. I see you have use space characters rather than TABs for indent throughout the patch. The convention for EL is TABS. Though not 100% followed, it is particularly an issue in code that does use TABS as the space using code shows non-aligned. PITA I know, but hopefully your text editor supports fixing this easily.
  2. In slider_click() of widgets.c, there's a compile warning because of the late declaration of pos; due to C90 comparability being enabled. Perhaps time to change that but its what we currently have.
  3. For the current value shown in the context menu, perhaps limit floats to 2 significant figures.
  4. The context menu stays open when sliding the bar, but the value does not update, perhaps close it in the el_config handler. - Looks to be only on Android, I can investigate if you like.

@bendoughty
Copy link
Contributor Author

bendoughty commented Mar 3, 2025

Thank you for taking the time to test out the widget, I really appreciate the constructive feedback 😊

  1. The integer truncation bug causing the slider positioning issue should now be fixed. I have tested scaling up, scaling down, and restarting the client at various scaling levels.

  2. I am glad the widget is (mostly) working as expected for Android, but clearly I need to take a look at picking up a cheap device I can use to test things like this in future. The keyboard issue you noted has been resolved, however I think it might be best for me to tap you in (if that’s okay) re: the Android scaling issue as I am a little dubious about making changes blindly.

  3. Sorry about the formatting problem, I have a new machine and it would appear I was blissfully unaware that Xcode now defaults to indenting with spaces(?!) - this should now be resolved.


  4. I have fixed the compiler warning, thank you for pointing it out.


  5. The “current value” and other context menu option lines for slider floats have now been limited to 2 significant figures.


  6. I have added a fix which I believe should resolve the context menu issue for Android - let me know.

@pjbroad
Copy link
Collaborator

pjbroad commented Mar 8, 2025

Thanks for making the changes, looks good.

The following patch fixes the Android with scaling. It also replaces the cm_destroy() call with the poorly named cm_post_show_check() that close the context menu window rather then destroy it. We could remove the #def around it too. android-patch.txt

One other thing I realised while testing, other widgets use sound for actions. What do you think about adding sounds for the slider? At least for clicks, but what about dragging. For the Gnome desktop, you get sounds for clicks, and a sound when you stop dragging. Both could potentially be based on mouse up events but there's nothing the the window/widget framework to provide such events; adding that would be a fair sized change.

If you apply the Android patch, and assuming we pick up the sound thing later, are you ready for this to be merged?

@pjbroad pjbroad self-assigned this Mar 8, 2025
elconfig.c Outdated
widget_width = slider_width;
widget_id = slider_add_extended(window_id, elconfig_free_widget_id++, NULL,
#ifdef ANDROID
window_width - right_margin - 2.0f * widget_width, current_y, 2.0f * widget_width, 2.0f * line_height,
Copy link
Collaborator

@pjbroad pjbroad Mar 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, the width and x position scaling should be removed to avoid making the widget too wide.

elconfig.c Outdated
widget_width = slider_width;
widget_id = slider_add_extended(window_id, elconfig_free_widget_id++, NULL,
#ifdef ANDROID
window_width - right_margin - 2.0f * widget_width, current_y, 2.0f * widget_width, 2.0f * line_height,
Copy link
Collaborator

@pjbroad pjbroad Mar 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, the width and x position scaling should be removed to avoid making the widget too wide.

elconfig.c Outdated

#ifdef ANDROID
if (cm_valid(CM_INIT_VALUE))
cm_destroy(CM_INIT_VALUE);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, suggest replacing if () cm_destroy() with cm_post_show_check(1)

elconfig.c Outdated

#ifdef ANDROID
if (cm_valid(CM_INIT_VALUE))
cm_destroy(CM_INIT_VALUE);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, suggest replacing if () cm_destroy() with cm_post_show_check(1)

elconfig.c Outdated
@@ -2151,14 +2220,23 @@ static void call_option_menu(var_struct *option)
cm_set_colour(cm_id, CM_GREY, 201.0/256.0, 254.0/256.0, 203.0/256.0);
cm_set(cm_id, option->name, context_option_handler);
cm_grey_line(cm_id, 0, 1);
add_cm_current_value_line(cm_options_current_str, option, *(float*)option->var);
cm_grey_line(cm_id, 1, 1);
Copy link
Collaborator

@pjbroad pjbroad Mar 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cm_grey_line(cm_id, 1, 1) is harmless at this stage but could be moved to the add_cm_current_value_line() function or made conditional on the return value.

@bendoughty
Copy link
Contributor Author

Thank you very much for the patch, I have applied it and also made the change in call_option_menu that you recommended 😊

Re: an action sound for the slider, this is actually something I have also been wondering about. Although a perfect implementation is not currently possible, I agree that it is better to at least have something in place for clicks. I have added a confirmationary do_click_sound to the onclick handler. This results in a "click!" when the slider is clicked (and, weirdly, at the beginning of a drag).

If you are happy with this then I am happy for the merge to go ahead!

@pjbroad pjbroad merged commit 1717d9b into raduprv:master Mar 9, 2025
5 checks passed
@pjbroad
Copy link
Collaborator

pjbroad commented Mar 9, 2025

All merged. Thanks very much for adding this function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants