GNOME Bugzilla – Bug 479884
Mouse dragging UI broken.
Last modified: 2008-04-17 23:07:40 UTC
This bug is a direct result of bug #341935. The default of the program has changed a major (if not THE major) working of the program. Scroll wheel zoom and mouse drag no longer work. If there was ever any reason to use eog, that ease of operation was it. There is a hidden gconf key to restore the scroll wheel zoom. However, it does not honour the old behaviour on upgrade, and it certainly isn't easy to find. There must be a preference in the UI to disable this. The second is that there appears to be NO way to restore dragging to button one. This not only makes it inconsistent with the scrollwheel-zoom functionality, but it also makes eog impossible to use on a typical laptop with one hand. I would like to propose that in terms os HIG and usability, this is a MAJOR regression. You need two hands to operate this thing now.
(In reply to comment #0) > This bug is a direct result of bug #341935. Ok. > The default of the program has changed a major (if not THE major) working of > the program. Scroll wheel zoom and mouse drag no longer work. If there was ever > any reason to use eog, that ease of operation was it. > > There is a hidden gconf key to restore the scroll wheel zoom. However, it does > not honour the old behaviour on upgrade, and it certainly isn't easy to find. > There must be a preference in the UI to disable this. At first sight, adding preferences for that in the UI doesn't seem to be a good shot because it's too specific. I'd like to get some feedback from other/more users to know if this is really needed. I've added this hidden gconf key in order to keep "power users" able to keep this behavior if they want. Also, according to HIG: 1. The scroll-wheel should be used for vertical scrolling 2. Shift+scroll-wheel should be used for horizontal scrolling 3. Ctrl+scroll-wheel should be used for zooming > The second is that there appears to be NO way to restore dragging to button > one. This not only makes it inconsistent with the scrollwheel-zoom > functionality, but it also makes eog impossible to use on a typical laptop with > one hand. There's a problem on keeping the button one for dragging because we have this plan of adding some more advanced image transformations (like cropping) which involve selecting a region of the image with button one. This is why we're using middle-button for dragging now. However, according to HIG we should not depend only on middle-button for any action. This is why you can use Ctrl+Button1 for dragging as well. > I would like to propose that in terms os HIG and usability, this is a MAJOR > regression. You need two hands to operate this thing now. EOG 2.20 is much more compliant with HIG and the problems you report here are basically against HIG guidelines. Therefore, I suggest you to open discussions about those issues in HIG scope. The only thing I can do is to provide some kind of "power/hidden features" that would enable users (like you) to tune EOG according to your specific needs.
(In reply to comment #1) > At first sight, adding preferences for that in the UI doesn't seem to be a good > shot because it's too specific. I'd like to get some feedback from other/more > users to know if this is really needed. I've added this hidden gconf key in > order to keep "power users" able to keep this behavior if they want. Also, However, the gconf key does not revert all of the UI. Without button1 dragging, scroll-zooming is quite useless. Maybe just a checkbox that says "classic mode" or something along those guidelines, and elaborates with a short message? > There's a problem on keeping the button one for dragging because we have this > plan of adding some more advanced image transformations (like cropping) which > involve selecting a region of the image with button one. This is why we're > using middle-button for dragging now. However, according to HIG we should not > depend only on middle-button for any action. This is why you can use > Ctrl+Button1 for dragging as well. There has always been the question of whether eog should even edit pictures. It was designed to be an ultra-light-weight (read "fast") image viewer. The more gets added to it, the more the startup time increases. There is already a significant startup penalty compared to eog 2.6, with functionality added that I'd use Gimp or gthumb for anyway. I know the argument that neither is in platform, but realistically one of the other two is always there. Nevertheless, an edit mode should be just that, a mode. Much like Adobe Reader has drag mode and selection mode toggled on the toolbar. > EOG 2.20 is much more compliant with HIG and the problems you report here are > basically against HIG guidelines. Therefore, I suggest you to open discussions > about those issues in HIG scope. The only thing I can do is to provide some > kind of "power/hidden features" that would enable users (like you) to tune EOG > according to your specific needs. The HIG hardly applies. It just doesn't cover good usability on anything with a large scrollable canvas. We see this same problem for Evince and Inkscape. As you point out in the other bug, Gimp does what they feel is best, not what the HIG says. EOG was written with good user interactability in mind, much of which predates the HIG. The classic scrolling method is hardly a power user thing. Use case, I'm a regular user, I want to see a detail in a digital photo I took. I remember that hitting "1" will get me 100% zoom, so I hit it. Now I need to get over to where my son's face is. I drag the photo as I've been doing for six years now and nothing happens. I grudgingly move my mouse to the vertical scroll bar and move up. Still not where I want to be. I move my mouse to the bottom scroll bar and move it left. I notice I'm off vertically, so I move my mouse back to the vertical scrollbar. Click-and-drag had a nice little hand cursor and was very discoverable. That is why it is the default mode in Adobe Reader. I maintain it's not right to change the major functional component of a program just because someone complains that a program isn't 100% in alignment with a book of suggestions. And it is a book of suggestions to any program with established workings. As a user, do you like the behaviour of the program more now?
Come to think of it, would it not be a good solution to do what Adobe Reader does with a toggle between pan-by-scrollbar-and-edit and click-and-drag-view? I think it would be a good way to keep the functionality, do something users are familiar with from other programs, and keep the editing features out of the way unless they are toggled on.
(In reply to comment #2) > (In reply to comment #1) > > At first sight, adding preferences for that in the UI doesn't seem to be a good > > shot because it's too specific. I'd like to get some feedback from other/more > > users to know if this is really needed. I've added this hidden gconf key in > > order to keep "power users" able to keep this behavior if they want. Also, > > However, the gconf key does not revert all of the UI. Without button1 dragging, > scroll-zooming is quite useless. You're right. I'll fix this. > Maybe just a checkbox that says "classic mode" or something along those > guidelines, and elaborates with a short message? I really can't think of any good description for this. > > There's a problem on keeping the button one for dragging because we have this > > plan of adding some more advanced image transformations (like cropping) which > > involve selecting a region of the image with button one. This is why we're > > using middle-button for dragging now. However, according to HIG we should not > > depend only on middle-button for any action. This is why you can use > > Ctrl+Button1 for dragging as well. > > There has always been the question of whether eog should even edit pictures. It > was designed to be an ultra-light-weight (read "fast") image viewer. The more > gets added to it, the more the startup time increases. There is already a > significant startup penalty compared to eog 2.6, with functionality added that > I'd use Gimp or gthumb for anyway. I know the argument that neither is in > platform, but realistically one of the other two is always there. AFAIK, EOG is faster than recent previous releases (at least 2.18, 2.16, 2.14). I don't really think those editing features will damage that much EOG's performance. Also, they'll most likely be plugins (you load them if you want). > Nevertheless, an edit mode should be just that, a mode. Much like Adobe Reader > has drag mode and selection mode toggled on the toolbar. I'm not sure yet about how exactly this will be implemented. I tend to not enjoy editing modes because they can bring more complexity to the UI (which we don't really want for EOG). > > EOG 2.20 is much more compliant with HIG and the problems you report here are > > basically against HIG guidelines. Therefore, I suggest you to open discussions > > about those issues in HIG scope. The only thing I can do is to provide some > > kind of "power/hidden features" that would enable users (like you) to tune EOG > > according to your specific needs. > > The HIG hardly applies. It just doesn't cover good usability on anything with a > large scrollable canvas. We see this same problem for Evince and Inkscape. As > you point out in the other bug, Gimp does what they feel is best, not what the > HIG says. EOG was written with good user interactability in mind, much of which > predates the HIG. (Keep in mind that Gimp is not official part of GNOME. They don't need to care about HIG.) You're a little bit biased when you say "good user interactability" (which is not a problem per se, really). You're complaining about this change now but I've heard from other users the exact oposite (that mouse-wheel should be used for scrolling). Also, there are even others that think the mouse-wheel should be used for quickly switching images. They/You/We all have different opinions about the best way to interact with an image viewer but I need to decide on one aproach (which, of course, involves pissing off some users and bringing hapiness to others). I chose the standard (aka HIG) way of doing things in GNOME. Maybe I will be proven wrong during the next 6 months. In case I get much more negative feeback from users about this issue, I'll definitely rethink this decision. Don't worry. :-) > The classic scrolling method is hardly a power user thing. Use case, I'm a > regular user, I want to see a detail in a digital photo I took. I remember that > hitting "1" will get me 100% zoom, so I hit it. Now I need to get over to where > my son's face is. I drag the photo as I've been doing for six years now and > nothing happens. I grudgingly move my mouse to the vertical scroll bar and move > up. Still not where I want to be. I move my mouse to the bottom scroll bar and > move it left. I notice I'm off vertically, so I move my mouse back to the > vertical scrollbar. Click-and-drag had a nice little hand cursor and was very > discoverable. That is why it is the default mode in Adobe Reader. You don't need to use scrollbars that much. You can just hold Ctrl key and use Button1 for dragging and mouse-wheel for zooming. Anyway, I'll make the hidden GConf key to make EOG work exactly as it was before. > I maintain it's not right to change the major functional component of a program > just because someone complains that a program isn't 100% in alignment with a > book of suggestions. And it is a book of suggestions to any program with > established workings. As a user, do you like the behaviour of the program more > now? HIG is not just a "book of suggestions". Guidelines are stronger than "suggestions" and they're very important for GNOME (I guess you know that). My decision is strongly motivated by HIG-compliance but that's not all. There are users who will enjoy this new behavior (others won't even care). I'd like to remark (again) that I haven't dropped the old mouse-wheel and dragging behavior, I just made them optional. Distributions are free to define different default settings, if they want. As an user, I don't really care about this change because I rarely do zooming with mouse-wheel and prefer dragging with middle-button. :-)
Concerning the scrolling issue bug 336223 might be of interest too.
Ok. I re-enabled button1 dragging when the old wheel behavior is enabled. Therefore, I consider this issue fixed. Let's see what users think when distros start shipping 2.20. As I said, if we see that many users complain about this UI change, we can bring this topic for discussion again. Pat, I really hope this makes you a happy user again. :-) Commited in trunk and gnome-2-20 branch. 2007-10-16 Lucas Rocha <lucasr@gnome.org> * src/eog-scroll-view.c (eog_scroll_view_button_press_event): enable dragging with button1 when scroll_wheel_zoom is enabled in order to make it possible to fully restore old wheel zooming and dragging behavior. Fixes bug #479884.
I hope so too. :) I was just looking at the latest version of Preview.app in OSX, and interestingly enough, they went the Adobe way as well. There is a toggle in toolbar between "hand" mode and "border" mode. Therefore, regardless of user feedback, perhaps we can think to eventually incorporate that kind of mode switching in eog.
> EOG 2.20 is much more compliant with HIG and the problems you report here are > basically against HIG guidelines. Therefore, I suggest you to open discussions > about those issues in HIG scope. The only thing I can do is to provide some > kind of "power/hidden features" that would enable users (like you) to tune EOG > according to your specific needs. > Then please do provide these power features, so that this program will be worth using again. As Pat said, you need both hands to operate this now; rather than just one hand on the mouse. People who have lost the use of one arm will now find this program impossible to use, and people who have both their arms will find this program too annoying to use due to these changes.
Hi Patrick, (In reply to comment #8) > > EOG 2.20 is much more compliant with HIG and the problems you report here are > > basically against HIG guidelines. Therefore, I suggest you to open discussions > > about those issues in HIG scope. The only thing I can do is to provide some > > kind of "power/hidden features" that would enable users (like you) to tune EOG > > according to your specific needs. > > > Then please do provide these power features, so that this program will be worth > using again. As Pat said, you need both hands to operate this now; rather than > just one hand on the mouse. People who have lost the use of one arm will now > find this program impossible to use, and people who have both their arms will > find this program too annoying to use due to these changes. EOG now supports one (with the hidden gconf key set) and two arms usage with the fix to this bug? What's your point? Anything still missing?
I think Patrick is noticing the 2.20.0 behaviour as opposed to the 2.20.1 behaviour, where this bug fix is in. I'd still like to see either a "Classic mode" toggle in the preferences or a toolbar icon switching between pan and select mode, but that can come later.
(In reply to comment #10) > I think Patrick is noticing the 2.20.0 behaviour as opposed to the 2.20.1 > behaviour, where this bug fix is in. Ok. > I'd still like to see either a "Classic mode" toggle in the preferences or a > toolbar icon switching between pan and select mode, but that can come later. Could you please report a separate bug report for that? Then we can have proper discussion there. :-)
(In reply to comment #9) > > just one hand on the mouse. People who have lost the use of one arm will now > > find this program impossible to use, and people who have both their arms will > > find this program too annoying to use due to these changes. > > EOG now supports one (with the hidden gconf key set) and two arms usage with > the fix to this bug? What's your point? Anything still missing? > Good defaults are missing. Having to press LMB, the touchpad and ctrl at the same time on a laptop is quite annoying. Hidden gconf keys are not a good solution, as you shouldn't have to be familiar with the gconf system to use GNOME. So here's one more vote for please enable dragging with LMB (without ctrl) by default. :)
Ok, I think I've got enough negative and valid feedback from users/developers to convince me to restore the previous defaults. Thanks a lot for caring. Your feedback was/is really important. It's good to know that mousewheel zooming is a very important feature for many users. I'll definitely take this into account when developing future features of EOG. Commited in trunk and gnome-2-20 branch. 2007-10-30 Lucas Rocha <lucasr@gnome.org> * data/eog.schemas.in: restored the default mousewheel-for-zooming behavior by setting /apps/eog/view/scroll_wheel_zoom key to true by default. Fixes bug #491826.
Thanks Lucas. At this point I'm running 2.20.1 and with the gconf key set the behaviour appears to work nicely. The only thing that is different still is the hand-icon that made the feature discoverable. But perhaps there are good reasons why that part changed as well.
(In reply to comment #14) > Thanks Lucas. At this point I'm running 2.20.1 and with the gconf key set the > behaviour appears to work nicely. The only thing that is different still is the > hand-icon that made the feature discoverable. But perhaps there are good > reasons why that part changed as well. Unfortunately, the hand-icon is a regression. :-/ Federico has already reported it (see bug #491851). I'll try to get this fix in 2.20.3. Let's see if I get approval from release team.
Sorry for commenting on an old bug like this, but is there any special reason to have the image-drag-to-pan functionality disabled under either mode? I really prefer the scroll wheel to scroll (especially with a mouse that does vertical AND horizontal scrolling) but if it means losing the drag-to-pan feature, then it's not really worth it.