images disappear from control points tab

[xvlun]

i found a minor but annoying bug that happens sometimes in real stitching life but is also reproducible, the result is, that the control points tab doesn't show any images any more and cannot be convinced do show them again without restarting hugin.

There is also a similar bug, that might be related which causes the zoom tab not to work anymore but i haven't been able to intentionally reproduce that bug yet.

fedora 8
hugin 0.7.0-0.3.20080406svn.fc8.i386
procedure
start hugin
click load images
choose your images
click new project
click No (dont save)
load images
choose your images
change to control points tab
vary program window size => images disappear

[nobody (nobody-users)]

Logged In: NO

I have seen this also on OS X versions up through 3005. It can be reproduced exactly as described. Hugin must be restarted.

[Yuv (yuv)]

did you confirm this in a newer version, Gerry?

[Gerry Patterson (gpatters)]

Hello,

Yes I have. In fact I have fixed it. Unfortunately I am having problems
pushing the fix. I commited, pulled, merged, commited the merge... but I
still can't push.

Keep getting: abort: push creates new remote heads!

Any ideas?

- Gerry

On Sat, Nov 27, 2010 at 12:14 PM, Yuv <email address hidden> wrote:

> did you confirm this in a newer version, Gerry?
>
> --
> images disappear from control points tab
> https://bugs.launchpad.net/bugs/678841
> You received this bug notification because you are a member of Hugin Bug
> Hunters, which is subscribed to Hugin.
>
> Status in Hugin - Panorama Tools GUI: Triaged
>
> Bug description:
> i found a minor but annoying bug that happens sometimes in real stitching
> life but is also reproducible, the result is, that the control points tab
> doesn't show any images any more and cannot be convinced do show them again
> without restarting hugin.
>
> There is also a similar bug, that might be related which causes the zoom
> tab not to work anymore but i haven't been able to intentionally reproduce
> that bug yet.
>
> fedora 8
> hugin 0.7.0-0.3.20080406svn.fc8.i386
> procedure
> start hugin
> click load images
> choose your images
> click new project
> click No (dont save)
> load images
> choose your images
> change to control points tab
> vary program window size => images disappear
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~hugin-bug-hunters<https://launchpad.net/%7Ehugin-bug-hunters>
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~hugin-bug-hunters<https://launchpad.net/%7Ehugin-bug-hunters>
> More help : https://help.launchpad.net/ListHelp
>

[Yuv (yuv)]

On November 27, 2010 01:52:11 pm Gerry Patterson wrote:
> Keep getting: abort: push creates new remote heads!
>
> Any ideas?

hg pull
hg up
hg push

if there are conflicts (unlikely), they will show up

Yuv

[Gerry Patterson (gpatters)]

I am confused. I thought a bug was set to "Fix Released" if it was part of a release.

http://wiki.panotools.org/Hugin_Trackers#Understanding_Ticket_Status

As far as I can tell this change hasn't been pulled into the 2010.4 branch yet...

Am I missing something?

[Yuv (yuv)]

On November 28, 2010 08:46:24 pm you wrote:
> I am confused. I thought a bug was set to "Fix Released" if it was part
> of a release.
>
> http://wiki.panotools.org/Hugin_Trackers#Understanding_Ticket_Status
>
> As far as I can tell this change hasn't been pulled into the 2010.4
> branch yet...
>
> Am I missing something?

I see you committed the change to the default branch. Good. That's the right
place for dev work.

2010.4 is a different branch and it must be pulled manually from default
(because some changes to default could be new features that do not belong into
2010.4).

Best thing is to leave it as-is. When the release manager (in this case me)
will sync 2010.4 with the changes in default (usually before the next release
beta2, planned for Dec 3) it will go into 2010.4

So it will make it into the 2010.4beta2 tarball.

http://wiki.panotools.org/Development_of_Open_Source_tools#Release

Yuv

[Gerry Patterson (gpatters)]

Understood. However, when a fix is pushed in what status should the bug ticket be set to?

I had set it to "fix committed" when I pushed in the fix. Recently, Thomas set it to "Fix released". My understanding is that a ticket is set to "fix released" when it is either part of an existing release or a moved into a pending release branch....

[Yuv (yuv)]

On November 28, 2010 09:31:13 pm you wrote:
> Understood. However, when a fix is pushed in what status should the bug
> ticket be set to?
>
> I had set it to "fix committed" when I pushed in the fix. Recently,
> Thomas set it to "Fix released". My understanding is that a ticket is
> set to "fix released" when it is either part of an existing release or a
> moved into a pending release branch....

at the moment there is not much difference between the two states. "fix
released" has the advantage that it hides the report from the default view.

to use the finer grained distinction I need to work a little bit more about the
LP setup. This is my current understanding:

1. Register a serie https://launchpad.net/hugin/+addseries
2. Register a milestone within the serie
https://launchpad.net/hugin/+milestones
3. Then bugs can be assigned to a milestone
4. When bugs assigned to a milestone are fixed, they are set to "fix commited"
5. (TO BE VERIFIED) when a release is made against the milestone the fix
committed become fix released.

Currently I have set up all the series until 2010.4 (the last one is invisible
because it is marked as future)

I still need to catch up with history of 2010. Then we can test if what I
think is the difference between the two states is true.

Sorry for this off-topic here, I needed to fix this somewhere but I don't have
the time now to complete it all; and you needed an answer now.

HTH
Yuv