Re: [patch] bug 1820 --- footnotes in different language
Dov Feldstern wrote: Hi! Attached find a patch for bug 1820, which has resisted solution for a long time. After a lot of work done by others to tidy up the output_latex code in the past few months, the infrastructure was now in place so that finally we can provide a solution. It would be good if this could still make it in to 1.5.0, though I realize that this is deep inside the latex output, and therefore may be too risky at this point... :( I personally think that, at C++ level, there's nothing scary in your patch but I am not a LateX expert. Abdel.
Re: Windows 98 / Me support?
Joost Verburg wrote: Hi, LyX 1.5 almost works on Windows 98/Me. I can create, open and save documents and do all the normal work. There is however one major bug that makes it useless: The second time LyX is started (when no configuration needs to be done anymore) it just crashes on startup! When I remove the configuration data and start LyX again, everything works just fine. Is there anyone with a copy of Win9x who is able to debug this thing? If it's a simple fix, we can release 1.5 with Windows 9x support. The installer code for Win9x is ready. If you provide us with a backtrace we might do something without the need to have access to a Win9X machine. Abdel.
[Patch] Fix bug 3990: Wrong Paste Message between document with different Document Style
http://bugzilla.lyx.org/show_bug.cgi?id=3990
Attached.
Abdel.
Index: CutAndPaste.cpp
===
--- CutAndPaste.cpp (revision 19003)
+++ CutAndPaste.cpp (working copy)
@@ -413,6 +413,8 @@
void switchBetweenClasses(textclass_type c1, textclass_type c2,
InsetText in, ErrorList errorlist)
{
+ errorlist.clear();
+
BOOST_ASSERT(!in.paragraphs().empty());
if (c1 == c2)
return;
Re: Windows 98 / Me support?
Bo Peng wrote: Is your qt dependency file working under win 98? Do you use MSVC Express? I have a valid license of win 98 and I may be able to create a virtual machine for it. Yes, the dependency file works. The MSVC Express IDE doesn't support Windows 9x, so you'll have to use remote debugging or just the debug log. The standard '-dbg all' output doesn't seem to help, the only output before it crashes is: 'Setting debug level to all'. Joost
Re: Windows 98 / Me support?
Joost Verburg wrote: Bo Peng wrote: Is your qt dependency file working under win 98? Do you use MSVC Express? I have a valid license of win 98 and I may be able to create a virtual machine for it. Yes, the dependency file works. The MSVC Express IDE doesn't support Windows 9x, so you'll have to use remote debugging What's that? or just the debug log. The standard '-dbg all' output doesn't seem to help, the only output before it crashes is: 'Setting debug level to all'. That's not going to help... I guess the only solution is gcc then. Abdel.
Re: Windows 98 / Me support?
Abdelrazak Younes wrote: Yes, the dependency file works. The MSVC Express IDE doesn't support Windows 9x, so you'll have to use remote debugging What's that? Compiling on one computer and debugging on another. Microsoft provides a tool that allows you to do so. or just the debug log. The standard '-dbg all' output doesn't seem to help, the only output before it crashes is: 'Setting debug level to all'. That's not going to help... I guess the only solution is gcc then. If you add more debug output it may be possible to track the issue without having to setup remote debugging. Joost
Re: Windows 98 / Me support?
Joost Verburg wrote: Abdelrazak Younes wrote: Yes, the dependency file works. The MSVC Express IDE doesn't support Windows 9x, so you'll have to use remote debugging What's that? Compiling on one computer and debugging on another. Microsoft provides a tool that allows you to do so. Then why don't you do that? ;-) or just the debug log. The standard '-dbg all' output doesn't seem to help, the only output before it crashes is: 'Setting debug level to all'. That's not going to help... I guess the only solution is gcc then. If you add more debug output it may be possible to track the issue without having to setup remote debugging. The problem is to know where to put them... Abdel.
Re: Windows 98 / Me support?
Abdelrazak Younes wrote: Compiling on one computer and debugging on another. Microsoft provides a tool that allows you to do so. Then why don't you do that? ;-) I don't have a computer with Windows 98 / Me and network support. Joost
Re: Towards LyX 1.4.5 [status update #1]
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Hello, Since Jose' plans to release 1.5.0 next week, we'd better be ready with 1.4.5 too. I append the ANNOUNCE file that I just updated. Jose', I would appreciate if you could upgrade lyx2lyx in branch to handle the 1.5 final format. Other things? beamer.layout is not up do date compared to 1.5.version (see attachment http://bugzilla.lyx.org/attachment.cgi?id=1626action=view to bug 3141). -- Jean-Pierre
Re: [PATCH] Translation problem in paragraph dialog
Koji Yokota schrieb: Michael Gerz wrote: Hi, this patch fixes a translation problem. OK? Michael Yes, I confirmed. Thank you! Thanks. I need one more OK. Anybody, please? Michael
Re: [PATCH] Translation problem in paragraph dialog
Michael Gerz wrote: Koji Yokota schrieb: Michael Gerz wrote: Hi, this patch fixes a translation problem. OK? Michael Yes, I confirmed. Thank you! Thanks. I need one more OK. Anybody, please? While I agree that your patch is good and clean (thus you have my OK), I don't understand why qt_() does not work. Do you? Abdel.
[Patch] Fix Bug 3862: Inconsistency of appendix with child documents
http://bugzilla.lyx.org/show_bug.cgi?id=3862
Attached.
Abdel.
Index: buffer_funcs.cpp
===
--- buffer_funcs.cpp(revision 19003)
+++ buffer_funcs.cpp(working copy)
@@ -474,7 +474,13 @@
Layout_ptr const layout = par.layout();
Counters counters = textclass.counters();
- if (it.pit() == 0) {
+ Buffer const * mbuf = buf.getMasterBuffer();
+ bool const child_in_appendix = buf != mbuf
+mbuf-text().paragraphs().back().params().appendix();
+
+ if (child_in_appendix)
+ par.params().appendix(true);
+ else if (it.pit() == 0) {
par.params().appendix(par.params().startOfAppendix());
} else {
par.params().appendix(it.plist()[it.pit() -
1].params().appendix());
Re: [patch] Re: RTL justification bug
Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov I still haven't gotten any other responses regarding this patch. Dov I think it's safe, I've been working with it since I first sent Dov it to the list and haven't run into any trouble. I don't think Dov that it's *crucial* that this go in before 1.5.0, but it would be Dov nice... I guess the problem is that nobody understands this bidi stuff like you do. I would tend to say go ahead!, but I am not sure what are my credentials to do so :) JMarc
Re: [patch] Re: RTL justification bug
Jean-Marc Lasgouttes wrote: Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov I still haven't gotten any other responses regarding this patch. Dov I think it's safe, I've been working with it since I first sent Dov it to the list and haven't run into any trouble. I don't think Dov that it's *crucial* that this go in before 1.5.0, but it would be Dov nice... I guess the problem is that nobody understands this bidi stuff like you do. I would tend to say go ahead!, but I am not sure what are my credentials to do so :) Same position for me. The patch looks not so complicate so I'd say go ahead too. As this is a display thing, we'll notice soon enough if something is wrong. Abdel.
[PATCH] Fix bug 3992: Screen update problem in change tracking mode
http://bugzilla.lyx.org/show_bug.cgi?id=3992
Attached.
Index: Text3.cpp
===
--- Text3.cpp (revision 19003)
+++ Text3.cpp (working copy)
@@ -1141,9 +1141,10 @@
// auto_region_delete, which defaults to
// true (on).
- if (lyxrc.auto_region_delete)
- if (cur.selection())
- cutSelection(cur, false, false);
+ if (lyxrc.auto_region_delete cur.selection()) {
+ cutSelection(cur, false, false);
+ cur.updateFlags(Update::Force);
+ }
cur.clearSelection();
Font const old_font = real_current_font;
Re: Upgrade from 1.4 to 1.5
Abdelrazak Younes [EMAIL PROTECTED] writes: Charpentier Philippe wrote: My problem is not the encoding of the layout. It is that, since 1.2 version of lyx I used layouts I wrote and they contain definition of styles with non ASCII characters like this: Style Théorème ... Style Énumère ... Style Liste_à_puce ... etc... and I did it because these names appear in the GUI (and it was not written in the documentation that those name must contain only ASCII). This was working perfectly until 1.4.x. But now the 1.5 version crash if I want to use one of my layouts (independently of the encoding): non ASCII characters seems forbidden now for the Style name. As these names appear in the layout and in the documents, I am afraid that, if nothing is done for this I will never be able to use the next versions of lyx AFAIU, the problem is that the translation machinery requires that these field are 7 bits ASCII. The point there is that these are collected by the gettext mechanism (see for instance the IEEEtran template: the style menu offers the translated version of Theorem, Itemize and Enumerate as Théorème, LstePuces and Énumération). These known translations are uses by new layouts as far as the same style names are used. The layouts are parsed to build .pot field used for translations. The problem is that for new local style names, the user should update the pot file, merge with the current po file, edit the result, build the new format and replace the old one in the LC_MESSAGES directory. 1) provide a python script that converts the layout as good as possible: Théorème - Theoreme Liste_à_puce - Liste_a_puce The problem is that it could be done easily for French but maybe not for other languages. Second problem is that I am not sure we have a lyx2lyx equivalent for layoouts, do we? 2) Accept the layout field as is and do not try to translate them. Given the burden of gettext management, this would clearly be better, but what about encoding ? From 1.5, the reference encoding is Unicode, so that style naming should be in Unicode in the layout file, and converted to the locale to display, like any other menu. Maybe some script to ease gettext management would be better, to keep this in the global translation flow. -- Jean-Pierre
Re: [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
Anders Ekberg wrote: The patch addresses this by excluding all accented characters from the list that revert_unicode processes. In principle this results in that accented characters get properly translated and remaining unicode characters are replaced by ERT or math commands (if they are in the list of characters). And then we have to maintain two unicodesymbols lists? I do not think this is a good idea. How about adding a new flag revert to the unicodesymbols list instead? Jürgen
[Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
Jean-Pierre Chrétien wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
1) provide a python script that converts the layout as good as possible:
Théorème - Theoreme
Liste_à_puce - Liste_a_puce
The problem is that it could be done easily for French but maybe not for
other languages. Second problem is that I am not sure we have a lyx2lyx
equivalent for layoouts, do we?
2) Accept the layout field as is and do not try to translate them.
Given the burden of gettext management, this would clearly be better,
I've implemented that already, see attached patch. I agree this is
better to the end-user who doesn't care if his styles are not
translated. Especially if these styles are not meant to be distributed
outside his classroom for example.
but what about encoding ? From 1.5, the reference encoding is Unicode,
so that style naming should be in Unicode in the layout file, and
converted to the locale to display, like any other menu.
Yes, all layout files need to be encoded in UTF-8 otherwise my patch
will not work.
Maybe some script to ease gettext management would be better, to keep
this in the global translation flow.
Too difficult IMHO.
Abdel.
Index: src/BufferView.h
===
--- src/BufferView.h(revision 19003)
+++ src/BufferView.h(working copy)
@@ -242,7 +242,7 @@
std::string data) updateDialog;
/// This signal is emitted when the layout at the cursor is changed.
- boost::signalvoid(std::string layout) layoutChanged;
+ boost::signalvoid(docstring layout) layoutChanged;
private:
///
Index: src/CutAndPaste.cpp
===
--- src/CutAndPaste.cpp (revision 19003)
+++ src/CutAndPaste.cpp (working copy)
@@ -423,7 +423,7 @@
// layouts
ParIterator end = par_iterator_end(in);
for (ParIterator it = par_iterator_begin(in); it != end; ++it) {
- string const name = it-layout()-name();
+ docstring const name = it-layout()-name();
bool hasLayout = tclass2.hasLayout(name);
if (hasLayout)
@@ -435,7 +435,7 @@
docstring const s = bformat(
_(Layout had to be changed
from\n%1$s to %2$s\n
because of class conversion
from\n%3$s to %4$s),
-from_utf8(name), from_utf8(it-layout()-name()),
+name, it-layout()-name(),
from_utf8(tclass1.name()), from_utf8(tclass2.name()));
// To warn the user that something had to be done.
errorlist.push_back(ErrorItem(_(Changed Layout), s,
Index: src/factory.cpp
===
--- src/factory.cpp (revision 19003)
+++ src/factory.cpp (working copy)
@@ -228,7 +228,7 @@
return new
InsetTOC(InsetCommandParams(tableofcontents));
case LFUN_ENVIRONMENT_INSERT:
- return new InsetEnvironment(params,
to_utf8(cmd.argument()));
+ return new InsetEnvironment(params, cmd.argument());
#if 0
case LFUN_LIST_INSERT:
@@ -491,7 +491,7 @@
inset.reset(new InsetInclude(p));
} else if (tmptok == Environment) {
lex.next();
- inset.reset(new InsetEnvironment(buf.params(),
lex.getString()));
+ inset.reset(new InsetEnvironment(buf.params(),
lex.getDocString()));
} else if (tmptok == ERT) {
inset.reset(new InsetERT(buf.params()));
} else if (tmptok == listings) {
Index: src/frontends/LyXView.cpp
===
--- src/frontends/LyXView.cpp (revision 19003)
+++ src/frontends/LyXView.cpp (working copy)
@@ -68,7 +68,7 @@
using lyx::frontend::ControlCommandBuffer;
-string current_layout;
+docstring current_layout;
LyXView::LyXView(int id)
@@ -462,7 +462,7 @@
}
BOOST_ASSERT(work_area_);
- string const layout = work_area_-bufferView().cursor().
+ docstring const layout = work_area_-bufferView().cursor().
innerParagraph().layout()-name();
if (layout != current_layout) {
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp (revision 19003)
+++ src/frontends/qt4/QDocument.cpp (working copy)
@@ -852,7 +852,7 @@
if (toclevel != Layout::NOT_IN_TOC
(*cit)-labeltype == LABEL_COUNTER) {
item = new QTreeWidgetItem(numberingModule-tocTW);
- item-setText(0, qt_((*cit)-name()));
+
Re: [Cvslog] r18992 - /lyx-devel/trunk/src/frontends/controllers/front...
Michael Gerz wrote: OK, I did it for you... thanks to you both. Jürgen
Re: Upgrade from 1.4 to 1.5
Abdelrazak Younes wrote: I am not sure we have a lyx2lyx equivalent for layoouts, do we? layout2layout. Jürgen
Re: [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
Jürgen Spitzmüller
Mon, 09 Jul 2007 02:05:27 -0700
Anders Ekberg wrote:
The patch addresses this by excluding all accented characters from
the list that revert_unicode processes. In principle this results in
that accented characters get properly translated and remaining
unicode characters are replaced by ERT or math commands (if they are
in the list of characters).
And then we have to maintain two unicodesymbols lists? I do not
think this is
a good idea.
I know, I tried some different options (like searching for {...}),
but didn't come up with anything I thought was better. So as a
compromise, I kept the lists identical and just commented out the
accented characters. If there is little maintenance of the
unicodesymbols list, I think it is acceptable (you can do a diff to
fairly easy spott errors).
How about adding a new flag revert to the unicodesymbols list
instead?
I thought about that too, but was afraid this would mess things up in
other places.
/Anders
Re: [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
Anders Ekberg wrote:
And then we have to maintain two unicodesymbols lists? I do not
think this is
a good idea.
I know, I tried some different options (like searching for {...}),
but didn't come up with anything I thought was better. So as a
compromise, I kept the lists identical and just commented out the
accented characters. If there is little maintenance of the
unicodesymbols list, I think it is acceptable (you can do a diff to
fairly easy spott errors).
I think lots of symbols will be added soon after 1.5.0. The need to always
snchronize the two lists is inefficient and error-prone.
How about adding a new flag revert to the unicodesymbols list
instead?
I thought about that too, but was afraid this would mess things up in
other places.
Where?
Jürgen
Re: [patch] Re: RTL justification bug
On Monday 09 July 2007 09:50:27 Abdelrazak Younes wrote: I guess the problem is that nobody understands this bidi stuff like you do. I would tend to say go ahead!, but I am not sure what are my credentials to do so :) Same position for me. The patch looks not so complicate so I'd say go ahead too. As this is a display thing, we'll notice soon enough if something is wrong. Abdel. I agree with Jean-Marc and Abdel so you have my OK. -- José Abílio
Re: [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
On 9 jul 2007, at 11.36, Jürgen Spitzmüller wrote:
Anders Ekberg wrote:
And then we have to maintain two unicodesymbols lists? I do not
think this is
a good idea.
I know, I tried some different options (like searching for {...}),
but didn't come up with anything I thought was better. So as a
compromise, I kept the lists identical and just commented out the
accented characters. If there is little maintenance of the
unicodesymbols list, I think it is acceptable (you can do a diff to
fairly easy spott errors).
I think lots of symbols will be added soon after 1.5.0. The need to
always
snchronize the two lists is inefficient and error-prone.
How about adding a new flag revert to the unicodesymbols list
instead?
I thought about that too, but was afraid this would mess things up in
other places.
Where?
I assumed in the conversion to TeX. But I don't know anything about
that, so I took what I thought was the safest route.
Anders
Re: Crash only in recent SVN on FreeBSD
On Sunday 08 July 2007 18:10:37 Koji Yokota wrote: Yap, it solved the problem. Thank you!! OK Enrico you can commit the patch. Koji -- José Abílio
Re: [Patch] Fix bug 3990: Wrong Paste Message between document with different Document Style
On Monday 09 July 2007 07:49:25 Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3990 Attached. OK. Abdel. -- José Abílio
Re: [Patch] Fix bug 3990: Wrong Paste Message between document with different Document Style
José Matos wrote: On Monday 09 July 2007 07:49:25 Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3990 Attached. OK. Done.
Re: [PATCH] Toolbars
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael See it that way: I removed an obsolete non-const method for Michael defined and added a _different_ non-const method for Michael used. There is no case in which we want to change a Michael defined toolbar whereas we have to change a used toolbar. OK, go ahead. JMarc
Re: Unicode in source code viewer?
Michael Cysouw wrote: the source code viewer does not display unicode. could you elaborate a bit please? Jürgen
Re: [PATCH] Bug 3764: Implicit \author field in .lyx files
José == José Matos [EMAIL PROTECTED] writes: All of this make perfectly sense to me. Although Jean-Marc has left us with some FUD (but without a given proof), I would like to commit his patch. Could someone please give another OK? José I would like to wait for Jean-Marc on this. Not that I have José problem with this, for the record. I did not manage to reproduce the problem I saw and anyway I do not think they are introduced by the patch. Please go ahead. JMarc
Re: [PATCH] Toolbars
On Monday 09 July 2007 11:07:28 Jean-Marc Lasgouttes wrote: OK, go ahead. +1 JMarc -- José Abílio
Re: [Patch] Fix Bug 3862: Inconsistency of appendix with child documents
On Monday 09 July 2007 09:34:12 Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3862 Attached. Abdel. The patch seems straightforward but this is also the type of bug that can wait for 1.5.1. Let us wait for other opinions. -- José Abílio
Re: [PATCH] Fix bug 3992: Screen update problem in change tracking mode
On Monday 09 July 2007 09:56:18 Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3992 Attached. OK. -- José Abílio
Re: [patch] fix Bug 3983: system external_template file is ignored when user defined external_template file exists
Bernhard == Bernhard Roider [EMAIL PROTECTED] writes: What about a different idea: since the problem is the hardcoding of RasterImage, we could replace it by code like the following. Bernhard This solution looks good to me and should go in imho. José, is this patch OK? JMarc
Re: [patch] fix Bug 3983: system external_template file is ignored when user defined external_template file exists
On Monday 09 July 2007 11:19:22 Jean-Marc Lasgouttes wrote: José, is this patch OK? Yes. JMarc -- José Abílio
Re: Towards LyX 1.4.5 [status update #1]
christian == christian ridderstrom [EMAIL PROTECTED] writes: christian On Fri, 6 Jul 2007, Jean-Marc Lasgouttes wrote: Since Jose' plans to release 1.5.0 next week, we'd better be ready with 1.4.5 too. I append the ANNOUNCE file that I just updated. christian Looks good to me. I thought some of the lines were christian justified a bit funny, so here's an adjusted version (I christian didn't have time to make a patch, sorry). Applied thanks. christian I did notice a minor language issue... in the following christian paragraph christianLyX is for people that write and want their writing to christian look great, right out of the box. No more endless tinkering christian with formatting christian I think the comma should be removed, i.e. so that it reads: christianLyX is for people that write and want their writing to christian look great right out of the box. No more endless tinkering christian with formatting It looks correct to me as it is, but someone else concurs with you, I'll change it. JMarc
Re: [Patch] Fix Bug 3862: Inconsistency of appendix with child documents
José Matos wrote: On Monday 09 July 2007 09:34:12 Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3862 Attached. Abdel. The patch seems straightforward but this is also the type of bug that can wait for 1.5.1. Some more explanation: 1) The section labels won't have a good number - inconsistency with LateX. 2) In the outline, if a child document is in the appendix section of a master document (something I always do personally), you will have a Chapter 1 after Appendix XX: very misleading. Let us wait for other opinions. Sure (but the patch is safe). Abdel.
Re: [PATCH] Fix bug 3992: Screen update problem in change tracking mode
José Matos wrote:
On Monday 09 July 2007 09:56:18 Abdelrazak Younes wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3992
Attached.
OK.
I committed a better version with some comments:
Author: younes
Date: Mon Jul 9 12:32:28 2007
New Revision: 19010
URL: http://www.lyx.org/trac/changeset/19010
Log:
Fix 3992: Screen update problem in change tracking mode
http://bugzilla.lyx.org/show_bug.cgi?id=3992
Modified:
lyx-devel/trunk/src/Text3.cpp
Modified: lyx-devel/trunk/src/Text3.cpp
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Text3.cpp?rev=19010
==
--- lyx-devel/trunk/src/Text3.cpp (original)
+++ lyx-devel/trunk/src/Text3.cpp Mon Jul 9 12:32:28 2007
@@ -1141,9 +1141,17 @@
// auto_region_delete, which defaults to
// true (on).
- if (lyxrc.auto_region_delete)
- if (cur.selection())
- cutSelection(cur, false, false);
+ if (lyxrc.auto_region_delete cur.selection()) {
+ cutSelection(cur, false, false);
+ // When change tracking is set to off, the metrics
update
+ // mechanism correctly detects if a full update is
needed or not.
+ // This detection fails when a selection spans multiple
rows and
+ // change tracking is enabled because the paragraph
metrics stays
+ // the same. In this case, we force the full update:
+ // (see http://bugzilla.lyx.org/show_bug.cgi?id=3992)
+ if (cur.buffer().params().trackChanges)
+ cur.updateFlags(Update::Force);
+ }
cur.clearSelection();
Font const old_font = real_current_font;
Re: Crash only in recent SVN on FreeBSD
On Mon, Jul 09, 2007 at 10:51:15AM +0100, José Matos wrote: On Sunday 08 July 2007 18:10:37 Koji Yokota wrote: Yap, it solved the problem. Thank you!! OK Enrico you can commit the patch. Done. -- Enrico
Re: [patch] fix Bug 3983: system external_template file is ignored when user defined external_template file exists
José == José Matos [EMAIL PROTECTED] writes: José On Monday 09 July 2007 11:19:22 Jean-Marc Lasgouttes wrote: José, is this patch OK? José Yes. Done thanks. JMarc
Re: Fwd: readme updates
Pavel == Pavel Sanda [EMAIL PROTECTED] writes: Pavel Sanda schrieb: For the patch to readme.localization, could you please send this as separate patch to the devel list for approval. i wonder what is this list for then :) I'm only unsure if I'm allowed to commit anything else than docs and po files because of the release freeze we are in. Your changes are reasonable I just want to have the OK from someone else. regards Uwe Pavel please see the attached patch pavel Looks good to me except maybe: - On Linux: LANG=xx_CC lyx + On Linux: export LANG=xx_CC lyx I do not thing the 'export' is needed. Does it change something for you? (when typing all in the same line) JMarc
Re: issues with change tracking
On Sunday 08 July 2007 17:01:56 Michael Gerz wrote: Edwin Leuven schrieb: second thing is when i delete a collapsed footnote. the collapse footnote gets crossed out in lyx but not the text inside. in the dvi the footnote isn't crossed out. Ouch. This is a very serious CT problem! Luckily, I have a tentative patch at hand :-) The idea is that the inset's content inherits the change information from the complete (deleted) inset during LaTeX output. (Note: Marking the complete inset content as deleted in LyX is not preferable. Imagine, you spend a lot of time on the rewrite of a footnote and then your co-author decides to delete the complete footnote. Certainly, you still want to preserve the change status of the footnote content just in case your co-author changes his mind). Gentlemen, the problem raised by Edwin should definitely be fixed for 1.5.0. Please have a look at the attached patch. Comments, suggestions for improvement, testing, and even OKs are welcome :-) The patch seems reasonable as far as I can see. :-) If Edwin confirms that it works it can go in. Thanks! Michael PS: This is my fourth uncommitted patch. Looks like we have more patches than OKs at the moment. With all the due respect for you and your work, a more conservative stance several days before releasing a stable version is a good thing (at least for me). :-) -- José Abílio
Re: Fwd: readme updates
Looks good to me except maybe: - On Linux: LANG=xx_CC lyx + On Linux: export LANG=xx_CC lyx I do not thing the 'export' is needed. Does it change something for you? (when typing all in the same line) $ unset LANG $ lyx -english menus $ LANG=cs_CZ $ lyx -english menus $ export LANG=cs_CZ $ lyx -czech menus pavel
Re: Fwd: readme updates
Pavel Sanda wrote: $ unset LANG $ lyx -english menus $ LANG=cs_CZ $ lyx -english menus $ export LANG=cs_CZ $ lyx -czech menus $ LANG=cs_CZ lyx -czech menus Jürgen
Re: Fwd: readme updates
(when typing all in the same line) bah, i should be more attentive. sorry. fixed patch attached. pavel Index: README.localization === --- README.localization (revision 19005) +++ README.localization (working copy) @@ -14,9 +14,9 @@ The file you need to edit it an xx.po file where xx stands for your language's two letter code. German would be for example de.po and Polish pl.po. For a list -of country codes look at: +of languages codes look at: - http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC222 + http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#Language-Codes If you want to start from scratch then you should obtain a copy of the lyx.pot and name it after your language. German would be for example de.po and Polish @@ -40,7 +40,7 @@ that a #, fuzzy line is just a hint for translation from compiler - in order to get the translation of the current item working you have to delete this line. It is recommended that you would take a look at another .po file - that -way you can get an idea of what to do. If your using a specialized po editor +way you can get an idea of what to do. If you are using a specialized po editor then you will see in it the untranslated strings and a place to write your translation for them. @@ -83,17 +83,38 @@ The most comfortable way to see your updated translation while editing, is running (in linux): -1. make xx.po in po directory to compile updated xx.po translation +1. make xx.gmo in the po directory to compile updated xx.po translation 2. make install in root lyx tree to copy xx.gmo into the appropriate location (or do it by hand...) +For advanced users - if you want to remerge your files against current source +files run make update-po. -7) REFERENCES +7) HOW TO CONTRIBUTE MY WORK? + +You can manually use diff utility to make patch; usually the most comfortable +way is to run something like (after you edit xx.po): + + svn diff xx.po xx.po.patch + +This file should be sent to [EMAIL PROTECTED] + +Also you can check http://www.lyx.org/trac/browser/lyx-devel/trunk to track +changes or watch updates. + + +8) REFERENCES + For some basic idea on how the translation works, you can look at http://en.wikipedia.org/wiki/Gettext -For detailed reference, have a look at +For detailed reference (including full list of country and language codes), +have a look at http://www.gnu.org/software/gettext/manual/gettext.html + + +Consider subscribing to the documentation list at [EMAIL PROTECTED] (rather +silent one) or developer's mailing list lyx-devel@lists.lyx.org (high volume).Index: po/README === --- po/README (revision 19005) +++ po/README (working copy) @@ -1,56 +1,3 @@ -This file is intended to provide information about the different translation -files. If you want to make one for your language, please read -Help-Customization for more information, and the information below. - -How can I update an existing po file? -- - -It requires a bit of work to get started, but once you are set up, -the procedure should be relatively easy: - -1) Getting ready - -Get and install gettext (available from ftp://alpha.gnu.org). Read the -documentation for gettext. Then get the latest LyX distribution including -patches, and unpack it in your home directory. It is yet better if you checkout -the CVS version of LyX. -Read the README in the LyX distribution. -Check the mailing list archives to learn what is going on at the moment. -Consider subscribing to the developer's mailing list, [EMAIL PROTECTED] - -2) Preparing a patch - -Now do (where XX stands for the code of your language): - -cp -R lyx-*.*.* lyx.new - (Which makes a copy of the source distribution for -you to change, but you should work in a CVS workarea) - cd lyx.new/po/ - - make XX.pox - (It merges the po file into the temporary file XX.pox) -emacs XX.pox - (Using po-mode. Emacs is convenient for po editing, but not -mandatory.) - (Make all necessary changes in XX.pox, and save.) -mv XX.pox XX.po -rm XX.pox~ - (To remove Emacs autosave.) - make XX.gmo - (Update the ChangeLog file.) - - cd .. - - (Maybe update lib/CREDITS) - - cvs diff -u XX_po_update.patch - (Or whatever good method to have a patch in unified diff format) - -3) Submitting the patch - - Check your patch and mail it to lyx-devel@lists.lyx.org - -Thanks! - -The LyX Team. - +If you want to make translation for your language, please read +Help-Customization for more information, and the information +in
Re: Fwd: readme updates
On Mon, Jul 09, 2007 at 01:01:21PM +0200, Jean-Marc Lasgouttes wrote: Pavel == Pavel Sanda [EMAIL PROTECTED] writes: Pavel Sanda schrieb: For the patch to readme.localization, could you please send this as separate patch to the devel list for approval. i wonder what is this list for then :) I'm only unsure if I'm allowed to commit anything else than docs and po files because of the release freeze we are in. Your changes are reasonable I just want to have the OK from someone else. regards Uwe Pavel please see the attached patch pavel Looks good to me except maybe: - On Linux: LANG=xx_CC lyx + On Linux: export LANG=xx_CC lyx I do not thing the 'export' is needed. Does it change something for you? (when typing all in the same line) I would use env in place of export, such that it works whatever the shell used. -- Enrico
Re: [Updated PATCH] accept utf8 in layout files
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Here is an updated patch that I actually tested. It Abdelrazak doesn't crash anymore but it doesn't work well because Abdelrazak there is a problem with layout files in trunk: I think Abdelrazak they are encoded in ISO-8859-1 (latin-1) so ICONV choke on Abdelrazak characters with accents. Shouldn't we convert all layout Abdelrazak files to utf8? I think it is the reason why nothing has been done until now: there is no really good solution. You cannot convert the users' layouts to utf8... JMarc
Re: 1.4.x vs. 1.5.x roadmap (Re: LyX-1.4.4 fails to build against boost-1.34)
Mikhail == Mikhail Teterin [EMAIL PROTECTED] writes: Mikhail But do you intend to keep maintaining the two branches for a Mikhail while? If so, I'll, probably, make a separate port of lyx15 Mikhail -- for the adventerous. No, there is no plan to maintain 1.4 beyond 1.4.5 (unless something really bad happens). Mikhail Otherwise, if there will be not 1.4.x releases beyond 1.4.5, Mikhail I'll just skip the 1.5.0 and update the existing port to for Mikhail 1.5.1 with all the new bugs ironed out :) It might indeed be a good idea. JMarc
Re: [Updated PATCH] accept utf8 in layout files
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Here is an updated patch that I actually tested. It Abdelrazak doesn't crash anymore but it doesn't work well because Abdelrazak there is a problem with layout files in trunk: I think Abdelrazak they are encoded in ISO-8859-1 (latin-1) so ICONV choke on Abdelrazak characters with accents. Shouldn't we convert all layout Abdelrazak files to utf8? I think it is the reason why nothing has been done until now: there is no really good solution. You cannot convert the users' layouts to utf8... Why should we? I am probably missing something but... isn't it enough to tell to the users that their layout needs to be converted to utf8? Of course we should say it big and loud but I reckon that users that are able to change a layout are also able to change the encoding of their layout. Especially so if the big goal of 1.5 is unicode. Abdel.
Re: 1.5rc2 binary for dapper
Sam == Sam Lewis [EMAIL PROTECTED] writes: Sam Hi, I've moved a 1.5rc2 binary for ubuntu dapper to incoming Sam ftp.lyx.org. Could someone please place in the appropriate Sam folder. Many thanks! Hello, I did that. JMarc
Re: [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
Anders == Anders Ekberg [EMAIL PROTECTED] writes: Anders The patch addresses this by excluding all accented characters Anders from the list that revert_unicode processes. In principle this Anders results in that accented characters get properly translated Anders and remaining unicode characters are replaced by ERT or math Anders commands (if they are in the list of characters). What is the different between reverse_unicode and revert accent? Is it just generating ERT versus InsetLaTexAccent? In this case, lyx2lyx could look at the generated string and decide what to do? JMarc
Re: [Updated PATCH] accept utf8 in layout files
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Why should we? I am probably missing something but... Abdelrazak isn't it enough to tell to the users that their layout Abdelrazak needs to be converted to utf8? Of course we should say it Abdelrazak big and loud but I reckon that users that are able to Abdelrazak change a layout are also able to change the encoding of Abdelrazak their layout. Especially so if the big goal of 1.5 is Abdelrazak unicode. And then, what about their old .lyx files that contain layouts with latin1 names? Or am I missing something? JMarc
[PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
The reason is that closing a Buffer triggers an update of all opened
dialogs when dispatching LFUN_DIALOG_UPDATE (hence the patch). The path
is as following:
setBuffer() - updateBufferDependent() - RestoreButton() - LFUN
The problem here is that the Toc dialog has not been reconstructed
(because it comes after in the list of dialogs).
This patch should definitely go _before_ 1.5.0; OK?
Abdel.
Index: LyXFunc.cpp
===
--- LyXFunc.cpp (revision 19003)
+++ LyXFunc.cpp (working copy)
@@ -1838,8 +1838,10 @@
}
}
if (!quitting) {
- lyx_view_-updateMenubar();
- lyx_view_-updateToolbars();
+ if (cmd.action != LFUN_DIALOG_UPDATE) {
+ lyx_view_-updateMenubar();
+ lyx_view_-updateToolbars();
+ }
// Some messages may already be translated, so we cannot use _()
sendDispatchMessage(translateIfPossible(getMessage()), cmd);
}
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak The problem here is that the Toc dialog has not been Abdelrazak reconstructed (because it comes after in the list of Abdelrazak dialogs). Abdelrazak This patch should definitely go _before_ 1.5.0; OK? I understand that we need to fix that before 1.5.0 and that this is the easiest route, but in general I'd rather avoid to add explicit tests against LFUNS like this one. (not that I have a better solution at hand...). JMarc
Re: [Updated PATCH] accept utf8 in layout files
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Why should we? I am probably missing something but... Abdelrazak isn't it enough to tell to the users that their layout Abdelrazak needs to be converted to utf8? Of course we should say it Abdelrazak big and loud but I reckon that users that are able to Abdelrazak change a layout are also able to change the encoding of Abdelrazak their layout. Especially so if the big goal of 1.5 is Abdelrazak unicode. And then, what about their old .lyx files that contain layouts with latin1 names? Or am I missing something? As for the layouts, they should also convert their LyX file to utf8. If they can convert their layouts, they can also convert their LyX files. They should do that in any case. For any users (especially users not using latin-1 encoding), I reckon there should be a strong recommendation to convert all their old LyX file to UTF-8. If it is not the announcement, it should be. Abdel.
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak The problem here is that the Toc dialog has not been Abdelrazak reconstructed (because it comes after in the list of Abdelrazak dialogs). Abdelrazak This patch should definitely go _before_ 1.5.0; OK? I understand that we need to fix that before 1.5.0 and that this is the easiest route, but in general I'd rather avoid to add explicit tests against LFUNS like this one. (not that I have a better solution at hand...). I agree and I will offer a better solution after 1.5.0 is out. They are several alternatives at hand but this patch is easiest and the safest for now. Abdel.
Re: 1.5rc2 binary for dapper
On Sun, Jul 08, 2007 at 03:49:34PM +0100, Sam Lewis wrote: Hi Sam, I've moved a 1.5rc2 binary for ubuntu dapper to incoming ftp.lyx.org. Could someone please place in the appropriate folder. Many thanks! I don't like to bother other people with licence issue but there's no diff.gz avaible so that someone can rebuild and/or prove what you did and how you build the package. Maybe I'm a little bit over concerned but if I install a package I'm root and I don't like to give you root on my system. Nothing personal of course. :) Cheers, Sven
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak The problem here is that the Toc dialog has not been
Abdelrazak reconstructed (because it comes after in the list of
Abdelrazak dialogs).
Abdelrazak This patch should definitely go _before_ 1.5.0; OK?
I understand that we need to fix that before 1.5.0 and that this is
the easiest route, but in general I'd rather avoid to add explicit
tests against LFUNS like this one. (not that I have a better solution
at hand...).
Here is an alternative patch. I don't like it because this means that
the Toc dialog will be rebuilt twice. But I'll put it in if you prefer.
Longer term, we probably need to add some new properties to the LFUNs
like the new clearSelection one.
Abdel.
Index: LyXView.cpp
===
--- LyXView.cpp (revision 19003)
+++ LyXView.cpp (working copy)
@@ -163,6 +163,18 @@
connectBuffer(*newBuffer);
+ /* FIXME: Rebuild the Toc dialog before the others even if it
+ will be rebuilt again in the next line. This avoid a crash when
+ other dialogs are rebuilt before the Toc dialog. The reason is
+ that closing a Buffer triggers an update of all opened dialogs
+ when dispatching LFUN_DIALOG_UPDATE (hence the patch).
+ The path is as following:
+ setBuffer() - updateBufferDependent() -
RestoreButton() - LFUN
+
+ The problem here is that the Toc dialog has not been
+ reconstructed (because it comes after in the list of dialogs).
*/
+ updateToc();
+
// Buffer-dependent dialogs should be updated or
// hidden. This should go here because some dialogs (eg ToC)
// require bv_-text.
@@ -462,7 +474,7 @@
}
BOOST_ASSERT(work_area_);
- string const layout = work_area_-bufferView().cursor().
+ docstring const layout = work_area_-bufferView().cursor().
innerParagraph().layout()-name();
if (layout != current_layout) {
Re: 1.5rc2 binary for dapper
Sven == Sven Hoexter [EMAIL PROTECTED] writes: Sven On Sun, Jul 08, 2007 at 03:49:34PM +0100, Sam Lewis wrote: Sven Hi Sam, I've moved a 1.5rc2 binary for ubuntu dapper to incoming ftp.lyx.org. Could someone please place in the appropriate folder. Many thanks! Sven I don't like to bother other people with licence issue but Sven there's no diff.gz avaible so that someone can rebuild and/or Sven prove what you did and how you build the package. Maybe I'm a Sven little bit over concerned but if I install a package I'm root Sven and I don't like to give you root on my system. Nothing personal Sven of course. :) Good point. This stands for all our binary packages actually. Should we do something about it? JMarc
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes
[EMAIL PROTECTED] writes:
Abdelrazak The problem here is that the Toc dialog has not been
Abdelrazak reconstructed (because it comes after in the list of
Abdelrazak dialogs).
Abdelrazak This patch should definitely go _before_ 1.5.0; OK?
I understand that we need to fix that before 1.5.0 and that this is
the easiest route, but in general I'd rather avoid to add explicit
tests against LFUNS like this one. (not that I have a better solution
at hand...).
Here is an alternative patch.
The part below was not meant to be in the patch, please ignore:
@@ -462,7 +474,7 @@
}
BOOST_ASSERT(work_area_);
- string const layout = work_area_-bufferView().cursor().
+ docstring const layout = work_area_-bufferView().cursor().
innerParagraph().layout()-name();
if (layout != current_layout) {
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
On Monday 09 July 2007 13:55:01 Abdelrazak Younes wrote: The part below was not meant to be in the patch, please ignore: If that fixes the bug then OK. -- José Abílio
Re: 1.5rc2 binary for dapper
On Mon, Jul 09, 2007 at 02:56:34PM +0200, Jean-Marc Lasgouttes wrote: Sven == Sven Hoexter [EMAIL PROTECTED] writes: Sven On Sun, Jul 08, 2007 at 03:49:34PM +0100, Sam Lewis wrote: Sven Hi Sam, I've moved a 1.5rc2 binary for ubuntu dapper to incoming ftp.lyx.org. Could someone please place in the appropriate folder. Many thanks! Sven I don't like to bother other people with licence issue but Sven there's no diff.gz avaible so that someone can rebuild and/or Sven prove what you did and how you build the package. Maybe I'm a Sven little bit over concerned but if I install a package I'm root Sven and I don't like to give you root on my system. Nothing personal Sven of course. :) Good point. This stands for all our binary packages actually. Should we do something about it? Well in this case the package was created with checkinstall. That means there are no proper dependency information and no pre-/post- install scriptlets. Still no check if the upstream source has been modified before the build or not. Cheers, Sven
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
José Matos wrote: On Monday 09 July 2007 13:55:01 Abdelrazak Younes wrote: The part below was not meant to be in the patch, please ignore: If that fixes the bug then OK. Which one? The one that add a redundant updateToc() in LyXView or the one that updates the dialogs only if this is not LFUN_UPDATE_DIALOG in LyXFunc? Conceptually speaking, the later is more correct, even if this means a special case in LyXFunc::dispatch(). The first one will only cure the problem with the Toc, maybe other dialog has the very same problem Conclusion: I am recommending the change in LyXFunc. Abdel.
Re: [Patch] Fix Bug 3862: Inconsistency of appendix with child documents
José Matos wrote: On Monday 09 July 2007 09:34:12 Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3862 Attached. Abdel. The patch seems straightforward but this is also the type of bug that can wait for 1.5.1. Hum, you were right to be cautious. This patch only works for my use case where the child document are at the end of the document. I will work on something more general so for get about this patch for now. Abdel.
Re: Towards LyX 1.4.5 [status update #1]
Bo == Bo Peng [EMAIL PROTECTED] writes: Other things? Bo Two easy bugs that are fixed in trunk but not in 1.4.x: Bo http://bugzilla.lyx.org/show_bug.cgi?id=1486 I applied this one. Bo http://bugzilla.lyx.org/show_bug.cgi?id=3363 This one is less problematic, so I skipped it (because things are slightly different in 1.4) JMarc
Re: [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
On 9 jul 2007, at 14.15, Jean-Marc Lasgouttes wrote: Anders == Anders Ekberg [EMAIL PROTECTED] writes: Anders The patch addresses this by excluding all accented characters Anders from the list that revert_unicode processes. In principle this Anders results in that accented characters get properly translated Anders and remaining unicode characters are replaced by ERT or math Anders commands (if they are in the list of characters). What is the different between reverse_unicode and revert accent? Is it just generating ERT versus InsetLaTexAccent? Basically yes (ERT or math inset) In this case, lyx2lyx could look at the generated string and decide what to do? You mean merge the two? That would of course be the best solution, but that requires someone with better knowledge of revert_accent and the LyX-format (and time ;-) than I have. Otherwise I think it would be quite straightforward to merge reverse_unicode. Just read in the unicodesymbols file, keep track of whether you're in an inset (and which) and if you include a math or an ERT. Then get the corresponding replacement string. /Anders
Backward Compatibility.
I use Lyx quite extensively to write most of my letters. Reason is I use LaTeX in my work so it is a nice compliment. However, I found that the last two versions of Lyx could not process any of my older lyx files. The error I get was that something needs to be inserted. DVI files could obviously not be compiled. When I uninstalled the newer version and found an older version to install i could open the file again as normal. In particular, the Tables of the older version could not be processed by the newer version. My problem is that I have hundreds of Letters that I cannot open anymore as the new versions object compiling them. If there is something simple you know of how to fix this, let me know, otherwise I will create a more detailed report. Lventer
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
I think I prefer the LFUN based solution as it is more systematic. But at the same time why keep Cursor::selHandle() if we do that? I tried a little bit but while my patch is pretty straightforward and safe, moving or deleting selHandle seems to be too dangerous to be done right now. Of course, if you know it well, it is another story. Cheers, Bo
Re: Backward Compatibility.
Lventer == [EMAIL PROTECTED] us [EMAIL PROTECTED] writes: Lventer My problem is that I have hundreds of Letters that I cannot Lventer open anymore as the new versions object compiling them. Lventer If there is something simple you know of how to fix this, let Lventer me know, otherwise I will create a more detailed report. Hello, I guess that we will need more details indeed (LyX version, example file, error message). We try hard to maintain backwards compatibility, but bugs happen. JMarc
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Bo == Bo Peng [EMAIL PROTECTED] writes: I think I prefer the LFUN based solution as it is more systematic. But at the same time why keep Cursor::selHandle() if we do that? Bo I tried a little bit but while my patch is pretty straightforward Bo and safe, moving or deleting selHandle seems to be too dangerous Bo to be done right now. Of course, if you know it well, it is Bo another story. Concerning your approach, many things are still missing (IMO of course). For example, self-insert will replace the selection if there is one, so you should save the selection. Tracking all the lfuns where this happens is more complicated IMO than adding a proper call in eraseSelection and cutSelection (patch coming). JMarc
Re: [Patch] Fix Bug 3862: Inconsistency of appendix with child documents
Abdelrazak Younes wrote:
José Matos wrote:
On Monday 09 July 2007 09:34:12 Abdelrazak Younes wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3862
Attached.
Abdel.
The patch seems straightforward but this is also the type of bug that
can wait for 1.5.1.
Hum, you were right to be cautious. This patch only works for my use
case where the child document are at the end of the document. I will
work on something more general so for get about this patch for now.
Here is an updated patch that works on all use cases.
Abdel.
Index: Buffer.cpp
===
--- Buffer.cpp (revision 19003)
+++ Buffer.cpp (working copy)
@@ -196,13 +196,16 @@
/// Container for all sort of Buffer dependant errors.
mapstring, ErrorList errorLists;
+
+ ///
+ Paragraph const * parent_paragraph_;
};
Buffer::Impl::Impl(Buffer parent, FileName const file, bool readonly_)
: lyx_clean(true), bak_clean(true), unnamed(false),
read_only(readonly_),
filename(file), file_fully_loaded(false), inset(params),
- toc_backend(parent)
+ toc_backend(parent), parent_paragraph_(0)
{
inset.setAutoBreakRows(true);
lyxvc.buffer(parent);
@@ -1795,4 +1798,16 @@
}
+Paragraph const * Buffer::parentParagraph() const
+{
+ return pimpl_-parent_paragraph_;
+}
+
+
+void Buffer::setParentParagraph(Paragraph const * parent_paragraph)
+{
+ pimpl_-parent_paragraph_ = parent_paragraph;
+}
+
+
} // namespace lyx
Index: Buffer.h
===
--- Buffer.h(revision 19003)
+++ Buffer.h(working copy)
@@ -258,6 +258,12 @@
*/
Buffer * getMasterBuffer();
+ /// Get the parent paragraph.
+ Paragraph const * parentParagraph() const;
+
+ /// Set the parent paragraph.
+ void setParentParagraph(Paragraph const *);
+
/// Is buffer read-only?
bool isReadonly() const;
Index: buffer_funcs.cpp
===
--- buffer_funcs.cpp(revision 19003)
+++ buffer_funcs.cpp(working copy)
@@ -474,7 +474,12 @@
Layout_ptr const layout = par.layout();
Counters counters = textclass.counters();
- if (it.pit() == 0) {
+ bool const child_in_appendix = buf.parentParagraph()
+buf.parentParagraph()-params().appendix();
+
+ if (child_in_appendix)
+ par.params().appendix(true);
+ else if (it.pit() == 0) {
par.params().appendix(par.params().startOfAppendix());
} else {
par.params().appendix(it.plist()[it.pit() -
1].params().appendix());
@@ -708,6 +713,9 @@
return;
}
+ // Master documents don't have a parent paragraph.
+ const_castBuffer (buf).setParentParagraph(0);
+
// start over the counters
textclass.counters().reset();
}
@@ -737,7 +745,7 @@
for (; iit != end; ++iit) {
if (iit-inset-lyxCode() == Inset::INCLUDE_CODE)
static_castInsetInclude const *(iit-inset)
- -updateLabels(buf);
+ -updateLabels(buf, *it);
}
}
Index: insets/InsetInclude.cpp
===
--- insets/InsetInclude.cpp (revision 19003)
+++ insets/InsetInclude.cpp (working copy)
@@ -30,6 +30,7 @@
#include Lexer.h
#include MetricsInfo.h
#include OutputParams.h
+#include Paragraph.h
#include TocBackend.h
#include frontends/alert.h
@@ -917,12 +918,13 @@
}
-void InsetInclude::updateLabels(Buffer const buffer) const
+void InsetInclude::updateLabels(Buffer const buffer, Paragraph const par)
const
{
- Buffer const * const childbuffer = getChildBuffer(buffer, params_);
+ Buffer * childbuffer = getChildBuffer(buffer, params_);
if (!childbuffer)
return;
+ childbuffer-setParentParagraph(par);
lyx::updateLabels(*childbuffer, true);
}
Index: insets/InsetInclude.h
===
--- insets/InsetInclude.h (revision 19003)
+++ insets/InsetInclude.h (working copy)
@@ -27,6 +27,7 @@
class Buffer;
class Dimension;
class LaTeXFeatures;
+class Paragraph;
class RenderMonitoredPreview;
@@ -97,7 +98,7 @@
///
void addToToc(TocList , Buffer const , ParConstIterator const )
const;
///
- void updateLabels(Buffer const buffer) const;
+ void updateLabels(Buffer const buffer, Paragraph const par) const;
///
bool getStatus(Cursor , FuncRequest const , FuncStatus ) const;
/// if this inset contains lstinputlisting and has a caption,
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Concerning your approach, many things are still missing (IMO of course). For example, self-insert will replace the selection if there is one, so you should save the selection. This is expected, and can be solved easily by adding SaveSelection flag to this LFUN. The advantage of my patch is that I can handle all these cases in a uniform way, in a single file (LyXAction.cpp). Tracking all the lfuns where this happens is more complicated IMO than adding a proper call in eraseSelection and cutSelection (patch coming). I know your point and I am not objecting your patch. I prefer mine when I have to handle DELETE in mathed in a different way than DELETE in text using your approach (IIRC, cutSelection is not called in mathed DELETE cases). Jose, you can decide which way you prefer. Bo
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Bo Peng wrote: I think I prefer the LFUN based solution as it is more systematic. But at the same time why keep Cursor::selHandle() if we do that? I tried a little bit but while my patch is pretty straightforward and safe, moving or deleting selHandle seems to be too dangerous to be done right now. Sure. Of course, if you know it well, it is another story. It seems straight forward to my eyes but this can probably wait for 1.5.1. Abdel.
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Bo Peng wrote: Concerning your approach, many things are still missing (IMO of course). For example, self-insert will replace the selection if there is one, so you should save the selection. This is expected, and can be solved easily by adding SaveSelection flag to this LFUN. The advantage of my patch is that I can handle all these cases in a uniform way, in a single file (LyXAction.cpp). FWIW I agree with Bo. The reason why I like it more is that Bo's approach will allow us to remove some more code (selHandle, etc). Abdel.
Re: Towards LyX 1.4.5 [status update #1]
On Fri, Jul 06, 2007 at 04:31:24PM +0200, Enrico Forestieri wrote:
On Fri, Jul 06, 2007 at 01:23:48PM +0200, Jean-Marc Lasgouttes wrote:
Hello,
Since Jose' plans to release 1.5.0 next week, we'd better be ready
with 1.4.5 too. I append the ANNOUNCE file that I just updated.
Jose', I would appreciate if you could upgrade lyx2lyx in branch to
handle the 1.5 final format.
Other things?
I think that the patch by Peter dealing with duplicate font names
in the system font dir should also be applied to 1.4.5.
Here it is. I verified that with the patch applied one can have fonts
with the same name as the Bakoma ones installed in the system font dir
and yet the latter are used in LyX.
--
Enrico
Index: src/frontends/qt2/qfont_loader.C
===
--- src/frontends/qt2/qfont_loader.C(revision 19013)
+++ src/frontends/qt2/qfont_loader.C(working copy)
@@ -52,7 +52,9 @@ using std::string;
#endif
#ifdef Q_WS_WIN
-#include windows.h
+// Require Windows API Win98 (only needed for AddFontResourceEx)
+#define _WIN32_WINNT 0x0500
+#include windows.h
#include support/os.h
#include support/package.h
#include support/path.h
@@ -100,9 +102,9 @@ void FontLoader::initFontPath()
string const fonts_dir = AddPath(package().system_support(), fonts);
for (int i = 0 ; i num_fonts_truetype ; ++i) {
- string const font_current =
- AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
- AddFontResource(os::external_path(font_current).c_str());
+ string const font_current = os::external_path(
+ AddName(fonts_dir, win_fonts_truetype[i] + .ttf));
+ AddFontResourceEx(font_current.c_str(), FR_PRIVATE, 0);
}
#endif
}
@@ -113,9 +115,9 @@ FontLoader::~FontLoader() {
string const fonts_dir = AddPath(package().system_support(), fonts);
for(int i = 0 ; i num_fonts_truetype ; ++i) {
- string const font_current =
- AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
- RemoveFontResource(os::external_path(font_current).c_str());
+ string const font_current = os::external_path(
+ AddName(fonts_dir, win_fonts_truetype[i] + .ttf));
+ RemoveFontResourceEx(font_current.c_str(), FR_PRIVATE, 0);
}
#endif
}
Re: Need for better dialogs
Mael Hilléreau wrote: To Richard: please, don't forget the list in your reply ;-) I was out of town and using an unfamiliar system Le 6 juil. 07 à 23:17, [EMAIL PROTECTED] a écrit : There are going to be many of dialogs that behave like this one. AFAIU, precisely all dialogs whose controller has a method virtual bool isBufferDependent() const returning true. You can find them in all src/frontends/controllers/ ControlXXX.h source files. BTW, there seems to be an rc1/rc2 bug for some of them (e.g. graphics dialog don't hide anymore when switching buffer, whereas it did in 1.4.4). Please could you confirm? This was changed a while ago: Buffer dependent dialogs are not automatically closed when switching buffers any longer. There was a bug report about this, in particular, concerning the TOC/outline. Does automatically means for every class of dialog? Yes. Previously, any dialog whose isBufferDependent() method returned true would be closed on buffer switch. But I'm now convinced that most of these dialogs should remain hidden when another buffer is displayed. Indeed, it is senseless (despite respecting the don't close without prompt UI guideline) to keep on screen e.g. a graphics dialog when switching to another buffer (unrelated info). Right, but what this means, it seems to me, is that the isBufferDependent() function was being double-used. To be buffer dependent, in the intended sense, is to make no sense absent a buffer. That is different from being dependent upon the specific buffer displayed. Then I can confirm. There's a problem related to the use of isBufferDependent(). Into LyXView.cpp (line 168), you have this function call: // Buffer-dependent dialogs should be updated or // hidden. This should go here because some dialogs (eg ToC) // require bv_-text. getDialogs().updateBufferDependent(true); Then, if you go to Dialogs.cpp, Dialogs::updateBufferDependent() (line 214), you can see that isBufferDependent() leads to hiding buffer dependent dialogs (assuming that dialog-controller().initialiseParams() will always return false, which is the case for log dialogs). I checked that if you modify isBufferDependent() for LaTeX logs (hence into ControlLog.h) so that it returns true when belonging to a LaTeX log dialog, then it is no more hidden when switching buffer (but this isn't sufficient because there are update issues to deal with...). Yes, this is all related to the update issue. The call to ControlLog::initialiseParams() is supposed to pass (a) the name of the logfile type and (b) the name of the logfile. We're supposed to return false if there's some error in the parsing of this information. The call you mention passes no data at all, so the parsing fails, and we return false. To do a proper update, you'd have to have that information lying around somewhere. I'm curious to know how one should specify that a buffer dependent dialog has to hide/keep displayed when switching to another buffer. At present, there is no way to do this. Perhaps a new hideOnSwitch() virtual method is needed. A more general solution, perhaps, would be to add a new onSwitch() virtual method, which would allow the dialog to do whatever it wished when the buffer was switched. Perhaps it would hide itself; perhaps it would clear itself; perhaps it would try to update itself. This could be called before the update(). As for the graphics dialog, a question: If you click away from the graphics inset to which the dialog is attached, what happens? The dialog remains as is if you stay into the same buffer. It is emptied if you switch to another buffer. But in the latter case I think we have a bug: despite the dialog is emptied, if you modify some parameters and click the Apply button, then parameters are always linked (and so applied) to the graphics inset. IMO, this is really unadapted! Yes, that would be a bug. This should probably return true for hideOnSwitch(), or do something sensible in onSwitch(). What should happen? In my vision, this shouldn't be possible for dialogs such as graphics (modal dialogs). You'd have to close the dialog before. This would avoid undesired effects (e.g. modify some graphic parameters whereas the preview is no more visible due to scrolling, or buffer switching...). The addition of a hideOnSwitch() method would deal with this problem, while allowing you to do this: change the graphics parameters for one inset; then (in the same document), click another graphics dialog and make changes there, without having to close and re-open the dialog. But there are issues about update that led to the paragraph settings dialog becoming modal. Abdel is working on this. The intention is for it to become non-modal again, once he's got it sorted out. Well I can't see why. If you want to apply the same settings to several paragraphs, you could select them all, and then apply settings, no? The idea was that maybe you are making different changes in different
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Bo == Bo Peng [EMAIL PROTECTED] writes:
Concerning your approach, many things are still missing (IMO of
course). For example, self-insert will replace the selection if
there is one, so you should save the selection.
Bo This is expected, and can be solved easily by adding SaveSelection
Bo flag to this LFUN. The advantage of my patch is that I can handle
Bo all these cases in a uniform way, in a single file
Bo (LyXAction.cpp).
OTOH, in my approach I try to put the calls at the place where the
selection is actually lost, which makes the code simpler to
understand. (and shall I say shorter?)
BTW, the entries for paragraph-move-up/down seem bogus to me (isn't it
disabled when there is a selection)?
Tracking all the lfuns where this happens is more complicated IMO
than adding a proper call in eraseSelection and cutSelection (patch
coming).
Here is what I came up with. Note that now saveSelection does its job
only if cursor is actually bv.cursor() (to make Abdel happy).
The changes in Text3.cpp should go in anyway, I think. The
semantics of the LFUNS with a selection was bad.
The only known issue now is that I do not handle BUFFER_SWITCH. It is
not that I cannot add one line in an LFUN, but I'd like first to
understand what the policy is: can we have several selections active
different bufferviews? AFAIK, Bo's code does not work with multiple
windows (where no buffer-switch happens). Therefore the solution has
to be different.
As you said, it is up to Jose' to decide.
JMarc
Index: src/BufferView.cpp
===
--- src/BufferView.cpp (révision 19007)
+++ src/BufferView.cpp (copie de travail)
@@ -1347,6 +1347,10 @@ bool BufferView::mouseSetCursor(Cursor
{
BOOST_ASSERT(cur.bv() == this);
+// this event will clear selection so we save selection for
+ // persistent selection
+ cap::saveSelection(cursor());
+
// Has the cursor just left the inset?
bool badcursor = false;
bool leftinset = (cursor_.inset() != cur.inset());
Index: src/CutAndPaste.cpp
===
--- src/CutAndPaste.cpp (révision 19007)
+++ src/CutAndPaste.cpp (copie de travail)
@@ -18,6 +18,7 @@
#include Buffer.h
#include buffer_funcs.h
#include BufferParams.h
+#include BufferView.h
#include Cursor.h
#include debug.h
#include ErrorList.h
@@ -524,6 +525,8 @@ void cutSelection(Cursor cur, bool doc
Text * text = cur.text();
BOOST_ASSERT(text);
+ saveSelection(cur);
+
// make sure that the depth behind the selection are restored, too
recordUndoSelection(cur);
pit_type begpit = cur.selBegin().pit();
@@ -674,7 +677,9 @@ void saveSelection(Cursor cur)
// This function is called, not when a selection is formed, but when
// a selection is cleared. Therefore, multiple keyboard selection
// will not repeatively trigger this function (bug 3877).
- if (cur.selection()) {
+ if (cur.selection()
+ cur.selBegin() == cur.bv().cursor().selBegin()
+ cur.selEnd() == cur.bv().cursor().selEnd()) {
LYXERR(Debug::ACTION) BOOST_CURRENT_FUNCTION : `
to_utf8(cur.selectionAsString(true)) '.
endl;
@@ -830,6 +835,7 @@ void eraseSelection(Cursor cur)
CursorSlice const i1 = cur.selBegin();
CursorSlice const i2 = cur.selEnd();
if (i1.inset().asInsetMath()) {
+ saveSelection(cur);
cur.top() = i1;
if (i1.idx() == i2.idx()) {
i1.cell().erase(i1.pos(), i2.pos());
@@ -850,7 +856,6 @@ void eraseSelection(Cursor cur)
}
// need a valid cursor. (Lgb)
cur.clearSelection();
- theSelection().haveSelection(false);
} else {
lyxerr can't erase this selection 1 endl;
}
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (révision 19007)
+++ src/Cursor.cpp (copie de travail)
@@ -588,9 +588,11 @@ bool Cursor::selHandle(bool sel)
if (sel == selection())
return false;
+ if (!sel)
+ cap::saveSelection(*this);
+
resetAnchor();
selection() = sel;
- cap::saveSelection(*this);
return true;
}
Index: src/Text3.cpp
===
--- src/Text3.cpp (révision 19007)
+++ src/Text3.cpp (copie de travail)
@@ -436,20 +436,26 @@ void Text::dispatch(Cursor cur, FuncRe
}
case LFUN_WORD_DELETE_FORWARD:
- cur.clearSelection();
- deleteWordForward(cur);
+ if (cur.selection()) {
+ cutSelection(cur, true, false);
+ } else
+ deleteWordForward(cur);
finishChange(cur, false);
break;
case LFUN_WORD_DELETE_BACKWARD:
- cur.clearSelection();
- deleteWordBackward(cur);
+ if (cur.selection()) {
+ cutSelection(cur, true, false);
+ } else
+ deleteWordBackward(cur);
finishChange(cur, false);
break;
case LFUN_LINE_DELETE:
- cur.clearSelection();
- deleteLineForward(cur);
+ if (cur.selection()) {
+ cutSelection(cur, true, false);
+ } else
+ deleteLineForward(cur);
finishChange(cur, false);
break;
Re: [Patch] Fix Bug 3862: Inconsistency of appendix with child documents
On Monday 09 July 2007 16:03:50 Abdelrazak Younes wrote: Here is an updated patch that works on all use cases. Abdel. Please target this for 1.5.1. :-) -- José Abílio
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak FWIW I agree with Bo. The reason why I like it more is Abdelrazak that Bo's approach will allow us to remove some more code Abdelrazak (selHandle, etc). I am not 100% sure with that. In particular, one thing I would have liked to do is merge things like char-forward and char-forward-select into one lfun taking an argument (like select). The flag approach would be problematic there. Also, something that is kind of broken right now, but would be nice to fix is the persistent mark (a command that puts you in selection mode and then keyboard extends selection). Again, this would be difficult with the flag approach. Actually, the strong point of the flag approach (all the information is in one file) is also its weak spot: when changing the behaviour of a lfun, it is very easy to forget to set/remove the SaveSelection flag. JMarc
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
On Monday 09 July 2007 14:21:58 Abdelrazak Younes wrote: Which one? The one that add a redundant updateToc() in LyXView or the one that updates the dialogs only if this is not LFUN_UPDATE_DIALOG in LyXFunc? Conceptually speaking, the later is more correct, even if this means a special case in LyXFunc::dispatch(). The first one will only cure the problem with the Toc, maybe other dialog has the very same problem Then when we find the bug we fix it the same way. ;-) Conclusion: I am recommending the change in LyXFunc. I am more comfortable with the later solution (the redundant TOC). We can fix this properly for 1.6. Abdel. -- José Abílio
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Jean-Marc Lasgouttes wrote:
Bo == Bo Peng [EMAIL PROTECTED] writes:
Concerning your approach, many things are still missing (IMO of
course). For example, self-insert will replace the selection if
there is one, so you should save the selection.
Bo This is expected, and can be solved easily by adding SaveSelection
Bo flag to this LFUN. The advantage of my patch is that I can handle
Bo all these cases in a uniform way, in a single file
Bo (LyXAction.cpp).
OTOH, in my approach I try to put the calls at the place where the
selection is actually lost, which makes the code simpler to
understand. (and shall I say shorter?)
The patch is shorter yes but I don't think the final code will be shorter.
Here is what I came up with. Note that now saveSelection does its job
only if cursor is actually bv.cursor() (to make Abdel happy).
Why don't you just passed cur.bv().cursor()?
if (cur.selection()) {
LYXERR(Debug::ACTION) BOOST_CURRENT_FUNCTION : `
to_utf8(cur.selectionAsString(true)) '.
endl;
copySelectionToStack(cur.bv().cursor(), selectionBuffer);
}
The changes in Text3.cpp should go in anyway, I think. The
semantics of the LFUNS with a selection was bad.
Yes.
The only known issue now is that I do not handle BUFFER_SWITCH. It is
not that I cannot add one line in an LFUN, but I'd like first to
understand what the policy is: can we have several selections active
different bufferviews?
Yes. Each BufferView has its own cursor and thus its own selection. The
only reason why a BufferView selection could be cleared externally is if
we aknowledge the ClearSelection command from X11, which we don't.
AFAIK, Bo's code does not work with multiple
windows (where no buffer-switch happens).
Why is that? IIRC he saves the selection in LyXFunc::setLyXView().
Abdel.
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak FWIW I agree with Bo. The reason why I like it more is Abdelrazak that Bo's approach will allow us to remove some more code Abdelrazak (selHandle, etc). I am not 100% sure with that. I was talking about the removal of the lines of type: needsUpdate |= cur.selHandle(cmd.action == LFUN_BUFFER_BEGIN_SELECT); but maybe your patch can lead to that do. In particular, one thing I would have liked to do is merge things like char-forward and char-forward-select into one lfun taking an argument (like select). The flag approach would be problematic there. I don't think so: we can augment Bo's patch in Text3.cpp like this: + // if this LFUN will clear selection, saveSelection for persistent + // selection + if (lyxaction.funcHasFlag(cmd.action, LyXAction::SaveSelection) +cmd.argument() != select) + saveSelection(cur.bv().cursor()); + Also, something that is kind of broken right now, but would be nice to fix is the persistent mark (a command that puts you in selection mode and then keyboard extends selection). Again, this would be difficult with the flag approach. The same solution as above would be fine I think. Actually, the strong point of the flag approach (all the information is in one file) is also its weak spot: when changing the behaviour of a lfun, it is very easy to forget to set/remove the SaveSelection flag. The same can be said about specific code in LFUNs. Abdel.
Re: [PATCH] Fix crash when closing a child document when outline and Pref dialogs are opened
José Matos wrote: On Monday 09 July 2007 14:21:58 Abdelrazak Younes wrote: Which one? The one that add a redundant updateToc() in LyXView or the one that updates the dialogs only if this is not LFUN_UPDATE_DIALOG in LyXFunc? Conceptually speaking, the later is more correct, even if this means a special case in LyXFunc::dispatch(). The first one will only cure the problem with the Toc, maybe other dialog has the very same problem Then when we find the bug we fix it the same way. ;-) Conclusion: I am recommending the change in LyXFunc. I am more comfortable with the later solution (the redundant TOC). I don't understand why it looks any safer but anyway, I've committed it. We can fix this properly for 1.6. The proper fix would be to get rid of the restoreButton() call in Dialogs::updateBufferDependant() but I didn't dare to do it now. Abdel.
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak The patch is shorter yes but I don't think the final code
Abdelrazak will be shorter.
No, but it is less complex IMO.
Here is what I came up with. Note that now saveSelection does its
job only if cursor is actually bv.cursor() (to make Abdel happy).
Abdelrazak Why don't you just passed cur.bv().cursor()?
The code says: I do something at 'cur', and saveselection looks
whether that matters. This seems more robust to me.
AFAIK, Bo's code does not work with multiple windows (where no
buffer-switch happens).
Abdelrazak Why is that? IIRC he saves the selection in
Abdelrazak LyXFunc::setLyXView().
I stand corrected (and the code is already in).
The following version of my patch saves selection in
BufferView::setBuffer, thus handling buffer-switch. But since I look
where stuff really happens, this handle the case of
buffer-next/previous (ctrl-page up/down), which Bo missed. Besides the
fact that adding the SaveSelection flag is easy, I guess you can see
why this is error prone...
Also, I removed a saveSelection in BufferView::putSelectionAt. I think
it is a remnant of the old code.
JMarc
PS: concerning Bo's patch, I _think_ it should be possible to put the
test for clearselection in LyXFunc::dispatch, instead of copying it in
3 different places.
Index: src/BufferView.cpp
===
--- src/BufferView.cpp (révision 19007)
+++ src/BufferView.cpp (copie de travail)
@@ -149,6 +149,8 @@ void BufferView::setBuffer(Buffer * b)
[ b = b ] endl;
if (buffer_) {
+ // Save the current selection if any
+ cap::saveSelection(cursor_);
// Save the actual cursor position and anchor inside the
// buffer so that it can be restored in case we rechange
// to this buffer later on.
@@ -1347,6 +1349,10 @@ bool BufferView::mouseSetCursor(Cursor
{
BOOST_ASSERT(cur.bv() == this);
+// this event will clear selection so we save selection for
+ // persistent selection
+ cap::saveSelection(cursor());
+
// Has the cursor just left the inset?
bool badcursor = false;
bool leftinset = (cursor_.inset() != cur.inset());
@@ -1399,7 +1405,6 @@ void BufferView::putSelectionAt(DocItera
cursor_.setSelection(cursor_, -length);
} else
cursor_.setSelection(cursor_, length);
- cap::saveSelection(cursor_);
}
}
Index: src/CutAndPaste.cpp
===
--- src/CutAndPaste.cpp (révision 19007)
+++ src/CutAndPaste.cpp (copie de travail)
@@ -18,6 +18,7 @@
#include Buffer.h
#include buffer_funcs.h
#include BufferParams.h
+#include BufferView.h
#include Cursor.h
#include debug.h
#include ErrorList.h
@@ -524,6 +525,8 @@ void cutSelection(Cursor cur, bool doc
Text * text = cur.text();
BOOST_ASSERT(text);
+ saveSelection(cur);
+
// make sure that the depth behind the selection are restored, too
recordUndoSelection(cur);
pit_type begpit = cur.selBegin().pit();
@@ -674,7 +677,9 @@ void saveSelection(Cursor cur)
// This function is called, not when a selection is formed, but when
// a selection is cleared. Therefore, multiple keyboard selection
// will not repeatively trigger this function (bug 3877).
- if (cur.selection()) {
+ if (cur.selection()
+ cur.selBegin() == cur.bv().cursor().selBegin()
+ cur.selEnd() == cur.bv().cursor().selEnd()) {
LYXERR(Debug::ACTION) BOOST_CURRENT_FUNCTION : `
to_utf8(cur.selectionAsString(true)) '.
endl;
@@ -830,6 +835,7 @@ void eraseSelection(Cursor cur)
CursorSlice const i1 = cur.selBegin();
CursorSlice const i2 = cur.selEnd();
if (i1.inset().asInsetMath()) {
+ saveSelection(cur);
cur.top() = i1;
if (i1.idx() == i2.idx()) {
i1.cell().erase(i1.pos(), i2.pos());
@@ -850,7 +856,6 @@ void eraseSelection(Cursor cur)
}
// need a valid cursor. (Lgb)
cur.clearSelection();
- theSelection().haveSelection(false);
} else {
lyxerr can't erase this selection 1 endl;
}
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (révision 19007)
+++ src/Cursor.cpp (copie de travail)
@@ -588,9 +588,11 @@ bool Cursor::selHandle(bool sel)
if (sel == selection())
return false;
+ if (!sel)
+ cap::saveSelection(*this);
+
resetAnchor();
selection() = sel;
- cap::saveSelection(*this);
return true;
}
Index: src/Text3.cpp
===
--- src/Text3.cpp (révision 19007)
+++ src/Text3.cpp (copie de travail)
@@ -436,20 +436,26 @@ void Text::dispatch(Cursor cur, FuncRe
}
case LFUN_WORD_DELETE_FORWARD:
- cur.clearSelection();
- deleteWordForward(cur);
+ if (cur.selection()) {
+ cutSelection(cur, true, false);
+ } else
+ deleteWordForward(cur);
finishChange(cur, false);
break;
case LFUN_WORD_DELETE_BACKWARD:
- cur.clearSelection();
- deleteWordBackward(cur);
+ if
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I don't think so: we can augment Bo's patch in Text3.cpp Abdelrazak like this: Abdelrazak + // if this LFUN will clear selection, saveSelection for Abdelrazak persistent + // selection + if Abdelrazak (lyxaction.funcHasFlag(cmd.action, Abdelrazak LyXAction::SaveSelection) + cmd.argument() != select) Abdelrazak + saveSelection(cur.bv().cursor()); Abdelrazak + This is not an option IMO. The select argument may mean something else for other functions (like self-insert select if such a thing makes sense?) Actually, the strong point of the flag approach (all the information is in one file) is also its weak spot: when changing the behaviour of a lfun, it is very easy to forget to set/remove the SaveSelection flag. Abdelrazak The same can be said about specific code in LFUNs. Except that the specific code is at the same place as the main lfun code, and one has to see it when following the code path. This is important for people who do not know the code very well. JMarc
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak FWIW I agree with Bo. The reason why I like it more is Abdelrazak that Bo's approach will allow us to remove some more code Abdelrazak (selHandle, etc). I am not 100% sure with that. Abdelrazak I was talking about the removal of the lines of type: Abdelrazak needsUpdate |= cur.selHandle(cmd.action == Abdelrazak LFUN_BUFFER_BEGIN_SELECT); Abdelrazak but maybe your patch can lead to that do. No, I meant that I am not 100% sure that we can remove these lines (or only at the price of adding too many flags). JMarc
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
this handle the case of buffer-next/previous (ctrl-page up/down), which Bo missed. Besides the fact that adding the SaveSelection flag is easy, I guess you can see why this is error prone... I admit that I did not go through the LFUN carefully. I planned to do so after my approach is agreed upon. After all, it needs some time to see whether or not a LFUN needs this flag, and we have a bunch of LFUNs. Jose, if you can not decide, just toss a coin. IMO, both approaches are good enough. :-) Bo
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I don't think so: we can augment Bo's patch in Text3.cpp Abdelrazak like this: Abdelrazak + // if this LFUN will clear selection, saveSelection for Abdelrazak persistent + // selection + if Abdelrazak (lyxaction.funcHasFlag(cmd.action, Abdelrazak LyXAction::SaveSelection) + cmd.argument() != select) Abdelrazak + saveSelection(cur.bv().cursor()); Abdelrazak + This is not an option IMO. The select argument may mean something else for other functions This is a bit far-fetched... (like self-insert select if such a thing makes sense?) ?? Actually, the strong point of the flag approach (all the information is in one file) is also its weak spot: when changing the behaviour of a lfun, it is very easy to forget to set/remove the SaveSelection flag. Abdelrazak The same can be said about specific code in LFUNs. Except that the specific code is at the same place as the main lfun code, and one has to see it when following the code path. This is important for people who do not know the code very well. And then people who do not know the code very well will not notice that the selection was already saved somewhere else and put a saveSelection(), just in case... It's a bit like the toolbars and dialogs which are updated multiple times for a single action... The situation is a bit better now there are things that are done multiple times for nothing in LyX. Anyway, both solutions are fine with me at this point. Abdel.
Re: Windows 98 / Me support?
Joost Verburg wrote:
LyX 1.5 almost works on Windows 98/Me. I can create, open and save
documents and do all the normal work. There is however one major bug
that makes it useless: The second time LyX is started (when no
configuration needs to be done anymore) it just crashes on startup! When
I remove the configuration data and start LyX again, everything works
just fine.
I've finally been able to solve the problem. It turned out to be a bug
in recent versions of the boost filesystem library.
I suggest to apply this patch and upload the patch itself to the
development directory.
OK?
Joost
Index: libs/filesystem/src/operations.cpp
===
--- libs/filesystem/src/operations.cpp (revision 19015)
+++ libs/filesystem/src/operations.cpp (working copy)
@@ -254,7 +254,7 @@
create_file(
ph1.c_str(),
0,
- FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE,
+ FILE_SHARE_READ | FILE_SHARE_WRITE,
0,
OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS,
@@ -266,7 +266,7 @@
create_file(
ph2.c_str(),
0,
- FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE,
+ FILE_SHARE_READ | FILE_SHARE_WRITE,
0,
OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS,
@@ -409,7 +409,7 @@
{
handle_wrapper hw(
create_file( ph.c_str(), 0,
-FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
+FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0 ) );
if ( hw.handle == INVALID_HANDLE_VALUE )
return ::GetLastError();
@@ -423,7 +423,7 @@
{
handle_wrapper hw(
create_file( ph.c_str(), FILE_WRITE_ATTRIBUTES,
-FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
+FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0 ) );
if ( hw.handle == INVALID_HANDLE_VALUE )
return ::GetLastError();
Re: [patch] Re: RTL justification bug
José Matos wrote: On Monday 09 July 2007 09:50:27 Abdelrazak Younes wrote: I guess the problem is that nobody understands this bidi stuff like you do. I would tend to say go ahead!, but I am not sure what are my credentials to do so :) Same position for me. The patch looks not so complicate so I'd say go ahead too. As this is a display thing, we'll notice soon enough if something is wrong. Abdel. I agree with Jean-Marc and Abdel so you have my OK. Thanks, all! Committed as http://www.lyx.org/trac/changeset/19016. I closed bug 3889, and opened a new one, http://bugzilla.lyx.org/show_bug.cgi?id=3997, reporting a minor problem which is exposed by this fix (as explained when the patch was first submitted). Dov
Re: Towards LyX 1.4.5 [status update #1]
Enrico Forestieri wrote: Here it is. I verified that with the patch applied one can have fonts with the same name as the Bakoma ones installed in the system font dir and yet the latter are used in LyX. I just made LyX 1.5 support Windows 98/Me, so this patch needs to be changed to work on Windows versions without support for AddFontResourceEx. Joost
Arrival/departure dates for Bromarv?
I'm trying to plan my vacation trip just before Bromarv, as well as the trip to Bromarv. It'd be nice to know what times people are planning to be there? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Towards LyX 1.4.5 [status update #1]
On Mon, Jul 09, 2007 at 07:34:03PM +0200, Joost Verburg wrote: Enrico Forestieri wrote: Here it is. I verified that with the patch applied one can have fonts with the same name as the Bakoma ones installed in the system font dir and yet the latter are used in LyX. I just made LyX 1.5 support Windows 98/Me, so this patch needs to be changed to work on Windows versions without support for AddFontResourceEx. This is a patch for LyX 1.4.5, which already doesn't run on Win98... -- Enrico
Re: Towards LyX 1.4.5 [status update #1]
Enrico Forestieri wrote: This is a patch for LyX 1.4.5, which already doesn't run on Win98... That's correct. So this should probably go in 1.4.5 even if the 1.5 version is not ready yet. Joost
Re: [PATCH] Translation problem in paragraph dialog
Abdelrazak Younes schrieb: While I agree that your patch is good and clean (thus you have my OK), I don't understand why qt_() does not work. Do you? Because the label to be translated does not appear in the po files. I will commit in a minute... Michael
Re: [PATCH] Fix bug 3992: Screen update problem in change tracking mode
Abdelrazak Younes schrieb: I committed a better version with some comments: Thanks a lot! Michael
Re: Windows 98 / Me support?
On Mon, Jul 09, 2007 at 07:25:09PM +0200, Joost Verburg wrote: Joost Verburg wrote: LyX 1.5 almost works on Windows 98/Me. I can create, open and save documents and do all the normal work. There is however one major bug that makes it useless: The second time LyX is started (when no configuration needs to be done anymore) it just crashes on startup! When I remove the configuration data and start LyX again, everything works just fine. I've finally been able to solve the problem. It turned out to be a bug in recent versions of the boost filesystem library. obvious suggestion inserted here Andre'
Re: Windows 98 / Me support?
Andre Poenitz wrote: I've finally been able to solve the problem. It turned out to be a bug in recent versions of the boost filesystem library. obvious suggestion inserted here You mean that it should be reported to the boost developers? Sure, but as long as this boost version is included with LyX, it needs a temporary patch. Joost
Re: Windows 98 / Me support?
On Mon, Jul 09, 2007 at 09:23:48PM +0200, Joost Verburg wrote: Andre Poenitz wrote: I've finally been able to solve the problem. It turned out to be a bug in recent versions of the boost filesystem library. obvious suggestion inserted here You mean that it should be reported to the boost developers? No... rather an obvious replacement that's e.g. known to work with Chinese Windows or such... Andre'
Re: Windows 98 / Me support?
Andre Poenitz wrote: No... rather an obvious replacement that's e.g. known to work with Chinese Windows or such... FILE_SHARE_DELETE is a sharing mode supported by Windows 2000 and later. This boost library uses it in the part of the code that is supposed to work on older Windows versions. That's why it needs to be removed. You won't notice the difference anyway because the file handles are closed immediately. Joost
