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

Resizing of columns when changing displays #5872

Open
funnym0nk3y opened this issue Jan 26, 2020 · 12 comments
Open

Resizing of columns when changing displays #5872

funnym0nk3y opened this issue Jan 26, 2020 · 12 comments
Labels
component: maintable component: ui [outdated] type: bug Confirmed bugs or reports that are very likely to be bugs status: waiting-for-feedback The submitter or other users need to provide more information about the issue

Comments

@funnym0nk3y
Copy link

funnym0nk3y commented Jan 26, 2020

Hi,

on the current master build I observed a strange behavior when dragging the window from one screen (4K, 150% scaling, screen 1) to another screen (1050p, 100% scaling, screen 2) on Windows 10. Basically the width of the columns in the main view changes when dragging the window from screen 1 to screen 2. But when dragging the window back to screen 1 the width of the columns is not resized.

Screen 1:
grafik

to screen 2:
grafik

and back to screen 1:
grafik

Sorry to bother you again with my HiDPI issues...

funnym0nk3y

@calixtus
Copy link
Member

Hi @funnym0nk3y , thanks for describing the issue. This really seems a bit odd. What would be the expected behaviour?

I believe the deeper cause for the current behaviour is that JabRef / JavaFX is storing the column widths as absolute values instead of relative to the window / screen size.

@calixtus calixtus added [outdated] type: bug Confirmed bugs or reports that are very likely to be bugs component: ui labels Jan 27, 2020
@funnym0nk3y
Copy link
Author

There are three different behaviours I'd find more intuitive:

  • The relative sizes to each other are kept to display the same information what was shown in screen 1 on screen 2.

  • Adding to the first one, one could introduce a minimal width each column should have and if not everything fits into the available width, introduce horizontal scrolling.

  • Save a default layout for each screen. When the user changes column width or shown columns update the default layout to a user specific. When dragging the window arround use the most recent layout.

Those are some possibilities I could imagine...

@calixtus
Copy link
Member

Thanks for the ideas @funnym0nk3y . This issue is marked as a bug and put in the line.

We are always happy about people contributing to JabRef. Maybe you see some things you like to work on?

@funnym0nk3y
Copy link
Author

@calixtus I certainly would, but I have not written literally on line of Java in my life. But I'll try to make contributions where I can!

@tobiasdiez
Copy link
Member

The same problem also appears when the window is resized: #5898 (comment)

@digdig
Copy link

digdig commented Mar 12, 2020

Any schedule of this issues? It still persists in the stable version. Previously I submit a very similar issue on the mac version #5615 , it got fixed. Hope this issue will help the current one.

@ilippert
Copy link
Contributor

ilippert commented May 1, 2020

The same issue affects the width of the window segment reserved for groups, web search etc.

@github-actions github-actions bot added the status: stale Issues marked by a bot as "stale". All issues need to be investigated manually. label Dec 8, 2020
@ilippert
Copy link
Contributor

ilippert commented Dec 8, 2020

JabRef 5.2--2020-12-07--c770310
Linux 5.9.11-200.fc33.x86_64 amd64
Java 15.0.1

I currently experience the problem that when I move jabref from my horizontal screen to a vertical screen, on the vertical screen, JabRef renders the columns not sufficiently wide, so I cannot read anything in them. I cannot scroll the table sideways.

JabRef does restore the prior column widths when returning to the horizontal screen.

@Siedlerchr Siedlerchr added component: maintable and removed status: stale Issues marked by a bot as "stale". All issues need to be investigated manually. labels Dec 8, 2020
@github-actions github-actions bot added the status: stale Issues marked by a bot as "stale". All issues need to be investigated manually. label Jun 7, 2021
@calixtus calixtus removed the status: stale Issues marked by a bot as "stale". All issues need to be investigated manually. label Jun 8, 2021
@funnym0nk3y
Copy link
Author

funnym0nk3y commented Jun 8, 2021

This issue is still present in the latest nightly.

EDIT: I've just seen the stale lable has already been removed.

@ilippert
Copy link
Contributor

I imagine this bug is also related to what I describe at #6348 (comment)

@ThiloteE
Copy link
Member

Does this happen when fit table horizontally on screen that can be found under options>preferences>entry table is enabled or does it happen when it is disabled?

@Siedlerchr Siedlerchr added the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Apr 7, 2022
@JabRef JabRef deleted a comment from github-actions bot Sep 26, 2022
@JabRef JabRef deleted a comment from github-actions bot Sep 26, 2022
@koppor
Copy link
Member

koppor commented Sep 26, 2022

Fixed by #7181

@koppor koppor moved this to Normal priority in Prioritization Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: maintable component: ui [outdated] type: bug Confirmed bugs or reports that are very likely to be bugs status: waiting-for-feedback The submitter or other users need to provide more information about the issue
Projects
Status: Normal priority
Development

No branches or pull requests

8 participants