Merge Entries Dialog should render properly at smaller screen resolutions

[koppor]

I have a Full HD (1920x1080) resolution for screen sharing.

It renders as follows at first start:

Can this be changed? - Maybe start maximized if it covers more than one screen at the first start

Updates:

• This happened after the first (!) run of the new dialog and trying to maximize the dialog.
• When the user maximized the dialog, JabRef should start the new instance also maximized

Refs #6190

[u7306160]

Hi, my group plan to work on this issue and do it by the end of October 2022. This is our first issue on an open-source project. Looks like it hasn't been updated since August. Could you assign this issue to me, please?

[ThiloteE]

sure :-)

As a general advice for newcomers: check out https://github.com/JabRef/jabref/blob/main/CONTRIBUTING.md for a start. Also, https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace is worth having a look at. Feel free to ask if you have any questions here on GitHub or also at 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.

Since this is your first contribution, be aware that we collect good first issues here: https://github.com/orgs/JabRef/projects/5

[u6689285]

Hi, just want to check that it needs us to solve that when the user changes the size of the dialog, other components in the dialog should change the size with same ratio. or when it starts first time, the dialog should be the full screen.

[u6689285]

Hi, do you mean when you open the dialog first time, it is over the screen? @koppor

[ThiloteE]

@u6689285 Koppor is a very busy person and he has so many issues and messages spamming him that this here might have flown a little under his radar. Do you have two screens you could test this with a resolution of 1920x1080? You can enter the "merge entries dialogue" by selecting two entries and then choose "Quality --> Merge entries (CTRL+M)"

If I understand Koppor right, then yes, at first start of the dialogue, it goes over the screen.

Goal would be to have the screen fit within one screen, which it does on my laptop with a very small screen size of 1366x768 (Linux Mint), so maybe there is something off with the window manager on windows, or only when there are two screens?

[koppor]

Reproducing steps:

1. Set screen resolution to 1920x1080
2. Create a new library (if buttons are disabled. Save the library and restart JabRef)
3. Add a new entry
4. Content: author: Demo
   
5. Select the entry in the entry table
6. Type Ctrl+C
7. Type Ctrl+V
8. Merge Entries dialog opens - and is not shown fully on the screen, but off the screen:
   

Expected result:

Dialog moved to the screen so that it fits. If the dialog is too large, it is resized.

For demonstration purposes, I just hit the "maximize" button:

[u7306160]

Hi, could you check the PR I create (#9278), I think it talks about the same merge entries dialog as yours. And after improving, the dialog is fully on the screen.

[koppor]

I am not sure whether this is a "Window Manager" issue - and the issue only happening on Windows. @ThiloteE does this also appear on Linux?

[ThiloteE]

I was able to reproduce the issue on newest jabref development version using Linux Mint Cinnamon.

[ThiloteE]

ACTUALLY, my problem is a different bug. I just noticed that not the merge dialogue gets pushed to second screen upon start, but a part of JabRef's main window instead, which I cannot find an issue for, but was probably caused by changes introduced pr #8936, because it roughly emerged for me around that time.

What usually happens on my machine is this: once a second window pops up is that the main window of JabRef takes the left half side of the screen and once the second window closes, it will return to its original position, which I have ignored up till now, because yes it is kinda weird and not really how it should be, but there was no harm done until now.

In short: Maybe it is a window manager problem after all? I now also was able to reproduce this jump to the left with pr 9278, so yeah, it does not really make a difference for me if this pr gets merged or not.

---

Edit: I was not able to properly test this issue, because I have a very small screen on my Linux device. I found both the current implementation and the proposed pull-request #9278 to be very satisfactory.