Oups, I've added two strings!

[Yuval Levy-6]

Hi all, particularly translators.

I have done something that is not very nice IMO: i've just added two new
strings to the release branch (and to trunk, but that's less critical)
after syncing the PO files and calling for translation.

The background: a bug (or rather: a misbehavior) was discovered last
night: it is possible to give Hugin an invalid, inversed crop both in
the fast preview and in the stitcher tab. This results in an aborted
stitch.

One of the value added of a GUI is that it prevents the entry of this
kind of "illegal" values. Hence I set out to fix it. No problem in the
fast preview (the feedback is given by the moving cursor) but for the
stitcher tab I had to add two error messages.

This affects the translators. What should I do:

1. add the two new strings to the translation? none of your work would
be lost, but it will change the status of the work of those who have
already translated from complete to incomplete; and it may confuse
translators who have started working on the current status of the PO file.

2. leave it as is? the consequence is that these two strings won't be
translated.

It was not my intention to "move your cheese". The bug was important
enough to warrant a fix.

Yuv

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-6]

Yuval Levy wrote:
> 1. add the two new strings to the translation?

since nobody objected, this is what I did. 2009.4.0_beta1 is undergoing
basic tests before uploading.

Yuv

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Kornel Benko]

Am Thursday 01 October 2009 schrieb Yuval Levy:

>
> Hi all, particularly translators.
>
> I have done something that is not very nice IMO: i've just added two new
> strings to the release branch (and to trunk, but that's less critical)
> after syncing the PO files and calling for translation.
>
> The background: a bug (or rather: a misbehavior) was discovered last
> night: it is possible to give Hugin an invalid, inversed crop both in
> the fast preview and in the stitcher tab. This results in an aborted
> stitch.
>
> One of the value added of a GUI is that it prevents the entry of this
> kind of "illegal" values. Hence I set out to fix it. No problem in the
> fast preview (the feedback is given by the moving cursor) but for the
> stitcher tab I had to add two error messages.
>
> This affects the translators. What should I do:
>
> 1. add the two new strings to the translation? none of your work would
> be lost, but it will change the status of the work of those who have
> already translated from complete to incomplete; and it may confuse
> translators who have started working on the current status of the PO file.

Please add them. Sure, I am not a translator in this group (but in another). This will be at least a remainder.
And it is far less confusing then one may think.

> 2. leave it as is? the consequence is that these two strings won't be
> translated.
>
> It was not my intention to "move your cheese". The bug was important
> enough to warrant a fix.
>
> Yuv
>
        Kornel

--
Kornel Benko
Kornel.Benko@...

[Alexandre Prokoudine]

On 2 окт, 00:45, Yuval Levy <goo...@...> wrote:
> Hi all, particularly translators.
>
> I have done something that is not very nice IMO: i've just added two new
> strings to the release branch (and to trunk, but that's less critical)
> after syncing the PO files and calling for translation.

You could do a much worse thing: finally mark "Loading image:" and
"Saving image:" messages translatable too :)

Alexandre
--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-6]

Alexandre Prokoudine wrote:
> You could do a much worse thing: finally mark "Loading image:" and
> "Saving image:" messages translatable too :)

OK, I am trying.

DISCLAIMER: newbie at work. I am new to gettext. I don't use non-EN
locale. What I did is like if a legally blind person drives.

