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
Hi,
When writing a paragraph with an RTL language (I checked with Hebrew, but it
should also happen with Arabic), and adding numbered list, the symbols are
shown in the wrong order. I mean by that, that the dot comes before the
numbering symbol instead of after it.
The patch checks whether we are
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
rgheck wrote:
> Jurgen, I'd like to do this, r27975, r27987, and r27989 for branch.
> Together, these improve the presentation of citation strings, using
> unicode where appropriate and parsing the "family name" better than we
> now do.
Could you post a patch?
Jürgen
uwestoehr wrote:
> Author: uwestoehr
> Date: Mon Jan 12 03:40:50 2009
> New Revision: 28111
>
> URL: http://www.lyx.org/trac/changeset/28111
> Log:
> languages: fix http://bugzilla.lyx.org/show_bug.cgi?id=4736 hopefully now
> really Jürgen OK for branch too?
OK.
Jürgen
> 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
Jean-Marc Lasgouttes schrieb:
+Preamble
+\...@ifundefined{textcolor}{}
+{%
+ \definecolor{BLACK}{gray}{0}
+ \definecolor{WHITE}{gray}{1}
Why not \...@ifundefined{definecolor}{} ?
That is equivalent to my solution. When \textcolor is known, also \definecolor
is known.
regard
On Sunday 11 January 2009 03:49:53 Uwe Stöhr wrote:
> Python 2.6 changes a lot and was released to make it easier to switch to
> Python 3. Python 2.6 is compatible to Python 2.5 and to Python 3.0.
python 2.6 is not compatible with python 3.0, one of the most flagrant
examples is print that is a s
rgh...@lyx.org wrote:
Author: rgheck
Date: Sun Jan 11 22:40:10 2009
New Revision: 28105
URL: http://www.lyx.org/trac/changeset/28105
Log:
Fix the translation of macros like: \"u, which don't appear
in unicodesymbols.
Jurgen, I'd like to do this, r27975, r27987, and r27989 for branch.
Togeth
Bo Peng wrote:
On Sun, Jan 11, 2009 at 2:02 AM, Jürgen Spitzmüller
wrote:
Bo Peng wrote:
The attached patch
fixes the bug but I am not sure if this is the best solution.
Looks sensible.
Jürgen
It is now fixed in branch: http://www.lyx.org/trac/changeset/28101 .
Can any
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
Le 11 janv. 09 à 16:00, Jürgen Spitzmüller a écrit :
Uwe Stöhr wrote:
The attached patch fixes http://bugzilla.lyx.org/show_bug.cgi?
id=5684. We
forgot on the letter layout file the \thispagestyle definitions
needed for
\telephone and \location. OK for branch too?
OK.
I know this already
+Preamble
+ \...@ifundefined{textcolor}{}
+ {%
+\definecolor{BLACK}{gray}{0}
+\definecolor{WHITE}{gray}{1}
Why not \...@ifundefined{definecolor}{} ?
JMarc
On Sun, Jan 11, 2009 at 2:02 AM, Jürgen Spitzmüller
wrote:
> Bo Peng wrote:
>> The attached patch
>> fixes the bug but I am not sure if this is the best solution.
>
> Looks sensible.
>
> Jürgen
>
It is now fixed in branch: http://www.lyx.org/trac/changeset/28101 .
Can anyone apply it to trunk?
T
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
Anders Ekberg schrieb:
That's not entirely the case either. See the last section of:
http://docs.python.org/3.0/whatsnew/3.0.html ...
However, there are a lot of persons who knows much more about this than
me (José!).
Yes, and therefore I shut up now before I'm talking something wrong.
Never
> 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:
> The attached patch fixes http://bugzilla.lyx.org/show_bug.cgi?id=5684. We
> forgot on the letter layout file the \thispagestyle definitions needed for
> \telephone and \location. OK for branch too?
OK.
Jürgen
Jürgen Spitzmüller wrote:
Uwe Stöhr wrote:
Actually, because we distribute a version of Python under window and
python 2.x will stay on any *nix system for very long time. I do not
see a need to upgrade our script to Python 3.0 right now.
Why are you sure that python 2.x will stay on
Guy Rutenberg wrote:
I've understood there is an instance of the Layout class that represents the
Enumerate environment, but I didn't find where it's created and where its
content is printed to the screen.
The enumerate layout is created from a layout file, normally
stdlists.inc. These files
On 11 jan 2009, at 14.40, Uwe Stöhr wrote:
> i know nothing about the problem, but it is not possible to have
scripts which
> work with both 2.5 and 3 versions
No, and that is the problem. The only version that is compatible to
both versions is Python 2.6.x.
That's not entirely the case e
>> Or should I apply the fix
>> nevertheless also to this file?"
>
> I think it's not needed.
The patch is in.
>> Btw. as the old revtex package is from 1992 and is incompatible to recent
>> babel versions, I propose to remove this layout for LyX 2.0. Opinions?
>
> I would leave things as they a
The attached patch fixes http://bugzilla.lyx.org/show_bug.cgi?id=5684. We forgot on the letter
layout file the \thispagestyle definitions needed for \telephone and \location.
OK for branch too?
regards Uwe
Index: layouts/stdletter.inc
=
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
Uwe Stöhr wrote:
> What about my question:
> "The same is needed for the old revtex.layout but I think we shouldn't take
> of this file anymore because the underlying LaTeX package is outdated since
> 1995 and incompatible to recent babel versions. Or should I apply the fix
> nevertheless also to t
> OK.
What about my question:
"The same is needed for the old revtex.layout but I think we shouldn't take of this file anymore
because the underlying LaTeX package is outdated since 1995 and incompatible to recent babel
versions. Or should I apply the fix nevertheless also to this file?"
Btw.
> 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:
> Oops, the attached one works.
OK.
Jürgen
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
Uwe Stöhr wrote:
> > i know nothing about the problem, but it is not possible to have scripts
> which
> > work with both 2.5 and 3 versions
>
> No, and that is the problem.
i still cant believe this is a bad joke ;) how often do the python guys change
the language definition in such an incompatib
> 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
Uwe Stöhr wrote:
> > Actually, because we distribute a version of Python under window and
> > python 2.x will stay on any *nix system for very long time. I do not
> > see a need to upgrade our script to Python 3.0 right now.
>
> Why are you sure that python 2.x will stay on any *nix system for very
> i know nothing about the problem, but it is not possible to have scripts which
> work with both 2.5 and 3 versions
No, and that is the problem. The only version that is compatible to both
versions is Python 2.6.x.
I think we can wait, but when the first distribution ships Python 3.0 as default
> This does not work. If xou do not use colors, you get
>
> ! Undefined control sequence.
> l.10 \definecolor
Oops, the attached one works.
regards Uwe
Index: revtex4.layout
===
--- revtex4.layout (revision 28092)
+++ revtex4.layout
Uwe Stöhr wrote:
>> Actually, because we distribute a version of Python under window and
>> python 2.x will stay on any *nix system for very long time. I do not
>> see a need to upgrade our script to Python 3.0 right now.
>
> Why are you sure that python 2.x will stay on any *nix system for very lo
Bo Peng schrieb:
I started with the SCons script and need the attached patch to get it
running.
Bo, can this go in or do you want to change more (comments etc.)?
You mean scons already supports Python 3.0?
I use SCons 1.2 and this works with Python 3.
Actually, because we distribute a vers
On Sun, Jan 11, 2009 at 09:07:54AM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > > Enrico Forestieri wrote:
> > > > Please try the attached patch. It works for me even with Qt 4.2.
> > > > The Source View window always opens at its minimum height.
> > >
> > > yes, that works here
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,
Enrico Forestieri wrote:
> > Enrico Forestieri wrote:
> > > Please try the attached patch. It works for me even with Qt 4.2.
> > > The Source View window always opens at its minimum height.
> >
> > yes, that works here.
>
> Jürgen?
go ahead.
Jürgen
Uwe Stöhr wrote:
> When we use ulem only for change tracking then no objections from me,
> otherwise yes.
For change tracking only.
Jürgen
Uwe Stöhr wrote:
> The added entries. But I see that I'm not able to get this context menu
> when right clicking on a math hspace. Georg what needs to be done to get
> the new math hspace context menu??
Does not work:
http://marc.info/?l=lyx-devel&m=123002014026626&w=2
Jürgen
Bo Peng wrote:
> The attached patch
> fixes the bug but I am not sure if this is the best solution.
Looks sensible.
Jürgen
47 matches
Mail list logo
