in fast preview drag with left mouse impossible

Bug #797370 reported by Maaike
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Hugin
Won't Fix
Undecided
Unassigned

Bug Description

I use Hugin Pre-Release 2011.1.0, but this behaviour also existed in 2011.0.0. I use Archlinux. On three pc's this bug exists.
When going to the 'Fast Preview panorama'-window and than the Move/Drag tab, it should be possible to drag the panorama with the left mouse button. This was ever possible in older versions, but not with the versions I use now. When trying to drag with the left mouse button to move the panorama, nothing happens. When trying to drag together with shift, also nothing happens. Right mouse button is doing what it has to do ('rotate' the image).
This is very annoying since I sometimes want to move single pictures or straighten the horizon, but I can't do that this way :(.

Revision history for this message
Maaike (ekki-a) wrote :

I just found out that the latest Windows version does work. So only in the Linux version, dragging is not working.

Revision history for this message
Bruno Postle (brunopostle) wrote :

I don't see this on fedora, either with the 2011.1.0 branch or the 2011.0.0 release.

Revision history for this message
Jaap Crezee (jaap-jcz) wrote :

It used to be working just right on our systems, only hugin has been updated and now the dragging doesn't work anymore. I will try this on fedora just in case...

Revision history for this message
Jaap Crezee (jaap-jcz) wrote :

After some investigation I found out that with our windowmanager (fluxbox) the leftmouseclick-dragging does not work. With Icewm it does. I will cross check with older hugin versions if they do work with fluxbox...

Revision history for this message
tmodes (tmodes) wrote :

Set status to new again, if you have more information which are helpful to fix this issue.

Changed in hugin:
status: New → Invalid
Revision history for this message
arclance (arclancesu) wrote :

I am also seeing this bug in Ubuntu 11.04 64bit when using fluxbox 1.3.1 and the builds on the fluxbox nightly repository.
I have seen this bug in hugin 2011.0 and Pre-Release 2011.3.0.c1a3cf06612c.
This my be related to this bug in fluxbox https://sourceforge.net/tracker/?func=detail&aid=3164835&group_id=35398&atid=413960 .

I built hugin 2011.3.0.c1a3cf06612c with -DCMAKE_BUILD_TYPE=Debug and nothing is output in the terminal when trying to drag with the left mouse button in the fast preview window.

Rotating by clicking with the right mouse button does work and produces debug output in the terminal.
Clicking with the right mouse button and then the left mouse button allows dragging and rotating at the same time and produces debug output in the terminal.

I have attached screenshots of the results of the mouse clicks after dragging and the debug output from the terminal.
Let me know if any other information is needed.

arclance (arclancesu)
Changed in hugin:
status: Invalid → New
Revision history for this message
tmodes (tmodes) wrote :

Sorry, but this needs to be fixed in the windows manager. We at Hugin can't fix this issue or work around. We rely on the mouse events send by the window manager. When the window manager is sending wrong or none message we can not work around this.

Changed in hugin:
status: New → Won't Fix
Revision history for this message
VladV (vlad-volkov) wrote :

I have exactly the same problem in 2011.2.0.752ea80728d6 on Ubuntu 11.10 with Gnome 2.32.1. Window manager is metacity, compiz is turned off. Hence it is likely not a fluxbox-specific bug.

Dragging used to work before (in version 2010.*, I believe).

As a workaround, it is possible to drag by pressing middle mouse button and then pressing left button. Dragging stops when either of the buttons is released.

Revision history for this message
Jaap Crezee (jaap-jcz) wrote :

I have reinvestigate this issue. I have straced hugin and I am seeing input events going into hugin. So this does not seem a windowmanager bug?

14:29:22.514388 recvfrom(4, "\10\0\240\347\32\241`\0W\2\0\0^\1\0\2\0\0\0\0\260\tM\2\366"..., 4096, 0, NULL, NULL) = 96 <0.000030>
14:29:22.514510 recvfrom(4, 0x142e2e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000031>
14:29:22.514686 poll([{fd=4, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=4, revents=POLLOUT}]) <0.000033>
14:29:22.514783 writev(4, [{"&\0\2\0E\1\0\2", 8}, {NULL, 0}, {"", 0}], 3) = 8 <0.000025>
14:29:22.514851 poll([{fd=4, events=POLLIN}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN}]) <0.002062>
14:29:22.516964 recvfrom(4, "\7\1\240\347\35\241`\0W\2\0\0;\1\0\2E\1\0\2\260\tM\2/"..., 4096, 0, NULL, NULL) = 128 <0.000027>
14:29:22.517042 poll([{fd=4, events=POLLIN}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN}]) <0.000022>
14:29:22.517106 recvfrom(4, "\1\1\241\347\0\0\0\0W\2\0\0^\1\0\2\260\tM\2\366\0z\1\0"..., 4096, 0, NULL, NULL) = 96 <0.000024>
14:29:22.517185 recvfrom(4, 0x142e2e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000014>
14:29:22.517352 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=12, events=0}, {fd=11, events=POLLIN}], 4, 0) = 0 (Timeout) <0.000026>
14:29:22.517445 poll([{fd=4, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=4, revents=POLLOUT}]) <0.000014>
14:29:22.517504 writev(4, [{"&\0\2\0;\1\0\2", 8}, {NULL, 0}, {"", 0}], 3) = 8 <0.000021>
14:29:22.517574 poll([{fd=4, events=POLLIN}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN}]) <0.006084>
14:29:22.523717 recvfrom(4, "\1\1\242\347\0\0\0\0W\2\0\0E\1\0\2\260\tM\2/\0024\2\0"..., 4096, 0, NULL, NULL) = 32 <0.000036>
14:29:22.523813 recvfrom(4, 0x142e2e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000033>
14:29:22.523903 recvfrom(4, 0x142e2e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000033>
14:29:22.524061 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=12, events=0}, {fd=11, events=POLLIN}], 4, 0) = 0 (Timeout) <0.000035>
14:29:22.524163 poll([{fd=4, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=4, revents=POLLOUT}]) <0.000020>
14:29:22.524228 writev(4, [{"&\0\2\0;\1\0\2", 8}, {NULL, 0}, {"", 0}], 3) = 8 <0.000021>
14:29:22.524294 poll([{fd=4, events=POLLIN}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN}]) <0.001659>
14:29:22.526006 recvfrom(4, "\1\1\243\347\0\0\0\0W\2\0\0E\1\0\2\260\tM\2/\0024\2\0"..., 4096, 0, NULL, NULL) = 32 <0.000036>
14:29:22.526101 recvfrom(4, 0x142e2e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000033>
14:29:22.526184 recvfrom(4, 0x142e2e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000027>
14:29:22.526314 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=12, events=0}, {fd=11, events=POLLIN}], 4, 0) = 0 (Timeout) <0.000026>

But based on other reports here and elsewhere (googleing) this might still be a real issue.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.