Scale album art by number of images, rather than image size

coderkun commented

2017-06-17 23:51:58 +02:00

(Migrated from gitlab.com)

Created by: wtok

MCG is a great program, thanks for making it.

In my opinion, it only really makes sense for the album art scale slider to switch between how many albums can be fit horizontally, rather than the image size. As it is today, I have to make micro-adjustments on the slider to avoid having a bunch of empty space on the right side of the grid view.

I think the slider should just have a list of small numbers that make sense -- probably calculated based on some minimum album art size, and the width of the window. On a super-high resolution screen you might be able to select 1-50, but on a small screen you could select 1-20 or so, and the actual image size would be calculated based on how many images the user wants to fit horizontally.

*Created by: wtok* MCG is a great program, thanks for making it. In my opinion, it only really makes sense for the album art scale slider to switch between how many albums can be fit horizontally, rather than the image size. As it is today, I have to make micro-adjustments on the slider to avoid having a bunch of empty space on the right side of the grid view. I think the slider should just have a list of small numbers that make sense -- probably calculated based on some minimum album art size, and the width of the window. On a super-high resolution screen you might be able to select 1-50, but on a small screen you could select 1-20 or so, and the actual image size would be calculated based on how many images the user wants to fit horizontally.

coderkun commented

2017-06-18 12:12:48 +02:00

(Migrated from gitlab.com)

Created by: coderkun

Thanks for the great feedback. I totally agree that the current approach easily creates blank, wasted space (on the right) and has some UX issues in adjusting it for the perfect width. Your suggestion of setting the number of covers to show horizontally and then calculating the cover width based on that number to fit the total width would be more usable and would avoid the blank space.

I have two questions though:

How should the application behave when resizing the windows? Will the covers be resized/recalculated to keep the same number of covers in view (if this is not done, the same blank space will appear)? And what happens if the window is resized from a very large size where probably 50 covers easily fit in one row to a very small size? Will the covers be very small (because we keep 50 ones in one row) or will there be a minimum pixel size which leads to an automatic reduction of the number of covers?
How should the available appropriate numbers of covers be calculated? This would require a smart logic to provide good results (e. g. using the screen resolution, DPI and window size—also recalculated when resizing the window).

For this kind of setting maybe a GTK SpinButton would make more sense though it would be harder to trigger the actual resizing process.

