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

Relevance star should only appear when toggled #10431

Closed
ryan-carpenter opened this issue Sep 30, 2023 · 7 comments · Fixed by #10742
Closed

Relevance star should only appear when toggled #10431

ryan-carpenter opened this issue Sep 30, 2023 · 7 comments · Fixed by #10742
Assignees
Labels
FirstTimeCodeContribution Triggers GitHub Greeter Workflow maintable ui

Comments

@ryan-carpenter
Copy link

When the Relevance (Special) column is shown in the entry table and the relevance of an entry is false, hovering over the entry makes a star appear in that column, regardless of the actual value. This makes it hard to identify and select the intended value, because relevance always appears true for the entry under the cursor. For instance, clicking with the intention of removing the star when relevance is already false will set it to true (opposite of the intended result).

The relevance status should be discernable regardless of hovering state.

Possible solutions

  • Show relevance star only when relevance = true
  • Use a different indicator on hover when relevance = false

JabRef 5.10--2023-09-01--779e555
Linux 6.4.12-1-default amd64
Java 21-internal
JavaFX 20+19

@LenkaBuebnkova
Copy link

Hi, I would like to try to solve this issue, if it's possible :)

@ThiloteE ThiloteE added the FirstTimeCodeContribution Triggers GitHub Greeter Workflow label Sep 30, 2023
@github-actions
Copy link
Contributor

As a general advice for newcomers: check out Contributing for a start. Also, guidelines for setting up a local workspace is worth having a look at.

Feel free to ask here at GitHub, if you have any issue related questions. If you have questions about how to setup your workspace use JabRef's Gitter chat. Try to open a (draft) pull-request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback.

@ThiloteE
Copy link
Member

Thanks, @LenkaBuebnkova
To test your changes, you can go to File > Preferences > Entry table > ... and add Relevance (Special) to the table.
image
image

@github-project-automation github-project-automation bot moved this to Normal priority in Features & Enhancements Sep 30, 2023
@ThiloteE ThiloteE moved this from Normal priority to Low priority in Features & Enhancements Sep 30, 2023
@ryan-carpenter
Copy link
Author

The BibTeX source shows relevance = {relevant} for true or no data for false

@LenkaBuebnkova
Copy link

Hello, I'd appreciate a more comprehensive explanation. While I grasp the general idea, I'm struggling to pinpoint the specific section of the code responsible for setting the 'RELEVANCE' value. Could you kindly assist me in locating this information?

@koppor
Copy link
Member

koppor commented Oct 23, 2023

@LenkaBuebnkova I think, maybe the code is somewhere in org.jabref.gui.maintable.columns.SpecialFieldColum. I currently do not see where the actual data is filled. You need to read the code.

Note that you can search for an arbitrary string in the code using Ctrl+Shift+F. Maybe that helps to locate some code.

@koppor
Copy link
Member

koppor commented Jan 2, 2024

I can reproduce.

The issue is that we treat toggle fields differently than fields with more than one value.

grafik

Long ago, we decided that it has to be possible to quickly change the state. We did not want to distinguish between undefined, true, and false. We decided to have following to cases:

relevance = {relevant} if entry is relevant

@Article{,
  priority   = {prio1},
  readstatus = {read},
  relevance  = {relevant},
}

and relevance not existing if not relevant

@Article{,
  priority   = {prio1},
  readstatus = {read},
}

We are aware that this cases huge diffs if changing that state, but we accept it in favor of a smaller BibTeX file.


One sees that we use the same color for "relevant" and for "toggle relevance" (on hover). This is not an issue for the read status, because we use colors if set.

There is not a consistency between the contents for the star-ratings (1 to 5 stars if set - all unset stars are gray) and the hover for the other fields.

We do not want to do a deep change to relevance (e.g., introducing slightly relevant, relevant, highly relevant), but keep as is.

We do following:

  • Show relevance star only when relevance = true (already implemented)
  • Use a different indicator on hover when relevance = false --> we will use a different color (consistent with the stars)

Fix: Color the icons to the colors of the five gray stars (instead of the black). Hoping that the user can distinguish gray from black.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FirstTimeCodeContribution Triggers GitHub Greeter Workflow maintable ui
Projects
Archived in project
4 participants