-
Notifications
You must be signed in to change notification settings - Fork 6
Introduce settings options within the UI framework #482
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
Conversation
@BHoMBot check project-compliance |
@FraserGreenroyd to confirm, the following actions are now queued:
|
@FraserGreenroyd fix requested for project compliance. The errors with the CSProject ( I will apply the fixes to every case detailed on the checks tab with the exception of any references to the target framework. I am unable to provide fixes to the Target Framework automatically, these will need to be performed manually. If you want to perform the fixes in a different manner please resolve this manually and rerun the check. If you are happy for me to go ahead and perform this action, please reply with:
|
@BHoMBot fix project file ref. 21976635563 |
@FraserGreenroyd I have queued up your request to fix the |
@FraserGreenroyd I am now going to fix the project compliance in accordance with the annotations previously made. |
@FraserGreenroyd to confirm I have now resolved the project compliance issues and pushed a commit to this Pull Request. |
@BHoMBot check project-compliance |
@FraserGreenroyd to confirm, the following actions are now queued:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing with the branch in Grasshopper_UI, Works as expected - When deselecting toolkits like PowerPoint and then saving, their respective methods and objects are removed from the search menu. If I close and reopen rhino+gh, the settings are saved, and still cannot search the objects/methods deselected. Then when resetting and saving, the changes persist between instances of rhino as well. The toolkits are also omitted from the grasshopper drag/drop search.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some testing it looks to work as intended. However, it would be nice with a "Select all" button to deselect all of the toolkits and then select one or two toolkits without having to deselect all of the others one by one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked the new select/deselect all button, and it correctly selects and deselects all the inputs, and from a colourblind perspective the buttons are all distinct as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approving based off previous approval (only headers changed)
@BHoMBot check copyright-compliance |
@FraserGreenroyd to confirm, the following actions are now queued:
There are 7 requests in the queue ahead of you. |
@BHoMBot check project-compliance |
@FraserGreenroyd to confirm, the following actions are now queued:
|
@FraserGreenroyd to confirm, the following actions are now queued:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I really like this and it's a great first step to expanding and improving our UI UX. Looking forward to seeing this implemented in our supported UIs.
I did test in grasshopper using the matching branch. I'll make some comments on an issue in GH UI to talk about specific implementations there.
A few requested changes I'll note here:
-
If I'm a user and I've updated my settings but in doing so, I've accidentally removed a relevant namespace, it would be good to prompt the user to modify the settings again if they are not seeing what is expected. For example: if noPossibleItems & user has filter on then tell user to check settings. This would be changing the UI message from "No result found..." to something like "Try adjusting the UI search settings and try again".
-
The window seems a bit rigid and can't be moved or minimised. Would expect to be able to move/close/minimise.
Thanks for the review @michaelhoehn . For item 1, I think that will need to go in as a new feature/enhancement request because that will need to update across a few parts of the search (simply adding a check in the I have implemented item 2 however if you wish to take another look 😄 |
@FraserGreenroyd to confirm, the following actions are now queued:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @FraserGreenroyd 👍
This looks really great. Excited for the direction.
Good stuff @FraserGreenroyd - I had not looked at the code but enjoyed the test in GH 👍 A few comments from my side:
...but of course this is all phase 2 I would say, this PR seems to be a good start! |
Thanks for the feedback @pawelbaran 😄 To answer some points below:
This is a good question. The bit of code responsible for handling Toolkit items is:
Which is in the I agree it's one to take another look at before we turn it on fully in any of the UIs though - a workshop with a few of us to bottom out and check objects are suitable with namespaces should suffice - I'll look to schedule something in soon 😄
The settings themselves load/save using the Settings_Engine which will automatically save any settings to the The Settings_Engine does need documenting better (on BHoM.xyz) to be fair, which is slated for the end of this milestone which may benefit. But equally happy to workshop around additional save/loading options - perhaps a load from file for an initial set up for people who may not be comfortable pasting the file into
Agreed - I'm hoping the discipline communities can help with this 😄
Agreed, and I think falls under point 1 above as well of checking what some names are (
Also agreed, which is primarily why I opted to do this PR first without doing a conjoined PR on Grasshopper, I wasn't comfortable with the approach based on the lack of buttons on ribbon option I could find so want to give that more thought/input before it becomes available. I'd also like (though it may not be feasible given resource available) to do both GH and Excel at the same time, and also, liaise with you to do Revit, so all 3 UIs can benefit potentially at once - but that needs more mapping out and workshops I think for planning week for coordination as well 😄 That said, @michaelhoehn had a reasonable idea and has documented it in this issue - I think it's worth crowding round that issue for the Grasshopper implementation specifically (and eventually the Excel one, and eventually the Revit one, and eventually the new UI one, etc., etc.). |
Thanks @FraserGreenroyd, all makes sense, just one immediate thought on your replies:
What we as programmers find easy, for others may be uncomfortable or even worse, a no-go. Digging in 'system' files scares off many individuals from my experience, while everyone is fine with clicking 'Save' in the UI. So I would still opt for a button, as long as the users do not disagree 😉 |
@BHoMBot check ready-to-merge |
@FraserGreenroyd to confirm, the following actions are now queued:
|
NOTE: Depends on
BHoM/BHoM_Engine#3296 - this helps make this work for testing, but is not strictly a dependency given the outline of this work.
Issues addressed by this PR
Fixes #215
Test files
There is an identically named branch on Grasshopper_UI to help test this.
ctrl
shift
b
menu for items being excluded which is introduced in this PR, but is not intended to be available fully until a later milestone - but as proof of concept, my example was to untickAcoustic
,Analytical
, andFacades
and then search forPanel
and the firstPanel
object to show up is the Environment PanelChangelog
Additional comments
This PR introduces the concept of settings windows for BHoM to provide greater flexibility in user set up and enhance UX across the BHoM UIs which work from this UI framework.
The work covered in this PR is NOT designed to be utilised by any UI in this milestone (7.1), as greater thought needs to be given to the individual settings each UI might want to make. For example, the ability to search when wires are dropped is a Grasshopper specific setting as Excel does not perform the same action. However, both UIs can benefit from only having certain items appear in their
ctrl
shift
b
menus based on user selection.This PR will thus be excluded from versioning needs if changes need to be made for final implementations by others, but provides the starting blocks on which we can then aim to build. As such, perfection is not necessarily required by this PR providing it is not glaringly problematic with what's introduced, because this simply being here will not impact any user experience until explicitly called upon by a UI implementation.