Uwe Stöhr wrote:
Do you prefer from_ascii for all calls?
No, I prefer from_ascii for all calls where we are sure that no characters
beyond the ascii range are involved.
The reason for the two calls is that from_utf8 is rather expensive, so we use
the much faster from_ascii whereever possible.
On 29/09/2008 02:38, hzluo wrote:
Yes, the fact that this code _is not used_, provided that you use
Qt4.4. And we _will_ use Qt4.4 on Windows for 1.6.x. This code is
meant to disappear when we finally switch to 4.4, but this is not
very important. The other issue is much more important.
Yes,
On 29/09/2008 04:21, hzluo wrote:
Friends,
I have taken complete examination and test for this problem,
found the following information:
1. Qt 4.4 has fixed several locale related problems, so now lyx
is able to handle any files with non-ASCII chars in filename.
That's good news!
This is
Uwe Stöhr [EMAIL PROTECTED] writes:
When using hyperref with the option colorlinks (that we support),
hyperref loads the color package \AtBeginDocument. But babel loads it
too \AtBeginDocument, so that is not loaded when babel defined
shorthand characters. Thus document with the languages
Abdelrazak Younes [EMAIL PROTECTED] writes:
setlocale(LC_ALL,);
I have tested on Windows and it works. The attached patch
will add this call at proper position.
Looks like a sane solution.
Be very careful with that. It will mean for example that double
variables will use 1,23 instead of
Hello,
This small patch adds a much desired feature without any sensible
performance penalty: List of changes in the Navigator pane.
The list is presented as follow:
Deletion (author1)
Insertion (author2)
Insertion (author1)
Insertion (author2)
...
An alternative would
On 29/09/2008 09:51, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes[EMAIL PROTECTED] writes:
setlocale(LC_ALL,);
I have tested on Windows and it works. The attached patch
will add this call at proper position.
Looks like a sane solution.
Be very careful with that. It will
[EMAIL PROTECTED] writes:
Fix bug http://bugzilla.lyx.org/show_bug.cgi?id=5285 .
--- lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp Fri Sep 26 23:34:08
2008
@@ -338,6 +338,7 @@
bufferview()-updateMetrics();
Pavel Sanda wrote:
i tend for 3. solution but would like to hear your opinions.
Why not have a Multiple View Component architecture ? The Outliner would be
one view and the main window another view ; each view would have a
infrastucture to remember what is collapsed or not. It would make
On 29/09/2008 11:03, Charles de Miramon wrote:
Pavel Sanda wrote:
i tend for 3. solution but would like to hear your opinions.
Why not have a Multiple View Component architecture ? The Outliner would be
one view and the main window another view ; each view would have a
On 29/09/2008 10:53, Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Fix bug http://bugzilla.lyx.org/show_bug.cgi?id=5285 .
--- lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp Fri Sep 26 23:34:08 2008
@@ -338,6
I would have thought that this kind of thing is only handled in the GUI
and that the LyX format would use SI conventions (which I think is 1.23).
So, if I am right, putting this in tex2lyx won't harm us, would it?
Abdel.
JMarc's concern may be true, I'm not quite sure.
I tested a less
Jean-Marc Lasgouttes schrieb:
Why don't you load it always before babel, then? Is there a reason for
having two cases?
I could do this, I just only wanted to change less as possible. I yesterday had a look at the
packages and it indeed shouldn't harm to load color always before babel, as
Uwe Stöhr [EMAIL PROTECTED] writes:
Why don't you load it always before babel, then? Is there a reason for
having two cases?
I could do this, I just only wanted to change less as possible. I
yesterday had a look at the packages and it indeed shouldn't harm to
load color always before babel,
Abdelrazak Younes [EMAIL PROTECTED] writes:
I think this chage should be reverted and GuiParagraph should be changed
to work through LyXFunc.
Is that a question or a request to do it? If the former: I agree, if
the later, not in the immediate future :-)
It is mainly a request to think about
The reason for the two calls is that from_utf8 is rather expensive, so we use
the much faster from_ascii whereever possible. As soon as a non-ascii
character is expected, we have to use from_utf8.
But why do we use it then for babel? The babel code (language names) also contains only ASCII
Uwe Stöhr [EMAIL PROTECTED] writes:
The reason for the two calls is that from_utf8 is rather expensive, so we use
the much faster from_ascii whereever possible. As soon as a non-ascii
character is expected, we have to use from_utf8.
But why do we use it then for babel? The babel code
On 29/09/2008 02:38, hzluo wrote:
Yes, the fact that this code _is not used_, provided that you use
Qt4.4. And we _will_ use Qt4.4 on Windows for 1.6.x. This code is
meant to disappear when we finally switch to 4.4, but this is not
very important. The other issue is much more important.
Yes,
On 29/09/2008 10:53, Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Fix bug http://bugzilla.lyx.org/show_bug.cgi?id=5285 .
--- lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp Fri Sep 26 23:34:08 2008
@@ -338,6
Jean-Marc Lasgouttes wrote:
But why do we use it then for babel? The babel code (language names)
also contains only ASCII characters?
It is probably an oversight.
right. As I wrote, there may be occurences of from_utf8 where from_ascii is
sufficient. But think carefully. Sometimes ascii is
On 29/09/2008 11:59, Abdelrazak Younes wrote:
On 29/09/2008 10:53, Jean-Marc Lasgouttes wrote:
This is typically a consequence of code that tries to be smart: directly
access param at point when we do not have a selection, and avoid to
dispatch an lfun.
That is not a question of smartness but
On 29/09/2008 12:13, [EMAIL PROTECTED] wrote:
Author: lasgouttes
Date: Mon Sep 29 12:13:28 2008
New Revision: 26616
URL: http://www.lyx.org/trac/changeset/26616
Log:
compilation fix
Oups, sorry.
Abdel.
Abdelrazak Younes [EMAIL PROTECTED] writes:
That is not a question of smartness but of efficiency. At the time I
didn't want to trigger to make a full copy of the current parameter
set each cursor move. That was not to avoid the dispatch of an LFUN
which can still be done easily with current
Abdelrazak Younes [EMAIL PROTECTED] writes:
Hum... in decoded abdel mode that means: At the time I didn't want to
make a full copy of the current parameter set for each cursor move.
I understood that :) But I doubt that this copy is expensive.
JMarc
On 29/09/2008 12:22, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes[EMAIL PROTECTED] writes:
That is not a question of smartness but of efficiency. At the time I
didn't want to trigger to make a full copy of the current parameter
set each cursor move. That was not to avoid the dispatch of
Abdelrazak Younes [EMAIL PROTECTED] writes:
Hum, I already did that :-)
And it seems that the patches are almost equivalent...
JMarc
On 29/09/2008 12:31, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes[EMAIL PROTECTED] writes:
Hum, I already did that :-)
And it seems that the patches are almost equivalent...
The only difference is that I preserve the efficiency ;-)
Abdel.
FYI, I merged the two methods now:
Author: younes
Date: Mon Sep 29 11:35:13 2008
New Revision: 26615
URL:http://www.lyx.org/trac/changeset/26615
Log:
Merge FileFileName::Private::checksum() into FileFileName::checksum().
Looks good to me. I believe it will work even if I havn't tested it.
Abdelrazak Younes [EMAIL PROTECTED] writes:
The only difference is that I preserve the efficiency ;-)
And that you have one of these useless and confusing mutable objects.
What about this?
JMarc
svndiff src/frontends/qt4/GuiParagraph.cpp src/frontends/qt4/GuiParagraph.h
Index:
On 29/09/2008 12:49, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes[EMAIL PROTECTED] writes:
The only difference is that I preserve the efficiency ;-)
And that you have one of these useless and confusing mutable objects.
What about this?
That's good.
Abdel.
FYI, I merged the two methods now:
Author: younes
Date: Mon Sep 29 11:35:13 2008
New Revision: 26615
URL:http://www.lyx.org/trac/changeset/26615
Log:
Merge FileFileName::Private::checksum() into FileFileName::checksum().
I have an off-topic, but related question.
For all error messages, the
hzluo [EMAIL PROTECTED] writes:
For all error messages, the absFilename() is used to print filenames.
It is always UTF-8. However, on the Windows console,
UTF-8 strings can't be displayed properly if it has non-ASCII chars.
So any messages directing to console may have chaose chars.
In
On 29/09/2008 13:00, hzluo wrote:
FYI, I merged the two methods now:
Author: younes
Date: Mon Sep 29 11:35:13 2008
New Revision: 26615
URL:http://www.lyx.org/trac/changeset/26615
Log:
Merge FileFileName::Private::checksum() into FileFileName::checksum().
I have an off-topic, but related
On 29/09/2008 13:04, Jean-Marc Lasgouttes wrote:
hzluo[EMAIL PROTECTED] writes:
For all error messages, the absFilename() is used to print filenames.
It is always UTF-8. However, on the Windows console,
UTF-8 strings can't be displayed properly if it has non-ASCII chars.
So any messages
I just checked and at least the latin1 subset is properly displayed in
my console on Vista.
It's because UTF-8's latin1 subset happen to follow your locale codepage.
On different locale settings, even latin1 may be in chaose.
Hangzai
Charles de Miramon wrote:
Pavel Sanda wrote:
i tend for 3. solution but would like to hear your opinions.
Why not have a Multiple View Component architecture ? The Outliner would be
one view and the main window another view ; each view would have a
infrastucture to remember what is
I am running fedora core 9 on a 64-bit machine, and installed
lyx-1.5.6-2.fc9.x86_64.
Lyx crashes at the start with the following report:
QPaintEngine::setSystemClip: Should not be changed while engine is active
QPaintEngine::setSystemClip: Should not be changed while engine is active
Cudell Jean-René wrote:
I am running fedora core 9 on a 64-bit machine, and installed
lyx-1.5.6-2.fc9.x86_64.
Hoping you can fix this bug in future versions, or tell me what is wrong
with my machine.
this _was_ known bug of earlier version of lyx and new version of Qt.
can you check you
On 28/09/2008 23:22, Pavel Sanda wrote:
hi,
its constant frustration for me that it is not possible to keep outliner tree
view
in some persistent state. i very often need to uncollapse only few branches in
my view to see the structure and move between these places. the document is big
enough
Abdelrazak Younes wrote:
On 28/09/2008 23:22, Pavel Sanda wrote:
hi,
its constant frustration for me that it is not possible to keep
outliner tree view
in some persistent state. i very often need to uncollapse only few
branches in
my view to see the structure and move between these places.
hi,
while translating braille module
i came to few strange things in braille module:
1. commentaries '# turn off dots' wrong (copypaste repetition bug)
2. i guess that Style Braille_(mirror_off) should contain
dashed version of LeftMargin and LabelString.
i haven't fixed it since i'm not
On Sunday 28 September 2008 20:54:07 Abdelrazak Younes wrote:
So I reckon that the risk is very minimal
and we should upgrade boost before rc3 so that we have more testing
before 1.6.0.
I would prefer after rc3. We are putting too much in the same plate.
rc3 is already released in any
On Sunday 28 September 2008 21:39:53 Pavel Sanda wrote:
Abdelrazak Younes wrote:
I would prefer after rc3. We are putting too much in the same plate.
rc3 is already released in any case, isn't it?
there were two problems reported from Konrad, dunno if its showstopper.
pavel
Not for a
On Saturday 27 September 2008 09:43:50 Jürgen Spitzmüller wrote:
I've noticed that our beamer layout does not support quote, quotation and
verse, even though beamer includes these environments.
I'll add these to branch and trunk (is trunk open again for commits?)
Yes.
Jürgen
--
José
Hi,
I am going to rename the tar balls placed in my area as rc3 (that is
svn
revision 26576). I will tag the release tomorrow morning (GMT time).
Now that rc3 is going to be out I would like to ask what is missing
before
releasing a proper 1.6.0? Surely I can and I have looked
On Fri, Sep 26, 2008 at 10:12:31AM +0200, Jean-Marc Lasgouttes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
That would be the setSelection() overload without arguments, no?
You are right indeed.
But having the overload is a bit misleading. Separating it into two
functions or renaming the
On Fri, Sep 26, 2008 at 11:31:53AM +0200, Abdelrazak Younes wrote:
Index: TocModel.cpp
===
--- TocModel.cpp (revision 26565)
+++ TocModel.cpp (working copy)
@@ -45,9 +45,52 @@
}
+TocModel::TocModel(QObject *
Jean-Marc Lasgouttes schrieb:
I could do this, I just only wanted to change less as possible. I
yesterday had a look at the packages and it indeed shouldn't harm to
load color always before babel, as this problem could also occur with
other packages that users might load in the preamble, not
its constant frustration for me that it is not possible to keep outliner tree
view
in some persistent state. i very often need to uncollapse only few branches in
my view to see the structure and move between these places. the document is big
enough that full uncollapsing is not usable
How
On Sun, Sep 28, 2008 at 08:15:09PM -, [EMAIL PROTECTED] wrote:
Author: uwestoehr
Date: Sun Sep 28 22:15:08 2008
New Revision: 26603
URL: http://www.lyx.org/trac/changeset/26603
Log:
tex2lyx/preamble.cpp: fix bug 19, patch by JMarc (I'm working with this patch
for 4 months now and it
On Sun, Sep 28, 2008 at 06:18:55PM +0200, Abdelrazak Younes wrote:
On 28/09/2008 18:18, Abdelrazak Younes wrote:
The patch from Hangzai is attached.
The patch...
Abdel.
Index: DetourCapIntf.cpp
===
--- DetourCapIntf.cpp
On Sun, Sep 28, 2008 at 11:22:02PM +0200, Pavel Sanda wrote:
hi,
its constant frustration for me that it is not possible to keep
outliner tree view in some persistent state. i very often need to
uncollapse only few branches in my view to see the structure and move
between these places. the
but I would like to hear what are the bugs that developers would like
to have fixed before tagging 1.6.0.
Surely I can and I have looked into the bugzilla reports
I did this for you:
list of current regressions: http://tinyurl.com/yu4the
list of current crashes and critical bugs:
killermike wrote:
its constant frustration for me that it is not possible to keep outliner
tree view
in some persistent state. i very often need to uncollapse only few
branches in
my view to see the structure and move between these places. the document
is big
enough that full
Le 29 sept. 08 à 20:26, Andre Poenitz a écrit :
On Fri, Sep 26, 2008 at 10:12:31AM +0200, Jean-Marc Lasgouttes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
That would be the setSelection() overload without arguments, no?
You are right indeed.
But having the overload is a bit misleading.
Pavel Sanda wrote:
killermike wrote:
is big
enough that full uncollapsing is not usable
How about an expand current section button?
how is this connected with persistence ?
It's not directly connected but it does concern management of the
navigation sidebar. Such a feature
On 29/09/2008 20:29, Andre Poenitz wrote:
On Fri, Sep 26, 2008 at 11:31:53AM +0200, Abdelrazak Younes wrote:
Index: TocModel.cpp
===
--- TocModel.cpp(revision 26565)
+++ TocModel.cpp(working copy)
@@ -45,9
Richard Heck wrote:
i tend for 3. solution but would like to hear your opinions.
I prefer 2, kind off. This can be done completely in the frontend using
simple string comparison techniques and session management. Each time a
toc reset is requested, save in the session the strings of all
I'd like to see a somewhat more verbose explanation than 'does not work
sometimes' before introducing a platform specific monstrosity like that
into LyX sources.
Is this related or unrelated?
This patch just expired. We now has much better patch for Qt 4.4.
Regards,
Hangzai
Uwe Stöhr wrote:
> Do you prefer from_ascii for all calls?
No, I prefer from_ascii for all calls where we are sure that no characters
beyond the ascii range are involved.
The reason for the two calls is that from_utf8 is rather expensive, so we use
the much faster from_ascii whereever
On 29/09/2008 02:38, hzluo wrote:
Yes, the fact that this code _is not used_, provided that you use
Qt4.4. And we _will_ use Qt4.4 on Windows for 1.6.x. This code is
meant to disappear when we finally switch to 4.4, but this is not
very important. The other issue is much more important.
Yes,
On 29/09/2008 04:21, hzluo wrote:
Friends,
I have taken complete examination and test for this problem,
found the following information:
1. Qt 4.4 has fixed several locale related problems, so now lyx
is able to handle any files with non-ASCII chars in filename.
That's good news!
This is
Uwe Stöhr <[EMAIL PROTECTED]> writes:
> When using hyperref with the option colorlinks (that we support),
> hyperref loads the color package \AtBeginDocument. But babel loads it
> too \AtBeginDocument, so that is not loaded when babel defined
> shorthand characters. Thus document with the
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> setlocale(LC_ALL,"");
>>
>> I have tested on Windows and it works. The attached patch
>> will add this call at proper position.
>
> Looks like a sane solution.
Be very careful with that. It will mean for example that double
variables will use 1,23
Hello,
This small patch adds a much desired feature without any sensible
performance penalty: List of changes in the Navigator pane.
The list is presented as follow:
Deletion (author1)
Insertion (author2)
Insertion (author1)
Insertion (author2)
...
An alternative would
On 29/09/2008 09:51, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
setlocale(LC_ALL,"");
I have tested on Windows and it works. The attached patch
will add this call at proper position.
Looks like a sane solution.
Be very careful with that. It
[EMAIL PROTECTED] writes:
> Fix bug http://bugzilla.lyx.org/show_bug.cgi?id=5285 .
> --- lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp (original)
> +++ lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp Fri Sep 26 23:34:08
> 2008
> @@ -338,6 +338,7 @@
>
>
Pavel Sanda wrote:
>
> i tend for 3. solution but would like to hear your opinions.
>
Why not have a Multiple View Component architecture ? The Outliner would be
one view and the main window another view ; each view would have a
infrastucture to remember what is collapsed or not. It would make
On 29/09/2008 11:03, Charles de Miramon wrote:
Pavel Sanda wrote:
i tend for 3. solution but would like to hear your opinions.
Why not have a Multiple View Component architecture ? The Outliner would be
one view and the main window another view ; each view would have a
On 29/09/2008 10:53, Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Fix bug http://bugzilla.lyx.org/show_bug.cgi?id=5285 .
--- lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp Fri Sep 26 23:34:08 2008
@@ -338,6
I would have thought that this kind of thing is only handled in the GUI
and that the LyX format would use SI conventions (which I think is 1.23).
So, if I am right, putting this in tex2lyx won't harm us, would it?
Abdel.
JMarc's concern may be true, I'm not quite sure.
I tested a less
Jean-Marc Lasgouttes schrieb:
Why don't you load it always before babel, then? Is there a reason for
having two cases?
I could do this, I just only wanted to change less as possible. I yesterday had a look at the
packages and it indeed shouldn't harm to load color always before babel, as
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> Why don't you load it always before babel, then? Is there a reason for
>> having two cases?
>
> I could do this, I just only wanted to change less as possible. I
> yesterday had a look at the packages and it indeed shouldn't harm to
> load color always
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> I think this chage should be reverted and GuiParagraph should be changed
>> to work through LyXFunc.
> Is that a question or a request to do it? If the former: I agree, if
> the later, not in the immediate future :-)
It is mainly a request to
> The reason for the two calls is that from_utf8 is rather expensive, so we use
> the much faster from_ascii whereever possible. As soon as a non-ascii
> character is expected, we have to use from_utf8.
But why do we use it then for babel? The babel code (language names) also contains only ASCII
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> The reason for the two calls is that from_utf8 is rather expensive, so we use
>> the much faster from_ascii whereever possible. As soon as a non-ascii
>> character is expected, we have to use from_utf8.
>
> But why do we use it then for babel? The babel
On 29/09/2008 02:38, hzluo wrote:
Yes, the fact that this code _is not used_, provided that you use
Qt4.4. And we _will_ use Qt4.4 on Windows for 1.6.x. This code is
meant to disappear when we finally switch to 4.4, but this is not
very important. The other issue is much more important.
Yes,
On 29/09/2008 10:53, Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Fix bug http://bugzilla.lyx.org/show_bug.cgi?id=5285 .
--- lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiParagraph.cpp Fri Sep 26 23:34:08 2008
@@ -338,6
Jean-Marc Lasgouttes wrote:
> > But why do we use it then for babel? The babel code (language names)
> > also contains only ASCII characters?
>
> It is probably an oversight.
right. As I wrote, there may be occurences of from_utf8 where from_ascii is
sufficient. But think carefully. Sometimes
On 29/09/2008 11:59, Abdelrazak Younes wrote:
On 29/09/2008 10:53, Jean-Marc Lasgouttes wrote:
This is typically a consequence of code that tries to be smart: directly
access param at point when we do not have a selection, and avoid to
dispatch an lfun.
That is not a question of smartness but
On 29/09/2008 12:13, [EMAIL PROTECTED] wrote:
Author: lasgouttes
Date: Mon Sep 29 12:13:28 2008
New Revision: 26616
URL: http://www.lyx.org/trac/changeset/26616
Log:
compilation fix
Oups, sorry.
Abdel.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> That is not a question of smartness but of efficiency. At the time I
> didn't want to trigger to make a full copy of the current parameter
> set each cursor move. That was not to avoid the dispatch of an LFUN
> which can still be done easily with
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Hum... in decoded abdel mode that means: At the time I didn't want to
> make a full copy of the current parameter set for each cursor move.
I understood that :) But I doubt that this copy is expensive.
JMarc
On 29/09/2008 12:22, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
That is not a question of smartness but of efficiency. At the time I
didn't want to trigger to make a full copy of the current parameter
set each cursor move. That was not to avoid the dispatch of
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Hum, I already did that :-)
And it seems that the patches are almost equivalent...
JMarc
On 29/09/2008 12:31, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
Hum, I already did that :-)
And it seems that the patches are almost equivalent...
The only difference is that I preserve the efficiency ;-)
Abdel.
FYI, I merged the two methods now:
Author: younes
Date: Mon Sep 29 11:35:13 2008
New Revision: 26615
URL:http://www.lyx.org/trac/changeset/26615
Log:
Merge FileFileName::Private::checksum() into FileFileName::checksum().
Looks good to me. I believe it will work even if I havn't tested it.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> The only difference is that I preserve the efficiency ;-)
And that you have one of these useless and confusing mutable objects.
What about this?
JMarc
svndiff src/frontends/qt4/GuiParagraph.cpp src/frontends/qt4/GuiParagraph.h
Index:
On 29/09/2008 12:49, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
The only difference is that I preserve the efficiency ;-)
And that you have one of these useless and confusing mutable objects.
What about this?
That's good.
Abdel.
FYI, I merged the two methods now:
Author: younes
Date: Mon Sep 29 11:35:13 2008
New Revision: 26615
URL:http://www.lyx.org/trac/changeset/26615
Log:
Merge FileFileName::Private::checksum() into FileFileName::checksum().
I have an off-topic, but related question.
For all error messages, the
"hzluo" <[EMAIL PROTECTED]> writes:
> For all error messages, the absFilename() is used to print filenames.
> It is always UTF-8. However, on the Windows console,
> UTF-8 strings can't be displayed properly if it has non-ASCII chars.
> So any messages directing to console may have chaose chars.
On 29/09/2008 13:00, hzluo wrote:
FYI, I merged the two methods now:
Author: younes
Date: Mon Sep 29 11:35:13 2008
New Revision: 26615
URL:http://www.lyx.org/trac/changeset/26615
Log:
Merge FileFileName::Private::checksum() into FileFileName::checksum().
I have an off-topic, but related
On 29/09/2008 13:04, Jean-Marc Lasgouttes wrote:
"hzluo"<[EMAIL PROTECTED]> writes:
For all error messages, the absFilename() is used to print filenames.
It is always UTF-8. However, on the Windows console,
UTF-8 strings can't be displayed properly if it has non-ASCII chars.
So any
I just checked and at least the latin1 subset is properly displayed in
my console on Vista.
It's because UTF-8's latin1 subset happen to follow your locale codepage.
On different locale settings, even latin1 may be in chaose.
Hangzai
Charles de Miramon wrote:
> Pavel Sanda wrote:
> >
> > i tend for 3. solution but would like to hear your opinions.
> >
>
> Why not have a Multiple View Component architecture ? The Outliner would be
> one view and the main window another view ; each view would have a
> infrastucture to
I am running fedora core 9 on a 64-bit machine, and installed
lyx-1.5.6-2.fc9.x86_64.
Lyx crashes at the start with the following report:
QPaintEngine::setSystemClip: Should not be changed while engine is active
QPaintEngine::setSystemClip: Should not be changed while engine is active
Cudell Jean-René wrote:
> I am running fedora core 9 on a 64-bit machine, and installed
> lyx-1.5.6-2.fc9.x86_64.
>
> Hoping you can fix this bug in future versions, or tell me what is wrong
> with my machine.
this _was_ known bug of earlier version of lyx and new version of Qt.
can you check
On 28/09/2008 23:22, Pavel Sanda wrote:
hi,
its constant frustration for me that it is not possible to keep outliner tree
view
in some persistent state. i very often need to uncollapse only few branches in
my view to see the structure and move between these places. the document is big
enough
Abdelrazak Younes wrote:
On 28/09/2008 23:22, Pavel Sanda wrote:
hi,
its constant frustration for me that it is not possible to keep
outliner tree view
in some persistent state. i very often need to uncollapse only few
branches in
my view to see the structure and move between these places.
hi,
while translating braille module
i came to few strange things in braille module:
1. commentaries '# turn off dots' wrong (copy repetition bug)
2. i guess that Style Braille_(mirror_off) should contain
dashed version of LeftMargin and LabelString.
i haven't fixed it since i'm not sure
1 - 100 of 118 matches
Mail list logo
