Some programming tasks...

[bruno.postle]

We should be able to release 2009.4.0 final soon, though it would be
nice to have a positive report that 2009.4.0_rc3 builds on Windows
first.

When that is done we want to look at branching the current trunk, with
Lukáš' deghosting tools, for the next incremental release (probably
2010.0.0).

This means that the layout branch, with the support for linked stacks,
mosaics and the layout preview, can be merged into the trunk soon (and
break everything ;-).

One other thing is that we have another branch with a very nice and
functional 'autocrop' tool that should also go into the next stable
release, but before we can merge this 'autocrop' branch needs a couple
of minor things doing and I don't have the time or resources:

1. The autocrop tool is currently launched by a button on the Stitcher
tab, this needs to move to the Fast Preview window button bar (there
is already an autocrop icon for this in SVN).

2. Although it is quite fast, the autocrop function takes a finite
time to complete, so it needs a modal progress or status window so
people don't think Hugin has crashed.

Please can somebody take on these two tasks?

[James Legg]

On Tue, 2009-12-08 at 01:17 -0800, bruno.postle wrote:
> One other thing is that we have another branch with a very nice and
> functional 'autocrop' tool that should also go into the next stable
> release, but before we can merge this 'autocrop' branch needs a couple
> of minor things doing and I don't have the time or resources:
>
> 1. The autocrop tool is currently launched by a button on the Stitcher
> tab, this needs to move to the Fast Preview window button bar (there
> is already an autocrop icon for this in SVN).

I've just done this:
http://hugin.svn.sourceforge.net/viewvc/hugin?view=rev&revision=4756

> 2. Although it is quite fast, the autocrop function takes a finite
> time to complete, so it needs a modal progress or status window so
> people don't think Hugin has crashed.

I'll do this next.

-James

[James Legg]

On Tue, 2009-12-08 at 16:46 +0000, James Legg wrote:
> On Tue, 2009-12-08 at 01:17 -0800, bruno.postle wrote:
> > 1. The autocrop tool is currently launched by a button on the Stitcher
> > tab, this needs to move to the Fast Preview window button bar (there
> > is already an autocrop icon for this in SVN).

I know you said move rather than copy, but I've left it accessible from
the stitcher tab. I think it should stay there at least until we've
fixed the bug with the toolbar buttons disappearing when they don't fit.

> > 2. Although it is quite fast, the autocrop function takes a finite
> > time to complete, so it needs a modal progress or status window so
> > people don't think Hugin has crashed.
>
> I'll do this next.

It's done now.

-James

[Bruno Postle]

On Tue 08-Dec-2009 at 17:54 +0000, James Legg wrote:
>
>I know you said move rather than copy, but I've left it accessible from
>the stitcher tab. I think it should stay there at least until we've
>fixed the bug with the toolbar buttons disappearing when they don't fit.

That's fine, thanks for doing this. It all seems to work ok.

I shortened the labels on the buttons to 'Autocrop' as on some
platform (Windows I think) the widest label determines the spacing
for the entire button bar.

--
Bruno

[Gerry Patterson]

Hello,


On Dec 8, 2009, at 3:17 AM, "bruno.postle"

<bruno...@googlemail.com> wrote:

> We should be able to release 2009.4.0 final soon, though it would be
> nice to have a positive report that 2009.4.0_rc3 builds on Windows
> first.
>
> When that is done we want to look at branching the current trunk, with
> Lukáš' deghosting tools, for the next incremental release (probably
> 2010.0.0).
>
> This means that the layout branch, with the support for linked stacks,
> mosaics and the layout preview, can be merged into the trunk soon (and
> break everything ;-).
>

I thought that code that was known to break things wasn't going to be
merged into trunk until it works first. Perhaps you were being
sarcastic, I haven't been active here for a bit and haven't checked
out the layout branch recently so i don't know it's status. Is it not
possible to merge changes from the trunk into the branch while
developing layout mode and then push the whole branch back to trunk
when one is reasonably comfortable things won't go sideways? (things
can be missed though, after all we are only human)

