-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Fix 845 #930
Fix 845 #930
Conversation
simonharrer
commented
Mar 10, 2016
- better German translation of the menu items groups -> highlight groups ...
- add radio button functionality to the menu items groups -> highlight groups ... which is mutually exclusive plus add a disable menu entry which was not explicit before
- enable showing what is currently toggled in the menu as well (and not only in the toolbar)
Looks good! |
Code looks good. I don't see the current state in the toolbar. - The radio indicators change. I don't see any change in my database, but that was also the case before your change. |
Change in the database? Why should there be a change in the database? What are you not seeing in the toolbar? All toolbar stuff works on my machine. |
Yeah, only the group window should have a change. Could we implement "highlight" as change in the background color (maybe the JabRef colour) and not via underline? 😇 -> Filed as #932
|
I do not want to mess with the groups code at the moment, as this is done by @tobiasdiez currently - avoding any merge conflicts. The toolbar has not been changed, but the menu itself now shows the state of the toogle-actions. |
Please rebase, then this can be merged in my opinion. |
… menu items and in the groups interface
…works with an additional disable radio button in the menu plus using only a single enum (i.e., a string value instead of using two boolean flags with forbidden combinations (true, true))
I had to improve this fix: previously, two boolean preferences were used to describe the three states DISABLED, ANY and ALL. The combination (true, true) of the booleans was not allowed. I replaced this by using a single string preference which is either "all", "any" or anything else which resorts to DISABLED. I did not implement any migrations as I would take it into account if the behaviour changes upon upgrade as the user can easily change the setting manually. Should not be a hassle. |
Would it make sense to create an enum for these states? |
I tried to create an enum, but ended up creating a separate preferences class with methods for each setting. |
I wonder whether MDSD would have been of any help here 😇 |
??? |