Re: Towards LyX 1.4.5 [status update #1]
On Mon, Jul 09, 2007 at 10:48:32PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> Here it is. I verified that with the patch applied one can > Enrico> have fonts with the same name as the Bakoma ones installed in > Enrico> the system font dir and yet the latter are used in LyX. > > I'll apply it tomorrow (is there a bug number?) Bug 3962. > Note that the call to RemoveFontResourceEx is probably not necessary: > > FR_PRIVATESpecifies that only the process that called the > AddFontResourceEx function can use this font. When the font name > matches a public font, the private font will be chosen. When the > process terminates, the system will remove all fonts installed by the > process with the AddFontResourceEx function. Nevertheless, I think that it is a good policy to cleanup by ourselves, unless you want to get rid of the destructor. -- Enrico
Re: issues with change tracking
José Matos schrieb: The patch seems reasonable as far as I can see. :-) If Edwin confirms that it works it can go in. IIRC Edwin went on vacation. Therefore, someone else should have a look at the patch (from a technical and an operational perspective). This is very nasty bug and I am surprised that nobody else (including myself) stumbled over it before... 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). :-) I know, I know Edwin's problem report was around for a couple of days but I did not manage to address it before yesterday :-( Michael
Re: [PATCH] Bug 3764: Implicit \author field in .lyx files
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: Michael> Jean-Marc Lasgouttes schrieb: >> 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. >> Committed as Michael> http://www.lyx.org/trac/changeset/19019 Thanks. JMarc
Re: [PATCH] Bug 3764: Implicit \author field in .lyx files
Jean-Marc Lasgouttes schrieb: 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. Committed as http://www.lyx.org/trac/changeset/19019 Michael
Re: Towards LyX 1.4.5 [status update #1]
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Here it is. I verified that with the patch applied one can Enrico> have fonts with the same name as the Bakoma ones installed in Enrico> the system font dir and yet the latter are used in LyX. I'll apply it tomorrow (is there a bug number?) Note that the call to RemoveFontResourceEx is probably not necessary: FR_PRIVATE Specifies that only the process that called the AddFontResourceEx function can use this font. When the font name matches a public font, the private font will be chosen. When the process terminates, the system will remove all fonts installed by the process with the AddFontResourceEx function. JMarc
Re: [PATCH] Toolbars
Jean-Marc Lasgouttes schrieb: "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. Committed in revision r19018. Michael
Re: [patch] bug 1820 --- footnotes in different language
Dov Feldstern wrote:
Dov Feldstern wrote:
are attached in bugzilla (though I'm having trouble downloading
attachments from bugzilla, at the moment, anyone know anything about
this?)
Dov
I was able to download the attachments from bugzilla now, and I see
there's one case which still isn't solved. I'll try to take a look at it
sometime, but this patch is still better than the current situation...
Dov
Okay, the remaining unsolved case turned out to be due to a rather
different issue. I've tracked it down and fixed it with the attached
patch, believe it or not...
So, to sum up: the patch attached at
http://permalink.gmane.org/gmane.editors.lyx.devel/89376 together with
the patch attached here solve bug 1820 completely. I can't say that I
like these patches (especially the new one) very much --- but then
again, the entire latex output code with respect to the font / language
/ encoding transitions leaves a lot to be desired. I think it's just
that our current code doesn't map very well to how these transitions are
actually handled by latex (i.e., when such a change is pushed onto or
popped off the stack by the closing of a command / environment). So for
now, at least, I think we'll have to stick with patches such as this...?
I'd be interested in hearing comments; and if possible, it would be nice
if this could go into 1.5.0, though again, I realize that it may be too
risky... If everyone could just try applying this and see that it
doesn't hurt anything, and especially by trying it out with complex
documents (in terms of encodings / language transitions), we could get
an idea of whether or not this introduces any problems.
Thanks!
Dov
Index: src/insets/InsetFootlike.h
===
--- src/insets/InsetFootlike.h (revision 19014)
+++ src/insets/InsetFootlike.h (working copy)
@@ -37,7 +37,7 @@
/** returns true if, when outputing LaTeX, font changes should
be closed before generating this inset. This is needed for
insets that may contain several paragraphs */
- bool noFontChange() const { return true; }
+ bool noFontChange() const { return false; }
};
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
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. > > > > > > 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: I've finally been able to solve the problem. It turned out to be a bug in recent versions of the boost filesystem library. 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 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. Andre'
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: [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: 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: 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
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]
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
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: 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: [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: [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
> "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
> "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> 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 LFU
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
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: [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: [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
> "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 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
> "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
+ de
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
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
#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: [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: [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
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: [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.
map 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_cast(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_cast(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
> "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: 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
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
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: [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
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] 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: [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: 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
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: [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: 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
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
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...). 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: [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
> "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
[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: [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
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: 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: [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.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
> "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: 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: 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 +
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
> 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: 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
> "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: [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: 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 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: [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: 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 christian>LyX 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: christian>LyX 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 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: [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 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 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] Toolbars
On Monday 09 July 2007 11:07:28 Jean-Marc Lasgouttes wrote: > OK, go ahead. +1 > JMarc -- José Abílio
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: 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] 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: [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] 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: 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] 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: [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
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] 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: 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: [Cvslog] r18992 - /lyx-devel/trunk/src/frontends/controllers/front...
Michael Gerz wrote: > OK, I did it for you... thanks to you both. 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::signal layoutChanged;
+ boost::signal 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()));
+ item-
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
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
[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: [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.
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
[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] 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.
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: 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=1626&action=view to bug 3141). -- Jean-Pierre
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