I looked for those strings. I found "Loading image:" (I did not find
"Saving image:", but anyway let's first get it done on a single string).

I (think that I) understood the problem: currently internationalization
is handled by wxWidgets. Anything built outside wxWidgets can't be
translated. This means all the CLI tools, but also some functionality of
the GUI app such as the image cache (which is the one that issue the
"Loading image:" messages).

Next I found the solution: implement gettext in the affected files. To
my understanding, gettext is implemented by wxWidgets, so I am not
really adding a new dependency.

The question to those more expert in coding is: where to implement it?
For the ImageCache, I linked it in ImageCache.h and then I could make
the strings in ImageCache.cpp translatable. For now I only made "Loading
image:" translatable, so that we can test if this work.

So here are the next steps:
* attached is a patch, against trunk. If I got my things right, it
should make "Loading Images:" translatable. Download it to a freshly
checked out hugin trunk, then do the following:

svn up
patch -p 0 < lang.patch
cd src/translations
./extract-messages.sh

if you find "Loading Images:" in the PO file, we're almost there.

build and install this version of Hugin, to check that it really works
and that I have not broken anything. We need this to be done also in
Windows and OSX, to be sure.

if the above works; and if more expert coders than me review my changes
as OK, we can commit it. if more expert coders have a better idea where
to include the gettext code, I'll modify the patch. And if it does not
work... back to the drawing board.

HTH
Yuv


--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Index: src/hugin_base/huginapp/ImageCache.cpp
===================================================================
--- src/hugin_base/huginapp/ImageCache.cpp (revision 4557)
+++ src/hugin_base/huginapp/ImageCache.cpp (working copy)
@@ -506,7 +506,7 @@
         return it->second;
     } else {
         if (m_progress) {
-            m_progress->pushTask(AppBase::ProgressTask("Loading image: "+hugin_utils::stripPath(filename), "", 0));
+            m_progress->pushTask(AppBase::ProgressTask(_("Loading image: ")+hugin_utils::stripPath(filename), "", 0));
         }
 #if 1
         // load images with VIGRA impex, and store either 8 bit or float images
Index: src/hugin_base/huginapp/ImageCache.h
===================================================================
--- src/hugin_base/huginapp/ImageCache.h (revision 4557)
+++ src/hugin_base/huginapp/ImageCache.h (working copy)
@@ -30,7 +30,11 @@
 #include <vigra/imageinfo.hxx>
 #include <hugin_utils/utils.h>
 #include <appbase/ProgressDisplayOld.h>
+// gettext
+#include <libintl.h>
+#define _t(String) gettext (String)
 
+
 #define HUGIN_IMGCACHE_MAPPING_INTEGER        0l
 #define HUGIN_IMGCACHE_MAPPING_FLOAT          1l
 

[T. Modes]

Hi Yuv,

> build and install this version of Hugin, to check that it really works
> and that I have not broken anything. We need this to be done also in
> Windows and OSX, to be sure.
>

does not compiles on Windows. Compiler complains about not finding
libintl.h.
Also in imagecache.cpp it complains about function "_" not found.

Thomas
--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-6]

Hi Thomas,
thanks for the feedback.

T. Modes wrote:
> does not compiles on Windows. Compiler complains about not finding
> libintl.h.

it's part of gettext. I see that CMake has defines if gettext is found.
I'll boot into Windows later this weekend and have a look.


> Also in imagecache.cpp it complains about function "_" not found.

it is very well possible that MSVC does not understand

#define _t(String) gettext (String)

sounds the same like with the log2 thing. I'll try to solve it the same
way we solved that.

Slowly but surely I'll learn the pitfalls of cross-plattform development ;-)

Yuv



--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Kornel Benko]

Am Samstag 03 Oktober 2009 schrieb Yuval Levy:

> Hi Thomas,
> thanks for the feedback.
>
> T. Modes wrote:
> > does not compiles on Windows. Compiler complains about not finding
> > libintl.h.
>
> it's part of gettext. I see that CMake has defines if gettext is found.
> I'll boot into Windows later this weekend and have a look.
>
> > Also in imagecache.cpp it complains about function "_" not found.
>
> it is very well possible that MSVC does not understand
>
> #define _t(String) gettext (String)
>
> sounds the same like with the log2 thing. I'll try to solve it the same
> way we solved that.

I think, it is not the same. Here it is defined in wx/intl.h as a macro  (not a function)

> Slowly but surely I'll learn the pitfalls of cross-plattform development
> ;-)
>
> Yuv
>
        Kornel

--
Kornel Benko
Kornel.Benko@...

[Yuval Levy-6]

Kornel Benko wrote:
> Am Samstag 03 Oktober 2009 schrieb Yuval Levy:
>> #define _t(String) gettext (String)
>>
>> sounds the same like with the log2 thing. I'll try to solve it the same
>> way we solved that.
>
> I think, it is not the same. Here it is defined in wx/intl.h as a macro  (not a function)

AFAIK wx/intl.h is wxWidgets' own implementation of gettext. But we
don't want to make non-GUI stuff dependent on wxWidgets. This is the
reason why non-GUI stuff is currently non translatable. IMO making it
translatable is a good thing. Making it wx-dependent is not.

Hence I linked directly to gettext with
#include <libintl.h>

that's the first error on Windows: CMake does not seem to tell directly
where gettext is (even though IIRC we have it in the SDK).

the second error, which I think is the same like the log2 thing, is
completely unrelated to the CMake build.

It is similar to the log2 thing in that Hugin defined it as a macro in
FreeBSD and as a function in Windows.

anyway, I will look into this as soon as I am on the Windows side of
things again.

Yuv

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Jean-Luc Coulon (f5ibh)-2]

Le 01/10/2009 22:45:44, Yuval Levy a écrit :
>
>Hi all, particularly translators.
>
>I have done something that is not very nice IMO: i've just added two
>new
>strings to the release branch (and to trunk, but that's less critical)
>after syncing the PO files and calling for translation.


Sorry, but I want to checkout the related branch but I'm not sure which
one it is...

is it hugin/2008.4/obsolete_branches/  ?

Regards

Jean-Luc

[Yuval Levy-6]

Jean-Luc Coulon (f5ibh) wrote:
> Sorry, but I want to checkout the related branch but I'm not sure which
> one it is...
>
> is it hugin/2008.4/obsolete_branches/  ?

please work in trunk. I don't know where you get the above path from, it
does not exist.

Yuv

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Jean-Luc Coulon (f5ibh)-2]