Forgive me if this is the case. I just wanted to make a case for
keeping trunk as clean and releasable as possible at all times.


Best regards,

Gerry

[T. Modes]

On 8 Dez., 10:17, "bruno.postle" <brunopos...@googlemail.com> wrote:
> We should be able to release 2009.4.0 final soon, though it would be
> nice to have a positive report that 2009.4.0_rc3 builds on Windows
> first.

2009.4 RC3 builds on windows (checkout from subversion). But I did no
further testing.

> This means that the layout branch, with the support for linked stacks,
> mosaics and the layout preview, can be merged into the trunk soon (and
> break everything ;-).

Gerry wrote

> thought that code that was known to break things wasn't going to be
> merged into trunk until it works first. Perhaps you were being
> sarcastic

There are some bugs regarding the layout mode already in the bug
tracker.
At least the bug
http://sourceforge.net/tracker/?func=detail&aid=2869480&group_id=77506&atid=550441
is a showstopper for windows. It is not possible to start a new
panorama project in the layout branch. I can only load existing
projects and working with it.

I think, some of them should be fixed before merging to trunk.

Thomas

[Oskar Sander]

2009/12/9 T. Modes <Thomas...@gmx.de>

Gerry wrote

>  thought that code that was known to break things wasn't going to be
>  merged into trunk until it works first.  Perhaps you were being
>  sarcastic

Well, I heard cheerful irony here
 

There are some bugs regarding the layout mode already in the bug
tracker.
At least the bug
http://sourceforge.net/tracker/?func=detail&aid=2869480&group_id=77506&atid=550441
is a showstopper for windows.  It is not possible to start a new
panorama project in the layout branch. I can only load existing
projects and working with it.

This bug has been discussed before (i could not find the thread now), this EXIF load behavior stems from the pre 0.8 branch that Layout was built on.  The remedy for that *is* the merge.  (If i got this right)

I'm using the experimental layout branch build on windows regularly with large projects now, and have not ran into serious problem other than those I and others reported earlier.   I work on windows and work around the particular problem above by switching binaries when creating the project file.

There are workflow issues and practical things that would be good to discuss, once there are more people using and working with these features.

Cheers
O


IMHO please merge!

--
/O

[bruno.postle]

On Dec 9, 2:18 am, Gerry Patterson <thedeepvo...@gmail.com> wrote:
> On Dec 8, 2009, at 3:17 AM, "bruno.postle"  
>

> > This means that the layout branch, with the support for linked stacks,
> > mosaics and the layout preview, can be merged into the trunk soon (and
> > break everything ;-).
>
> I thought that code that was known to break things wasn't going to be  
> merged into trunk until it works first.

Yes, we shouldn't deliberately break the trunk, it needs to remain
functional and it shouldn't be necessary for users to have to switch
back to earlier releases to get work done.

The main point is that, once the deghosting and autocrop features have
been split out to a 'stable' branch for release, the remaining task is
merging the layout branch - There isn't anything else in the 'queue',
this is a good thing.

--
Bruno

[Dale Beams]

I was under the impression that svn was always a work in progress and always assumed that there could be breakage depending upon what was being done.  In other words, svn was the "testing" version and should never be considered stable enough for regular use. Did I miss someting in the development processes?



> Date: Wed, 9 Dec 2009 01:45:16 -0800
> Subject: [hugin-ptx] Re: Some programming tasks...
> From: bruno...@googlemail.com
> To: hugi...@googlegroups.com

> --
> You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx

---

Chat with Messenger straight from your Hotmail inbox. Check it out

[Bruno Postle]

On Wed 09-Dec-2009 at 08:57 -0600, Dale Beams wrote:
>
> I was under the impression that svn was always a work in progress
> and always assumed that there could be breakage depending upon
> what was being done. In other words, svn was the "testing"
> version and should never be considered stable enough for regular
> use. Did I miss someting in the development processes?

