-
-
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
Rename the Review Tab into Comments Tab #3658
Conversation
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.
At first, I was also confused about the "review" tab. So, I welcome the change. I'm not completely sold on "Comments" - maybe "Notes"? - but I've no strong opinion here.
I think, however, that the field name (in the bib file) should match the tab name and thus would ask you to add a migration step that renames (or at least change the default fieldname and make Review
an alias). Moreover, it would be nice if you could rename all the classes involved (e.g. ReviewTab)
@tobiasdiez I did not change the field name to ensure backwards compatibility. (otherwise we would have to write a migration) Second, the Tab is not an own class, but a Custom Tab, initialized here:
|
Yeah, backwards compatibility is a good point but on the other hand I also find it confusing that the content of the "comments" tab is stored in the field |
Well, I just realized that the Comments field is also displayed in the General tab. :/ Thus, is might be that users have both the Review field and the Comments field filled. Proposed migration: Concatenate the Review to the Comment field, afterwards delete the Review field. |
So as discussed this PR does the following:
|
|
||
action.performAction(actualParserResult); | ||
|
||
assertEquals(new ParserResult(Collections.singletonList(expectedEntry)).getDatabase().getEntryByKey("Entry1"), |
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.
why not just assertEquals(expectedEntry, actualParserResult.getDatabase().getEntryByKey("Entry1"))
?
Same remark applies also to some other tests here.
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.
good remark! (:
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.
Simplifying the entry editor by removing tabs is very much appreciated from my point of view. I have one comment regarding class placement and then this is good to go imho.
I suspect, though, that some users will howl because of this. I also have the feeling that @koppor has an opinion ;-)
@@ -0,0 +1,39 @@ | |||
package org.jabref.logic.importer.util; |
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.
Could you move the complete class into org.jabref.migrations
? Because that's what it actually does, it migrates an opened bib file to a newer version of JabRef. I think it makes sense to bundle all this stuff in a dedicated package, because then it gets easier for us to see what sort of conversions are performed on open.
While you're doing that, could you also move the ConvertLegacyExplicitGroups
?
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.
Done. I also renamed these actions to what they are: migrations
I think this PR is quite ready now |
fixed issue 298
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.
I have some more usability nitpicking:
- When I open a database with entries with review/comment fields a dialog tells me about the problem and I hit yes. Then I end up at the GUI, but nothing is written to the file system and the database is not marked as changed in JabRef. That's weird. Either the changes should make it to the file system directly or the database should be marked as changed.
- The dialog informs on what happens if you click yes. But what are the implications when you say no? No migration and JabRef will keep nagging on next startup? Shouldn't this be an inform dialog where the user can only click ok? After all, the user doesn't have a choice, right?
Btw.: Sorry for merging the other PR into this. It was wrongly based on this PR and I didn't notice before merging...
@lenhard I have incorporated your suggestions. The solution I used for remembering the change in the database was to add a field in the ParserResult class and check that when instantiating the BasePanel. |
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.
Tested locally and it works as expected, but there's still one thing in the code that you have to fix :-)
@@ -19,6 +19,7 @@ | |||
import org.jabref.model.metadata.MetaData; | |||
|
|||
public class ParserResult { | |||
public boolean wasChangedOnMigration = false; |
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.
Sorry, but there is no way I am going to sign off a public instance variable such as this. Please follow the Java Conventions and use a getter and a setter.
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.
Yeah I though somebody might complain... I just find it so stupid... The `protection' is just the same with getters and setters...
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.
I know a new book that's about to come out that argues for keeping to conventions when programming Java ;-)
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.
The "protection" is not the same. Getters and setters encapsulate the variable and might perform (in future) addtional operations on them. That's what I liked about the automatic properties of C#. Automatically generated getters and setters.
import org.slf4j.Logger; | ||
import org.slf4j.LoggerFactory; | ||
|
||
public class MergeReviewIntoComment implements PostOpenMigration { |
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.
I think most of this code should move to the logic package.
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.
I told him to move it there, because I want to have the migrations together. The migrations package should probably go into logic, but some of the migration classes are awefully coupled to UI classes.
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.
ok, then the location is fine. But at least the new class should be completely decoupled in logic and gui since otherwise the migration of the migration package is getting harder with this PR.
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.
@tobiasdiez I guess you mean this line?
if (!conflicts.isEmpty() && new MergeReviewIntoCommentUIManager().askUserForMerge(conflicts)) { |
I can create another Class for this confirmation, but where would you put that?
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.
I have no deep knowledge about the migration code, so the following may be a bit naïve. For me, the expected flow is something like:
- You have a general migration manager class (in gui), which is getting called as soon as the user opens a database
- This manager has a list of possible migrations which are defined in logic and which provide two methods: one for determining if an action is needed and a second one to actually perform the action
- The manager first calls
actionNeeded
and maybe asks the user for confirmation, then runsperformAction
on the migration action.
Not sure how much of this architecture is already in place and how much you are willing to refactor for this PR. My initial comment was triggered by the fact that a new class was created that mixed UI and logic.
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.
Okay, I totally support your point, however this is all a bit tricky, as these PostOpenMigrations are all called before the main GUI is instatiated.
Suggestion: Lets merge this PR now, and I'll refactor the code in a sensible way in a followup PR. (I'm on the train tomorrow for at least 5 hours)
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.
That's fine with me!
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.
The follow-up was done at #3733
Thanks for all the feedback! I'll merge this now and start with the refactoring in the next PR. |
@TarryDan Interestingly, your comment and the follow-up are not shown in my web browsers. Thank you for your long comment and explanation. Especially the "faith" and trust of JabRef not altering data without asking. Back then, the group of developers of JabRef consistet of more progressive developers Now, the more thoughtful voices have more shares. The workaround by @Siedlerchr DOES NOT WORK. We need to fix code @Siedlerchr The workaround by @Siedlerchr is as follows: Close the library, revert all changes. Start JabRef. File -> Preferences -> Entry types. Select "Article". Add "Review" as field: Mark it as optional (AKA non-required) and multiline Click on "Save" Repeat for all other types. Restart JabRef Then, the field appears again: Save the library. Close the library. Open the library again. JabRef displays no warning "Review" moved to comment: This is a BUG! @TarryDan Thank you for raising this. We will discuss internally how to proceed with that and then create a public issue. -- We have "preference migration", where it is IMHO "more OK" to more around data. For libraries it is "more difficult" (to unacceptable in my opinion). |
After a discussion with colleagues, it became apparent, that the Review Tab is maybe named a bit misleadingly. After all I know it is meant for comments about this paper, and I guess few really use it for actual peer-reviews.
To keep consistency, I have just changed the wording.I wrote a migration and handled conflict cases by asking the user.