Re: [kde] Bad Gwenview
On Sun, Aug 03, 2014 at 03:20:51AM -0400, Felix Miata wrote: > 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. :-( FWIW, you can of course rearrange your toolbar and you can use the default shortcut F to toggle between 100% and fit-to-window. -- Gruß | Greetings | Qapla’ Ich möchte nicht, daß irgendetwas von mir auf einem sozialen Netzwerk landet. Please do not share anything from, with or about me on any social network. “Hannibal’s plans newer work right. They work.” – Amy, the A-Team signature.asc Description: Digital signature ___ 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.
Re: [kde] Bad Gwenview
Felix Miata posted on Sun, 03 Aug 2014 07:41:09 -0400 as excerpted: > On 2014-08-03 05:40 (GMT-0400) Duncan composed: > >> If you can't get gwenview behaving as you like, >> try gimv and see if it works better for you. > > The trackballs I own have no middle button, while keeping track of > meanings of middle according to context is something I've never been > able to manage, not to mention the difficulty of striking two buttons > simultaneously. Generally, striking one and holding it down, then the other, within a certain (IIRC configurable) period, then let them up within a reasonably close approximation to simultaneously, is enough. They don't have to be clicked /exactly/ at the same time. I've actually been a bit surprised at how well it works, but it does. > I have many installations, making the complicated options (multiple > displays, > mapping) much too much trouble to contemplate. Yes, that wouldn't work for everyone. It's just what works for me. And on my netbook, I generally want the zoom-to-fit, so that too works just fine for me. > Whatever version is whatever version, as most are whatever Cauldron, > Factory or Rawhide offer. 4.13.80 just happened to be the one I wanted > to view some images with. > > I've been able to find no decent keyboards made since the early '90s. > All I have were made before Win keys existed. "Decent" is defined to > mean function keys where they belong, where one hand's fingers can hit > any combination of Fn/Shift/Alt/Ctrl easily. "Decent" means different things to different people. Here, it's not "decent" unless it's an ergonomically split "wave" keyboard. But FWIW I did try an MS branded one (wireless) at some point and it was /horrible/. I've stuck with Logitech since. Anyway, there's other mappings possible. I use a bit different mappings on my netbook, for instance, as some of its keys are already dual-key mapping (Fn-Home, for example). But definitely a few "extra" keys, including an extra modifier generally not used by built-in mappings for individual apps, which is what the win/ super/meta key ends up being, certainly help. That allows that modifier key to be mapped to global "window" functions as there's little danger of a global shortcut conflicting with something app-specific, that way. > Looks like it has worked in v4 previously: > https://bugs.kde.org/show_bug.cgi?id=291759 > > While gimv might be better than "Gwenview", KDE3's Gwenview clearly is, > because when 100% is selected, that's the way it stays until another > selection is made. Apparently I'm not the only one who thinks selecting > 100% ought to be sticky: > https://bugs.kde.org/show_bug.cgi?id=334530 I agree, which is one reason I had to switch to gimv for awhile. It just so happens that in my case, the window can be made large enough that in most cases 100% is smaller than the window, such that gwenview's checkbox for that option works and I can actually have 100% by default. Were it to work the other way and the checkbox applied only to larger-than-window images, I'd have to find another alternative, just as I did when gwenview lost sticky 100% on small images until they restored it with that checkbox option. And as I said, I already apply zoom-step patches to gwenview. If that checkbox option disappeared again and zoom-to-fit became the hard-coded default for small images, I might end up trying to diff and patch that as well. (While I don't claim to be a coder, it's nice to have at least /limited/ ability to read code and to apply patches. It just struck me how much I simply assume that I have sources available and /can/ do that, these days. Quite a difference from back before the turn of the century when I used proprietary servantware, for sure!) -- 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.
Re: [kde] Bad Gwenview
On 2014-08-03 05:40 (GMT-0400) Duncan composed: If you can't get gwenview behaving as you like, try gimv and see if it works better for you. The trackballs I own have no middle button, while keeping track of meanings of middle according to context is something I've never been able to manage, not to mention the difficulty of striking two buttons simultaneously. I have many installations, making the complicated options (multiple displays, mapping) much too much trouble to contemplate. Whatever version is whatever version, as most are whatever Cauldron, Factory or Rawhide offer. 4.13.80 just happened to be the one I wanted to view some images with. I've been able to find no decent keyboards made since the early '90s. All I have were made before Win keys existed. "Decent" is defined to mean function keys where they belong, where one hand's fingers can hit any combination of Fn/Shift/Alt/Ctrl easily. Looks like it has worked in v4 previously: https://bugs.kde.org/show_bug.cgi?id=291759 While gimv might be better than "Gwenview", KDE3's Gwenview clearly is, because when 100% is selected, that's the way it stays until another selection is made. Apparently I'm not the only one who thinks selecting 100% ought to be sticky: https://bugs.kde.org/show_bug.cgi?id=334530 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ 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.
Re: [kde] Bad Gwenview
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
Re: [kde] keyboard and mouse not working after upadte to latest xorg server
Peter Nikolic posted on Sat, 02 Aug 2014 21:25:03 +0100 as excerpted: > Thanks for the reply i think it may be as you suggest a permissions > problem but it is proving to be hell to sort out every thing was fine > untill i accepted the update to the latest Xorg server then well FWIW, latest xorg-server 1.16.0 here, recently upgraded (as it'd have to be, because it only recently came out). No problems to report, but as I said, I do the text login, startx with a kde xsession setting, thing here, and don't even have a *dm installed, so if there were issues with it and *dm, I'd never know it. But it does seem to me that your issue is likely related to logind console session dynamic permissions. Obviously those logging into a text login session and running startx from there have a login session already going when they run startx, with console perms already set for the existing login. That contrasts significantly with the *dm login case, where X is already running and at least basic input perms would be necessary in ordered to be even to login graphically at all, which seems to be your problem. I just don't know how to fix it since the little *dm experience I have is over a decade outdated now, well before systemd's logind solution and indeed, before hal and the like as well, so literally, generations of solutions have come and gone since then. =:^\ > Ok well i am going to be out all day tomorrow fishing =:^) > so will try to solve it monday evening and get back to you then . -- 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.
[kde] Bad Gwenview
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. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ 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.