The trunk has been continuously usable (if not releasable) for me
for a long time, I don't have a 'stable' Hugin that I fall back-on.

The main point is that the trunk isn't a place to dump whatever you
happen to be working-on without checking it works. My understanding
of the layout branch is that existing functionality will work, but
the new functionality needs "more eyes".

--
Bruno

[Bruno Postle]

On Tue 08-Dec-2009 at 23:00 +0000, Bruno Postle wrote:
>On Tue 08-Dec-2009 at 17:54 +0000, James Legg wrote:
>>
>>I know you said move rather than copy, but I've left it accessible from
>>the stitcher tab. I think it should stay there at least until we've
>>fixed the bug with the toolbar buttons disappearing when they don't fit.
>
>That's fine, thanks for doing this. It all seems to work ok.

I just merged the autocrop branch into the trunk (svn4765),
including two more fixes from Thomas today, seems to be ok.

--
Bruno

[T. Modes]

> I just merged the autocrop branch into the trunk (svn4765),
> including two more fixes from Thomas today, seems to be ok.

I think the autocrop button in the preview windows belongs to the
group of buttons with "center" and "fit" and not beside "identify" or
"show control points".

--
Thomas

[bruno.postle]

On Dec 10, 6:33 am, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> I think the autocrop button in the preview windows belongs to the
> group of buttons with "center" and "fit" and not beside "identify" or
> "show control points".

Please go ahead and move it.

--
Bruno

[brian_ims]

I am not a C/C+ programmer but have managed to build a windows version using
SVN 4782 following the SDK and various other pointers given in this forum
and I can confirm that with the introduction of the autocrop button a
previously viewable button has essentially disappeared from my screen. If
Bruno is corrrect the culprit is the 'show control points' button and
presumably this needs shortening

Cheers

Brian

> --
> You received this message because you are subscribed to the Google Groups
> "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
>
>

--
View this message in context: http://old.nabble.com/Some-programming-tasks...-tp26690840p26764014.html
Sent from the hugin ptx mailing list archive at Nabble.com.

[Bruno Postle]

On Sat 12-Dec-2009 at 22:41 -0800, brian_ims wrote:
>
> I am not a C/C+ programmer but have managed to build a windows
> version using SVN 4782 following the SDK and various other
> pointers given in this forum and I can confirm that with the
> introduction of the autocrop button a previously viewable button
> has essentially disappeared from my screen. If Bruno is corrrect
> the culprit is the 'show control points' button and presumably
> this needs shortening

Can you post a screenshot somewhere? (with the preview maximised)
you can add it as a 'file' to the google group page.

This label is in the 2009.2.0 release already, but if it makes the
button bar unusable on Windows then we need to fix it for the
2009.4.0 release.

--
Bruno

[Bruno Postle]

On Sun 13-Dec-2009 at 10:56 +0000, Bruno Postle wrote:
>
> This label is in the 2009.2.0 release already, but if it makes the
> button bar unusable on Windows then we need to fix it for the
> 2009.4.0 release.

[Just doing some research] The problem as I understand it is that
the buttonbar on Windows is spaced to the widest label. Looking at
just the 'Show control points' label, it is even longer in most
other translations:

English "Show control points"
bg.po "Показване на контролните точки"
ca_ES.po "Mostra els punts de control"
cs_CZ.po "Zobrazit kontrolní body"
de.po "Kontrollpunkte"
es.po "Mostrar los puntos de control"
fr.po "Afficher les points de contrôle"
hu.po "K. p. mutat"
it.po "Mostra punti di controllo"
ja.po "コントロールポイントを表示"
ko.po "제어 위치들을 보여줌"
nl.po "Toon ijkpunten"
pl.po "Pokaż pkt. kontr."
pt_BR.po "Mostrar pontos de controle"
ru.po "Контрольные точки"
sk.po "Zobraziť kontrolné body"
sl.po "Pokaži stične točke"
sv.po "Visa kontrollpunkter"
uk.po "Показати контрольні крапки"
zh_CN.po "显示控制点"
zh_TW.po "顯示控制點"

