Re: Bad Gwenview

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felix Miata posted on Sun, 03 Aug 2014 03:20:51 -0400 as excerpted:

> In 4.13.80, is there a way to make it stop shifting back to fit from
> 100% when doing next/previous? The Fit button with mouse is a seriously
> long way away from the prv/nxt buttons. :-(

4.13.80?  That's 4.14-beta1, isn't it, making it a rather outdated pre-
release since 4.13.97 aka 4.14-rc1 is out now.  FWIW I'm running (gentoo/
kde overlay) live-build packages, 4.x-HEAD, now (well, as of a rebuild 
about a day ago) listed as kde 4.14.60, gwenview 4.14.0-pre, but it's 
probably a later 4.14.0 pre than you're running if you're still on kde 
4.13.80.

Never-the-less, I had some sizing issues with gwenview at one point some 
versions ago but they seem to be worked out now, tho I think that's as 
much due to a change in my behavior as a change in gwenview's.

To some extent gwenview sizing behavior depends on whether the image size 
is smaller or larger than the window size.

* Where image size is SMALLER than the window size:

in the config dialog, imageview section, there's a checkbox "Enlarge 
smaller images".  With that set, small images are zoomed IN to window 
size when first displayed.  With it unset, they're 100% view, thus 
smaller than window size for this case.

* Where image size is LARGER than window size:

Unfortunately, there's not a similar checkbox for this case.  It seems 
gwenview now defaults to zooming OUT to window size, tho there's the 100% 
button.


Since I'm running a triple-stacked full-HD monitor config with my full-
size desktop thus 1920x3240 (height of 1080*3), tho with the top monitor 
dedicated to system status display (superkaramba), leaving a working area 
of 1920x2160 (height of 1080*2), and most of the images I deal with here 
aren't /too/ huge, smaller than 1920x2160, the solution I came up with 
was a kwin window rule that sets the gwenview window size to almost, but 
not quite the full 1920x2160, leaving enough room around the edge to 
focus-shift between gwenview and other apps (focus-follows-mouse, click-
to-raise policy), while leaving the gwenview window big enough to show 
most of my images at 100%, with room for the thumbnail bar at the bottom 
and the toolbar on the side (sidebar hidden).

That kwin-window-rule solution works well for me, but I'd certainly be 
frustrated without a multi-monitor setup big enough to allow it, just as 
I was frustrated with gwenview previously, when it started zooming all my 
small images in to >100%, until it got that config checkbox that allowed 
setting the small-image default-zoom to 100%.


Meanwhile, as you mentioned there's the fit/100% buttons and zoombar, but 
it's not exactly convenient to repeatedly hit them for /every/ image.  
There are, however, a couple workarounds.

1) Mouse middle-button.  In gwenview, clicking the middle mouse button 
toggles between 100% and zoom-to-fit mode.  While clicking the middle 
button repeatedly in mouse-browse mode is certainly tedious, it's 
definitely less so than having to move to the fit/100% buttons every time.

(Two-button mouse note:  Two-button mice can be configured such that 
clicking both buttons together emulates a middle-click.  While my mouse 
has/had a middle button, that's also the scrollwheel, and I used to have 
issues with accidentally scrolling when I wanted to middle-click, or less 
often, middle-clicking when I wanted to scroll.  So when the middle-click 
button broke I was actually a bit relieved as the scrolling functionality 
was then uninterrupted and third-button click emulation using the other 
two buttons worked well enough for me anyway.  So here, I dual-click left/
right together to middle-click. That works well enough in gwenview, 
particularly with the window-rule enlarged gwenview window size described 
above so I don't have to do it so often. =:^)

2) Keyboard shortcuts.  Given kde's common keyboard shortcut remapping 
functionality, I long ago remapped keyboard shortcuts both in kde 
globally and in gwenview specifically, so I've no longer any idea what 
the default mapping might be.  However, here's my zoom-related mapping:

Gwenview:

Zoom-to-fit:	ctrl-right
Actual-size:	ctrl-left
Zoom-in:	ctrl-plus
Zoom-out:	ctrl-minus

IIRC gwenview's default zoom-step is 100% at a time, way **WAY** to big 
for me, so when gwenview changed that from it's earlier much smaller zoom-
step, I diffed the sources for the two versions and came up with a patch 
that redefined the zoom-step to 5%.  Since I run gentoo and build from 
sources anyway, I was able to simply drop that patch in the appropriate 
location, and it gets automatically applied when I rebuild gwenview -- 
which given I'm running live-sources and typically update once or twice a 
week, automatically rebuilding gwenview if its sources have changed, 
means I've rebuilt and applied that patch quite some number of times by 
now. =:^)

So anyway, with that patch zoom-in and zoom-out do so in 5% steps for me, 
not the 100% steps that are IIRC the default. =:^)  I can of course post 
the patch if you're interested...

But these days I don't actually use gwenview zooming, other than 
occasionally the actual/fit toggling, so much.  Instead:

Kwin whole-desktop zoom-effect:

Zoom-in:	meta-ctrl-up
Zoom-out:	meta-ctrl-down
Actual-size:	meta-ctrl-left

(Meta is my "winkey", which I reserve for global kwin/window effect 
shortcuts, meta/win-end to close a window, for instance, win-c for the 
cube effect, etc.  So win-arrow shortcuts make sense for zooming, but 
simple win-arrow is reserved for left/right/up/down movement when zoomed, 
so win-ctrl-arrow is what I use to zoom-in/out/normal.)

At least on Radeon graphics with the native kernel driver (I don't do 
proprietary drivers), kwin's opengl-based zooming is more efficient and 
of better quality than gwenview's, anyway. =:^)

FWIW I have kwin's zoom set to 1% zoom-steps.  Which works really well 
with auto-repeat, zooming in/out smoothly as I hold the keys down.


So all told the solution I use here is:

1) Multiple monitors and a kwin rule to set gwenview size larger than a 
single monitor and generally larger than most images I view in gwenview.

2) Kwin whole-desktop zooming using keyboard shortcuts.

Less often but as necessary:

3) (Sometimes) Gwenview middle-click 100%/fit zoom toggle.

4) (Seldom) Gwenview keyboard shortcut zooming, using 5% zoom-step patch.


Meanwhile, as I mentioned, at one point I found gwenview's behavior a bit 
broken for my needs.  During that time I found a gtk-based alternative 
that seems to work reasonably well, tho I never used it enough to become 
as comfortable with it as I am with gwenview, and between my own behavior 
changing and gwenview getting that small-image default-zoom behavior 
checkbox, I'm back on gwenview now.  But it's nice to have working 
alternatives when they are needed, and this is mine:

gimageview, aka gimv .  If you can't get gwenview behaving as you like, 
try gimv and see if it works better for you.  As I said it does seem to 
be a reasonable alternative to gwenview for my usage, and tho gwenview's 
working for me well enough now, having an alternative comes in useful 
when it's not. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.




[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux