D12848: Set fix steps for icon sizes

[Henrik Fehlauer]

rkflx added a comment.


  > In the open/save dialog use the same fixed icon sizes for the zoom slider as Dolphin.
  
  So we could also change Dolphin to support continuous zoom instead? As the summary is quite sparse, I'm not sure what the patch is about: Is it about consistency, or is there a fundamental reason why fixed sizes are better for users?
  
  Note that we allow arbitrary window sizes, sidebar sizes and so on. Targeting a specific icon size can still easily be done by clicking on the button, or by dragging the slider while observing the tooltip showing the pixel size.
  
  Personally I prefer smooth zooming (which Dolphin is doing, too) instead of having big jumps between steps. Nevertheless, if you can find more +1's and better reasons for the change itself, I'm not going to block this patch. However, "nobody complained for Dolphin" is not good enough of a reason.
  
  Could you research why for Dolphin there are discrete sizes? Maybe this stems from pre-SVG times, where only certain pixel sizes had sharp rendering of icons. If this is the case, with today's SVGs we could easily support all in-between sizes without much loss of rendering quality.
  
  In D12848#262303 <https://phabricator.kde.org/D12848#262303>, @ngraham wrote:
  
  > IMHO what we really need is a standard size slider widget so that each app doesn't need to reinvent the wheel. Right now Gwenview, Dolphin, and the file dialogs each implement their own, and they're all subtly (or very) different from each other.
  >
  > That said, I find myself agreeing with Kai and Alex here. Arbitrary zoom levels aren't really needed in the file dialog like they are in Gwenview. Dolphin's slider has discrete sizes and I don't think it causes problems there.
  
  
  I'm confused: First you propose a common widget, and then you say Gwenview needs arbitrary zoom levels?

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D12848

To: anemeth, #frameworks, #vdg
Cc: broulik, rkflx, ngraham, kde-frameworks-devel, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180515/eeb12aa1/attachment.html>