..so we could fix this for English by substituting "Show Points",
but this wouldn't help everyone else.

--
Bruno

[Bruno Postle]

[AKS-Gmail-IMAP]

If I could make a suggestion. The button label needs to be only
"Points". It is already understood that the button will do something
so a verb is not necessary and there is an icon image that could
easily be changed to a simple stylized eye if desired to combine the
two concepts. Furthermore, the tooltip already provides and explanation.

Allan

[brian_ims]

Can the 'all' and 'none' buttons be turned into a single toggle button?

Brian

--
View this message in context: http://old.nabble.com/Some-programming-tasks...-tp26690840p26772032.html

[T. Modes]

> This label is in the 2009.2.0 release already, but if it makes the
> button bar unusable on Windows then we need to fix it for the
> 2009.4.0 release.

I uploaded a patch to the patch tracker (https://sourceforge.net/
tracker/?func=detail&aid=2914002&group_id=77506&atid=550443).

It modifies the toolbar of the fast preview window. It breaks the
functions into several parts and therefore the too long toolbar should
be fixed.
Maybe some groups needs some tweaking which buttons belong to this
group.

Please test it.

Thomas

[brian_ims]

I've tried rebuilding and got the following errors

F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(101) : error C2143: syntax
error : missing ';' before '*'
F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(101) : error C4430: missing
type specifier - int assumed. Note: C++ does not support default-int
F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(101) : error C4430: missing
type specifier - int assumed. Note: C++ does not support default-int
F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(102) : error C2143: syntax
error : missing ';' before '*'
F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(102) : error C4430: missing
type specifier - int assumed. Note: C++ does not support default-int
F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(102) : error C4430: missing
type specifier - int assumed. Note: C++ does not support default-int
F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(117) : error C2504:
'wxXmlResourceHandler' : base class undefined
F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(123) : error C2061: syntax
error : identifier 'wxXmlNode'

cheers

> --
> You received this message because you are subscribed to the Google Groups
> "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
>
>

--

View this message in context: http://old.nabble.com/Some-programming-tasks...-tp26690840p26777135.html

[T. Modes]

> I've tried rebuilding and got the following errors
>
> F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(101) : error C2143: syntax
> error : missing ';' before '*'
> F:\sdk\hugin\src\hugin1\hugin/OptimizePanel.h(101) : error C4430: missing

</snip>

