Skip to content
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

Merged
merged 28 commits into from
Feb 17, 2018
Merged

Rename the Review Tab into Comments Tab #3658

merged 28 commits into from
Feb 17, 2018

Conversation

LinusDietz
Copy link
Member

@LinusDietz LinusDietz commented Jan 22, 2018

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.


  • Change in CHANGELOG.md described
  • Manually tested changed features in running JabRef
  • Test created
  • Check documentation status (Issue created for outdated help page at help.jabref.org?)

@LinusDietz LinusDietz added type: enhancement status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers entry-editor labels Jan 22, 2018
Copy link
Member

@tobiasdiez tobiasdiez left a 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)

@LinusDietz
Copy link
Member Author

@tobiasdiez I did not change the field name to ensure backwards compatibility. (otherwise we would have to write a migration)
Is this a good (enough) argument?

Second, the Tab is not an own class, but a Custom Tab, initialized here:

defaults.put(CUSTOM_TAB_FIELDS + "_def2", FieldName.REVIEW);

@tobiasdiez
Copy link
Member

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 review. I don't know how to proceed. Maybe we should indeed write a migration...

@LinusDietz
Copy link
Member Author

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.
Anyways, this makes it clear that the solution as it is right now cannot be used and we definitely have to write a migration if we want to rename this tab.

Proposed migration: Concatenate the Review to the Comment field, afterwards delete the Review field.
The Comment field should go from the General Tab to the Comments tab.

@LinusDietz LinusDietz removed the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Jan 22, 2018
@LinusDietz LinusDietz changed the title Rename the Review Tab into Comments Tab [WIP] Rename the Review Tab into Comments Tab Jan 22, 2018
@LinusDietz
Copy link
Member Author

So as discussed this PR does the following:


action.performAction(actualParserResult);

assertEquals(new ParserResult(Collections.singletonList(expectedEntry)).getDatabase().getEntryByKey("Entry1"),
Copy link
Member

@tobiasdiez tobiasdiez Feb 14, 2018

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

good remark! (:

@LinusDietz LinusDietz changed the title [WIP] Rename the Review Tab into Comments Tab Rename the Review Tab into Comments Tab Feb 14, 2018
@LinusDietz LinusDietz added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Feb 14, 2018
Copy link
Member

@lenhard lenhard left a 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;
Copy link
Member

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?

Copy link
Member Author

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

@LinusDietz LinusDietz requested a review from koppor February 14, 2018 13:18
@LinusDietz
Copy link
Member Author

I think this PR is quite ready now

Copy link
Member

@lenhard lenhard left a 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...

@LinusDietz
Copy link
Member Author

@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.

Copy link
Member

@lenhard lenhard left a 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;
Copy link
Member

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.

Copy link
Member Author

@LinusDietz LinusDietz Feb 16, 2018

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...

Copy link
Member

@lenhard lenhard Feb 16, 2018

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 ;-)

Copy link
Member

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 {
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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 runs performAction 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.

Copy link
Member Author

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)

Copy link
Member

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!

Copy link
Member

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

@LinusDietz
Copy link
Member Author

Thanks for all the feedback! I'll merge this now and start with the refactoring in the next PR.

@koppor
Copy link
Member

koppor commented Sep 6, 2023

@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:

image

Mark it as optional (AKA non-required) and multiline

image

Click on "Save"

Repeat for all other types.

Restart JabRef

Then, the field appears again:

image

Save the library.

Close the library.

Open the library again.

JabRef displays no warning

image

"Review" moved to comment:

image

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).

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

Successfully merging this pull request may close these issues.

8 participants