Uwe Stöhr wrote:
> Indeed it works. So please add them.
For branch rather not (yet). For trunk, I think some more teseting and
research might be good. I'd like to know the reason why they have been
removed.
Jürgen
> Sure? The following works for me as expected:
>
> a\hspace{0.25\textwidth}b
> \vspace{.5\textheight}
Indeed it works. So please add them.
(I don't know why it didn't for me yesterday. I only tested by deleting noPercents(), perhaps that
was not enough).
regards Uwe
Uwe Stöhr wrote:
> > BTW, why did we remove the %-items from hspace and vspace again? I think
> > that
>
> > \hspace{0.25\linewidth} or \vspace{.5\textheight} might be quite useful,
> > wouldn't it?
>
> Yes it would, but \h(v)space don't allow relative units.
Sure? The following works for me as
> Jürgen Spitzmüller wrote:
>> > AFAIK, it is only usable in math. So we might want to _add_ it only
>> > in this case (if we ever need it).
>
> Would be the attached. Some testing would be nice.
The patch is OK from my point of view and after testing.
> BTW, why did we remove the %-items from h
On Sun, 11 Jan 2009, Andre Poenitz wrote:
Fair enough. Just submit then.
"to trunk" that means.
Andre', usually not talking about "branch".
André, usually not talking about André in 3rd person :-)
Sorry, I'm bored... :-)
/Christian
--
Christian Ridderström, +46-8-768 39 44http
Jürgen Spitzmüller wrote:
> > AFAIK, it is only usable in math. So we might want to _add_ it only
> > in this case (if we ever need it).
>
> that might be more tricky.
Would be the attached. Some testing would be nice.
BTW, why did we remove the %-items from hspace and vspace again? I think tha
Jean-Marc Lasgouttes wrote:
> > BTW Uwe, it appears that the mu unit is not allowed in further
> > contexts. I
> > tried minipage width, where it triggers an error. We need to check
> > that.
>
> AFAIK, it is only usable in math. So we might want to _add_ it only
> in this case (if we ever ne
Jürgen Spitzmüller wrote:
> Furthermore, I have commented out the buggy and apparently unused function
> Length widgetsToLength()
> in qt_helpers. This function would fail because it checks for the wrong
> strings. I think commenting out prevents that this is used somewhere.
I fixed that function
> AFAIK, it is only usable in math. So we might want to _add_ it only in this case (if we ever need
> it).
Yes, "mu" means "math unit". So we should really only add this unit when it is really needed. I
don't currently know a case where mu is allowed as unit in one of our dialogs.
regards Uwe
BTW Uwe, it appears that the mu unit is not allowed in further
contexts. I
tried minipage width, where it triggers an error. We need to check
that.
AFAIK, it is only usable in math. So we might want to _add_ it only
in this case (if we ever need it).
JMarc
Jürgen Spitzmüller wrote:
> The problem is that if you remove the "mu" item from the combo,
> widgetsToLength will return a wrong value (off by one) for all subsequent
> items, so it will return "mu" for "textwidth%", for instance. For the
> percent- items, this was no problem only because they are
Uwe Stöhr wrote:
> I want to be sure that this won't cover another bug. While do so I found
> another problem and a fix. Not too bad ;-)
Indeed.
> Attached is the patch that compares against the untranslatable unit_name.
OK for the mu-unit.diff patch.
As for the other patch, I'm afraid there ar
> So you think you are in a position not only to describe, but even to prescribe
> the users of every language what they should translate and what not? I tend to
> think that our translators should decide themselves.
I now found out, that in Cyrillic one uses instead of e.g. "cm" "см", so I was w
Uwe Stöhr wrote:
> But that's what I meant, the bug is that they are translatable. This is not
> correct and this is the case for _every_ language. So we need to change our
> routine so that only the percent units are translatable. Is this possible?
> If not I don't have an idea how to fix this.
S
> This is irrelevant. You are not supposed to compare against a translat_able_
> string.
But that's what I meant, the bug is that they are translatable. This is not correct and this is the
case for _every_ language. So we need to change our routine so that only the percent units are
translatabl
Uwe Stöhr wrote:
> > 1. the strings in the combo are translated. So searching fo the English
>
> > version "mu" might fail. You will have to compare unit_name_gui against
> > unit_name
>
> I don't think so. What will you translate "mu" to? Units like "sp", "cm",
> etc. are proverbs that should no
> 1. the strings in the combo are translated. So searching fo the English
> version "mu" might fail. You will have to compare unit_name_gui against
> unit_name
I don't think so. What will you translate "mu" to? Units like "sp", "cm", etc. are proverbs that
should not be translatable. I don't kno
On Sun, Jan 11, 2009 at 11:19:42AM +0100, Andre Poenitz wrote:
> On Sun, Jan 11, 2009 at 03:18:37AM +0100, Uwe Stöhr wrote:
> > Andre Poenitz schrieb:
> >
> >>> + int num = QComboBox::count(); + for (int i = 0; i < num; i++) {
> >>> + if (QComboBox::itemText(i).contains("mu") > 0) {
> >>
>
On Sun, Jan 11, 2009 at 09:25:21AM +0100, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > Two issues:
> >
> > 1. the strings in the combo are translated. So searching fo the English
> > version "mu" might fail. You will have to compare unit_name_gui against
> > unit_name
> >
> > 2. Why "c
On Sun, Jan 11, 2009 at 03:18:37AM +0100, Uwe Stöhr wrote:
> Andre Poenitz schrieb:
>
>>> + int num = QComboBox::count(); + for (int i = 0; i < num; i++) {
>>> + if (QComboBox::itemText(i).contains("mu") > 0) {
>>
>> Shouldn't
>>
>> if (QComboBox::itemText(i).contains("mu"))
>>
>>
Jürgen Spitzmüller wrote:
> Two issues:
>
> 1. the strings in the combo are translated. So searching fo the English
> version "mu" might fail. You will have to compare unit_name_gui against
> unit_name
>
> 2. Why "contains("mu")"? I think you are looking for the string "mu"
> exactly.
Furthermore,
Uwe Stöhr wrote:
> +void LengthCombo::noMu()
> +{
> + int num = QComboBox::count();
> + for (int i = 0; i < num; i++) {
> + if (QComboBox::itemText(i).contains("mu")) {
> + QComboBox::removeItem(i);
> + --i;
> +
Andre Poenitz schrieb:
+ int num = QComboBox::count();
+ for (int i = 0; i < num; i++) {
+ if (QComboBox::itemText(i).contains("mu") > 0) {
Shouldn't
if (QComboBox::itemText(i).contains("mu"))
be sufficient?
You are right. I copied the code from the existi
On Sun, Jan 11, 2009 at 03:00:12AM +0100, Uwe Stöhr wrote:
> Index: frontends/qt4/LengthCombo.cpp
> ===
> --- frontends/qt4/LengthCombo.cpp (revision 28082)
> +++ frontends/qt4/LengthCombo.cpp (working copy)
> @@ -70,4 +70,16 @
Uwe Stöhr schrieb:
The attached patch fixes this.
Now it is attached.
regards Uwe
Index: frontends/qt4/GuiHSpace.cpp
===
--- frontends/qt4/GuiHSpace.cpp (revision 28082)
+++ frontends/qt4/GuiHSpace.cpp (working copy)
@@ -78,6 +78
\hspace and \vspace doesn't allow the unit "mu". Therefore documents will be uncompilable when you
use this unit in the H/VSpace dialog.
The attached patch fixes this.
OK for branch too?
regards Uwe
26 matches
Mail list logo
