Re: [PATCH] Bug 3770: configure needs modification to be run on FreeBSD
José == José Matos [EMAIL PROTECTED] writes: José On Tuesday 29 May 2007 15:32:12 Jean-Marc Lasgouttes wrote: Jose, OK? José OK. Done. JMarc
Re: Converter problem with Mac OS packages
Andre Poenitz wrote: On Tue, May 29, 2007 at 12:17:04PM +0200, Jean-Marc Lasgouttes wrote: Mael == Mael Hilléreau [EMAIL PROTECTED] writes: Mael Le 27 mai 07 à 00:55, Mael Hilléreau a écrit : According to Apple's Bundle Programming Guide, The Finder identifies packages by any of the following mechanisms: * The directory has a known extension: .app, .bundle, .framework, .plugin, .kext, and so on. * The directory has its bundle bit set. * The directory has a known structure type indicating it is a modern or versioned bundle. As a conclusion, as it is really not easy to distinguish between folders, applications, ..., and packages corresponding to graphics (such as '.graffle' files), I would suggest to replace the function call by a different one, and to consider folders having an extension to be valid files (only for Mac OS of course...). In the case the chosen package isn't supported (i.e. it is a folder or anything else but supported graphics), LyX won't crash because the file format won't be recognized. I think it would be better to real OSX code to determine whether a directory is a bundle (maybe CFBundleCreate?). QFileInfo::isBundle(). Unfortunately only since 4.3, i.e. today or so ;-} It was decided that the Mac port will ship with Qt4.3 IIRC. So a solution with an #ifdef is OK. Abdel.
Re: [patch] cursor misplaced after a linebreak, #2475
Stefan Schimanski wrote: Abdel, is it ok? Dov tested it with my other patch already. Everything looks fine ok. Need another OK then. I've tested it yesterday and it was OK so OK :-) Abdel.
Re: Putting Rtl content in Insets
Jean-Marc Lasgouttes wrote: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | I prefer No document open! Lars Sounds strange. Is that even english? Lars I thought that 'No' usually required plural (unless you want to Lars give it a different meaning.) I do not know... So where are the native English speakers? I am almost sure that No opened document! is English ;-) So is No open document! I think. Abdel.
Re: Parenthesis and RTL
Mostafa Vahedi wrote:
Dov Feldstern [EMAIL PROTECTED] wrote:
When testing Elazar's patch, I made sure to test
plaintext export and it was fine. And of course, I
also tested DVI/LaTeX export, and it was fine, too.
I think that parentheses is just a problem --- there
are different conventions AFAIK, and if LyX doesn't
match the convention used on the machine, that
may cause problems, I'm not sure. You could try
editing the Farsi keymap, and switch the
parentheses there, that may help. But then I guess
you'd have a problem with the plaintext export :( .
What OS are you working on?
Anyhow, I hope one of these suggestions help.
Otherwise, I think this is a real problem, which will
require some thinking... It's just the lack of a
standard...
I find out the problem. We have the problem only when
the encoding is Unicode and therefore we want to export
LyX to a plain text with Unicode encoding. As you know
in Unicode the starting parentheses is always '('
but the one that is displayed depends on the context.
Therefore I suggest to reverse the character-pairs
only if the encoding is not UTF.
Looks sensible. Patch?
Abdel.
Re: [PATCH] Bugs 3741 and 3756: Minor Citation Dialog Bugs
Richard Heck wrote: Abdelrazak Younes wrote: Richard Heck wrote: Not OK from me for 3756. I prefer to have the double-click bug provided that I still have the Enter feature. Maybe it is possible to distinguish between the two action though... I'll have a look at this. The behavior you describe makes sense. It ought to be possible to implement on_doubleclick() and use an on_keypress for the other one. Or something like that. I can do this, but it seems weird. I'd like to have some simple keyboard action that would ALWAYS just enter the citation into the Selected box and another one that would ALWAYS enter it and then hit OK. So what about this: We make Enter just enter the citation, and Ctrl-Enter enter and close? That would be fine with me. Or vice versa, if you prefer, though that version seems more intuitive, since then Ctrl-Enter does more. Agreed. Abdel.
Re: Putting Rtl content in Insets
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Jean-Marc Lasgouttes wrote: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | I prefer No document open! Lars Sounds strange. Is that even english? Lars I thought that 'No' usually required plural (unless you want to Lars give it a different meaning.) I do not know... So where are the native English speakers? Abdelrazak I am almost sure that No opened document! is English ;-) Abdelrazak So is No open document! I think. Angus, are you here? JMarc
Re: [Patch] Re: Crash when closing document
Andre Poenitz wrote: On Tue, May 29, 2007 at 10:11:16PM +0200, Stefan Schimanski wrote: I enabled stdlib-debug and then were surprised about the slowness. Some profiling was full of signal/slot stuff in copying cursors Well, I am not complaining about slowness (which hardly can be judged by a non-optimized build) but about the concept. If we need some kind of checked iterators (and we probably do) this should be done properly by e.g. registering the iterators with the buffers or such, not by working around symptoms by invalidating single slices. I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. What makes me really angry is that I thought I was clear enough when I put If you are angry, then I suggest that, in the future you should more closely follow the list and comment when the changes are proposed. // Do not add _any_ (non-static) data members as this would inflate // everything storing large quantities of insets. Mathed e.g. would // suffer. into Inset.h. Yet we get an int in each inset for its background color (very important! and only 4 bytes!), Which was there in InsetOld and InsetMathSomething anyway. So every inset had it! I don't know why you are angry that I made that explicit. an in-inset Dimension cache (12 bytes) About the same situation as above. when the whole system was designed to work without that, and now a mere 20 additional bytes for a signal that's used in a half-baked solution to plaster over conceptional shortcomings in someone's pet feature. Wrong, this is safe for non-multiview too! And I am pretty sure of that: think externally modified file. With this kind of 'improvement' (and others in the 1.5 cycle) we are now happily spending 48(!) bytes for every single character in mathed (and every time when a copy of it ends up on the undo stack) for what took 12 bytes six months ago. That is true but I reckon that there is more to it anyway. I've checked the memory consumption of a big document full of math with and without this signal an you know what? There is no sensible difference. I think I stated this already earlier: LyX is _not_ ready for multiple views. You never proposed a single analysis to prove your statement. Now I can say LyX _is_ ready for multiple views. It would certainly not hurt if we worked towards that goal, however, right now we get one last minute crutch piled on top of another, not only 'fixing' only symptoms instead of causes, but also impairing overall performance. I don't think that's true. To get back to a sane state rev 18516 needs to be reverted _now_, and in early 1.6 the dim_ cache should be externalized to prevent it from showing up in undo. If that means the death of multiple views for 1.5, so be it. I disagree. Abdel.
Re: InsetListingsParams enhancement for Bo (was [patch] Bug 3639- Sorted listing params)
Bo Peng wrote: Sorry Bo, it is been a bit late, but I wait for all the changes for the source file settles. It can go in if you change .find() to contains(), and trim() suffix to avoid problem with '?style ' etc (if it has not been trimmed before key is passed). All these controls and string searching really ought to be in the frontend IMHO. Abdel.
Re: [Cvslog] r18569 - in /lyx-devel/trunk/src: Cursor.cpp Cursor.h LyX...
Stefan Schimanski wrote: Just debugging, to see the values easily in gdb, that's why it is in #ifdef DEBUG ... #endif It is producing as much output as other debug output lines which are non-effective in release mode... Unused variable generates a compilation error with CMake/MSVC... Abdel.
Re: Listing vs. Listings
Lars Gullik Bjønnes schrieb: Michael Gerz [EMAIL PROTECTED] writes: | Bo Peng schrieb: | On 5/29/07, Michael Gerz [EMAIL PROTECTED] wrote: | Hi, | | we use the term Listing inconsistently at the moment. Sometimes we use | the singular form, sometimes we use plural. | | I suggest using Listing (without plural s), even though the package | is called Listings. Otherwise, we may confuse the users and | translators. | | I used listings because it is the package name. Internally, | listings_params means parameters of the listings package. For user | interface, it is weird to name a single inset 'listings' so 'listing' | is used. | | Well, there are many cases where we use the plural form. Not that I disagree with the chagnes... but just becuase Listings end with an 's' does not make it plural. In school, I learned that s *typically* indicates plural form. Let's say that listing (without s) is less confusing for people not familiar with the subtle rules of Englisch grammar :-) Michael
Re: [patch] bug 3764: Implicit \author field in .lyx files
Veto! You can have changes in a document even if change tracking is deactivated! (We no longer have the enervating restriction of the 1.4.X series) Michael Pavel Sanda schrieb: Hi, the following patch add author info to .lyx file only if change tracking is enabled ( http://bugzilla.lyx.org/show_bug.cgi?id=3764 ). Pavel
Re: [Cvslog] r18569 - in /lyx-devel/trunk/src: Cursor.cpp Cursor.h LyX...
Am 30.05.2007 um 08:44 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Just debugging, to see the values easily in gdb, that's why it is in #ifdef DEBUG ... #endif It is producing as much output as other debug output lines which are non-effective in release mode... Unused variable generates a compilation error with CMake/MSVC... Really??? Can we make them also fail on bad code, too high if/then nesting, missing comments? :) Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [Cvslog] r18569 - in /lyx-devel/trunk/src: Cursor.cpp Cursor.h LyX...
Stefan Schimanski wrote: Am 30.05.2007 um 08:44 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Just debugging, to see the values easily in gdb, that's why it is in #ifdef DEBUG ... #endif It is producing as much output as other debug output lines which are non-effective in release mode... Unused variable generates a compilation error with CMake/MSVC... Really??? Yes, that is just an option but it found many unused variable in the past so we'd like to keep it. Can we make them also fail on bad code, too high if/then nesting, missing comments? :) That would be nice but no unfortunately :-) Abdel.
Re: r18577 - /lyx-devel/trunk/src/Text2.cpp
[EMAIL PROTECTED] wrote: Author: sts Date: Wed May 30 08:58:08 2007 New Revision: 18577 URL: http://www.lyx.org/trac/changeset/18577 Log: * put debug variables into #ifdef 0 block. Good that modern computer science can enforce good code quality by stopping compilation if unused variables are found. Please put some comments nethertheless that this is debugging code. Otherwise, some other developper will complain that he doesn't understand what is the purpose of this code and question if it should be left or not. You surely know what I am talking about ;-) Abdel.
Re: [PATCH] po/ja.po: Japanese message file for 1.5.0 (merged from CJK-1.4.4)
OK, here we go. -- Hereby I grant permission to license my contributions to LyX under the GNU General Public License version 2 or later. Koji Yokota ([EMAIL PROTECTED])
Re: [PATCH] po/ja.po: Japanese message file for 1.5.0 (merged from CJK-1.4.4)
On Wednesday 30 May 2007 08:21:08 Koji Yokota wrote: OK, here we go. -- Hereby I grant permission to license my contributions to LyX under the GNU General Public License version 2 or later. Koji Yokota ([EMAIL PROTECTED]) Thanks and welcome. :-) -- José Abílio
Re: Updates to the Hebrew translation
On Wednesday 30 May 2007 06:45:44 Jean-Marc Lasgouttes wrote: Or have a toggle-language lfun that toggles between all the languages used by the document. Of course, this means that one has to explicitly set the second language for the first time. But the feature would be language neutral. I agree. JMarc -- José Abílio
Re: Updates to the Hebrew translation
Jean-Marc Lasgouttes wrote: Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov The best thing would probably be to ask at installation what the Dov primary and what the secondary languages are to be, then to set Dov the default language to primary, and set in the key bindings: Dov F12 language secondary --- perhaps with a comment explaining Dov that it should be the secondary language. Or have a toggle-language lfun that toggles between all the languages used by the document. Of course, this means that one has to explicitly set the second language for the first time. But the feature would be language neutral. A secondary (fallback) language could be (optionnally) defined in the Preference Settings dialog. I know that I would use such a facility to easily switch between French and English. Abdel.
Re: [patch] bug 3764: Implicit \author field in .lyx files
Michael Gerz wrote: You can have changes in a document even if change tracking is deactivated! (We no longer have the enervating restriction of the 1.4.X series) But the possibility to hide author information is a must. This is a serious security hole. Jürgen
Re: [patch] bug 3764: Implicit \author field in .lyx files
Juergen Spitzmueller schrieb: Michael Gerz wrote: You can have changes in a document even if change tracking is deactivated! (We no longer have the enervating restriction of the 1.4.X series) But the possibility to hide author information is a must. This is a serious security hole. Well, MS Word users may see it differently :-) I will have a look - hopefully this evening. Michael
Listing issues translation work
Hi, while translating the listing dialog messages, I found a few minor problems: - Shortcuts for first line and last line do not work - Step: has a faulty tooltip (move cursor to the label, not the field) - Font sizes (twice!) are not translated - Font Styles are not translated - No language is not translatable (but appears in *.po) - Placement: has no shortcut - Shortcut for More Parameters does not work - src/frontends/qt4/ui/ListingsUi.ui:520: String Feedback window - I can't find it - Input listing parameters here. - Is this text really needed? Does it help? I recommend removing it in all dialogs. - #: src/frontends/qt4/ui/ListingsUi.ui:410: Side: (needless space at the end) - What happens if neither floating nor inline is activated? (Confusing) I guess (hope) that some Qt expert can fix most of these bugs within minutes... Michael PS: I would like to see the settings dialog also in the include dialog :-) PS: Jürgen, what was the translation patch that you asked me to test? I hope I will be able to do some work this evening.
Re: Untranslateable strings in LyX (toolbar tooltip, TOC dialog, source preview)
Jürgen Spitzmüller wrote: Helge Hafting wrote: Insert table (just a table, no float) is a string that don't exist in either nb.po or de.po. Does the attached patch help? No. I checked out the entire source fresh from SVN, I applied your patch, compiled, remade lyx.pot and the po-files. Still no go, for Insert table is still the tooltip help, and the string still does not appear in any of the po files. The patch made no difference for this item, unless there is more I have to do to update the po-files? Do you perhaps have some uncommitted patches for the toolbars? Helge Hafting
Re: Listing issues translation work
Michael Gerz wrote: - What happens if neither floating nor inline is activated? (Confusing) I suppose that the user gets a listing, which is not a flot and not in a line ... ;-) How could this be confusing??? A listing is in the first case a listing and it can be inlined or not or a float or not ... Herbert
Re: InsetListingsParams enhancement for Bo (was [patch] Bug 3639- Sorted listing params)
On 5/30/07, Abdelrazak Younes [EMAIL PROTECTED] wrote: Bo Peng wrote: Sorry Bo, it is been a bit late, but I wait for all the changes for the source file settles. It can go in if you change .find() to contains(), and trim() suffix to avoid problem with '?style ' etc (if it has not been trimmed before key is passed). All these controls and string searching really ought to be in the frontend IMHO. Abdel. +1 I can move it to frontend after the release, if nobody objects.
Re: [patch] Cursor movement at RTL-LTR boundary
(for http://bugzilla.lyx.org/show_bug.cgi?id=3754)
Index: src/Text2.cpp
===
--- src/Text2.cpp (revision 18569)
+++ src/Text2.cpp (working copy)
@@ -1031,7 +1031,7 @@
if (cur.pos() != cur.lastpos()) {
// if left of boundary - just jump to right side
if (cur.boundary())
- return setCursor(cur, cur.pit(), cur.pos(), true,
false);
+ return setCursor(cur, cur.pit(), cur.pos() + 1, true,
false);
Please take care with those changes. Such a +1 can change and break a
lot. In this I am pretty sure that a character is skipped when going
over a newline. I added a special case for the RTL boundary for this
line.
+ if (bidi.isBoundary(cur.buffer(), cur.paragraph(), cur.pos() +
1)) {
+ return setCursor(cur, cur.pit(), cur.pos() + 1, true,
true);
+ }
That's good. To commit it we need another OK from somebody.
Stefan
Index: src/Text2.cpp
===
--- src/Text2.cpp (Revision 18579)
+++ src/Text2.cpp (Arbeitskopie)
@@ -1029,9 +1030,10 @@
cur.updateFlags(Update::FitCursor);
// not at paragraph end?
- if (cur.pos() != cur.lastpos()) {
- // if left of boundary - just jump to right side
- if (cur.boundary())
+ if (cur.pos() != cur.lastpos()) {
+ // if left of boundary - just jump to right side
+ // but for RTL boundaries don't, because: abc|DDEEFFghi -
abcDDEEF|Fghi
+ if (cur.boundary() !bidi.isBoundary(cur.buffer(), cur.paragraph
(), cur.pos()))
return setCursor(cur, cur.pit(), cur.pos(), true,
false);
// in front of editable inset, i.e. jump into it?
@@ -1049,0 +1051,0 @@
@@ -1062,6 +1066,13 @@
return setCursor(cur, cur.pit(), cur.pos() + 1, true,
true);
}
+ // in front of RTL boundary? Stay on this side of the boundary
because:
+ // ab|cDDEEFFghi - abc|DDEEFFghi
+
+ if (bidi.isBoundary(cur.buffer(), cur.paragraph(), cur.pos() +
1)) {
+ return setCursor(cur, cur.pit(), cur.pos() + 1, true,
true);
+ }
+
// move right
return setCursor(cur, cur.pit(), cur.pos() + 1, true, false);
}
PGP.sig
Description: Signierter Teil der Nachricht
Re: Ready for RC1?
Peter Kümmel wrote:
Dov Feldstern wrote:
(I hope I'm referring to the correct version of the patch:) As Helge
already reported, on very slow systems (I tested this by running under
valgrind), if you type quickly, some keystrokes get swallowed...
Nice idea to slow down with valgrind.
I've reproduced the error and fixed it.
The problem was, not only page up/down keys were dropped.
This code does not work (because of the implicit casts?)
static const int delayed_keys = Qt::Key_PageDown | Qt::Key_PageUp;
if (e-key() delayed_keys) {
I have to replace it by
if (e-key() == Qt::Key_PageDown || e-key() == Qt::Key_PageUp) {
With running valgrind I could also reproduce the scroll bar
behavior reported by Helge, but here I could fix it with
the patch.
Thank you for putting so much work into this!
Unfortunately, event_4 helps only a little for me.
It seems to help most for short periods of scrolling.
If I scroll a long way, such as through an entire chapter of the userguide
before releasing the mouse, then LyX still overshoot with several pages.
Using the scrollbar arrows or the page down key is no better. (I don't
need to scroll through a whole chapter when using the arrows)
Test machine:
2.4GHz pentium IV, running debian linux.
Graphics: radeon 7000, which is kind of oldish but it has
always been fine for non-3D use.
Problems happen only when the cpu get to 100% load. No
problems as long as there is some capacity left.
I have heard that LyX repaints everything even on single-line scroll.
That means the arrow-down scroll probably will improve
if LyX is optimized to just shift the screen bitmap and repaint
only the exposed area. This would also help jump scrolling, as
a jump usually is less than half a screen.
Perhaps such optimization is the way to go, seeing that nobody
but me have these problems. Optimization helps everybody,
by making LyX snappier, and it also makes this particular problem
much less likely.
Helge Hafting
Re: Ready for RC1? Corrected test of event4
Sorry for the previous test of event4 - I patched the wrong tree. :-( event4 solves the problem for pageup/pagedown! I can scroll through half the userguide at 100% cpu, release the key, and LyX stops instantly! This is very good. The scrollbar still overshoots. I can only make it overshoot slightly when clicking the scrollbar arrows, I was not able to make LyX roll for several pages with those. This is big improvement. Only jumpscrolling using the scrollbar is still a problem. I can easily have LyX roll for several pages extra. Again, thanks for looking into this. Helge Hafting
Re: Untranslateable strings in LyX (toolbar tooltip, TOC dialog, source preview)
Helge Hafting wrote: The patch made no difference for this item, unless there is more I have to do to update the po-files? Don't know. Maybe Michael can help. Do you perhaps have some uncommitted patches for the toolbars? No. Jürgen
Re: Ready for RC1?
Lars Gullik Bjønnes wrote: | What is the problem that you are trying to solve here? Is it my old pet? Countinued scorrling after key-release? What was wrong with my patch from months back? I tried this with todays svn. The patch will indeed prevent scrolling after key-release, so it fixes the pageup/pagedown case. It does not help for jumpscrolling using the scrollbar - LyX will then overshoot a lot, if the scrolling work needs more than 100% cpu. It is possible to use your patch and Peter Kümmels event_4 together. This cuts down on the scrollbar problems, but don't solve them completely. Helge Hafting
Re: r18573 - /lyx-devel/trunk/lib/unicodesymbols
+0x201a , # SINGLE LOW-9 QUOTATION MARK Uwe, I think the single low 9 quotation mark and the comma are not equal (wrt kerning). I'd use \quotesinglbase instead. You are right. I added this because in the existing unicodesymbols there was ,, instead of \quotedblbase for the DOUBLE LOW-9 QUOTATION MARK. I also looked into the LaTeX companion yesterday for crss check but must have overseen this. Could you please fix these two entries for me (0x201e and 0x201a)? We are using the correct quotation commands in unicodesymbols now, so I think we should for LyX 1.5 also use these commands when typing a quotation in LyX (bug 253 I think). --- BTW what about my siggestion for house? Did you have a look at the comprehensive symbols list? Yes I have, but instead of a house I get a single low line. I'm also not sure if it is safe to use the ascii package because it redefines some commands in the background. thanks and regards Uwe
Cursor movement performance problems in 1.5svn
While testing scrolling, I noticed that moving the cursor around seems to be rather heavy work. Moving the cursor sideways on a line is snappy, but this movement takes 33% of the cpu according to top. Moving the cursor up/down seems sluggish compared to sideways movement, and LyX spend 61% of the cpu on doing this. This is according to top, on a load meter it looks more like 90%. This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? It cannot possibly be necessary, and of course other software don't do this. Thunderbird needs 6% of the cpu to do the same. A small file don't necessarily do this, but it happens with the userguide. Making a bigger file (20 guides) don't make this problem worse. Helge Hafting
[patch] fixing segfault because of empty coord cache
Hi!
Here is a patch for a crash that happens due to a cell not in the
coord cache during the drawing of the selection. It could be that
this is related (and also fixes) http://bugzilla.lyx.org/show_bug.cgi?
id=3715 .
I believe the problem is when an inset derived from InsetMathNest
does not draw all its cells, and hence a cell is not in the coord
cache yet. Then the warm up call in InsetMathNest::drawSelection
cannot get the cell into the cache and the loop over all cells at the
bottom of this very function will trigger an assertion.
You can trigger this crash in Beta 3 or 1.5svn like this:
New document, Ctrl-M \ref space shift-right
With this patch the shift-right seems to have no effect. Haven't
checked why. But at least the segfault is gone.
Stefan
Index: src/mathed/InsetMathNest.cpp
===
--- src/mathed/InsetMathNest.cpp(Revision 18579)
+++ src/mathed/InsetMathNest.cpp(Arbeitskopie)
@@ -251,11 +251,15 @@
for (idx_type i = 0; i nargs(); ++i) {
if (idxBetween(i, s1.idx(), s2.idx())) {
MathData const c = cell(i);
- int x1 = c.xo(bv);
- int y1 = c.yo(bv) - c.ascent();
- int x2 = c.xo(bv) + c.width();
- int y2 = c.yo(bv) + c.descent();
- pi.pain.fillRectangle(x1, y1, x2 - x1, y2 - y1,
Color::selection);
+ // if the cell is not in the cache, it is
probably not drawn,
+ // and therefore not warmed up above. So skip
the selection!
+ if (bv.coordCache().arrays().has(c)) {
+ int x1 = c.xo(bv);
+ int y1 = c.yo(bv) - c.ascent();
+ int x2 = c.xo(bv) + c.width();
+ int y2 = c.yo(bv) + c.descent();
+ pi.pain.fillRectangle(x1, y1, x2 - x1,
y2 - y1, Color::selection);
+ }
}
}
}
refcrash.patch
Description: Binary data
PGP.sig
Description: Signierter Teil der Nachricht
Re: Cursor movement performance problems in 1.5svn
Am 30.05.2007 um 13:39 schrieb Helge Hafting: While testing scrolling, I noticed that moving the cursor around seems to be rather heavy work. Moving the cursor sideways on a line is snappy, but this movement takes 33% of the cpu according to top. Moving the cursor up/down seems sluggish compared to sideways movement, and LyX spend 61% of the cpu on doing this. This is according to top, on a load meter it looks more like 90%. This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? Will check... Stand by a moment. It cannot possibly be necessary, and of course other software don't do this. Thunderbird needs 6% of the cpu to do the same. A small file don't necessarily do this, but it happens with the userguide. Making a bigger file (20 guides) don't make this problem worse. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Cursor movement performance problems in 1.5svn
This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? Will check... Stand by a moment. You are right. I guess there is a redraw problem that a bigger redraw is issued on cursor down. Beta3 is much fast with this. Will look into this now. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [Patch] Re: Crash when closing document
Abdelrazak Younes wrote: I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. Small remark: note that not all DocIterators need to be stable (mainly cursors, maybe also bookmarks error marks), one could have a class derived from DocIterator for that purpose. A/
Re: Cursor movement performance problems in 1.5svn
Stefan Schimanski wrote: This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? Will check... Stand by a moment. You are right. I guess there is a redraw problem that a bigger redraw is issued on cursor down. Beta3 is much fast with this. Will look into this now. In principle there should be no redraw at all for simple cursor moving; except in mathed where the background is redrawn because of the pink corners. Abdel.
Re: [Patch] Re: Crash when closing document
Alfredo Braunstein wrote: Abdelrazak Younes wrote: I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. Small remark: note that not all DocIterators need to be stable (mainly cursors, maybe also bookmarks error marks), one could have a class derived from DocIterator for that purpose. I agree but it's more work than my signal based solution which is assured to work in all cases. I tell you what, in order to save the bits Andre is worried about I am going to remove the signal from Inset and transfer them to InsetText and InsetMathHull. In 1.6, we can think of this other solution. But really, my solution is cheap in terms of CPU and it will be cheaper in terms of memory when I do the change described above. Abdel.
Re: Cursor movement performance problems in 1.5svn
Am 30.05.2007 um 14:16 schrieb Abdelrazak Younes: Stefan Schimanski wrote: This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? Will check... Stand by a moment. You are right. I guess there is a redraw problem that a bigger redraw is issued on cursor down. Beta3 is much fast with this. Will look into this now. In principle there should be no redraw at all for simple cursor moving; except in mathed where the background is redrawn because of the pink corners. Yes, yes. I know. I just oversimplified the logic there. Have a patch in a few minutes. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: r18573 - /lyx-devel/trunk/lib/unicodesymbols
Uwe Stöhr wrote: You are right. I added this because in the existing unicodesymbols there was ,, instead of \quotedblbase for the DOUBLE LOW-9 QUOTATION MARK. I think ,, is o.k. (i.e., will be transformed into a double quotation mark). The single quotation mark difference is visible with ,Vater` vs. \quotesinglbase Vater\textquoteleft (the distance between the quotation mark and the V). I also looked into the LaTeX companion yesterday for crss check but must have overseen this. Could you please fix these two entries for me (0x201e and 0x201a)? Yes (if you don't beat me to it until Friday) We are using the correct quotation commands in unicodesymbols now, so I think we should for LyX 1.5 also use these commands when typing a quotation in LyX (bug 253 I think). I think so, too, but some people argued that the commands are too clumsy. Jürgen BTW thanks for doing all the work on this file. This is great stuff.
Re: Cursor movement performance problems in 1.5svn
Stefan Schimanski wrote: Am 30.05.2007 um 14:16 schrieb Abdelrazak Younes: Stefan Schimanski wrote: This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? Will check... Stand by a moment. You are right. I guess there is a redraw problem that a bigger redraw is issued on cursor down. Beta3 is much fast with this. Will look into this now. In principle there should be no redraw at all for simple cursor moving; except in mathed where the background is redrawn because of the pink corners. Yes, yes. I know. I just oversimplified the logic there. Have a patch in a few minutes. You really impress me with the speed at which you learnt you way inside the LyX code Stefan. Abdel.
Re: [Patch] Re: Crash when closing document
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I agree but it's more work than my signal based solution Abdelrazak which is assured to work in all cases. I tell you what, in Abdelrazak order to save the bits Andre is worried about I am going Abdelrazak to remove the signal from Inset and transfer them to Abdelrazak InsetText and InsetMathHull. In 1.6, we can think of this Abdelrazak other solution. But really, my solution is cheap in terms Abdelrazak of CPU and it will be cheaper in terms of memory when I do Abdelrazak the change described above. So it is not realted to Helge's comlaint that moving the cursor produces a high CPU load? JMarcc
Re: [Patch] Re: Crash when closing document
Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. Small remark: note that not all DocIterators need to be stable (mainly cursors, maybe also bookmarks error marks), one could have a class derived from DocIterator for that purpose. I agree but it's more work than my signal based solution which is assured to work in all cases. I tell you what, in order to save the bits Andre is worried about I am going to remove the signal from Inset and transfer them to InsetText and InsetMathHull. In 1.6, we can think of this other solution. But really, my solution is cheap in terms of CPU and it will be cheaper in terms of memory when I do the change described above. In general terms Abdel I agree that it is not so bad if it really works (in order to implement a correct solution (TM) having something working even if inefficient is /good/, not bad), but are we sure that it works in all cases? In general it seems wrong to me that invalidation of cursors is only due to inset destruction. For instance, put a cursor inside an inset, then in another window add or remove some text before the inset so the position of the inset changes... no destruction occurs, but is the cursor still valid? (sorry don't have svn to check here.) A/
Re: [Patch] Re: Crash when closing document
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I agree but it's more work than my signal based solution Abdelrazak which is assured to work in all cases. I tell you what, in Abdelrazak order to save the bits Andre is worried about I am going Abdelrazak to remove the signal from Inset and transfer them to Abdelrazak InsetText and InsetMathHull. In 1.6, we can think of this Abdelrazak other solution. But really, my solution is cheap in terms Abdelrazak of CPU and it will be cheaper in terms of memory when I do Abdelrazak the change described above. So it is not realted to Helge's comlaint that moving the cursor produces a high CPU load? I don't think so. Moving cursor shouldn't trigger any inset destruction. Abdel.
Re: Cursor movement performance problems in 1.5svn
Here it is. As I wrote already, the screen was redrawn every time the cursor was moved up or down. But this is only needed if bv().checkDepm (...) does some work. Now the behavior is as in beta 3 again. Stefan cursornoredraw.patch Description: Binary data Am 30.05.2007 um 14:33 schrieb Stefan Schimanski: Am 30.05.2007 um 14:16 schrieb Abdelrazak Younes: Stefan Schimanski wrote: This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? Will check... Stand by a moment. You are right. I guess there is a redraw problem that a bigger redraw is issued on cursor down. Beta3 is much fast with this. Will look into this now. In principle there should be no redraw at all for simple cursor moving; except in mathed where the background is redrawn because of the pink corners. Yes, yes. I know. I just oversimplified the logic there. Have a patch in a few minutes. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Cursor movement performance problems in 1.5svn
And also inline as promised:
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (Revision 18579)
+++ src/Cursor.cpp (Arbeitskopie)
@@ -1168,7 +1168,7 @@
}
-bool Cursor::upDownInText(bool up)
+bool Cursor::upDownInText(bool up, bool updateNeeded)
{
BOOST_ASSERT(text());
@@ -1248,12 +1248,11 @@
Cursor dummy = *this;
if (dummy == old)
++dummy.pos();
-
- bool const changed = bv().checkDepm(dummy, old);
-
- // Make sure that cur gets back whatever happened to dummy(Lgb)
- if (changed)
+ if (bv().checkDepm(dummy, old)) {
+ updateNeeded = true;
+ // Make sure that cur gets back whatever happened to
dummy(Lgb)
operator=(dummy);
+ }
} else {
// if there is a selection, we stay out of any inset, and just jump
to the right position:
Cursor old = *this;
@@ -1274,7 +1273,7 @@
}
}
- bv().checkDepm(*this, old);
+ updateNeeded |= bv().checkDepm(*this, old);
}
updateTextTargetOffset();
Index: src/Cursor.h
===
--- src/Cursor.h(Revision 18579)
+++ src/Cursor.h(Arbeitskopie)
@@ -256,12 +256,17 @@
/// return false for empty math insets
bool backspace();
/// move the cursor up by sending an internal LFUN_UP
+ /// return true if fullscreen update is needed
bool up();
- /// move the cursor up by sending an internal LFUN_DOWN
+ /// move the cursor up by sending an internal LFUN_DOWN,
+ /// return true if fullscreen update is needed
bool down();
- /// move up/down in a text inset, called for LFUN_UP/DOWN
- bool upDownInText(bool up);
+ /// move up/down in a text inset, called for LFUN_UP/DOWN,
+ /// return true if successful, updateNeeded set to true if fullscreen
+ /// update is needed, otherwise it's not touched
+ bool upDownInText(bool up, bool updateNeeded);
/// move up/down in math or any non text inset, call for LFUN_UP/DOWN
+ /// return true if successful
bool upDownInMath(bool up);
///
void plainErase();
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 18579)
+++ src/Text3.cpp (Arbeitskopie)
@@ -467,30 +467,28 @@
break;
case LFUN_UP:
- case LFUN_UP_SELECT:
+ case LFUN_UP_SELECT: {
//lyxerr handle LFUN_UP[SEL]:\n cur endl;
needsUpdate |= cur.selHandle(cmd.action == LFUN_UP_SELECT);
- needsUpdate |= cur.upDownInText(true);
-
- if (!needsUpdate oldTopSlice == cur.top()
- cur.boundary() == oldBoundary)
+ bool const successful = cur.upDownInText(true, needsUpdate);
+ if (!successful)
cur.undispatched();
if (cur.selection())
saveSelection(cur);
break;
+ }
case LFUN_DOWN:
- case LFUN_DOWN_SELECT:
+ case LFUN_DOWN_SELECT: {
//lyxerr handle LFUN_DOWN[SEL]:\n cur endl;
needsUpdate |= cur.selHandle(cmd.action == LFUN_DOWN_SELECT);
- needsUpdate |= cur.upDownInText(false);
-
- if (!needsUpdate oldTopSlice == cur.top()
- cur.boundary() == oldBoundary)
+ bool const successful = cur.upDownInText(false, needsUpdate);
+ if (!successful)
cur.undispatched();
if (cur.selection())
saveSelection(cur);
break;
+ }
case LFUN_PARAGRAPH_UP:
case LFUN_PARAGRAPH_UP_SELECT:
PGP.sig
Description: Signierter Teil der Nachricht
Re: [Patch] Re: Crash when closing document
Alfredo Braunstein wrote: Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. Small remark: note that not all DocIterators need to be stable (mainly cursors, maybe also bookmarks error marks), one could have a class derived from DocIterator for that purpose. I agree but it's more work than my signal based solution which is assured to work in all cases. I tell you what, in order to save the bits Andre is worried about I am going to remove the signal from Inset and transfer them to InsetText and InsetMathHull. In 1.6, we can think of this other solution. But really, my solution is cheap in terms of CPU and it will be cheaper in terms of memory when I do the change described above. In general terms Abdel I agree that it is not so bad if it really works (in order to implement a correct solution (TM) having something working even if inefficient is /good/, not bad), but are we sure that it works in all cases? At least I have tested it with every test I could think of. In general it seems wrong to me that invalidation of cursors is only due to inset destruction. Not only, this case below can invalidate cursor: For instance, put a cursor inside an inset, then in another window add or remove some text before the inset so the position of the inset changes... no destruction occurs, but is the cursor still valid? (sorry don't have svn to check here.) No, and that is the purpose of the new method DocIterator::FixIfBroken(). This will first validate the validity of the CursorSlice (thus the existence of the insets) then the validity of the text index, then the one of the cursor row, then the position in this row. Abdel.
Re: [Patch] Re: Crash when closing document
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak No, and that is the purpose of the new method Abdelrazak DocIterator::FixIfBroken(). This will first validate the Abdelrazak validity of the CursorSlice (thus the existence of the Abdelrazak insets) then the validity of the text index, then the one Abdelrazak of the cursor row, then the position in this row. But of course, this is not the correct solution, since the user will find that the cursor moves in weird places. Example: window 1: windows 2: |abcd abcd efgh ef|gh ijkl ijkl If you delete the first paragraph in window 1, the cursor will be between j and k in window 2. This means that after any non trivial editing in window 1, the cursor is at some random place of window 2. JMarc
Re: Cursor movement performance problems in 1.5svn
On Wed, 2007-05-30 at 13:39 +0200, Helge Hafting wrote: While testing scrolling, I noticed that moving the cursor around seems to be rather heavy work. Is this a known problem, with a planned fix? A small file don't necessarily do this, but it happens with the userguide. Making a bigger file (20 guides) don't make this problem worse. Sure this isn't http://bugzilla.lyx.org/show_bug.cgi?id=3700 ? Try the same thing and then resize the LyX window. See if it suddenly and inextricably improves. Have fun, Darren
Re: Putting Rtl content in Insets
Jean-Marc Lasgouttes wrote: Lars | I prefer No document open! Lars Sounds strange. Is that even english? Lars I thought that 'No' usually required plural (unless you want to Lars give it a different meaning.) I do not know... So where are the native English speakers? No document open is fine. E.g., No player scored more than one goal. The plural is ok there, too. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Putting Rtl content in Insets
Richard == Richard Heck [EMAIL PROTECTED] writes: Richard Jean-Marc Lasgouttes wrote: Lars | I prefer No document open! Lars Sounds strange. Is that even english? Lars I thought that 'No' usually required plural (unless you want to Lars give it a different meaning.) I do not know... So where are the native English speakers? Richard No document open is fine. E.g., No player scored more than Richard one goal. The plural is ok there, too. What is best? We have No documents open! now, the principle of least effort would advise to keep it like that... JMarc
Re: InsetListingsParams enhancement for Bo (was [patch] Bug 3639- Sorted listing params)
+1 I can move it to frontend after the release, if nobody objects. After 1.5.0 please. Time would be better spent on real bugs now. Bo
Re: Putting Rtl content in Insets
Jean-Marc Lasgouttes wrote: Richard Jean-Marc Lasgouttes wrote: Lars | I prefer No document open! Lars Sounds strange. Is that even english? Lars I thought that 'No' usually required plural (unless you want to Lars give it a different meaning.) I do not know... So where are the native English speakers? Richard No document open is fine. E.g., No player scored more than Richard one goal. The plural is ok there, too. What is best? We have No documents open! now, the principle of least effort would advise to keep it like that... I guess I prefer the singular. The plural suggests that documentS should have been open---that this was the expected situation. But it's a very subtle judgment, and probably subject to dialectical variation. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Cursor movement performance problems in 1.5svn
Am 30.05.2007 um 15:40 schrieb Darren Freeman: On Wed, 2007-05-30 at 13:39 +0200, Helge Hafting wrote: While testing scrolling, I noticed that moving the cursor around seems to be rather heavy work. Is this a known problem, with a planned fix? A small file don't necessarily do this, but it happens with the userguide. Making a bigger file (20 guides) don't make this problem worse. Sure this isn't http://bugzilla.lyx.org/show_bug.cgi?id=3700 ? No, was a bug in the cursor up/down code, see patch. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Listing issues translation work
while translating the listing dialog messages, I found a few minor problems: I am not familiar with either qt or gettext so I will leave these to others. PS: I would like to see the settings dialog also in the include dialog :-) Me too. I have asked the qt guys how to call the listings dialog from the include dialog but no one seems to have any good idea. The only way I found out is loading the dialog as a dumb dialog (use ui only) and repeat all the logic again. Cheers, Bo
Re: Untranslateable strings in LyX (toolbar tooltip, TOC dialog, source preview)
No. I checked out the entire source fresh from SVN, I applied your patch, compiled, remade lyx.pot and the po-files. Still no go, for Insert table is still the tooltip help, and the string still does not appear in any of the po files. Maybe this is a lyx_pot.py problem. Please describe which string you are translating (filename and line number) and I will have a look. Bo
Re: [Patch] Re: Crash when closing document
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak No, and that is the purpose of the new method Abdelrazak DocIterator::FixIfBroken(). This will first validate the Abdelrazak validity of the CursorSlice (thus the existence of the Abdelrazak insets) then the validity of the text index, then the one Abdelrazak of the cursor row, then the position in this row. But of course, this is not the correct solution, since the user will find that the cursor moves in weird places. Example: window 1: windows 2: |abcd abcd efgh ef|gh ijkl ijkl If you delete the first paragraph in window 1, the cursor will be between j and k in window 2. This means that after any non trivial editing in window 1, the cursor is at some random place of window 2. Yes, this is a problem. I thought that this side-effect was already accepted. (btw I could live with this) A/
beamer suggestion
I think inserting begin frame should automatically add the matching end frame.
Re: [Patch] Re: Crash when closing document
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak No, and that is the purpose of the new method Abdelrazak DocIterator::FixIfBroken(). This will first validate the Abdelrazak validity of the CursorSlice (thus the existence of the Abdelrazak insets) then the validity of the text index, then the one Abdelrazak of the cursor row, then the position in this row. But of course, this is not the correct solution, This is as good as one can make it ;-), at least it is better than the old Cursor::fixIsBroken() don't you reckon? since the user will find that the cursor moves in weird places. Example: window 1: windows 2: |abcd abcd efgh ef|gh ijkl ijkl If you delete the first paragraph in window 1, the cursor will be between j and k in window 2. This means that after any non trivial editing in window 1, the cursor is at some random place of window 2. I won't say random because as you found out you can predict the behaviour. We could think of the solution that takes into account the par id (and thus using Bookmarks instead of fixing the Cursor). But quite Frankly, this is not a major issue for now. Abdel.
Re: [Patch] Re: Crash when closing document
Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. Small remark: note that not all DocIterators need to be stable (mainly cursors, maybe also bookmarks error marks), one could have a class derived from DocIterator for that purpose. I agree but it's more work than my signal based solution which is assured to work in all cases. I tell you what, in order to save the bits Andre is worried about I am going to remove the signal from Inset and transfer them to InsetText and InsetMathHull. In 1.6, we can think of this other solution. But really, my solution is cheap in terms of CPU and it will be cheaper in terms of memory when I do the change described above. In general terms Abdel I agree that it is not so bad if it really works (in order to implement a correct solution (TM) having something working even if inefficient is /good/, not bad), but are we sure that it works in all cases? At least I have tested it with every test I could think of. In general it seems wrong to me that invalidation of cursors is only due to inset destruction. Not only, this case below can invalidate cursor: For instance, put a cursor inside an inset, then in another window add or remove some text before the inset so the position of the inset changes... no destruction occurs, but is the cursor still valid? (sorry don't have svn to check here.) No, and that is the purpose of the new method DocIterator::FixIfBroken(). This will first validate the validity of the CursorSlice (thus the existence of the insets) then the validity of the text index, then the one of the cursor row, then the position in this row. Ah! So you *are* sort of implementing the dociterator registering thing in a sense: you just manually keep track of a few dociterators ;-). Btw, just downloaded and had a look at the code, I think that the checks are not done correctly, you should for instance get sure that the pos of the inset is the one pointed in the parent slice, not just check that pos = lastpos. Otherwise you still get an invalid iterator methinks. Just a though... why do we need the invalidation signals at all? ...couldn't we go in fixIfBroken from the top to the tip of the DocIterator checking that there is an inset an the given position in the paragraph, and that the pointer of that inset is the one in the iterator in the next slice (as well as the idx, pit, pos checks)? A/
Re: Re[2]: lyx pictures
Bo Peng wrote: Unfortunately, lyx can not make use of this problem because it is a 'shareware', and AFAIK, not under GPL. That is no problem at all: Detect this in configure.py and use it if available. Then it is completely optional to use it. It would only be a problem if wmf2eps would make up a major part of the functionality of LyX. The sole purpose here is to paste images from windows clipboard to lyx. Why? Why should it not be possible to directly include wmf images in LyX, as you can include e.g. xfig images? For example my father uses a geometry program that can export to bmp and wmf, but nothing else. A wmf2eps converter would be perfect here, or should he be forced to always copy-paste a new figure if he is going to change an existing one? After your clipboard cleanup, it is now possible to parse clipboard in various format and paste to lyx intelligently. However, without proper wmf-eps conversion, image paste will be broken. Because windows wmf-eps conversion is easy, and we do not need this conversion under *nix, I think we can convert wmf by ourselves and implement this feature. What would this gain? I don't see the advantage. IMHO, if image pasting is implemented, it should be format independant and use the normal converter machinery. After all it is possible to put other image format onto tyhe clipboard, at least on Linux and Mac. In theory direct conversion inside LyX is faster, but I doubt that you will paste images with a rate of 10 per second or so. Why not implement a windows only wmf-eps converter as a standalone program? Then you don't need the shareware either, but are still more flexible. Georg
[PATCH] Saves some memory bits (was Re: [Patch] Re: Crash when closing document)
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
I am not sure that registering every single DocIterator would be any
more efficient that my signal/slot solution. At the end you will have to
go through a table.
Small remark: note that not all DocIterators need to be stable (mainly
cursors, maybe also bookmarks error marks), one could have a class
derived from DocIterator for that purpose.
I agree but it's more work than my signal based solution which is
assured to work in all cases. I tell you what, in order to save the bits
Andre is worried about I am going to remove the signal from Inset and
transfer them to InsetText and InsetMathHull.
I meant InsetMathNest.
Here is the patch. This saves 500K for the UserGuide and some megs when
editing a really big document full of math (extrememacro.lyx for those
in the knows). I've run through a lot of test with multiviews and I
couldn't make it crash.
OK?
Abdel.
Index: CursorSlice.cpp
===
--- CursorSlice.cpp (revision 18579)
+++ CursorSlice.cpp (working copy)
@@ -42,7 +42,9 @@
: inset_(p), idx_(0), pit_(0), pos_(0)
{
BOOST_ASSERT(inset_);
- inset_-destroyed.connect(
+ boost::signalvoid() * destroyed_signal = inset_-destroyedSignal();
+ if (destroyed_signal)
+ inset_connection_ = destroyed_signal-connect(
boost::bind(CursorSlice::invalidate, this));
}
@@ -52,16 +54,20 @@
operator=(cs);
}
+CursorSlice::~CursorSlice()
+{
+ inset_connection_.disconnect();
+}
+
CursorSlice CursorSlice::operator=(CursorSlice const cs)
{
inset_ = cs.inset_;
idx_ = cs.idx_;
pit_ = cs.pit_;
pos_ = cs.pos_;
- if (inset_) {
- BOOST_ASSERT(inset_);
- inset_-destroyed.connect(
+ if (inset_ inset_-destroyedSignal()) {
+ inset_connection_ = inset_-destroyedSignal()-connect(
boost::bind(CursorSlice::invalidate, this));
}
return *this;
Index: CursorSlice.h
===
--- CursorSlice.h (revision 18579)
+++ CursorSlice.h (working copy)
@@ -63,6 +63,7 @@
///
explicit CursorSlice(Inset );
///
+ virtual ~CursorSlice();
CursorSlice operator=(CursorSlice const );
///
bool isValid() const;
@@ -156,6 +157,8 @@
bool pit_valid_;
/// position in this cell
pos_type pos_;
+ /// connection to referred \c inset_ destruction signal.
+ boost::signals::connection inset_connection_;
};
/// test for equality
Index: insets/Inset.cpp
===
--- insets/Inset.cpp(revision 18579)
+++ insets/Inset.cpp(working copy)
@@ -121,19 +121,6 @@
{}
-Inset::Inset(Inset const inset)
- : dim_(inset.dim_), background_color_(inset.background_color_)
-{}
-
-
-Inset Inset::operator=(Inset const inset)
-{
- dim_ = inset.dim_;
- background_color_ = inset.background_color_;
- return *this;
-}
-
-
std::auto_ptrInset Inset::clone() const
{
std::auto_ptrInset b = doClone();
Index: insets/Inset.h
===
--- insets/Inset.h (revision 18579)
+++ insets/Inset.h (working copy)
@@ -72,7 +72,7 @@
typedef size_t col_type;
/// virtual base class destructor
- virtual ~Inset() { destroyed();}
+ virtual ~Inset() {}
/// replicate ourselves
std::auto_ptrInset clone() const;
@@ -477,14 +477,15 @@
//
enum { TEXT_TO_INSET_OFFSET = 4 };
- /// This signal is emitted when the inset is destroyed.
- boost::signalvoid() destroyed;
+ /// Signal for inset destruction.
+ /** This signal is emitted at the inset destruction for insets that
+ * support this.
+ */
+ virtual boost::signalvoid() * destroyedSignal() { return 0; }
protected:
Inset();
- Inset(Inset const i);
- ///
- Inset operator=(Inset const );
+
/** The real dispatcher.
* Gets normally called from Cursor::dispatch(). Cursor::dispatch()
* assumes the common case of 'LFUN handled, need update'.
Index: insets/InsetText.cpp
===
--- insets/InsetText.cpp(revision 18579)
+++ insets/InsetText.cpp(working copy)
@@ -51,6 +51,7 @@
#include boost/bind.hpp
#include boost/current_function.hpp
+#include boost/signal.hpp
#include sstream
Index: insets/InsetText.h
===
--- insets/InsetText.h (revision 18579)
+++ insets/InsetText.h (working copy)
@@ -42,6 +42,8 @@
explicit InsetText(BufferParams const );
///
Re: [Patch] Re: Crash when closing document
Alfredo Braunstein wrote: Abdelrazak Younes wrote: For instance, put a cursor inside an inset, then in another window add or remove some text before the inset so the position of the inset changes... no destruction occurs, but is the cursor still valid? (sorry don't have svn to check here.) No, and that is the purpose of the new method DocIterator::FixIfBroken(). This will first validate the validity of the CursorSlice (thus the existence of the insets) then the validity of the text index, then the one of the cursor row, then the position in this row. Ah! So you *are* sort of implementing the dociterator registering thing in a sense: you just manually keep track of a few dociterators ;-). Kindof yes :-) Btw, just downloaded and had a look at the code, I think that the checks are not done correctly, you should for instance get sure that the pos of the inset is the one pointed in the parent slice, not just check that pos = lastpos. Otherwise you still get an invalid iterator methinks. You are probably right. Just a though... why do we need the invalidation signals at all? ...couldn't we go in fixIfBroken from the top to the tip of the DocIterator checking that there is an inset an the given position in the paragraph, and that the pointer of that inset is the one in the iterator in the next slice (as well as the idx, pit, pos checks)? I did not think of that :-(. That could work indeed. I don't have the time to implement this right now, maybe this could be the occasion of a patch from you to signal that your come back is real? :-) Abdel.
Re: Listing issues translation work
Bo Peng wrote: while translating the listing dialog messages, I found a few minor problems: I am not familiar with either qt or gettext so I will leave these to others. It might be because those strings are marked N_() (I thought the would become translatable nevertheless, but I might be wrong). The alternative is to mark them _(), but then, they need to be transferred to docstring. Unfortunately, I don't have access to the sources now. Jürgen
Re: beamer suggestion
Neal Becker [EMAIL PROTECTED] writes: I think inserting begin frame should automatically add the matching end frame. Agreed. Andreas
Re: [Patch] Re: Crash when closing document
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: But of course, this is not the correct solution, Abdelrazak This is as good as one can make it ;-), at least it is Abdelrazak better than the old Cursor::fixIsBroken() don't you Abdelrazak reckon? Sure, but I think that, since most changes can be described in terms of insertion/deletion (thanks to the ct code), it is possible at each of these events to update all the relevant cursors. If you delete the first paragraph in window 1, the cursor will be between j and k in window 2. This means that after any non trivial editing in window 1, the cursor is at some random place of window 2. Abdelrazak I won't say random because as you found out you can Abdelrazak predict the behaviour. After I have edited during 10 minutes in one part of the document, the location in the other place will really seem random. Abdelrazak We could think of the solution that takes into account the Abdelrazak par id (and thus using Bookmarks instead of fixing the Abdelrazak Cursor). But quite Frankly, this is not a major issue for Abdelrazak now. Also, if I edit and use undo, the cursor will not be placed back where it was in the other window. These problems do not mean that you implemented badly, just that it is a bigger task than you thought. JMarc
Re: [Patch] Re: Crash when closing document
Jean-Marc Lasgouttes wrote: Abdelrazak I won't say random because as you found out you can Abdelrazak predict the behaviour. After I have edited during 10 minutes in one part of the document, the location in the other place will really seem random. Abdelrazak We could think of the solution that takes into account the Abdelrazak par id (and thus using Bookmarks instead of fixing the Abdelrazak Cursor). But quite Frankly, this is not a major issue for Abdelrazak now. Also, if I edit and use undo, the cursor will not be placed back where it was in the other window. These problems do not mean that you implemented badly, just that it is a bigger task than you thought. As I said and using Alfredo's words, I was well aware of this side-effect and I already accepted it. It would be nice to properly track the cursor location but personally I can live with current behaviour becuase the benefits of Multipleview are really worth it. Abdel.
Re: [Patch] Re: Crash when closing document
Jean-Marc Lasgouttes wrote: These problems do not mean that you implemented badly, just that it is a bigger task than you thought. An by the way, the additional work required to properly handling these cursors is basically *nothing* compared to what I've done to support multipleviews ;-) Abdel.
Re: [patch] fixing segfault because of empty coord cache
Stefan Schimanski wrote: Hi! Here is a patch for a crash that happens due to a cell not in the coord cache during the drawing of the selection. It could be that this is related (and also fixes) http://bugzilla.lyx.org/show_bug.cgi?id=3715 . I believe the problem is when an inset derived from InsetMathNest does not draw all its cells, and hence a cell is not in the coord cache yet. Then the warm up call in InsetMathNest::drawSelection cannot get the cell into the cache and the loop over all cells at the bottom of this very function will trigger an assertion. You can trigger this crash in Beta 3 or 1.5svn like this: New document, Ctrl-M \ref space shift-right With this patch the shift-right seems to have no effect. Haven't checked why. But at least the segfault is gone. Probably because the cell is not in the cache. The patch looks good and safe. Abdel.
Re: beamer suggestion
Neal Becker wrote:
I think inserting begin frame should automatically add the matching end frame.
It already does -- it ends the *previous* frame. If you mean that it
should add an EndFrame environment to end itself, I can see a problem
and an annoyance. The annoyance would be that the LyX file would be
littered with EndFrame environments. The problem is that if later
delete the BeginFrame (or change it to something else, such as a section
header), you are responsible for finding and deleting the
corresponding EndFrame environment, or else the file won't compile.
I assume it's the terminal EndFrame that concerns you, since that's the
only one you ever need to enter manually. One solution (that might have
benefits elsewhere) would be if LyX added a postamble feature to
layouts, which would contain LaTeX code to be inserted just before
\end{document} in the LaTeX output. AFAIK this is not a current
feature, but I'm not positive about that. The Beamer layout could
contain frame-ending code there -- I'm can't think of any exceptions
where a Beamer doc wouldn't end with a frame ender, but possibly someone
else can.
/Paul
Re: [Patch] Re: Crash when closing document
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak As I said and using Alfredo's words, I was well aware of Abdelrazak this side-effect and I already accepted it. It would be Abdelrazak nice to properly track the cursor location but personally Abdelrazak I can live with current behaviour becuase the benefits of Abdelrazak Multipleview are really worth it. A typical use of multiple view: you want to cut some parts of a document and paste them at another place of the same document. Having the cursor move is not very nice. I think that the announcement should say that there are some shortcoming in the current implementation. And yes, multiple views is a great feature to have JMarc PS: when I open a window with FileNew window, it does not pick the correct size from session handling.
Re: Cursor movement performance problems in 1.5svn
Stefan Schimanski wrote: And also inline as promised: The patch looks good and it works. But is there is a reason why you didn't use the cursor updateFlags instead of this additional boolean? Abdel.
Re: [Patch] Re: Crash when closing document
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak As I said and using Alfredo's words, I was well aware of Abdelrazak this side-effect and I already accepted it. It would be Abdelrazak nice to properly track the cursor location but personally Abdelrazak I can live with current behaviour becuase the benefits of Abdelrazak Multipleview are really worth it. A typical use of multiple view: you want to cut some parts of a document and paste them at another place of the same document. Having the cursor move is not very nice. I agree but I have no time to fix that right now. Nevertheless, if someone is interested, I think it should be very easy to fix: when losing the focus, the current LyXView should tell the BufferView to save the current cursor location as a bookmark. When a LyXView get the focus, it should tell the BufferView to revert the position to the last saved bookmark. Something like that. I think that the announcement should say that there are some shortcoming in the current implementation. Agreed. And yes, multiple views is a great feature to have JMarc PS: when I open a window with FileNew window, it does not pick the correct size from session handling. Session mangaement does not handle multiple views at all. I think the size of the new window is the default window size. It should be possible I guess to resize that either to the size of the current window or to the one contained in the section handling. Abdel.
Re: Cursor movement performance problems in 1.5svn
Am 30.05.2007 um 18:00 schrieb Abdelrazak Younes: Stefan Schimanski wrote: And also inline as promised: The patch looks good and it works. But is there is a reason why you didn't use the cursor updateFlags instead of this additional boolean? Just followed the example of the other functions moving the cursor and the old code. Cursor flags would do the job as well of course. Stefan PGP.sig Description: Signierter Teil der Nachricht
Table usability
Hello, I am not often working with tables in LyX, but I noticed two usability issues when inserting rows or columns: 1) I searched first in table settings (opened on right click on table), then used google to find it in the edit menu. 2) I inserted a row a time, inserting 10 rows was quite inefficient (maybe I just did not find the right shortcut) Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07032-359190 jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/
Re: [patch] request for permission to add more symbols to unicodesymbols file
On Wed, May 30, 2007 at 02:24:15AM +0200, Uwe Stöhr wrote:
\newcommand*\LyXrightangle{{\usefont{U}{msa}{m}{n}\char120}}
Many thanks.
Where is a table to look what number corresponds to what character in the
font files? I seared for a code chart table for msam and msbm but couldn't
found this character there.
Now only these characters used in Windows' standard fonts are not supported:
2015 HORIZONTAL BAR: ―
203e OVERLINE: ̅
20a7 PESETA SIGN: ₧ (no longer widely used due to the € sign)
20aa NEW SHEQEL SIGN: ₪
2302 HOUSE: ⌂
2320 TOP HALF INTEGRAL: ⌠
2321 BOTTOM HALF INTEGRAL: ⌡
25ac BLACK RECTANGLE: ▬
25d8 INVERSE BULLET: ◘
25d9 INVERSE WHITE CIRCLE: ◙
When you know a solution how to support one of them, please tell me.
(Using \={} is too short for the OVERLINE, it has to be the same length as
\_ )
\raisebox{1.3ex}{\_}
Andre'
Re: Updates to the Hebrew translation
Lars Gullik Bjønnes wrote: Elazar Leibovich [EMAIL PROTECTED] writes: | On 28 May 2007 23:07:36 +0200, Lars Gullik Bjønnes [EMAIL PROTECTED] wrote: | Elazar Leibovich [EMAIL PROTECTED] writes: | | | Isn't that wise that the language will be automatically detected by | | the input-language. ie, English letters will always be English, | | Hebrew/Arabic letters will always be Hebrew/Arabic and neutral | | characters will be the same language of the paragraph. | | That way, the user won't be forced to learn new key combinations to | | switch languages. | | I think I said in some other mail some hours ago: | (paraphrasing) | There is a difference between characters and language. You wouldn't | expect all latin characters to mean that you are writing latin would | you? | | You did and it is true generally. However, there is a difference. In | hebrew you'll never ever wish to have hebrew characters written in a | language different than Hebrew. It'll just be outputted wrongfully. What about norwegian? Could it be that I'd like to write a hebrew character there? as a reference to something? As a linguist f.ex? Well, I think you're misunderstanding each other: Certainly, you may be writing a document in Norwegian, and want to insert some Hebrew. In order to do that, you must (1) switch the language (locally, for the specific text you're typing, using the language hebrew command in the minibuffer) to Hebrew, and (2) make sure that the characters you insert are Hebrew characters (either by setting the keyboard to send Hebrew characters to LyX; how to do this is system-dependent; or by using LyX's builtin keymaps, which can be set up in the preferences). Doing only one or the other of those will result in broken LaTeX code (at least with the packages that LyX currently uses for Hebrew). That's what Elazar means, when he says you'll never ever wish to have hebrew characters written in a language different than Hebrew --- i.e., without switching the language to Hebrew. And that's why Elazar wants us to make sure that when a Hebrew character is typed in, the language is automatically set to Hebrew. This is not a problem if you use LyX's keymaps --- the keymap will only translate the characters to Hebrew based on the language. But if you switch the language externally to LyX, then that bypasses the keymap, and the Hebrew will be typed in as Hebrew regardless of the current language setting. I'm ambivalent about this. Certainly there's some sense in what Elazar is saying. And it could confuse a user that doesn't understand what's going on, types in Hebrew by switching the keyboard, and then gets latex which doesn't compile. OTOH, (a) this is only applicable to characters which are only associated with a single language (like Hebrew), but not with characters which are associated with many languages (like many European languages). (b) I think that implementing this kind of mechanism would not be trivial, and would introduce additional complexities into the code; and would also be costly at runtime, adding a new step to be performed for every keystroke (though I may be wrong on both counts); and (c) which I'm adamant about: this must not *replace* the current system. It is very important to be able to explicitly override the language if one wants too --- maybe not for the strongly-associated characters, but certainly for all others. Perhaps with some creative thinking we could work something out, but it should wait until after 1.5.0. Dov
Re: Putting Rtl content in Insets
On Wed, May 30, 2007 at 07:48:41AM +0200, Jean-Marc Lasgouttes wrote: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | I prefer No document open! Lars Sounds strange. Is that even english? Lars I thought that 'No' usually required plural (unless you want to Lars give it a different meaning.) I do not know... So where are the native English speakers? I think '0' comes with plural in English and singular in French. I am not sure whether '0' and 'No' are equivalent, though. And of course, I am not a native speaker... Andre'
Re: [Cvslog] r18569 - in /lyx-devel/trunk/src: Cursor.cpp Cursor.h LyX...
On Wed, May 30, 2007 at 08:44:22AM +0200, Abdelrazak Younes wrote: Stefan Schimanski wrote: Just debugging, to see the values easily in gdb, that's why it is in #ifdef DEBUG ... #endif It is producing as much output as other debug output lines which are non-effective in release mode... Unused variable generates a compilation error with CMake/MSVC... _error_? Andre'
Re: [Patch] Re: Crash when closing document
On Wed, May 30, 2007 at 02:30:37PM +0200, Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. Small remark: note that not all DocIterators need to be stable (mainly cursors, maybe also bookmarks error marks), one could have a class derived from DocIterator for that purpose. I agree but it's more work than my signal based solution which is assured to work in all cases. A signal per inset is not acceptable. Full stop. Per InsetText and InsetMathHull it is acceptable space-wise but then I still don't agree with the approach. Andre'
Re: [patch] request for permission to add more symbols to unicodesymbols file
Uwe Stöhr wrote:
Andre Poenitz schrieb:
(Using \={} is too short for the OVERLINE, it has to be the same
length as \_ )
\raisebox{1.3ex}{\_}
This is too low, the overline has to be in the same height as the bar
above an M: \=M
I found out that this would then be
\raisebox{2.61ex}{\_}
yes, that's right, but is save to use
\newcommand*\oline{\ensuremath{\overline{\phantom{A
A\oline B
Herbert
Re: Cursor movement performance problems in 1.5svn
On Wed, May 30, 2007 at 01:39:58PM +0200, Helge Hafting wrote: While testing scrolling, I noticed that moving the cursor around seems to be rather heavy work. Moving the cursor sideways on a line is snappy, but this movement takes 33% of the cpu according to top. Moving the cursor up/down seems sluggish compared to sideways movement, and LyX spend 61% of the cpu on doing this. This is according to top, on a load meter it looks more like 90%. This is just moving the cursorm around. Nothing is changed, and no scrolling either. Only the cursor itself is moved. This on a 2.4GHz pentium, with --disable-stdlib-debug Is this a known problem, with a planned fix? It cannot possibly be necessary, and of course other software don't do this. Thunderbird needs 6% of the cpu to do the same. There's a difference between displaying more or less static text and having the same text with wildly variying objects in an editable state. But you are right, scrolling is still too expensive. Andre'
Re: beamer suggestion
Actually, most of my frames are just a big itermize. So you choose begin frame, put a title, switch to itemize, add items. Now if you choose 'begin frame', guess what you've got? begin frame inside an item. blahh. You only need to insert 'endframe' environment at the end of a document. As of frame inside item environment, you need to change environment depth. Bo
Re: beamer suggestion
Paul A. Rubin wrote: Neal Becker wrote: I think inserting begin frame should automatically add the matching end frame. It already does -- it ends the *previous* frame. Doesn't seem to do that for me (1.5.0beta3). Actually, most of my frames are just a big itermize. So you choose begin frame, put a title, switch to itemize, add items. Now if you choose 'begin frame', guess what you've got? begin frame inside an item. blahh.
Re: [Patch] Re: Crash when closing document
On Wed, May 30, 2007 at 08:37:09AM +0200, Abdelrazak Younes wrote: Andre Poenitz wrote: On Tue, May 29, 2007 at 10:11:16PM +0200, Stefan Schimanski wrote: I enabled stdlib-debug and then were surprised about the slowness. Some profiling was full of signal/slot stuff in copying cursors Well, I am not complaining about slowness (which hardly can be judged by a non-optimized build) but about the concept. If we need some kind of checked iterators (and we probably do) this should be done properly by e.g. registering the iterators with the buffers or such, not by working around symptoms by invalidating single slices. I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. It would be a robust solution. What makes me really angry is that I thought I was clear enough when I put If you are angry, then I suggest that, in the future you should more closely follow the list and comment when the changes are proposed. Please give a pointer to the relevant discussion on lyx-devel. Even an admittedly quick look through the archives does not bring up anything that looks like it. // Do not add _any_ (non-static) data members as this would inflate // everything storing large quantities of insets. Mathed e.g. would // suffer. into Inset.h. Yet we get an int in each inset for its background color (very important! and only 4 bytes!), Which was there in InsetOld and InsetMathSomething anyway. So every inset had it! Wrong. svn diff -r 17912:17913. Not even a single math inset touched. And style issues with this patch as well so I doubt I have not seen this dicussion either. I don't know why you are angry that I made that explicit. an in-inset Dimension cache (12 bytes) About the same situation as above. Again wrong. The most commonly used math inset (InsetMathChar) had no dimension cache. For a very good reason that was even written down. when the whole system was designed to work without that, and now a mere 20 additional bytes for a signal that's used in a half-baked solution to plaster over conceptional shortcomings in someone's pet feature. Wrong, this is safe for non-multiview too! And I am pretty sure of that: think externally modified file. With this kind of 'improvement' (and others in the 1.5 cycle) we are now happily spending 48(!) bytes for every single character in mathed (and every time when a copy of it ends up on the undo stack) for what took 12 bytes six months ago. That is true but I reckon that there is more to it anyway. I've checked the memory consumption of a big document full of math with and without this signal an you know what? There is no sensible difference. It's not 'loading a document full of math', it's 'working on a document with math'. You obviously never did that. Konni has files with formulas spanning several pages. These easily several hundreds insets in LyX. Entering and editing this takes easily _several thousands_ operations. Each operation puts the whole thing on the undo stack, so even if this consisted only of 'cheap InsetMathChar', this eats several dozen MB. Reality is worse as there are even fatter insets. And that is for a single formula only. I think I stated this already earlier: LyX is _not_ ready for multiple views. You never proposed a single analysis to prove your statement. Now I can say LyX _is_ ready for multiple views. You broke other areas just to make your pet appear healthy. Andre'
Re: [patch] request for permission to add more symbols to unicodesymbols file
Andre Poenitz schrieb:
(Using \={} is too short for the OVERLINE, it has to be the same length as
\_ )
\raisebox{1.3ex}{\_}
This is too low, the overline has to be in the same height as the bar above an
M: \=M
I found out that this would then be
\raisebox{2.61ex}{\_}
Herbert, is this correct?
thanks and regards
Uwe
Re: [patch] Cursor movement at RTL-LTR boundary
Stefan Schimanski wrote:
Please take care with those changes. Such a +1 can change and break a
lot. In this I am pretty sure that a character is skipped when going
over a newline. I added a special case for the RTL boundary for this line.
Okay, I think I understand (how many times have I said that about this
whole issue already? ;) ). I applied your patch (had to type it in,
though, something about malformed patch) and it works.
Anyhow, I'm attaching your patch back again, just split some line so
they would fit (and this time patch should work ;) ).
Please, can someone else check this so that it can be committed? It
fixes http://bugzilla.lyx.org/show_bug.cgi?id=3754.
Thanks!
Dov
P.S. Stefan, just to make sure I really do understand: what I hadn't
understood until now is so how does just setting the boundary, without
changing the position, make the cursor move?. I think now I get it:
when the cursor drawing is done, it looks at the boundary: if the
boundary is set, it draws the cursor at the position of the character
*before* the boundary, otherwise it draws it at the position of the
current character. So moving forward (pos+1) but setting the boundary to
true will not register a movement; and staying at the same position, but
changing the boundary back to false, *will* appear to move. Is this correct?
Index: src/Text2.cpp
===
--- src/Text2.cpp (revision 18579)
+++ src/Text2.cpp (working copy)
@@ -1030,8 +1030,11 @@
// not at paragraph end?
if (cur.pos() != cur.lastpos()) {
- // if left of boundary - just jump to right side
- if (cur.boundary())
+ // if left of boundary - just jump to right side
+ // but for RTL boundaries don't, because:
+ // abc|DDEEFFghi - abcDDEEF|Fghi
+ if (cur.boundary()
+ !bidi.isBoundary(cur.buffer(), cur.paragraph(),
cur.pos()))
return setCursor(cur, cur.pit(), cur.pos(), true,
false);
// in front of editable inset, i.e. jump into it?
@@ -1061,6 +1064,12 @@
!cur.paragraph().isSeparator(cur.pos())) {
return setCursor(cur, cur.pit(), cur.pos() + 1, true,
true);
}
+
+ // in front of RTL boundary? Stay on this side of the boundary
because:
+ // ab|cDDEEFFghi - abc|DDEEFFghi
+ if (bidi.isBoundary(cur.buffer(), cur.paragraph(), cur.pos() +
1)) {
+ return setCursor(cur, cur.pit(), cur.pos() + 1, true,
true);
+ }
// move right
return setCursor(cur, cur.pit(), cur.pos() + 1, true, false);
[PATCH] Fix QInclude Enter Behavior
This patch was discussed a bit here. Angus suggested the problem was with signals from the QComboBox causing changes in the ButtonController, but I've investigated that and that does not seem to be the issue. In any event, this fixes the problem. OK to commit? Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto Index: QInclude.cpp === --- QInclude.cpp (revision 18579) +++ QInclude.cpp (working copy) @@ -133,6 +133,7 @@ visiblespaceCB-setEnabled(false); visiblespaceCB-setChecked(false); previewCB-setEnabled(false); + previewCB-setChecked(false); listingsGB-setEnabled(true); break; //case Verbatim @@ -143,6 +144,10 @@ listingsGB-setEnabled(false); break; } + //see this thread + // http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg118471.html + //for the reason this is here. + okPB-setDefault(true); }
Re: [Patch] Re: Crash when closing document
On Wed, May 30, 2007 at 02:37:43PM +0200, Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I agree but it's more work than my signal based solution Abdelrazak which is assured to work in all cases. I tell you what, in Abdelrazak order to save the bits Andre is worried about I am going Abdelrazak to remove the signal from Inset and transfer them to Abdelrazak InsetText and InsetMathHull. In 1.6, we can think of this Abdelrazak other solution. But really, my solution is cheap in terms Abdelrazak of CPU and it will be cheaper in terms of memory when I do Abdelrazak the change described above. So it is not realted to Helge's comlaint that moving the cursor produces a high CPU load? I have just browsed through boost/signals and I have a hard time to believe my eyes. A signal is not only the 20 static bytes I noticed yesterday, but there is Pandora's box of dynamic components hidden in it. When no slot is connected, a signal takes up a total of ~200 bytes of static and dynamic memory, connected to a single slot it takes ~280 bytes. This is ridiculous. Andre' PS: Same test for Qt signal/slot gives btw ~190 bytes for a connected signal and 100 for an unconnected one. So once more we picked the more expensive solution, but that's an issue I do not want to discuss in this thread...
Re: [Patch] Re: Crash when closing document
On Wed, May 30, 2007 at 02:42:14PM +0200, Alfredo Braunstein wrote: Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: I am not sure that registering every single DocIterator would be any more efficient that my signal/slot solution. At the end you will have to go through a table. Small remark: note that not all DocIterators need to be stable (mainly cursors, maybe also bookmarks error marks), one could have a class derived from DocIterator for that purpose. I agree but it's more work than my signal based solution which is assured to work in all cases. I tell you what, in order to save the bits Andre is worried about I am going to remove the signal from Inset and transfer them to InsetText and InsetMathHull. In 1.6, we can think of this other solution. But really, my solution is cheap in terms of CPU and it will be cheaper in terms of memory when I do the change described above. In general terms Abdel I agree that it is not so bad if it really works (in order to implement a correct solution (TM) having something working even if inefficient is /good/, not bad), but are we sure that it works in all cases? In general it seems wrong to me that invalidation of cursors is only due to inset destruction. For instance, put a cursor inside an inset, then in another window add or remove some text before the inset so the position of the inset changes... no destruction occurs, but is the cursor still valid? (sorry don't have svn to check here.) It isn't, as the pos() in the slice corresponding to the changed inset is changed. Andre'
Re: [Patch] Re: Crash when closing document
Abdelrazak Younes wrote: I did not think of that :-(. That could work indeed. I don't have the time to implement this right now, maybe this could be the occasion of a patch from you to signal that your come back is real? :-) My come back? What, did I accidentally left? ;-) A/
Re: [Patch] Re: Crash when closing document
On Wed, May 30, 2007 at 03:26:04PM +0200, Alfredo Braunstein wrote: Just a though... why do we need the invalidation signals at all? ...couldn't we go in fixIfBroken from the top to the tip of the DocIterator checking that there is an inset an the given position in the paragraph, and that the pointer of that inset is the one in the iterator in the next slice (as well as the idx, pit, pos checks)? This would probably be saner thatn what we have now but still lead to funyy behaviour asm in [inset 1] \par [inset |2] \par [inset 3] Delete par 1 and you'll end up with [inset 2] \par [inset |3] Andre'
What Qt Version Does 1.5 Presume?
In particular, do we presume Qt 4.1? -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Patch] Re: Crash when closing document
On Wed, 30 May 2007 19:20:50 +0200 Andre Poenitz [EMAIL PROTECTED] wrote: ... an in-inset Dimension cache (12 bytes) About the same situation as above. Again wrong. The most commonly used math inset (InsetMathChar) had no dimension cache. For a very good reason that was even written down. Yes... this is bad if it has disappeared, as it seems it has. - Martin
Re: [Patch] Re: Crash when closing document
On Wed, May 30, 2007 at 05:44:39PM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak I won't say random because as you found out you can Abdelrazak predict the behaviour. After I have edited during 10 minutes in one part of the document, the location in the other place will really seem random. Abdelrazak We could think of the solution that takes into account the Abdelrazak par id (and thus using Bookmarks instead of fixing the Abdelrazak Cursor). But quite Frankly, this is not a major issue for Abdelrazak now. Also, if I edit and use undo, the cursor will not be placed back where it was in the other window. These problems do not mean that you implemented badly, just that it is a bigger task than you thought. As I said and using Alfredo's words, I was well aware of this side-effect and I already accepted it. Had you any intentions to make a wider audience aware of these side-effects? Are there possibly other side effects that you already accepted? Andre'
Re: [Patch] Re: Crash when closing document
On Wed, May 30, 2007 at 05:46:46PM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: These problems do not mean that you implemented badly, just that it is a bigger task than you thought. An by the way, the additional work required to properly handling these cursors is basically *nothing* compared to what I've done to support multipleviews ;-) You are a hero. Let me kiss the soles of your feet. Andre'
Re: [patch] fixing segfault because of empty coord cache
On Wed, May 30, 2007 at 05:56:35PM +0200, Abdelrazak Younes wrote: Stefan Schimanski wrote: Hi! Here is a patch for a crash that happens due to a cell not in the coord cache during the drawing of the selection. It could be that this is related (and also fixes) http://bugzilla.lyx.org/show_bug.cgi?id=3715 . I believe the problem is when an inset derived from InsetMathNest does not draw all its cells, and hence a cell is not in the coord cache yet. Then the warm up call in InsetMathNest::drawSelection cannot get the cell into the cache and the loop over all cells at the bottom of this very function will trigger an assertion. You can trigger this crash in Beta 3 or 1.5svn like this: New document, Ctrl-M \ref space shift-right With this patch the shift-right seems to have no effect. Haven't checked why. But at least the segfault is gone. Probably because the cell is not in the cache. The patch looks good and safe. An interesting question might be: Why was it not in the cache?. Andre'
Re: [patch] request for permission to add more symbols to unicodesymbols file
Uwe Stöhr wrote:
\newcommand*\LyXrightangle{{\usefont{U}{msa}{m}{n}\char120}}
Many thanks.
Where is a table to look what number corresponds to what character in
the font files? I seared for a code chart table for msam and msbm but
couldn't found this character there.
Now only these characters used in Windows' standard fonts are not
supported:
2015 HORIZONTAL BAR: ―
203e OVERLINE: ̅
20a7 PESETA SIGN: ₧ (no longer widely used due to the € sign)
20aa NEW SHEQEL SIGN: ₪
2302 HOUSE: ⌂
\newcommand*\DEL{{\fontencoding{U}\fontfamily{ascii}\selectfont\char127}}
2320 TOP HALF INTEGRAL: ⌠
2321 BOTTOM HALF INTEGRAL: ⌡
25ac BLACK RECTANGLE: ▬
\newcommand*\SYN{{\fontencoding{U}\fontfamily{ascii}\selectfont\char022}}
25d8 INVERSE BULLET: ◘
\newcommand*\BS{{\fontencoding{U}\fontfamily{ascii}\selectfont\char008}}
25d9 INVERSE WHITE CIRCLE: ◙
\newcommand*\LF{{\fontencoding{U}\fontfamily{ascii}\selectfont\char010}}
needs installed ascii font, which should be on all systems, but
sometimes the map is not proper installed:
updmap Map=ascii.map
Herbert
Re: Updates to the Hebrew translation
Dov Feldstern [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Elazar Leibovich [EMAIL PROTECTED] writes:
| | On 28 May 2007 23:07:36 +0200, Lars Gullik Bjønnes
| [EMAIL PROTECTED] wrote:
| | Elazar Leibovich [EMAIL PROTECTED] writes:
| |
| | | Isn't that wise that the language will be automatically detected by
| | | the input-language. ie, English letters will always be English,
| | | Hebrew/Arabic letters will always be Hebrew/Arabic and neutral
| | | characters will be the same language of the paragraph.
| | | That way, the user won't be forced to learn new key combinations to
| | | switch languages.
| |
| | I think I said in some other mail some hours ago:
| | (paraphrasing)
| | There is a difference between characters and language. You wouldn't
| | expect all latin characters to mean that you are writing latin would
| | you?
| | | You did and it is true generally. However, there is a
| difference. In
| | hebrew you'll never ever wish to have hebrew characters written in a
| | language different than Hebrew. It'll just be outputted wrongfully.
| What about norwegian? Could it be that I'd like to write a hebrew
| character there? as a reference to something? As a linguist f.ex?
|
|
| Well, I think you're misunderstanding each other:
|
| Certainly, you may be writing a document in Norwegian, and want to
| insert some Hebrew.
Hmm da hmm... but no that is not what I want. I don't want to insert
some hebrew, just a character from the hebrew alphabet.
If to get this hebrew character output/rendered by latex it mean that
this single char is enclosed in some \lang{hebrew} is an export
detail. I am still not using any hebrew in my document.
--
Lgb
Re: [Cvslog] r18569 - in /lyx-devel/trunk/src: Cursor.cpp Cursor.h LyX...
+#ifdef DEBUG +bool bound = cur.boundary(); +int rowpos = cur.textRow().pos(); +int pos = cur.pos(); +bool sep = cur.paragraph().isSeparator(cur.pos() - 1); +bool newline = cur.paragraph().isNewline(cur.pos() - 1); +bool linesep = cur.paragraph().isLineSeparator(cur.pos() - 1); +#endif Given that nobody seems to have told Stefan how to avoid the error on MSVC, let me jump in. The trick, Stefan, is to do something like: bool bound = ...; (void)bound; Given that the meaning of that cast is rather inpenetrable, you might prefer to use: bool bound = ...; boost::unused_variable(bound); (The name of the function is probably wrong, but a quick search through the LyX sources will turn up the correct name.) Angus
