You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I'm pleased with how this API looks, so I'm going to write this out. If @dbr and @thomcc also agree with this kind of design, I'll add this to our docs and aim to keep this format for most of our overload-style code.
ui.menu_item creates a menu_item with just a label, and nothing else. This function returns a bool directly -- this means that users don't have to write .build at all. This allows for fast code to be written easily.
ui.menu_item_x are made for common overloads of a single value. So for menu_item, I bound all of them the various parameters, since they're common enough -- so we have a ui.menu_item_shortcut, ui.menu_item_selected, ui.menu_item_enabled, etc. These, like the main simple one, return bool, not the Builder struct, so users shouldn't have to type .build themselves.
ui.menu_item_config takes the same parameters as our basic ui.menu_item, but returns a Builder instead (ie, users need to type .build() at the end). For less common situations, we can use this builder to generate complex forms.
This should be generalizable to the vast majority of our builder structures, and in my code, made this as easy as it could be in a language without optional arguments. Optional arguments would be nice...
What do you think? imo, it would be nice if at least MOST of the library worked in a similar way
Menu built off ui. is much neater and easier to find from auto-complete
The simple case is simple - if ui.menu_item("blah") { ... } is good
Main thing I question is the value of having the multiple "shortcut" methods (menu_item_enabled/selected/selected_ref etc), because:
There is quite reasonable people would want to use combination of the two, like a "disable-able" menu item with a shortcut (and obviously then adding menu_item_enabled_and_shortcut and every other combination becomes silly)
Say I'm using menu_item("Thing") then realize I need to make that menu disabled on $condition, or want to add a shortcut to it, etc
If I have some code if ui.menu_item_config("Thing").build() - I think it is easier to discover I can do ui.menu_item_config("Thing").shortcut("...").build() { than if the code was ui.menu_item("Thing") { and I need to change it to ui.menu_item_config("Thing").build() {then add the shortcut builder argument.
Similarly, if there is a bunch of menu_item_selected, menu_item_enabled etc - as someone reading the API docs I wouldn't assume there was another way of making a menu item with both selected and enabled. There is some value in nudging people towards the builder for any "non default" usage
So maybe we just have ui.menu_item("Label") and the builder-based ui.menu_item_config("...")? Generalised this would mean:
Everything builds of ui.
If there is a clear "default usage", there is a simple construction method (like ui.button("..."), ui.menu_item("..."), ui.same_line() etc)
If there is more complex usages:
a) If the alternative uses are all exclusively non-overlapping (e.g you can make a button with a default size, or a button with a specific size - nonsensical to want to do both at same time) there is only nonbuilder methods (ui.button and ui.button_size)
b) Otherwise, there is a builder method (plus the "simple construction menu", if applicable)
seems very reasonable to me! In my case, I often end up using those other options for menu items and wanted to avoid the build call, but perhaps I was just being annoying. Increasing library space for Rust differences from C++ seems like a not good idea, so I think I'll implement your idea
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Moved the Menu-Item constructors onto
ui.I'm pleased with how this API looks, so I'm going to write this out. If @dbr and @thomcc also agree with this kind of design, I'll add this to our docs and aim to keep this format for most of our overload-style code.
ui.menu_itemcreates amenu_itemwith just a label, and nothing else. This function returns a bool directly -- this means that users don't have to write.buildat all. This allows for fast code to be written easily.ui.menu_item_xare made for common overloads of a single value. So formenu_item, I bound all of them the various parameters, since they're common enough -- so we have aui.menu_item_shortcut,ui.menu_item_selected,ui.menu_item_enabled, etc. These, like the main simple one, return bool, not the Builder struct, so users shouldn't have to type.buildthemselves.ui.menu_item_configtakes the same parameters as our basicui.menu_item, but returns a Builder instead (ie, users need to type.build()at the end). For less common situations, we can use this builder to generate complex forms.This should be generalizable to the vast majority of our builder structures, and in my code, made this as easy as it could be in a language without optional arguments. Optional arguments would be nice...
What do you think? imo, it would be nice if at least MOST of the library worked in a similar way