These errors are not related to the patch. There was a bug in the
trunk
(see http://groups.google.com/group/hugin-ptx/browse_thread/thread/2dc78b090315ec47)

Nevertheless I updated the patch.

Thomas

[Carl von Einem]

Brian,

that won't work if several (but not all) images are selected. In this
case the user needs to have both options.

Carl


brian_ims schrieb am 14.12.09 03:02:

[Bruno Postle]

On Mon 14-Dec-2009 at 17:01 +0100, Carl von Einem wrote:
>
>that won't work if several (but not all) images are selected. In this
>case the user needs to have both options.

The All and None buttons could be moved to the next row down next to
the individual image buttons - This would make some logical sense
too.

--
Bruno

[Bruno Postle]

On Sun 13-Dec-2009 at 22:25 -0800, T. Modes wrote:
>> This label is in the 2009.2.0 release already, but if it makes the
>> button bar unusable on Windows then we need to fix it for the
>> 2009.4.0 release.
>
>I uploaded a patch to the patch tracker (https://sourceforge.net/tracker/?func=detail&aid=2914002&group_id=77506&atid=550443).
>
>It modifies the toolbar of the fast preview window. It breaks the
>functions into several parts and therefore the too long toolbar should
>be fixed.

It is definitely an improvement, though I'm not sure this is
something we want to introduce to 2009.4.0 - The button bar in the
current 2009.4 branch is identical to that in the already released
2009.2.0, we are not making anything worse.

>Maybe some groups needs some tweaking which buttons belong to this
>group.

What it exposes is that we have these various 'modes' for the Fast
preview (photometrics, identify, crop, drag), but these modes don't
really correspond with the tasks you might want to perform:

- Identifying and fixing bad image relationships (show points,
identify, layout stuff)
- Checking and adjusting exposure and colours (photometrics, EV
button, future white balance?)
- Levelling a panorama (drag, straighten)
- Composing a picture (drag, fit, centre, crop)
- ?

--
Bruno

[T. Modes]

Hi Bruno,

> It is definitely an improvement, though I'm not sure this is
> something we want to introduce to 2009.4.0 - The button bar in the
> current 2009.4 branch is identical to that in the already released
> 2009.2.0, we are not making anything worse.
>

The patch was intended for the current trunk, after merging with
autocrop feature, when some tools were not accessible. For 2009.4 the
toolbar should not changed. It was intended for version 2010.0 or even
2010.2.

> What it exposes is that we have these various 'modes' for the Fast
> preview (photometrics, identify, crop, drag), but these modes don't
> really correspond with the tasks you might want to perform:
>
>- Identifying and fixing bad image relationships (show points,
> identify, layout stuff)
> - Checking and adjusting exposure and colours (photometrics, EV
> button, future white balance?)
>- Levelling a panorama (drag, straighten)
>- Composing a picture (drag, fit, centre, crop)

I could extend the mode selection to provide the mentioned modes.
But which modes are reasonable? E. g. do we need levelling and
composing:
when I try to levelling a pano, I also need fit to accomodate for the
changes.
So fit should also go into levelling, but then there is no big
difference between levelling
and composing.
I arranged the buttons after my workflow and grouped them after the
effect on the pano:
- Preview (Identify)
- Move pano or images
- Crop pano

But I'm open to better proposals.

Thomas

[Bruno Postle]

On Mon 14-Dec-2009 at 22:44 -0800, T. Modes wrote:
>
>The patch was intended for the current trunk, after merging with
>autocrop feature, when some tools were not accessible. For 2009.4 the
>toolbar should not changed. It was intended for version 2010.0 or even
>2010.2.

Ok, I'll try and release rc3 as 2009.4.0 as soon as possible.

> when I try to levelling a pano, I also need fit to accomodate for
> the changes. So fit should also go into levelling, but then there
> is no big difference between levelling and composing.

For spherical panoramas, the crop and field of view stuff isn't
relevant.

>I arranged the buttons after my workflow and grouped them after the
>effect on the pano:
>- Preview (Identify)
>- Move pano or images
>- Crop pano

I think it is the right direction. I know it is wxwidgets problem,
but it isn't obvious that the first button changes the 'mode' and
rearranges the rest of the buttons, what if it was a series of tabs
along the top? so you could see what the other 'modes' are before
selecting them.

--
Bruno

[T. Modes]

Hi Bruno,

> I think it is the right direction.  I know it is wxwidgets problem,
> but it isn't obvious that the first button changes the 'mode' and
> rearranges the rest of the buttons, what if it was a series of tabs
> along the top? so you could see what the other 'modes' are before
> selecting them.
>

Thanks for feedback. I uploaded an updated version of the patch which
uses tabs to the patch tracker (https://sourceforge.net/tracker/?
func=detail&aid=2914002&group_id=77506&atid=550443).
Please give it a try.

I could also add small images to the tabs.

Thomas

[Bruno Postle]

On Wed 16-Dec-2009 at 22:34 -0800, T. Modes wrote:
>
>Thanks for feedback. I uploaded an updated version of the patch which
>uses tabs to the patch tracker (https://sourceforge.net/tracker/?func=detail&aid=2914002&group_id=77506&atid=550443).
>Please give it a try.

Great, I put some screenshots here so others can comment:

http://www.flickr.com/photos/36383814@N00/4193726620/
http://www.flickr.com/photos/36383814@N00/4193726634/
http://www.flickr.com/photos/36383814@N00/4193726636/

Some ideas:

The tab bar eats up some screenspace, but actually it can be used to
free up some more, the 'Projection' box can be its own tab, and the
'Blend mode' and 'EV' functions can move to the 'Preview' tab (not
sure about this name though).

The Centre, Fit, Autocrop and Straighten buttons don't need to be on
the 'Preview' tab.

The Field of View text entry boxes can now be moved from the
Stitcher tab to the 'Drag' tab. I'd also move the field of view
sliders to this tab and free up even more space.

Similarly the Crop text entry boxes can be moved from the Stitcher
tab to the 'Crop' tab

When the layout mode is merged, this can have a tab too.

>I could also add small images to the tabs.

Good idea.

--
Bruno

[T. Modes]

Hi Bruno,

> Some ideas:
>
> The tab bar eats up some screenspace, but actually it can be used to
> free up some more, the 'Projection' box can be its own tab, and the
> 'Blend mode' and 'EV' functions can move to the 'Preview' tab (not
> sure about this name though).
>
> The Centre, Fit, Autocrop and Straighten buttons don't need to be on
> the 'Preview' tab.
>
> The Field of View text entry boxes can now be moved from the
> Stitcher tab to the 'Drag' tab.  I'd also move the field of view
> sliders to this tab and free up even more space.
>
> Similarly the Crop text entry boxes can be moved from the Stitcher
> tab to the 'Crop' tab
>
> When the layout mode is merged, this can have a tab too.
>

I will try it at the weekend.

Some more question: what's about the advanced parameters of some
projections? Currently they show up beside the projection box. When
the projection is moved inside the tab, should these parameters also
move in the same box? Or should the stay at the bottom?

Thomas

[brian_ims]

Sorry for dealy but for thsoe interested I have just uploaded a screen shot
to

http:/groups.google.com/group/hugin-ptx/web/screen.JPG

Cheers

> --
> You received this message because you are subscribed to the Google Groups
> "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
>
>

--
View this message in context: http://old.nabble.com/Some-programming-tasks...-tp26690840p26840676.html

[Bruno Postle]

On Thu 17-Dec-2009 at 22:40 -0800, T. Modes wrote:
>
>Some more question: what's about the advanced parameters of some
>projections? Currently they show up beside the projection box. When
>the projection is moved inside the tab, should these parameters also
>move in the same box? Or should the stay at the bottom?

It can move too. It would be great to move everything from the
bottom to free the space for an expanded preview canvas.

--
Bruno

[T. Modes]

> It can move too. It would be great to move everything from the
> bottom to free the space for an expanded preview canvas.

I uploaded a modified version of the toolbar patch to
https://sourceforge.net/tracker/?func=detail&aid=2914002&group_id=77506&atid=550443.
I moved most of the controls into the tab bar. I have not found a good
position for the fov slider in the tab. They become too small to allow
a fine selection of the fov. So they remain at the usual position.
The archive contains the patch file and 3 images which should be
copied into src/hugin1/hugin/xrc/data

Thomas

[Bruno Postle]

On Sat 19-Dec-2009 at 08:48 -0800, T. Modes wrote:
>
>I uploaded a modified version of the toolbar patch to
>https://sourceforge.net/tracker/?func=detail&aid=2914002&group_id=77506&atid=550443.
>I moved most of the controls into the tab bar. I have not found a good
>position for the fov slider in the tab. They become too small to allow
>a fine selection of the fov. So they remain at the usual position.

I think this clicking tabs is a very natural way to change the
modes, some more screenshots here:

http://www.flickr.com/photos/36383814@N00/4197750405/
http://www.flickr.com/photos/36383814@N00/4197750407/
http://www.flickr.com/photos/36383814@N00/4197750413/
http://www.flickr.com/photos/36383814@N00/4197750415/

It certainly frees a lot of screen space for a larger preview
canvas.

--
Bruno

[Harry van der Wolf]

Hi Bruno, Thomas,

2009/12/19 Bruno Postle <br...@postle.net>

I built the last extended patch on OSX and I certainly like it. There is one drawback: the icons are very small and miss the texts. I suppose that can be easily fixed later on, but currently you have to hover over the buttons/icons until the tooltip shows up to know exactly what it does.
As experienced user you are familiar with the buttons, but without the accompanying texts it makes you hesitate.

See screenshots here:
<http://panorama.dyndns.org/hugin_tmp/1-preview.png>
<http://panorama.dyndns.org/hugin_tmp/2-projection.png>
<http://panorama.dyndns.org/hugin_tmp/3-move_drag.png>
<http://panorama.dyndns.org/hugin_tmp/4-crop.png>

<http://panorama.dyndns.org/hugin_tmp/5-first_image.png>

Another remark: The move/drag tab should be the second tab IMO. After creating the CP's you have a "small" image (5-first_image.png), probably not centered both horizontal and vertical and with a curved horizon (at least: that's always the case on OSX with partial panos). The very first thing I always do is press 3 buttons: center it, FOV estimation and straighten.


Harry

[Bruno Postle]

On Sun 20-Dec-2009 at 08:52 +0100, Harry van der Wolf wrote:
>
>I built the last extended patch on OSX and I certainly like it. There is one
>drawback: the icons are very small and miss the texts. I suppose that can be
>easily fixed later on, but currently you have to hover over the
>buttons/icons until the tooltip shows up to know exactly what it does.

The labels are there on Linux, so this is probably some wxwidgets
quirk.

>See screenshots here:
><http://panorama.dyndns.org/hugin_tmp/1-preview.png>
><http://panorama.dyndns.org/hugin_tmp/2-projection.png>
><http://panorama.dyndns.org/hugin_tmp/3-move_drag.png>
><http://panorama.dyndns.org/hugin_tmp/4-crop.png>
>
><http://panorama.dyndns.org/hugin_tmp/5-first_image.png>
>
>Another remark: The move/drag tab should be the second tab IMO.

Maybe it should be first. This sure to change, e.g. the layout mode
would be another tab, as would the 'old' preview.

Though I don't see this as a workflow that you would step through,
the tabs each give you a different 'view' or way of interacting with
the panorama, and there is space for more.

--
Bruno

[T. Modes]

Hi Bruno,

> The labels are there on Linux, so this is probably some wxwidgets
> quirk.
>

I tried with Harrys help to overcome this problem. But there seems
some limitiation of the wxToolBar implementation on wxMac.
Therefore I redesigned the patch. The most changes are internal. There
are only some little changes in the GUI. This version works fine on
mac. The current version can found at
https://sourceforge.net/tracker/?func=detail&aid=2914002&group_id=77506&atid=550443.
It needs also the small png from the 7z archive of the previous
version.
So please test the patch against the 2010.0 branch. When it works, I
will commit it to branch and port it to the trunk.

Thomas

[Bruno Postle]

On Wed 30-Dec-2009 at 01:41 -0800, T. Modes wrote:
>So please test the patch against the 2010.0 branch. When it works, I
>will commit it to branch and port it to the trunk.

I think it is a huge improvement over the old new Preview without
tabs.

..and it finally makes the preview very usable with the 800x640
screen on the Asus Eee:

http://www.flickr.com/photos/36383814@N00/4236993228/
http://www.flickr.com/photos/36383814@N00/4236993230/
http://www.flickr.com/photos/36383814@N00/4236993234/
http://www.flickr.com/photos/36383814@N00/4236993236/

--
Bruno

[T. Modes]

> I think it is a huge improvement over the old new Preview without
> tabs.
>

I commit the patch to branch 2010.0 and also to trunk. The layout mode
has its own tab. So further functions can be easily added to the
toolbar.

Thomas