GNOME Bugzilla – Bug 689438
Main window does not fit on small screens
Last modified: 2021-05-26 09:51:29 UTC
As originally reported at: https://sourceforge.net/tracker/?func=detail&aid=3429544&group_id=5216&atid=105216 i am trying to use easytag on ubuntu 10.04LTS. i installed the package from synaptic, and when i start the application the screen appears but it is too large for my display (1024x768). in addition, the mouse does not seem to work properly to access pull down menus, i cannot resize the window -- the application is essentially unusable.
Confirmed. The window can neither be maximized, nor can the height be resized to fit a widescreen laptop display. With the latest version this somehow got worse (now I can't even see all the tag-fields) and the application is indeed unusable for displays of this (very common) size.
Created attachment 240702 [details] screenshot
(In reply to comment #1) > Confirmed. The window can neither be maximized, nor can the height be resized > to fit a widescreen laptop display. There is some ugly code in EasyTAG to special-case the maximised-window case (when storing the window size), and it would probably be better if most of the code that saves and restores window locations was removed. That would delegate the decision about window location to the window manager, and should solve the problem of restoring the maximised window state. > With the latest version this somehow got > worse (now I can't even see all the tag-fields) and the application is indeed > unusable for displays of this (very common) size. Unfortunately, some new tag fields were added in the last released version, and this made the default window size even larger than it was originally. There has been a bit of discussion on the mailing list about how to handle adding new tag fields to the UI, and this problem is related: https://mail.gnome.org/archives/easytag-list/2013-March/msg00025.html (In reply to comment #2) > screenshot The small entries are difficult to solve correctly because a user can change font face and size, which make setting the default size in pixels (as was done up to EasyTAG 2.1.8) a bad default. After 2.1.8 there were some reports of the text entries of the GTK+ 3 EasyTAG UI being too wide and causing the tag view to take up half the screen: https://mail.gnome.org/archives/easytag-list/2013-March/msg00005.html This was fixed by setting a default size corresponding to (approximately) the width of the appropriate number of characters for the entry field with gtk_entry_set_width_chars(). This is still not perfect, but at least a better default.
Thank you! I was just going to write a patch for the track# combobox, but in the git-version the problem with has already been resolved. The resizing-problem however remains. I think the only decent way to resolve this is to make the tag-box scrollable. Just removing or rearranging some fields (as suggested on the mailing list) won't do the trick, as there are even smaller screens (e.g. netbooks, tablets). The application should work independenly of the screen size.
(In reply to comment #4) > Thank you! I was just going to write a patch for the track# combobox, but in > the git-version the problem with has already been resolved. Good to know, thanks. > The resizing-problem however remains. I think the only decent way to resolve > this is to make the tag-box scrollable. Just removing or rearranging some > fields (as suggested on the mailing list) won't do the trick, as there are even > smaller screens (e.g. netbooks, tablets). The application should work > independenly of the screen size. I do not think that making the tag field container scrollable is a decent solution. The problem with the EasyTAG UI is that there are various parts of the UI that take up a lot of vertical (and arguably too much horizontal) space, and the solution is to reduce the amount of space that those large parts take up. Luckily, GDK (in 3.4 and above, and in a form that can be backported for applications which use GTK+ 2, like EasyTAG) provides a function that will be useful: https://developer.gnome.org/gdk3/stable/GdkScreen.html#gdk-screen-get-monitor-workarea Knowing the work area and the dimensions of the EasyTAG main window, it would be possible to determine if the UI fitted on the current screen, and to make adjustments to the UI (such as hiding the file header view, or switching to a less space-intensive tag field view) until the main window fitted on the screen. This would also help with different form factors, such as tablet devices in portrait orientation, where the UI would have to change significantly in order to still be usable.
Also reported in the Debian bugtracker: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528030
*** Bug 741671 has been marked as a duplicate of this bug. ***
With 2.2.5 this has gotten even worse. Now, I can't add/edit/delete cover images anymore (see screenshot). Also, I can still not see any status messages or logs. This renders EasyTag mostly unusable and I can't find a workaround for this. Any suggestions? This bug does not only affect me, but all people with a widescreen display laptop (1366x768 or similar).
Created attachment 292937 [details] Screenshot with cut statusbar and cover image section
I can chime in that the window size sadly is a problem also on a 1920x1080 display.
*** Bug 747402 has been marked as a duplicate of this bug. ***
(In reply to Jonathan from comment #10) > I can chime in that the window size sadly is a problem also on a 1920x1080 > display. Program difficult to use even at a resolution of 1366x768! This standard resolution laptop! And how to use the program on a netbook, whose resolution is 1024x600? When designing a program, you need to think about those who currently can not afford to buy a laptop with a resolution of 1080p.
The minimum size of the window should not exceed 1024x575. The next 5 years is a harsh reality.
*** Bug 776925 has been marked as a duplicate of this bug. ***
EasyTag is unusable on my laptop with 1366x768 screen because this very old problem.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/easytag/-/issues/ Thank you for your understanding and your help.