Oups, I've added two strings!
Yuval Levy
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
Yuval Levy
> 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
Kornel Benko
>
> 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...@berlin.de
Alexandre Prokoudine
> 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.
"Saving image:" messages translatable too :)
Alexandre
Yuval Levy
> 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
T. Modes
> 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.
>
libintl.h.
Also in imagecache.cpp it complains about function "_" not found.
Thomas
Yuval Levy
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
Kornel Benko
> 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
>
Yuval Levy
> 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
Jean-Luc Coulon (f5ibh)
>
>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
> 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
Jean-Luc Coulon (f5ibh)
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
> 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
J. Schneider
>
> 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
Yuval Levy
> 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
Bruno Postle
>
>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
Yuval Levy
> 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
Bruno Postle
>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
Yuval Levy
> 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
Bart van Andel
On 6 okt, 01:00, Yuval Levy <goo...@levy.ch> wrote:
> > 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.
behaviour to automatically flip the coordinates, since this is what
happens in any image editor when using the rectangular select tool.
Anyway, instead of a pop up error message box, couldn't we change the
color of the text box (into red for example) and add an exclamation
mark in front with a tooltip text when entering too high / too low
values? Just a suggestion, I reckon it's a matter of taste, but this
way it's less obtrusive and will require one click less.
--
Bart
Kornel Benko
>
> 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...@berlin.de
Rogier Wolff
> Anyway, instead of a pop up error message box, couldn't we change the
> color of the text box (into red for example) and add an exclamation
> mark in front with a tooltip text when entering too high / too low
> values? Just a suggestion, I reckon it's a matter of taste, but this
> way it's less obtrusive and will require one click less.
People with click-to-focus may have their mouse a mile away. And this
would mean you'd have to look at the "intermediate" results while the
user is typing which may annoy people who know what they are doing.
(If I want to generate the output image from 1000-9250, I would enter
1000, and then type 9 (ERROR! value lower than 1000!) 2 (error, 92<
1000), 5 (error, 925<1000), and only on the final 0 the error would go
away. If you look at the value in the box only in the end when focus
moves away from the box or enter is pressed you're in the current
situation, where a popup is most appropriate.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Yuval Levy
>> 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.
>
> I don't understand this point. My guess is that it's actually expected
> behaviour to automatically flip the coordinates, since this is what
> happens in any image editor when using the rectangular select tool.
it's expected behavior for advanced users who do gimmicks. it is not
natural behavior and it is not intuitive (or have you ever seen somebody
able to cut a negative shape with a scissor?) it is confusing. it has no
useful purpose. learn to drag the proper side to obtain the desired
effect. In fact, what I would expect when flipping coordinates is that
the image also gets flipped (more logical than just swapping borders).
> Anyway, instead of a pop up error message box, couldn't we change the
> color of the text box (into red for example) and add an exclamation
> mark in front with a tooltip text when entering too high / too low
> values? Just a suggestion, I reckon it's a matter of taste, but this
> way it's less obtrusive and will require one click less.
this is only on the stitcher tab, not on the dragging tool in the fast
preview. that tab need a complete overhaul.
that said, it is not a matter of taste or aesthetics, it's a matter of
*usability*. change the color of the text box is ok for a warning but
not for what will cause the application to fail. a pop up, saying loud,
clear, and ugly that the user has entered an illegal value will teach
them very quickly not to repeat the same mistake.
the fireplace also does not show a nice and less obtrusive background
when a kid sticks the finger where he should not.
usability before embellishment, not the other way around!
Yuv
Bart van Andel
On 7 okt, 23:26, Yuval Levy <goo...@levy.ch> wrote:
> Bart van Andel wrote:
> >> 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.
>
> > I don't understand this point. My guess is that it's actually expected
> > behaviour to automatically flip the coordinates, since this is what
> > happens in any image editor when using the rectangular select tool.
>
> it's expected behavior for advanced users who do gimmicks. it is not
> natural behavior and it is not intuitive (or have you ever seen somebody
> able to cut a negative shape with a scissor?) it is confusing. it has no
> useful purpose. learn to drag the proper side to obtain the desired
> effect. In fact, what I would expect when flipping coordinates is that
> the image also gets flipped (more logical than just swapping borders).
start to end? I know I don't. Same with image editing. If I want to
select a rectangle, I just click one of the desired corners and drag
to the opposite desired corner. Sometimes the lower bottom coordinate
is more obvious to select (example: it's a sharp corner of a building
while the other corners are less obvious for cropping) than the top
left coordinate which makes it easier to start dragging there. I'm
seriously annoyed by applications which don't allow you to do this. To
me, being able to select a rectangle any way I want is usability. Also
when zoomed in (I know this does not apply to Hugin currently, but it
might in the future?) you wouldn't always zoom in on the top left
corner first.
Of course if you don't like this behaviour, it could become another
preference.
> > Anyway, instead of a pop up error message box, couldn't we change the
> > color of the text box (into red for example) and add an exclamation
> > mark in front with a tooltip text when entering too high / too low
> > values? Just a suggestion, I reckon it's a matter of taste, but this
> > way it's less obtrusive and will require one click less.
>
> this is only on the stitcher tab, not on the dragging tool in the fast
> preview. that tab need a complete overhaul.
>
> that said, it is not a matter of taste or aesthetics, it's a matter of
> *usability*. change the color of the text box is ok for a warning but
> not for what will cause the application to fail. a pop up, saying loud,
> clear, and ugly that the user has entered an illegal value will teach
> them very quickly not to repeat the same mistake.
>
> the fireplace also does not show a nice and less obtrusive background
> when a kid sticks the finger where he should not.
I'd rather have the error message only when trying to switch to
another tab for instance while the crop values are invalid, One might
want to enter new values in all the fields (using the Tab key for
instance), which could lead to a situation that halfway entering the
four values, the combination is invalid, but after all values are
entered the result would be right. In my opinion the usability is
higher if there are less obtrusive messages blocking my preferred way
of entering values. I don't want to be worried by the order in which I
enter them.
> usability before embellishment, not the other way around!
different approaches. Apparently I'm used to other ways of using (for
instance) image editors than you are.
--
Bart
J. Schneider
> Stitcher tab at some point, I can't imagine that anyone uses it
> there.
to 0.
Once you cropped and play around with field of view and different
projections this switching may decrease the size of the rectangle when
necessary but it is not increased again when it is possible again.
Trying to drag the rectangle border onto the visual image border stops a
few display pixels before the image border. You have to reset the value
by hand.
(I know, I should file this as a proper bug report.)
regards
Joachim
J. Schneider
> 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.
Shouldn't the English text be "Top boundary *value* must ..." ? Anyway
now I understand and I will translate accordingly.
One more question:
"Checking for outlying control points": What is outlying exactly?
Outside an image? Outside an image area where it would belong?
By the way, is there a new feature to remove absurd cps? All those
strings suggest it. Did I miss a thread on the list?
There is a statistical method mentioned. I did not see anything of a
logical method (like "if cp 1 is lft of cp 2 in img 1 it can't be right
of it in img 2"). To me as a non-programmer this seems to be the most
obvious approach.
regards
Joachim
Yuval Levy
> usability is not universal: different users like
> different approaches.
ever visited a usability lab? usability is hard facts and has nothing to
do with likes or dislikes.
user interaction is analyzed and dissected in detail. and the resulting
rules, while depending on the context, are nearly universal.
for example times are measured, in millisecond, that it takes to an
average user (obtained through broad enough sampling) to understand the
interface, to activate the control, to complete a task.
success and failure to complete a task are measured and justified.
the learning curve (i.e. from newbie to expert) is visualized. what it
takes to be an expert is defined; and usually it is leveled down to
increase the comfort of the average user.
the goals are:
- tangible improvements to the user interaction: shorter times, fewer
clicks, faster and easier access to functionality
- easier learning curve: an environment that keeps the user within
boundaries that make him feel safe while enabling all the functionalities.
sometimes there are trade-offs - e.g. some boundaries may make the
newbie user feel comfortable but are a limiting factor to the expert
user; and such trade-offs warrant a preference.
this is not the case here. I see no advantage to the flipping other than
a show off another useless feature. It slows down the newbie without
offering any tangible improvement to the expert user.
show me a tangible improvement and we can *talk* of a preference.
Yuv
Yuval Levy
> Shouldn't the English text be "Top boundary *value* must ..." ? Anyway
> now I understand and I will translate accordingly.
Afaik it can be omitted and is understood by context. But I'm not a
native English speaker.
> One more question:
> "Checking for outlying control points": What is outlying exactly?
> Outside an image? Outside an image area where it would belong?
outlying outside of the statistic normal distribution.
> By the way, is there a new feature to remove absurd cps?
yes.
> Did I miss a thread on the list?
I don't know if there was a specific thread, but it has been mentioned a
number of time when discussing the integration queue. Thomas Modes
submitted it as a patch into the patch tracker IIRC.
> There is a statistical method mentioned. I did not see anything of a
> logical method (like "if cp 1 is lft of cp 2 in img 1 it can't be right
> of it in img 2"). To me as a non-programmer this seems to be the most
> obvious approach.
the approach is different. it is tried and tested (Bruno's ptoclean in
Panotools::Script). It is not a logical method like the one you describe
above, which would have a problem: you know that the two CP's can't be
right together, but which one is right and which one is wrong?
It identifies the kind of situation describe above by statistically
comparing each points with the whole cloud of points, and removing those
that are more than two standard deviations apart.
thanks for the updated German translation
Yuv
Bart van Andel
be done starting from the top left and dragging down right. You're
putting it as if the way you're telling it's supposed to work is the
only way it should ever work, but all programs I'm using or have been
using (including but not limited to GIMP, Inkscape, MS Paint,
Paint.NET, Photoshop, several UML tools etc etc) allow selecting a
rectangle starting from *any* of the 4 corners. And modifying this
rectangle usually allows flipping the corners too. I believe this is
enough empirical proof to show that I'm not as wrong as you'd like me
to be. It's intuitive.
Okay I might be slightly wrong on the usability bit. Of course
research has been done to find out what works for the *average* user.
Expert users are generally not average users, agreed. But this also
proves my point (indirectly) that there is not universal truth about
usability, except maybe when you define it as usable to the average
user. Always watch out when applying statistics. I dare to say that
there are relatively a lot of "expert users" among the Hugin user
base, so this group should not be denied.
On 8 okt, 21:51, Yuval Levy <goo...@levy.ch> wrote:
> Bart van Andel wrote:
> > usability is not universal: different users like
> > different approaches.
>
> ever visited a usability lab? usability is hard facts and has nothing to
> do with likes or dislikes.
> - tangible improvements to the user interaction: shorter times, fewer
> clicks, faster and easier access to functionality
selecting a corner which is not the top left corner, dragging into the
desired direction expecting to see a rectangle appear and instead
getting nothing. I would think this must be a bug, not a feature...
> - easier learning curve: an environment that keeps the user within
> boundaries that make him feel safe while enabling all the functionalities.
instead of allowing the other options too? What would you consider
easier or more user friendly? I know what I'd prefer.
> sometimes there are trade-offs - e.g. some boundaries may make the
> newbie user feel comfortable but are a limiting factor to the expert
> user; and such trade-offs warrant a preference.
>
> this is not the case here. I see no advantage to the flipping other than
> a show off another useless feature. It slows down the newbie without
> offering any tangible improvement to the expert user.
feature. I say it isn't. You say it slows down the newbie. I say it
won't. Again, consider my "empirical proof" above. To my, and with my
I guess lots of other people, it's pretty expected behaviour. I would
very much like this feature. Disabling it using a preference is pretty
easy, I'd think (pretty much a simple if statement).
Note that this applies to the visual crop selection alteration only
(dragging using the mouse). Crop values entered as numbers should not
work like this of course, in this case users should just be warned
about incorrect values.
> show me a tangible improvement and we can *talk* of a preference.
point more than often enough. I'd be happy to read what other users on
this list think.
--
Bart
Yuval Levy
> Then tell me where you read that selecting a rectangle should *always*
> be done starting from the top left and dragging down right.
have you tried to use the crop tool? do you have a clue what you're
talking about? this is not GIMP or Photoshop. The use case is completely
different. This one starts from an existing rectangle, not from a random
point inside the image.
> You're
> putting it as if the way you're telling it's supposed to work is the
> only way it should ever work,
no, I'm putting it as if I am annoyed at you telling me what I should
do. If you think you can do better, make your hands dirty and provide a
patch.
so far all I have seen from you is blah blah and never materialized
promises. your website mock up is still there, going stale.
Yuv (very much annoyed)
Bruno Postle
>
>Why learn that to create a selection you *must* from the top left
>instead of allowing the other options too? What would you consider
>easier or more user friendly? I know what I'd prefer.
Having played with it, the original bug is fixed - dragging the
edges together results in a very thin valid crop rather than a
inverted invalid crop.
I still say that 'the user' doesn't care which edge is which and
that dragging the top edge below the bottom edge should just make it
the new bottom edge. But the new behaviour is self-explanatory
enough and won't result in anyone screaming at the computer.
I couldn't reproduce the problem Joachim sees, dragging the crop
back to the edge of the canvas seems to be ok.
--
Bruno
prokoudine
> 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).
This is because the second one is "Scaling:" :) I messed it up :)
Alexandre
Yuval Levy
> This is because the second one is "Scaling:" :) I messed it up :)
no problems. should be part of my current patch. now I only hope it
works. when I embarked on this I thought "it's just two strings". It
ended up driving me further deep down i18n than I would have ever
wanted. next time I'll think twice before engaging :)
Yuv