Le 03/10/2009 19:57:16, Yuval Levy a écrit :

>
>Jean-Luc Coulon (f5ibh) wrote:
>> Sorry, but I want to checkout the related branch but I'm not sure
>which
>> one it is...
>>
>> is it hugin/2008.4/obsolete_branches/  ?
>
>please work in trunk. I don't know where you get the above path from,
>it
>does not exist.

The path *does* exist. I just wanted to say that it is sometimes
difficult to know which branches are active/dead.

Normally, I woks with trunk, it is easier ;)


I've committed the updated French translation to truck
It applies also to 2009.4 with some obsolete templates.

Regards

Jean-Luc

[Yuval Levy-6]

Jean-Luc Coulon (f5ibh) wrote:

> Le 03/10/2009 19:57:16, Yuval Levy a écrit :
>> Jean-Luc Coulon (f5ibh) wrote:
>>> Sorry, but I want to checkout the related branch but I'm not sure
>> which
>>> one it is...
>>>
>>> is it hugin/2008.4/obsolete_branches/  ?
>> please work in trunk. I don't know where you get the above path from,
>> it
>> does not exist.
>
> The path *does* exist.

not in the SVN repository, and it has never existed there. type the
following commands to confirm:

svn log -v https://hugin.svn.sourceforge.net/svnroot/hugin/ | grep "2008.4"

as a check that 2008.4 was not a typo:

svn log -v https://hugin.svn.sourceforge.net/svnroot/hugin/ | grep "2009.4"

and a last test for the paranoid:

svn log -v https://hugin.svn.sourceforge.net/svnroot/hugin/ | grep
"2008.4/obsolete"

svn log -v https://hugin.svn.sourceforge.net/svnroot/hugin/ | grep
"2009.4/obsolete"

If you have it on your hard disk, you may want to do some clean up.
Anybody can clone the repository in any status to any *local* folder
name that exist. e.g. this will result in a
hugin/2008.4/obsolete_branches on your end:

svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/ hugin/2008.4

or again:

svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/hugin/
mv hugin 2008.4

last but not least, a repetition of how the hugin SVN repository is
organized now (maybe somebody should add this information to the wiki,
the syntax is already mostly there).

the actual structure can also be browsed at

http://hugin.svn.sourceforge.net/viewvc/hugin/


At the top level of hugin's SVN are the different packages and the wesbite:
* KImageFuser
* autopano-sift-C
* htdocs (the website)
* hugin
* lensdb
* libpanorama
* panoglview

at the second level of the hugin tool (and ideally, later, all other
packages) there are five directories, each of them for codelines of
different purposes:
* branches (for the development codelines)
* obsolete_branches (for codelines that are no longer relevant)
* releases (for codelines that are polished toward release)
* tags (to mark the exact points of releases)
* trunk (the main codeline, where all development, including
translations, merge and is tested before going into a release codeline)

to check out hugin, find out a codeline inside one of these directories
(you can view the codeline's name from the web viewer) and enter it's
URL into TortoiseSVN (windows) or type

svn co
https://hugin.svn.sourceforge.net/svnroot/hugin/<FOLDER>/<CODELINE>/
<TARGET_LOCAL_FOLDER>

with the exception of trunk where you have to omit /<FOLDER>/

==== branches ====
branches are development codeline. check out a branch if you want to
help the developer owning it test his new code. does it build on a
different system? does it work as intended? early bug hunt only.

==== obsolete_branches ===
these codelines have been either absorbed into trunk or abandoned and
are now completely irrelevant. they are there for historical reasons.

==== releases ====
these codelines are where the code matures into a release. older
codelines in this area are very similar to what was released. sometimes
they become smaller improvements / patches after release. this is the
place to work on cleaning up the code. building from here makes sense
for testing purposes close to the release, during the beta/RC cycle.
commit with care here - no new features.

==== tags ====
these codelines are points in time that describe the status of the
repository at the moment of issuing the tarball. Committing to a
codeline here is committing a sin (pun intended).

==== trunk ====
this is where integration happens. this is where the new code, and the
bugfixes, and the improved translations, come together to move hugin
forward. This is the best place to commit translations and code that has
passed the three basic tests.

code and translation wander from trunk to release: either the
developer/translator understands how to keep the changes in sync, or the
release manager takes care of them.


 > I just wanted to say that it is sometimes
> difficult to know which branches are active/dead.

we have had some changes, added some codelines and moved others to have
a structure. The structure is described above. I hope this helps.


> I've committed the updated French translation to truck

merci! oui, this is the easiest way to work.


> It applies also to 2009.4 with some obsolete templates.


what do you mean by "obsolete templates"? usually trunk has a few more
strings, so some of the translations won't be applicable to 2009.4 but
they won't do any harm.

Yuv

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[J. Schneider-2]

> Hi all, particularly translators.
>
> I have done something that is not very nice IMO: i've just added two new
> strings to the release branch (and to trunk, but that's less critical)
> after syncing the PO files and calling for translation.

What I can see is

Can't start system's web browser
top boundary must be smaller than bottom
left boundary must be smaller than right

as new untranslated strings.
The first one is no problem, but can you explain where the other two are
used?

regards
Joachim

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-6]

J. Schneider wrote:
> Can't start system's web browser
> top boundary must be smaller than bottom
> left boundary must be smaller than right
>
> as new untranslated strings.
> The first one is no problem, but can you explain where the other two are
> used?

it's when setting the crop in the Stitcher tab. The top value must be
smaller than the bottom one; and the left value must be smaller than the
right one.

you can see it visually very nicely in the fast preview. before the fix,
  dragging the borders of the crop in the fast preview could yield a
negative crop (i.e. you could drag the left crop border over the right
one, or the top over the bottom one). Now this is prevented.

HTH
Yuv

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Bruno Postle]