*Created by: coderkun* Thanks for the great feedback. I totally agree that the current approach easily creates blank, wasted space (on the right) and has some UX issues in adjusting it for the perfect width. Your suggestion of setting the number of covers to show horizontally and then calculating the cover width based on that number to fit the total width would be more usable and would avoid the blank space. I have two questions though: 1. How should the application behave when resizing the windows? Will the covers be resized/recalculated to keep the same number of covers in view (if this is not done, the same blank space will appear)? And what happens if the window is resized from a very large size where probably 50 covers easily fit in one row to a very small size? Will the covers be very small (because we keep 50 ones in one row) or will there be a minimum pixel size which leads to an automatic reduction of the number of covers? 2. How should the available *appropriate* numbers of covers be calculated? This would require a smart logic to provide good results (e. g. using the screen resolution, DPI and window size—also recalculated when resizing the window). For this kind of setting maybe a [GTK SpinButton](https://developer.gnome.org/gtk3/stable/GtkSpinButton.html) would make more sense though it would be harder to trigger the actual resizing process.

coderkun commented

2017-06-20 03:51:06 +02:00

(Migrated from gitlab.com)

Created by: wtok

I think although the slider would select a number of columns, the user actually goes there with the goal of adjusting the image size. With that in mind, I think it'd more closely follow the Principle of Least Astonishment if the images always tried to stay the same size unless that slider is adjusted.

So when the window is resized, the number of columns would change, not the size of the images. Obviously they will usually have to scale slightly when the window is resized, but probably not enough to matter. However this is one of those things that's hard to get right just by imagining it. It'd probably best to try a few different ways of doing it, and see which one feels best.

I'm not quite sure what you mean by the second question, but I'll try to explain what I was thinking in the original post. I imagine you would need to set some minimum album art size in pixels -- say 25 pixels wide or something like that. The maximum number of columns would then be selected based on the width of the window. We don't need to worry about screen resolution and DPI; if the user's window is 2500 pixels wide, they can probably fit almost 100 columns. If it's a high-DPI screen and that's too small, they can always choose a smaller number if they like.

You could use DPI to make sure images don't get too small, but then we'd have to consider image size in inches rather than pixels, which might make things overly complicated -- for both the programmer and the user.

As for the SpinButton -- like I was saying above, I think the user is thinking "I want to make the images bigger", not "I want fewer columns", and a slider is very intuitive for that. I think you could just label the slider "Images per row", have it snap to each number, and put the current value next to it, and it'll be totally fine.

*Created by: wtok* I think although the slider would select a number of columns, the user actually goes there with the goal of adjusting the image size. With that in mind, I think it'd more closely follow the Principle of Least Astonishment if the images always tried to stay the same size unless that slider is adjusted. So when the window is resized, the number of columns would change, not the size of the images. Obviously they will usually have to scale slightly when the window is resized, but probably not enough to matter. However this is one of those things that's hard to get right just by imagining it. It'd probably best to try a few different ways of doing it, and see which one feels best. I'm not quite sure what you mean by the second question, but I'll try to explain what I was thinking in the original post. I imagine you would need to set some minimum album art size in pixels -- say 25 pixels wide or something like that. The maximum number of columns would then be selected based on the width of the window. We don't need to worry about screen resolution and DPI; if the user's window is 2500 pixels wide, they can probably fit almost 100 columns. If it's a high-DPI screen and that's too small, they can always choose a smaller number if they like. You *could* use DPI to make sure images don't get too small, but then we'd have to consider image size in inches rather than pixels, which might make things overly complicated -- for both the programmer and the user. As for the SpinButton -- like I was saying above, I think the user is thinking *"I want to make the images bigger"*, not *"I want fewer columns"*, and a slider is very intuitive for that. I think you could just label the slider "Images per row", have it snap to each number, and put the current value next to it, and it'll be totally fine.

coderkun commented

2017-06-20 09:37:22 +02:00

(Migrated from gitlab.com)

Created by: coderkun

Thanks, @wtok, for the detailed explanation. I will think about it and create a test implementation to see how it feels.

Are you willing to test this (on a different branch) once there is something to test?

*Created by: coderkun* Thanks, @wtok, for the detailed explanation. I will think about it and create a test implementation to see how it _feels_. Are you willing to test this (on a different branch) once there is something to test?

coderkun commented

2017-06-21 02:20:07 +02:00

(Migrated from gitlab.com)

Created by: wtok

Absolutely, I'd be happy to test. Please let me know once you've got something.

*Created by: wtok* Absolutely, I'd be happy to test. Please let me know once you've got something.

coderkun commented

2017-12-24 11:42:16 +01:00

(Migrated from gitlab.com)

Created by: coderkun

I am currently playing around with adding marks to the GtkScale. This seems to work fine except for some drawing issues Gtk seems to have with that …

*Created by: coderkun* I am currently playing around with adding marks to the GtkScale. This seems to work fine except for some drawing issues Gtk seems to have with that …

coderkun commented

2017-12-24 12:10:09 +01:00

(Migrated from gitlab.com)

Created by: coderkun

Okay, I have fixed the drawing issues and marks are working now.

@wtok, do you want to check out branch issue-28-album-art-scaling and see if the marks in the grid scale are working and providing what you want?

*Created by: coderkun* Okay, I have fixed the drawing issues and marks are working now. @wtok, do you want to check out branch `issue-28-album-art-scaling` and see if the marks in the grid scale are working and providing what you want?

coderkun commented

2017-12-26 07:38:46 +01:00

(Migrated from gitlab.com)

Created by: wtok

Thanks for all the work. I'm off on holiday at the moment so I won't be able to test this for a few weeks, but I'll definitely give it a look when I get back.

*Created by: wtok* Thanks for all the work. I'm off on holiday at the moment so I won't be able to test this for a few weeks, but I'll definitely give it a look when I get back.

coderkun commented

2017-12-26 09:57:20 +01:00

(Migrated from gitlab.com)

Created by: coderkun

Thanks, @wtok. Since the marks are a pretty small addition, I will merge this into the master branch and release it as part of version 1.3. Please feel free to open a new issue for further changes/a different way to handle this.

*Created by: coderkun* Thanks, @wtok. Since the marks are a pretty small addition, I will merge this into the master branch and release it as part of version 1.3. Please feel free to open a new issue for further changes/a different way to handle this.

coderkun commented

2018-08-04 11:12:18 +02:00

(Migrated from gitlab.com)

mentioned in issue #55

Scale album art by number of images, rather than image size #28