Change max number of selected images in View mode

Hi fellow KDE lovers!

I’m looking for some input/thoughts on something I’ve been thinking about adding to Gwenview for a while.

That is the ability to change the max number of selected images from the hard-coded 6. This is because on large screens, 4k, 5k and above, being limited to 6 selected images is too few. I’d like to be able to have the max number set in some way - perhaps by user input in a number entry widget, or by Gwenview having some awareness of what kind of screen it’s running on, and changing the number up or down accordingly. Or maybe have the number configurable in a setup file…

I’ve found the relevant place in mainviewpage.cpp - line 80 where an integer constant is declared - const int ViewMainPage::MaxViewCount = 6;

I’m able to change that in KDevelop or any text editor and rebuild Gwenview with the new value - I randomly chose 8 - and rebuild with kdesrc-build, and it all seems to work - the layout management code still copes with the images.

The questions I have are:

  • Do people think this is a good idea?
  • What is the best mechanism to make it variable?
  • How to make such a change persistent across session for a given user?
  • How to make the View code aware of a mid-session change, and adapt accordingly? I think that having it as a static constant at compile time means that the current system wouldn’t become aware of any change, as it’s set up at instantiation of the component, and if changed, the component would have to be re-initialized.

I’m a newbie at KDE development, so looking for advice from more experienced folks!

When I select pictures in Dolphin and chose to open them in Gwenview I get to see all the pictures I selected:

So I wonder if we are talking about the same thing.
I use Gwenview 24.05.0 on Fedora Kinoite. Which version do you use?

The selected images within gwenview itself I guess.

Hi…thanks for taking time to reply. I’m also using GV 24.05.0, but on KDE Neon.

I’m not talking about selecting pictures in Dolphin at all. This is all inside Gwenview. When in View (not browse) mode, you can have up to 6 images selected and displayed in the View Pane, and I want to be able to take advantage of larger screens by allowing more.

Hi!

I have never actually compared more than three images using this feature, so I am not sure if more than six is really needed. However, I don’t quite see a reason why it should be restricted to six either.

What is the best mechanism to make it variable?

Making this configurable by users seems like a bit too much customisation for a somewhat minor thing to me. As you noticed, making this configurable leads to some followup problems which you aptly identified. Aside from the extra work in code we also have to keep in mind that for every user who doesn’t want to change this, this is just extra unnecessary stuff in the user interface.

How to make such a change persistent across session for a given user?

To make such changes persistent they need to be saved to the disk and read from there. This is very commonly needed so KDE has a framework for this called KConfig - KConfig. Gwenview already uses this, so you can simply see how other parts of Gwenview are saving such changes and copy that approach.

How to make the View code aware of a mid-session change, and adapt accordingly? I think that having it as a static constant at compile time means that the current system wouldn’t become aware of any change, as it’s set up at instantiation of the component, and if changed, the component would have to be re-initialized.

That is correct.

Reacting to changes during normal application runtime means that you need to detect such a change happening and then communicate this change to the relevant objects. The objects need to be implemented in a way that allows sudden changes to this value.

KConfig can help and signal when a value changed. Here is an commit that does this: Fix closing a secondary viewContainer on startup settings change (fa8d9de4) · Commits · System / Dolphin · GitLab You can also see that this signal is connected to a relevant object that then triggers a change in the user interface.


I would say you have identified all the difficult parts in this and you do seem to show the right mindset to accomplish such a change. Perhaps the smaller adaption of changing the ViewMainPage::MaxViewCount to something like 10 is completely sufficient in this case though.