On Mon 05-Oct-2009 at 17:59 -0400, Yuval Levy wrote:
>
>you can see it visually very nicely in the fast preview. before the fix,
>dragging the borders of the crop in the fast preview could yield a
>negative crop (i.e. you could drag the left crop border over the right
>one, or the top over the bottom one). Now this is prevented.

I haven't played with this, but does this really need to generate an
error message?  Surely just dragging the box to the point that it
inverts could just silently flip the coordinates so that you are
still drawing a valid frame.  i.e drag the left border until it
touches the right border and hugin switches to dragging the right
border.

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-6]

Bruno Postle wrote:
> On Mon 05-Oct-2009 at 17:59 -0400, Yuval Levy wrote:
>> you can see it visually very nicely in the fast preview. before the fix,
>> dragging the borders of the crop in the fast preview could yield a
>> negative crop (i.e. you could drag the left crop border over the right
>> one, or the top over the bottom one). Now this is prevented.
>
> I haven't played with this, but does this really need to generate an
> error message?

the fast preview dragging not. but the error can be produced by entering
illegal values on the stitcher tab, where the message is required.


> Surely just dragging the box to the point that it
> inverts could just silently flip the coordinates

please don't.

It is like letting people tilt beyond nadir/zenith when navigating a
360x180 - fine for the expert who knows what he is doing, but not
helpful for the occasional user.

play with it to see what I mean.

Yuv


--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Bruno Postle]

On Mon 05-Oct-2009 at 19:00 -0400, Yuval Levy wrote:
>Bruno Postle wrote:
>> I haven't played with this, but does this really need to generate an
>> error message?
>
>the fast preview dragging not. but the error can be produced by entering
>illegal values on the stitcher tab, where the message is required.

Fair enough, though I'd like to remove the crop stuff from the
Stitcher tab at some point, I can't imagine that anyone uses it
there.

>> Surely just dragging the box to the point that it
>> inverts could just silently flip the coordinates
>
>please don't.
>
>It is like letting people tilt beyond nadir/zenith when navigating a
>360x180 - fine for the expert who knows what he is doing, but not
>helpful for the occasional user.

Well this is how the problem started, you could drag the box so that
it looked right but was actually inside out.  The answer is surely
to make it right if it looks right.

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-6]

Bruno Postle wrote:
> I'd like to remove the crop stuff from the
> Stitcher tab at some point, I can't imagine that anyone uses it
> there.

I do use it! I agree it need to go somewhere else, but not removed
completely.

Yuv

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Kornel Benko]

Am Tuesday 06 October 2009 schrieb Bruno Postle:

>
> On Mon 05-Oct-2009 at 19:00 -0400, Yuval Levy wrote:
> >Bruno Postle wrote:
> >> I haven't played with this, but does this really need to generate an
> >> error message?
> >
> >the fast preview dragging not. but the error can be produced by entering
> >illegal values on the stitcher tab, where the message is required.
>
> Fair enough, though I'd like to remove the crop stuff from the
> Stitcher tab at some point, I can't imagine that anyone uses it
> there.

I am. It is easier here to set exact integer values;

> >> Surely just dragging the box to the point that it
> >> inverts could just silently flip the coordinates
> >
> >please don't.
> >
> >It is like letting people tilt beyond nadir/zenith when navigating a
> >360x180 - fine for the expert who knows what he is doing, but not
> >helpful for the occasional user.
>
> Well this is how the problem started, you could drag the box so that
> it looked right but was actually inside out.  The answer is surely
> to make it right if it looks right.
>

        Kornel

--
Kornel Benko
Kornel.Benko@...