Re: cutandpaste.C simplifications
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Mon, Nov 06, 2006 at 11:03:55PM +0100, Michael Gerz wrote: Hi, am I too stupid to see the brilliancy of the code or can cutandpaste.C be simplified? Martin Probably both ;-) Yes, I suspect that someone wanted to play with all the new toys he read about in a C++ book. JMarc
Re: cutandpaste.C simplifications
Jean-Marc Lasgouttes wrote: Yes, I suspect that someone wanted to play with all the new toys he read about in a C++ book. No. resetParagraph was used in two places (see 1.4), therefore it made sense to not duplicate the code. Georg
Re: QT Translation
Michael Gerz wrote:
Hi,
this patch makes Qt strings translateable again (at least when using
scons).
Can I commit?
No. Adding qt_helpers.h to all includes is wrong. The attached patch
contains an example how to do it correctly (and how it was done in qt3) and
fixes the autotools part at the same time.
My uic (version 4.1.4) generates calls to the translation function with a
second argument. Did you not need that? I have no idea what it is supposed
to do.
GeorgIndex: src/frontends/qt4/qt_helpers.C
===
--- src/frontends/qt4/qt_helpers.C (Revision 15777)
+++ src/frontends/qt4/qt_helpers.C (Arbeitskopie)
@@ -155,8 +155,9 @@ void qstring_to_ucs4(QString const qst
}
-QString const qt_(char const * str)
+QString const qt_(char const * str int dummy)
{
+ // FIXME: Look up in uic docs what dummy is supposed to do
return toqstr(_(str));
}
Index: src/frontends/qt4/qt_helpers.h
===
--- src/frontends/qt4/qt_helpers.h (Revision 15777)
+++ src/frontends/qt4/qt_helpers.h (Arbeitskopie)
@@ -104,7 +104,7 @@ void qstring_to_ucs4(QString const qst
*
* Use this in qt4/ instead of qt_()
*/
-QString const qt_(char const * str);
+QString const qt_(char const * str, int dummy = 0);
/**
Index: src/frontends/qt4/ui/QAskForTextUi.ui
===
--- src/frontends/qt4/ui/QAskForTextUi.ui (Revision 15777)
+++ src/frontends/qt4/ui/QAskForTextUi.ui (Arbeitskopie)
@@ -103,6 +103,9 @@
/layout
/widget
pixmapfunction/pixmapfunction
+ includes
+ include location=local qt_helpers.h/include
+ /includes
resources/
connections/
/ui
Index: src/frontends/qt4/ui/Makefile.am
===
--- src/frontends/qt4/ui/Makefile.am (Revision 15777)
+++ src/frontends/qt4/ui/Makefile.am (Arbeitskopie)
@@ -8,7 +8,7 @@ EXTRA_DIST = $(UIFILES)
BUILT_SOURCES = $(UIFILES:.ui=.h)
# Use _() for localization instead of tr() or trUtf8()
-UICFLAGS=-tr qt_
+UIC4FLAGS=-tr lyx::qt_
%.h: %.ui
$(UIC4) $(UIC4FLAGS) $ -o $@
Re: QT Translation
On Tuesday 07 November 2006 8:34 am, Georg Baum wrote:
-QString const qt_(char const * str)
+QString const qt_(char const * str int dummy)
{
Isn't there a comma missing between str and int in the line above?
--
José Abílio
Re: QT Translation
José Matos wrote:
On Tuesday 07 November 2006 8:34 am, Georg Baum wrote:
-QString const qt_(char const * str)
+QString const qt_(char const * str int dummy)
{
Isn't there a comma missing between str and int in the line above?
Yes. I did not notice because the patch was incomplete anyway and I could
not compile all.
Georg
AW: Re: cutandpaste.C simplifications
Jean-Marc Lasgouttes wrote: Yes, I suspect that someone wanted to play with all the new toys he read about in a C++ book. No. resetParagraph was used in two places (see 1.4), therefore it made sense to not duplicate the code. I dropped the second call to resetParagraph because I think it is pointless. There is nothing to reset. Agreed? Michael
Re: AW: Re: cutandpaste.C simplifications
[EMAIL PROTECTED] wrote: Jean-Marc Lasgouttes wrote: Yes, I suspect that someone wanted to play with all the new toys he read about in a C++ book. No. resetParagraph was used in two places (see 1.4), therefore it made sense to not duplicate the code. I dropped the second call to resetParagraph because I think it is pointless. There is nothing to reset. Agreed? Yes, it looks like a single empty paragraph was reset. This was introduced by Andre, I guess either as result of some copy/paste, or because he did not know whether it was needed for change tracking. I am not sure of the latter either, but I am sure that you know :-) Georg
[patch] sledgehammer
With the attached brute force workaround, the doc and prefs dialogs are resizing properly again in Qt 4.2.1. Opinions? Jürgen P.S.: no, I don't like it either. Index: src/frontends/qt4/QDocumentDialog.C === --- src/frontends/qt4/QDocumentDialog.C (Revision 15766) +++ src/frontends/qt4/QDocumentDialog.C (Arbeitskopie) @@ -402,6 +402,10 @@ QDocumentDialog::QDocumentDialog(QDocume docPS-addPanel(branchesModule, _(Branches)); docPS-addPanel(preambleModule, _(LaTeX Preamble)); docPS-setCurrentPanel(_(Document Class)); +// FIXME: hack to work around resizing bug in Qt = 4.2 +#if QT_VERSION = 0x040200 + docPS-updateGeometry(); +#endif } Index: src/frontends/qt4/QPrefsDialog.C === --- src/frontends/qt4/QPrefsDialog.C (Revision 15766) +++ src/frontends/qt4/QPrefsDialog.C (Arbeitskopie) @@ -1887,6 +1887,10 @@ QPrefsDialog::QPrefsDialog(QPrefs * form add(new PrefIdentity); prefsPS-setCurrentPanel(_(User interface)); +// FIXME: hack to work around resizing bug in Qt = 4.2 +#if QT_VERSION = 0x040200 + prefsPS-updateGeometry(); +#endif form_-bcview().setOK(savePB); form_-bcview().setApply(applyPB);
Re: [patch] sledgehammer
Juergen Spitzmueller wrote: With the attached brute force workaround, the doc and prefs dialogs are resizing properly again in Qt 4.2.1. Opinions? Jürgen P.S.: no, I don't like it either. Better than nothing... Abdel.
Re: [patch] sledgehammer
Abdelrazak Younes wrote: Better than nothing... I think so, too. However, for the character dialog, I didn't find an appropriate position where to insert the updateGeometry() call (i.e. it didn't work where I've tried). Jürgen
Re: r15778 - /lyx-devel/trunk/Status.15x
[EMAIL PROTECTED] wrote: * There should be a close button on the tabs (Joost 3/11/06). + There is now a Qt feature request: + http://www.trolltech.com/developer/task-tracker/index_html?id=137891metho d=entry BTW KTabbar has a nice HoverCloseButton feature (used by Quanta+, for instance). Perhaps we can borrow some ideas from this? http://api.kde.org/3.3-api/kdeui/html/ktabbar_8cpp-source.html http://api.kde.org/3.3-api/kdeui/html/ktabwidget_8cpp-source.html Jürgen
Re: Can LyX handle large files ?
[EMAIL PROTECTED] schrieb: On Tue, 7 Nov 2006, [EMAIL PROTECTED] wrote: So any help is appreciated. But the advice to turn instant preview off is equivalent to saying quit LyX. Then you can try: * Use an older version of LyX (1.3.7 ?) * Split your document into several parts hope any of this helps. /Christian PS. It'd be even better if you could help us discover *why* it's so slow so that it can be fixed, but unfortunately I don't have any ideas on this. If you are interested in helping, you could however contact the developers' list and ask if there's any kind of debugging information you can give them. lyx-devel AT lists.lyx.org I would be happy to help with finding the bug, thats why I send a copy of this to the devel-list. Splitting the document into parts would only be a crutch, since I often need to manage references to earlier theorems, to equation numbers, etc.. I could imagine a feature like folding away a section, so the heading would be shown but the section is only opened when you double-click on the section heading. Another possibility, I could imagine, is making the generated pngs resident, so they need not be generated again when I start lyx with the same document next time. One problem, however, is that I am working on the same document at work during the day, and at home in the evening. (By the way, the reported behaviour is the same on both computers. It could not only be faulted to csrssexe, since during the 3.5 min. of LyX not responding the process manager only credits 25% to csrss.exe and 75% to lyx.exe ) I am indeed considering reinstalling some old version of LyX, although this is like withdrawing my chips from LyX ... H.Peter
Re: Can LyX handle large files ?
On Tue, 7 Nov 2006, [EMAIL PROTECTED] wrote: Splitting the document into parts would only be a crutch, since I often need to manage references to earlier theorems, to equation numbers, etc.. Umm... as far as I know and remember from writing my thesis, this works just fine for a multi-part document. In order to access references to another sub-document you just need to have compiled the entire document once. Then LyX remembers what references etc the other sub-documents have. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Can LyX handle large files ?
[EMAIL PROTECTED] wrote: I would be happy to help with finding the bug, thats why I send a copy of this to the devel-list. Splitting the document into parts would only be a crutch, since I often need to manage references to earlier theorems, to equation numbers, etc.. That works well as long as you open the child documents from the master document. Then references etc are known across all parts. I could imagine a feature like folding away a section, so the heading would be shown but the section is only opened when you double-click on the section heading. That would be nice to have anyway. Another possibility, I could imagine, is making the generated pngs resident, so they need not be generated again when I start lyx with the same document next time. One problem, however, is that I am working on the same document at work during the day, and at home in the evening. I don't think that the previews are the problem. Surely it takes some time ot process them, but this is done iun the background, and although LyX is a bit slower until they are generated it is still usable (at least on linux). (By the way, the reported behaviour is the same on both computers. It could not only be faulted to csrssexe, since during the 3.5 min. of LyX not responding the process manager only credits 25% to csrss.exe and 75% to lyx.exe ) No, csrss.exe does not seem to be the problem, it only seems to be a symptom. See http://bugzilla.lyx.org/show_bug.cgi?id=2900 for more information. There was also a thread some time ago with a good explanation: http://www.mail-archive.com/lyx-users%40lists.lyx.org/msg51385.html What we know so far is that the slowness is related to math. It is improved by Instant Preview sometimes, but not completely solved. The reason is probably that the way how math insets are drawn on screen (and/or the metrics are calculated) is done in a way that is very expensive on windows. I am indeed considering reinstalling some old version of LyX, although this is like withdrawing my chips from LyX ... That would be a pity, but I guess we can find the bug with the help of somebody who is able to do some profiling on windows. Unfortunately we did not really get started on that, since profilers on windows either seem to be expensive (glowcode), or complicated to use (kernrate). Georg
Re: Can LyX handle large files ?
Georg Baum wrote: [EMAIL PROTECTED] wrote: (By the way, the reported behaviour is the same on both computers. It could not only be faulted to csrssexe, since during the 3.5 min. of LyX not responding the process manager only credits 25% to csrss.exe and 75% to lyx.exe ) No, csrss.exe does not seem to be the problem, it only seems to be a symptom. See http://bugzilla.lyx.org/show_bug.cgi?id=2900 for more information. There was also a thread some time ago with a good explanation: http://www.mail-archive.com/lyx-users%40lists.lyx.org/msg51385.html What we know so far is that the slowness is related to math. It is improved by Instant Preview sometimes, but not completely solved. The reason is probably that the way how math insets are drawn on screen (and/or the metrics are calculated) is done in a way that is very expensive on windows. I've tested again this document and the good news is that the performance will soon be a bit better in 1.5 with my forthcoming painting performance patch. But the problem I think Georg is right in that the problem lies in how lines and symbols are painted on screen with mathed. Abdel.
Re: Lyx1.5 crashes in preferences
i've been trying to look into this weird crash and have added the
following to see which converters are there:
void PrefConverters::updateButtons()
{
lyxerr UPDATEBUTTONS START std::endl;
Converters::const_iterator ccit1 = form_-converters().begin();
Converters::const_iterator cend1 = form_-converters().end();
for (; ccit1 != cend1; ++ccit1) {
int type = form_-converters().getNumber(ccit1-From-name(),
ccit1-To-name());
lyxerr from: ccit1-From-name() to:
ccit1-To-name() type type std::endl;
}
lyxerr UPDATEBUTTONS END std::endl;
Converters::const_iterator ccit = form_-converters().begin();
Converters::const_iterator cend = form_-converters().end();
for (; ccit != cend; ++ccit) {
int type = form_-converters().getNumber(ccit-From-name(),
ccit-To-name());
lyxerr from: ccit-From-name() to:
ccit-To-name() type type std::endl;
}
the strange thing is that on initialisation it loops twice over the same
list:
UPDATEBUTTONS START
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
UPDATEBUTTONS END
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
but when i change something in the file formats (which then updates the
converters) the second loop over the converters shows no longer the same:
UPDATEBUTTONS START
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
UPDATEBUTTONS END
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
from: bmp to: dateout type -1
from: pbm to: asciiimage type -1
from: bmp to: png type -1
from: literate to: png type -1
from: bmp to: xpm type -1
from: bmp to: tiff type -1
from: text4 to: asciichess type -1
from: text4 to: pdf type -1
from: dateout to: text4 type -1
from: dateout to: textparagraph type -1
from: ppm to: agr type -1
from: text to: asciichess type -1
from: bmp to: text3 type -1
from: ppm to: html type -1
from: text2 to: lyxpreview type -1
from: word to: wordhtml type -1
from: dvi to: linuxdoc type -1
from: docbook to: program type -1
from: docbook to: tgif type -1
from: png to: ps type -1
anyone a clue what is happening here?
thanks, ed
Re: r15778 - /lyx-devel/trunk/Status.15x
Juergen Spitzmueller wrote: [EMAIL PROTECTED] wrote: * There should be a close button on the tabs (Joost 3/11/06). + There is now a Qt feature request: + http://www.trolltech.com/developer/task-tracker/index_html?id=137891metho d=entry BTW KTabbar has a nice HoverCloseButton feature (used by Quanta+, for instance). Perhaps we can borrow some ideas from this? http://api.kde.org/3.3-api/kdeui/html/ktabbar_8cpp-source.html http://api.kde.org/3.3-api/kdeui/html/ktabwidget_8cpp-source.html This version is even better as it is for KDE4 and the dependency on other kde headers is very minimal: http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdeui/html/classKTabWidget.html Abdel.
Question about wide inset...
Dear Martin, dear all,
While trying to understand how the inset metrics are updated I stumbled
on this potential problem:
Find all wide_inset_, Match case, Whole word, Subfolders, Find Results
1, lyx-trunk, *.c;*.cpp;*.cxx;*.cc;*.tli;*.tlh;*.h;*.hpp;*.hxx;*.hh
D:\devel\lyx\trunk\src\insets\insettext.h(136):
bool Wide() const { return wide_inset_; }
D:\devel\lyx\trunk\src\insets\insettext.h(159):
mutable bool wide_inset_;
Matching lines: 2Matching files: 1Total files searched: 968
This means that the wide_inset_ variable is never set. By default, I
guess it is set to false on windows but I am not sure about other
platform. I seem to remember some discussion about this between Martin
and John; could you put some light on this matter?
Thanks in advance,
Abdel.
Re: Question about wide inset...
Abdelrazak Younes wrote:
Dear Martin, dear all,
While trying to understand how the inset metrics are updated I stumbled
on this potential problem:
Find all wide_inset_, Match case, Whole word, Subfolders, Find Results
1, lyx-trunk, *.c;*.cpp;*.cxx;*.cc;*.tli;*.tlh;*.h;*.hpp;*.hxx;*.hh
D:\devel\lyx\trunk\src\insets\insettext.h(136):
bool Wide() const { return wide_inset_; }
D:\devel\lyx\trunk\src\insets\insettext.h(159):
mutable bool wide_inset_;
Matching lines: 2Matching files: 1Total files searched: 968
This means that the wide_inset_ variable is never set.
Hum... I missed the mutable tag... Ok, it is used in rc\rowpainter.C(888):
// If this is the only object on the row, we can make it wide
for (pos_type i = rit-pos() ; i != rit-endpos(); ++i) {
InsetBase const * const in = par.getInset(i);
if (in) {
InsetText const * const t = in-asTextInset();
if (t)
t-Wide() = in_inset_alone_on_row;
}
}
I stand corrected but a const method giving non-const reference access a
mutable variable is not very nice.
Abdel.
Re: Question about wide inset...
Abdelrazak Younes wrote:
// If this is the only object on the row, we can make it wide
for (pos_type i = rit-pos() ; i != rit-endpos(); ++i) {
InsetBase const * const in = par.getInset(i);
if (in) {
InsetText const * const t = in-asTextInset();
if (t)
t-Wide() = in_inset_alone_on_row;
}
}
I stand corrected but a const method giving non-const reference access a
mutable variable is not very nice.
I've changed that and added a FIXME.
Abdel.
Author: younes
Date: Tue Nov 7 16:21:47 2006
New Revision: 15779
URL: http://www.lyx.org/trac/changeset/15779
Log:
* InsetText:
- wide_inset_ is not mutable any more
- Wide(): split up in Wide() and setWide()
* rowpainter.C:
- paintPar(): use a const_cast instead of the mutable InsetText::Wide()
Modified:
lyx-devel/trunk/src/insets/insettext.h
lyx-devel/trunk/src/rowpainter.C
Modified: lyx-devel/trunk/src/insets/insettext.h
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/insettext.h?rev=15779
==
--- lyx-devel/trunk/src/insets/insettext.h (original)
+++ lyx-devel/trunk/src/insets/insettext.h Tue Nov 7 16:21:47 2006
@@ -133,7 +133,9 @@
///
InsetText(InsetText const );
///
- bool Wide() const { return wide_inset_; }
+ bool Wide() const { return wide_inset_; }
+ ///
+ void setWide(bool wide_inset) { wide_inset_ = wide_inset; }
protected:
///
@@ -156,7 +158,7 @@
///
static int border_;
///
- mutable bool wide_inset_;
+ bool wide_inset_;
public:
///
mutable LyXText text_;
Modified: lyx-devel/trunk/src/rowpainter.C
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/rowpainter.C?rev=15779
==
--- lyx-devel/trunk/src/rowpainter.C (original)
+++ lyx-devel/trunk/src/rowpainter.C Tue Nov 7 16:21:47 2006
@@ -880,12 +880,17 @@
text);
// If this is the only object on the row, we can make it wide
+ //
+ // FIXME: there is a const_cast here because paintPar() is not
supposed
+ // to touch the paragraph contents. So either we move this
wide
+ // property out of InsetText or we localize the feature to the
painting
+ // done here.
for (pos_type i = rit-pos() ; i != rit-endpos(); ++i) {
InsetBase const * const in = par.getInset(i);
if (in) {
- InsetText const * const t = in-asTextInset();
+ InsetText * t = const_castInsetText
*(in-asTextInset());
if (t)
- t-Wide() = in_inset_alone_on_row;
+ t-setWide(in_inset_alone_on_row);
}
}
Re: Can LyX handle large files ?
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I've tested again this document and the good news is that Abdelrazak the performance will soon be a bit better in 1.5 with my Abdelrazak forthcoming painting performance patch. But the problem I Abdelrazak think Georg is right in that the problem lies in how lines Abdelrazak and symbols are painted on screen with mathed. It would be interesting to know whether the situation improves when the TeX fonts are unavailable. This is the only difference I can think of between math and non-maths. It may be that these fonts are expensive to handle. JMarc
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: It would be interesting to know whether the situation improves when the TeX fonts are unavailable. This is the only difference I can think of between math and non-maths. It may be that these fonts are expensive to handle. That could be easily checked by letting symbolFamily() in GuiFontLoader.C return an empty string. That disables all symbol fonts. You mean the Bakoma fonts, don't you? The Bakoma fonts are one package of the TeX fonts in truetype format. Others do exist, too. Georg
Re: QT Translation
Georg Baum wrote: Michael Gerz wrote: Hi, this patch makes Qt strings translateable again (at least when using scons). Can I commit? No. Adding qt_helpers.h to all includes is wrong. The attached patch contains an example how to do it correctly (and how it was done in qt3) and fixes the autotools part at the same time. I don't really see the benefit of replacing 30 #include statements by 70 XML include tags but if you like it that way, I will do so. Michael
Re: QT Translation
Michael Gerz wrote: Georg Baum wrote: Michael Gerz wrote: Hi, this patch makes Qt strings translateable again (at least when using scons). Can I commit? No. Adding qt_helpers.h to all includes is wrong. The attached patch contains an example how to do it correctly (and how it was done in qt3) and fixes the autotools part at the same time. I don't really see the benefit of replacing 30 #include statements by 70 XML include tags but if you like it that way, I will do so. This advantage of doing it Georg' way is that the uic generated files will remain self compilable. Abdel.
[Patch] About LyXText::drawSelection
Hello,
I was investigating what is going wring with text selection and I came
across a big #if 0. Svn blame tells me that:
At revision 9325, abraunst duplicated the LyXText::drawSelection()
method and commented out the first version.
At revision 10276 jug (who is Juergen Vigna I guess) changed
encapsulated the commented out code with #if 0/#else/#endif instead.
I think the code has already diverged too much so I am going to commit
the attached, any objection?
Abdel.
Index: text.C
===
--- text.C (revision 15743)
+++ text.C (working copy)
@@ -1953,89 +1953,7 @@
}
-#if 0
// only used for inset right now. should also be used for main text
-void LyXText::drawSelection(PainterInfo pi, int x , int) const
-{
- LCursor cur = pi.base.bv-cursor();
- if (!cur.selection())
- return;
- if (!ptr_cmp(cur.text(), this))
- return;
-
- lyxerr draw selection at x endl;
-
- DocIterator beg = cur.selectionBegin();
- DocIterator end = cur.selectionEnd();
-
- BufferView bv = pi.base.bv;
- Buffer const buffer = *bv.buffer();
-
- // the selection doesn't touch the visible screen
- if (bv_funcs::status(bv, beg) == bv_funcs::CUR_BELOW
- || bv_funcs::status(bv, end) == bv_funcs::CUR_ABOVE)
- return;
-
- Paragraph const par1 = pars_[beg.pit()];
- Paragraph const par2 = pars_[end.pit()];
-
- Row const row1 = par1.getRow(beg.pos(), beg.boundary());
- Row const row2 = par2.getRow(end.pos(), end.boundary());
-
- int y1,x1,x2;
- if (bv_funcs::status(bv, beg) == bv_funcs::CUR_ABOVE) {
- y1 = 0;
- x1 = 0;
- x2 = 0;
- } else {
- y1 = bv_funcs::getPos(beg).y_ - row1.ascent();
- int const startx = cursorX(buffer, beg.top(), begin.boundary());
- if (isRTL(buffer, par1)) {
- x1 = startx;
- x2 = 0 + dim_.wid;
- }
- else {
- x1 = 0;
- x2 = startx;
- }
- }
-
- int y2,X1,X2;
- if (bv_funcs::status(bv, end) == bv_funcs::CUR_BELOW) {
- y2 = bv.workHeight();
- X1 = 0;
- X2 = 0;
- } else {
- y2 = bv_funcs::getPos(end).y_ + row2.descent();
- int const endx = cursorX(buffer, end.top(), end.boundary());
- if (isRTL(buffer, par2)) {
- X1 = 0;
- X2 = endx;
- }
- else {
- X1 = endx;
- X2 = 0 + dim_.wid;
- }
- }
-
- lyxerr y1: y1 y2: y2
- xo: xo_ wid: dim_.wid
-endl;
-
- // paint big rectangle in one go
- pi.pain.fillRectangle(x, y1, dim_.wid, y2 - y1, LColor::selection);
-
- // reset background at begin of first selected line
- pi.pain.fillRectangle(x + x1, y1, x2 - x1, row1.height(),
- LColor::background);
-
- // reset background at end of last selected line
- pi.pain.fillRectangle(x + X1, y2 - row2.height(),
- X2 - X1, row2.height(), LColor::background);
-}
-
-#else
-
void LyXText::drawSelection(PainterInfo pi, int x, int) const
{
LCursor cur = pi.base.bv-cursor();
@@ -2133,7 +2051,6 @@
pi.pain.fillRectangle(x, y2, dim_.wid,
Y1 - y2, LColor::selection);
}
-#endif
bool LyXText::isLastRow(pit_type pit, Row const row) const
{
Re: [Patch] About LyXText::drawSelection
Abdelrazak Younes wrote: Hello, I was investigating what is going wring with text selection and I came across a big #if 0. Svn blame tells me that: At revision 9325, abraunst duplicated the LyXText::drawSelection() method and commented out the first version. This was the CoordBranch merge and it seems that he did duplicate the method as a backup in case something goes wrong afterward. Conclusion 1: I will commit now. Conclusion 2: please people, resist the temptation of #if 0 in SVN code. You can do it as much as you want in your local tree but _not_ in the official tree. Abdel.
Re: Question about wide inset...
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Modified: lyx-devel/trunk/src/insets/insettext.h
| URL:
| http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/insettext.h?rev=15779
| ==
| --- lyx-devel/trunk/src/insets/insettext.h (original)
| +++ lyx-devel/trunk/src/insets/insettext.h Tue Nov 7 16:21:47 2006
| @@ -133,7 +133,9 @@
| ///
| InsetText(InsetText const );
| ///
| - bool Wide() const { return wide_inset_; }
| + bool Wide() const { return wide_inset_; }
| + ///
| + void setWide(bool wide_inset) { wide_inset_ = wide_inset; }
I saw that you already change Wide to wide. nice.
I think you should also change setWide to wide...
void wide(bool wide_inset) { wide_inset_ = wide_inset; }
either both setX and getX, or just X and X (I like this last one
best.)
--
Lgb
Re: Let us remove the multi-window support !
Joost Verburg [EMAIL PROTECTED] writes: | Jean-Marc Lasgouttes wrote: | We could also have multiwindow without the possibility to have a | buffer shown in two different views. This is still much better than | two separate LyX instances, in terms of cut-and-paste in particular. | | Sure, but then we need agreement about whether using a single instance | can be the default behavior. Otherwise usability won't improve | compared to 1.4. As already stated. I do not agree with the above statement at all. -- Lgb
Re: Question about wide inset...
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Modified: lyx-devel/trunk/src/insets/insettext.h
| URL:
| http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/insettext.h?rev=15779
| ==
| --- lyx-devel/trunk/src/insets/insettext.h (original)
| +++ lyx-devel/trunk/src/insets/insettext.h Tue Nov 7 16:21:47 2006
| @@ -133,7 +133,9 @@
| ///
| InsetText(InsetText const );
| ///
| - bool Wide() const { return wide_inset_; }
| + bool Wide() const { return wide_inset_; }
| + ///
| + void setWide(bool wide_inset) { wide_inset_ = wide_inset; }
I saw that you already change Wide to wide. nice.
I think you should also change setWide to wide...
void wide(bool wide_inset) { wide_inset_ = wide_inset; }
either both setX and getX, or just X and X (I like this last one
best.)
Hum, yes I can see that both styles are used. I personally prefer to be
explicit when setting and implicit with getting a variable. This is
consistent with Qt coding style and I've followed pretty much that style
in the new frontend code.
Of course we could say that the style is different if the variable
underneath is a pointer to an object or a POD...
But at the end I guess that it would be better if we settle on one given
style. Let's make a poll! ;-)
Abdel.
Re: request for SVN write access
Uwe Stöhr [EMAIL PROTECTED] writes: | Has he replied yet? | | No :-(. try again (privately) -- Lgb
Re: LyX website broken in Internet Explorer 7
Joost Verburg [EMAIL PROTECTED] writes: | Hi, | | The main LyX website (www.lyx.org) does not work correctly in Internet | Explorer 7. The navigation bar is displayed above the texts, so you | can't read anything. File an explorer 7 bug? I belive we conform to the standards. -- Lgb
About the X11 selection bug
Hello, I've just committed a potential fix, can someone try again please? Abdel.
Re: cutandpaste.C simplifications
Lars Gullik Bjønnes wrote: Michael Gerz [EMAIL PROTECTED] writes: | Hi, | | am I too stupid to see the brilliancy of the code yes. (oh where did the friday go...) It is in the vein of prefere algorithms to manual constructs Anyway, I am going to commit my simplification. The manual construct is a simple loop that is used only once. Michael
Re: Let us remove the multi-window support !
On Tuesday 07 November 2006 4:59 pm, Lars Gullik Bjønnes wrote: As already stated. I do not agree with the above statement at all. I agree with Lars. -- José Abílio
Re: LyX website broken in Internet Explorer 7
On Saturday 04 November 2006 11:29 pm, Joost Verburg wrote: Hi, The main LyX website (www.lyx.org) does not work correctly in Internet Explorer 7. The navigation bar is displayed above the texts, so you can't read anything. Joost, the culprit should be the incorrect rendering of css by Explorer. This implies to play with some of the css parameters to see what is causing this. css is some kind of dark voodoo due to browsers bugs, the worst offender is IE. :-( Regards, Joost -- José Abílio
Re: Let us remove the multi-window support !
José Matos wrote: As already stated. I do not agree with the above statement at all. I agree with Lars. What's wrong with a preference to configure this behavior? On Mac OS X LyX already uses a single process and that's also what Windows users expect. Windows users should not have to worry about the concepts of processes etc. Instead of hard-coding this like on Mac OS X right now, the Windows / Mac installers can set a default in lyxrc.dist and users will always be able to change it. Joost
Re: LyX website broken in Internet Explorer 7
José Matos wrote: css is some kind of dark voodoo due to browsers bugs, the worst offender is IE. :-( No left position is set in the pinmenu div. I fixed it. Joost
Re: [Patch] About LyXText::drawSelection
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak This was the CoordBranch merge and it seems that he did Abdelrazak duplicate the method as a backup in case something goes Abdelrazak wrong afterward. Abdelrazak Conclusion 1: I will commit now. Good. JMarc
Re: Let us remove the multi-window support !
On Tuesday 07 November 2006 6:10 pm, Joost Verburg wrote: José Matos wrote: As already stated. I do not agree with the above statement at all. I agree with Lars. What's wrong with a preference to configure this behavior? On Mac OS X LyX already uses a single process and that's also what Windows users expect. Windows users should not have to worry about the concepts of processes etc. Instead of hard-coding this like on Mac OS X right now, the Windows / Mac installers can set a default in lyxrc.dist and users will always be able to change it. There are two separate issues as we have discussed before. I don't have any problem with your proposal above. I disagree when you say that in terms of usability 1.4 and 1.5 (such as it is) are equal. Joost -- José Abílio
Re: request for SVN write access
try again (privately) I did this right now and hope that the email reached you. regards Uwe
Re: Let us remove the multi-window support !
José Matos wrote: Instead of hard-coding this like on Mac OS X right now, the Windows / Mac installers can set a default in lyxrc.dist and users will always be able to change it. There are two separate issues as we have discussed before. I don't have any problem with your proposal above. OK. I'm only talking about the situation when a user clicks the LyX icon on the desktop or start menu. If LyX is already running, normal behavior for a Windows application is to open a new window in the current process. What would be the best way to send a message to another LyX process? Does Qt provide a cross-platform way to send/receive window messages? Joost
3 important bugs right now - more testing needed!
It seems bug fixing proceeds with a good pace. On my list, there are 3 items now, which should be enough for about one evening: * Spell checking cannot be invoked a second time. This is probably a one-liner. * The first time the spell checker is started, an empty window shown instead of the first misspelled word. Probably also a one-liner. * Cursor is still not visible on MAC Bennett (3/11/06). I propose to revert to the old cursor painting scheme if no progress is made on this. There is about 1 week to the deadline for the test release. It seems Abdel is cooking a painter optimisation, which will require a good deal of testing. Therefore, he should focus on getting that done as soon as possible and leave the bugs for others. So, guys, this is your chance to be a hero. In the testing department, I don't think new showstoppers have appeared for some time, as far as I can tell. Therefore we need more testers, because there *still* are very serious bugs in LyX to be found - bugs that mean that the program can not be used as intended in one serious way or another. Regards, Asger
Re: Can LyX handle large files ?
Am Dienstag, 7. November 2006 16:07 schrieb Abdelrazak Younes: Georg Baum wrote: Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: It would be interesting to know whether the situation improves when the TeX fonts are unavailable. This is the only difference I can think of between math and non-maths. It may be that these fonts are expensive to handle. That could be easily checked by letting symbolFamily() in GuiFontLoader.C return an empty string. That disables all symbol fonts. I've checked that. Without the symbolFamily(), all Greek symbols are replaced with their ascii names in red. Yes, that is what happens if the fonts are not available. Unfortunately that doesn't solve the problem. I still have csrss.exe eating 50% of the CPU... :-( Too bad. Georg
Re: [Cvslog] r15789 - /lyx-devel/trunk/src/mathed/InsetMathSymbol.C
[EMAIL PROTECTED] wrote: FontSetChanger dummy(pi.base, sym_-inset.c_str()); - // FIXME UNICODE Hi Georg, I have two questions: - What are we going to do with all those unicode-related FIXMEs? Are they ticking time-bombs or can they stay for 1.5.0? - Do you have a list of potential features that may be added for 1.5? I must confess that I somehow lost the overview. I suggest adding an MISSING/UNFINISHED FEATURES section to Status1.5. Michael
Re: 3 important bugs right now - more testing needed!
Asger Ottar Alstrup wrote: So, guys, this is your chance to be a hero. Despite the virtual honour, there are also very concrete prizes to win (see Status.15x)! In the testing department, I don't think new showstoppers have appeared for some time, as far as I can tell. Pardon? You really should have a look at Status.15x! I also noticed that some assertions are violated which indicate serious problems in the core Asger, which bug are you going to address tonight? :-) Michael (BTW: I will order the prizes from http://www.spreadshirt.de; I hope we have our mascot as vector graphics)
Re: Can LyX handle large files ?
Am Dienstag, 7. November 2006 16:43 schrieb Abdelrazak Younes: As my painting investigation continue, it seems that this problem has _nothing_ to do with painting on screen at all. Modifying a text line between two huge formula exhibits the slow behaviour even if only the text line is repainted on screen (you can use -dbg painting to make sure of that. I guess this could be related to the data memory models used in mathed. Maybe some big tables created/deleted on the fly? AFAIK no big tables, but in mathed we have many of insets. A single formula can contain 20 or so (and then it is not too big), so a bigger document can contain a 4-digit number of math insets This is different from text, where we have only few insets and most stuff is composed of ordinary characters. This could be a problem, but then we should keep in mind that the slowness was not there in 1.3.x, and the inset structure in mathed did not change. What did change is the cursor and dociterator stuff, but if that is the problem then I don't understand why cssrs.exe consumes so much time, in that case I would rather expect that it is only in lyx.exe Also, this comment from Michael Wojcik* makes me wonder if maybe mathed does something special with lyxerr... any clue someone? If anything is special then the WriteStream. I believe it is also used with lyxerr, but I believe also that Michael meant debug output in general. This happens also in Linux, if you write a lot of stuff to the terminal your program can get really slow. Georg
Nomencl = Notation?
Hi, why are the menu entries called Notation? stdmenus.ui:Item Notation Entry nomencl-insert stdmenus.ui:Item Notation List nomencl-print stdtoolbars.ui: Item Insert notation entry nomencl-insert Michael
Re: [Cvslog] r15789 - /lyx-devel/trunk/src/mathed/InsetMathSymbol.C
Am Dienstag, 7. November 2006 20:35 schrieb Michael Gerz: I have two questions: - What are we going to do with all those unicode-related FIXMEs? Are they ticking time-bombs or can they stay for 1.5.0? I fear that there are time bombs, but not necessarily where the FIXMEs are. Mostly the FIXMEs simply mean that a conversion occurs that will go away if more is converted to unicode. I am pretty sure that we have a couple of places with unciode problems. For example I fixed the branch name problem by simply converting some variables to docstring. I did not track down the real reason for this problem, but there are a couple of problems with utf8 in std::string, for example that length() will lie. - Do you have a list of potential features that may be added for 1.5? I must confess that I somehow lost the overview. I suggest adding an MISSING/UNFINISHED FEATURES section to Status1.5. I just upgraded my old tree with the esint stuff, and am about to prepare a patch. That was also the reason why I looked at InsetMathSymbol. I don't know what others plan. From my side there is the esint support and the image cache which are finished (expect patches soon). The navigation across child documents needs some work performance wise, and since everybody is busy I propose to postpone this- Georg
Re: QT Translation
Am Dienstag, 7. November 2006 17:16 schrieb Michael Gerz: I don't really see the benefit of replacing 30 #include statements by 70 XML include tags but if you like it that way, I will do so. We always try to include as little stuff as possible in headers, so we should do that in this case, too (and I see you did it - thanks). People even invented wrappers for enums so that they can be forward declared. If it was much work complain to the person who removed the includes from the ui files ;-) Georg
Re: Nomencl = Notation?
Am Dienstag, 7. November 2006 20:51 schrieb Michael Gerz: Hi, why are the menu entries called Notation? stdmenus.ui:Item Notation Entry nomencl-insert stdmenus.ui:Item Notation List nomencl-print stdtoolbars.ui: Item Insert notation entry nomencl-insert Because Ugras thought that nomenclature is not well known by non-native speakers. I don't know Notation either. Should we replace it with Glossary and Glossary Entry instead? Georg
Re: 3 important bugs right now - more testing needed!
Michael Gerz wrote: Pardon? You really should have a look at Status.15x! I also noticed that some assertions are violated which indicate serious problems in the core I did look at Status.15x, and did not find anything critical. Please correct me if I overlooked something, but to me it looks very much like the bugzilla db now: Full of annoying things, but nothing that really stops you from working. Polishing is important, but not urgent. Showstopppers are important and urgent. Asger, which bug are you going to address tonight? :-) You can choose between me spending some time to write status e-mails, or getting 0.1 bugs fixed because when I'm done updating and recompiling, my time is up. Regards, Asger
Re: Nomencl = Notation?
Georg Baum wrote: Because Ugras thought that nomenclature is not well known by non-native speakers. I don't know Notation either. Should we replace it with Glossary and Glossary Entry instead? As you know, the term Notation is quite generic in German. I guess the same holds in English. Glossary sounds much better. I am going to change this, if you don't mind. OK? Michael
Re: Nomencl = Notation?
Am Dienstag, 7. November 2006 21:05 schrieb Michael Gerz: Glossary sounds much better. I am going to change this, if you don't mind. OK? With me certainly. Please don't forget the documentation in Extended.lyx. Georg
Re: Question about wide inset...
On Tue, Nov 07, 2006 at 03:52:26PM +0100, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Dear Martin, dear all,
While trying to understand how the inset metrics are updated I stumbled
on this potential problem:
Find all wide_inset_, Match case, Whole word, Subfolders, Find Results
1, lyx-trunk, *.c;*.cpp;*.cxx;*.cc;*.tli;*.tlh;*.h;*.hpp;*.hxx;*.hh
D:\devel\lyx\trunk\src\insets\insettext.h(136):
bool Wide() const { return wide_inset_; }
D:\devel\lyx\trunk\src\insets\insettext.h(159):
mutable bool wide_inset_;
Matching lines: 2Matching files: 1Total files searched: 968
This means that the wide_inset_ variable is never set.
Hum... I missed the mutable tag... Ok, it is used in rc\rowpainter.C(888):
// If this is the only object on the row, we can make it wide
for (pos_type i = rit-pos() ; i != rit-endpos(); ++i) {
InsetBase const * const in = par.getInset(i);
if (in) {
InsetText const * const t = in-asTextInset();
if (t)
t-Wide() = in_inset_alone_on_row;
}
}
I stand corrected but a const method giving non-const reference access a
mutable variable is not very nice.
Putting it mildly... I remember fighting with this, or in fact, with an
unrelated bug. And forgot to reverse my change.
- Martin
pgpqi20WmJLz7.pgp
Description: PGP signature
[patch] document symbol font hack
I am going to commit the attached patch which is documenting the abuse of
docstrings to store code points of symbol fonts.
This is a bad hack IMO, and both Abdel and I where already fooled by it. To
my knowledge this is the only place where something else than UCS4 is
stored in a docstring or char_type variable, and it should really stay the
only place.
Since I do not have a better solution right now I am only documenting the
hack.
Georg
Index: src/mathed/MathParser.h
===
--- src/mathed/MathParser.h (Revision 15788)
+++ src/mathed/MathParser.h (Arbeitskopie)
@@ -35,11 +35,23 @@ public:
docstring name;
/// name of a inset that handles that macro
docstring inset;
- /// position of the thing in a font
+ /**
+ * The string or symbol to draw.
+ * This is a string of length 1 if \p name is a known symbol, and
+ * the corresponding font is available. In this case it is
+ * NO UCS4 STRING! The only character of the string simply denotes
+ * the code point of the symbol in the font. Therefore you have to
+ * be very careful if you pass \c draw to any function that takes a
+ * docstring argument.
+ * If \p name is a known symbol, but the corresponding font is not
+ * available, or if it is a function name, then \c draw contains a
+ * regular UCS4 string (actuallay \c draw == \c name) that is painted
+ * on screen.
+ */
docstring draw;
/// operator/..., fontname e
docstring extra;
- /// how is this called as XML entity?
+ /// how is this called as XML entity in MathML?
docstring xmlname;
/// required LaTeXFeatures
docstring requires;
Index: src/frontends/qt4/QLPainter.C
===
--- src/frontends/qt4/QLPainter.C (Revision 15788)
+++ src/frontends/qt4/QLPainter.C (Arbeitskopie)
@@ -211,6 +211,10 @@ int QLPainter::smallCapsText(int x, int
int QLPainter::text(int x, int y, char_type const * s, size_t ls,
LyXFont const f)
{
+ // Caution: The following ucs4_to_qstring conversion works for
+ // symbol fonts only because it is no real conversion but a simple
+ // cast in reality.
+
QString str;
ucs4_to_qstring(s, ls, str);
Index: src/frontends/qt4/GuiFontMetrics.C
===
--- src/frontends/qt4/GuiFontMetrics.C (Revision 15788)
+++ src/frontends/qt4/GuiFontMetrics.C (Arbeitskopie)
@@ -105,6 +105,10 @@ int GuiFontMetrics::smallcapsWidth(QStri
int GuiFontMetrics::width(char_type const * s, size_t ls) const
{
+ // Caution: The following ucs4_to_something conversions work for
+ // symbol fonts only because they are no real conversions but simple
+ // casts in reality.
+
if (ls == 1 !smallcaps_shape_) {
QChar const c = ucs4_to_qchar(s[0]);
return width(c.unicode());
Index: src/frontends/FontMetrics.h
===
--- src/frontends/FontMetrics.h (Revision 15788)
+++ src/frontends/FontMetrics.h (Arbeitskopie)
@@ -38,6 +38,11 @@
* - width -
* --+--+---maxDescent
*
+ * Caution: All char_type and docstring arguments of any method of this class
+ * are no UCS4 chars or strings if the font is a symbol font. They simply
+ * denote the code points of the font instead. You have to keep this in mind
+ * when you implement the methods in a frontend. You must not pass these
+ * parameters to a unicode conversion function in particular.
*/
namespace lyx {
Index: src/frontends/Painter.h
===
--- src/frontends/Painter.h (Revision 15788)
+++ src/frontends/Painter.h (Arbeitskopie)
@@ -43,6 +43,13 @@ namespace frontend {
* management.
*
* Note that the methods return *this for convenience.
+ *
+ * Caution: All char_type and docstring arguments of the text drawing
+ * methods of this class are no UCS4 chars or strings if the font is a
+ * symbol font. They simply denote the code points of the font instead.
+ * You have to keep this in mind when you implement the methods in a
+ * frontend. You must not pass these parameters to a unicode conversion
+ * function in particular.
*/
class Painter {
public:
Re: Can LyX handle large files ?
Abdelrazak Younes wrote:
As my painting investigation continue, it seems that this problem has
_nothing_ to do with painting on screen at all. Modifying a text line
between two huge formula exhibits the slow behaviour even if only the
text line is repainted on screen (you can use -dbg painting to make
sure of that.
You are running to conclusions. Math is painted using a different
mechanism than text - it goes through MathHullInset. The # debug
painting only works for text.
Insert debugging info in the QLPainter around line 253, and you will see
that math indeed draws text on the screen.
So, for example, if LyX were running
with debug enabled, the debug lines being written to the LyX console
window might cause a noticeable jump in csrss load. But I haven't
tested that.
csrss.exe handles output to the console. If you are printing stuff to
stderr or stdout, this might show in csrss spending a lot of CPU on some
systems.
Another bad thing to do is to have lines line
lyxerr[Debug::PAINTING] (something here);
because even if Debug::PAINTING is NOT turned on, the (something here)
will be evaluated.
You need to rewrite such things to
if (lyxerr.debugging(Debug::PAINTING)) {
lyxerr (something here);
}
Try running LyX with a command line parameter -dbg any and inspect the
output when redrawing. If lots of stuff is coming out, review that
output to make sure it is not done like the above.
I started my LyX process 45 minutes ago with -dbg any, and the main
window has not come up yet - it's still reading the layout files and
dumping everything character by character.
So it's fair to conclude that debugstream is a piece of crap. I suspect
that even the tiniest lyxerr statement costs a billion cycles.
I tried to see the best way to hack it out, but the code is so
convoluted that it's probably much simpler to use preprocessing magic to
redefine lyxerr as // and be done with it.
Regards,
Asger
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: Try running LyX with a command line parameter -dbg any and inspect the output when redrawing. If lots of stuff is coming out, review that output to make sure it is not done like the above. Most of it was done wrong - some of it even using monsters like BOOST_CURRENT_FUNCTION. Who knows what voodoo that shit does? I've changed it. Please test. There is a fair chance this gives a nice speedup, maybe even on MacOS as well. Regards, Asger
Re: [Cvslog] r15794 - /lyx-devel/trunk/lib/ui/stdtoolbars.ui
On Tue, Nov 07, 2006 at 09:45:31PM -, [EMAIL PROTECTED] wrote: * stdtoolbars.ui: change notation to glossary; change TeX Code to TeX code This is a step backwards. It's in direct contradiction to most (all?) UI guidelines: http://developer.gnome.org/projects/gup/hig/2.0/design-text-labels.html#layout-capitalization Where the other menu entries really broken too? I could have sworn I had them right. john
Re: [Cvslog] r15794 - /lyx-devel/trunk/lib/ui/stdtoolbars.ui
On Tue, Nov 07, 2006 at 10:00:58PM +, John Levon wrote: On Tue, Nov 07, 2006 at 09:45:31PM -, [EMAIL PROTECTED] wrote: * stdtoolbars.ui: change notation to glossary; change TeX Code to TeX code This is a step backwards. It's in direct contradiction to most (all?) UI guidelines: Whooo! Brain fart time. Sorry Michael. john
Re: [Cvslog] r15794 - /lyx-devel/trunk/lib/ui/stdtoolbars.ui
John Levon wrote: Whooo! Brain fart time. Sorry Michael. :-) I changed the toolbars, not the menus. I think they are both quite consistent now. I guess the translators will hate me. Ooops, I'm a translator, too :-) Michael
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote:
Abdelrazak Younes wrote:
As my painting investigation continue, it seems that this problem has
_nothing_ to do with painting on screen at all. Modifying a text line
between two huge formula exhibits the slow behaviour even if only the
text line is repainted on screen (you can use -dbg painting to make
sure of that.
You are running to conclusions. Math is painted using a different
mechanism than text - it goes through MathHullInset. The # debug
painting only works for text.
I know but I was talking about this other debug info at line 240 of
QLPainter that is also using PAINTING:
if (isDrawingEnabled()) {
lyxerr[Debug::PAINTING] draw std::string(str.toUtf8())
at x , y std::endl;
drawText(x, y, str);
}
So I think I am right there... Well at least for 1.5.
Insert debugging info in the QLPainter around line 253, and you will see
that math indeed draws text on the screen.
?? Line 253 is about underlined text:
if (f.underbar() == LyXFont::ON) {
underline(f, x, y, textwidth);
}
So, for example, if LyX were running
with debug enabled, the debug lines being written to the LyX console
window might cause a noticeable jump in csrss load. But I haven't
tested that.
csrss.exe handles output to the console. If you are printing stuff to
stderr or stdout, this might show in csrss spending a lot of CPU on some
systems.
Another bad thing to do is to have lines line
lyxerr[Debug::PAINTING] (something here);
because even if Debug::PAINTING is NOT turned on, the (something here)
will be evaluated.
You need to rewrite such things to
if (lyxerr.debugging(Debug::PAINTING)) {
lyxerr (something here);
}
This was my initial idea also but I am not sure if this is useful
because is the test is done in any case in the lyxerr operator. More
exactly this test is done at line 97 of debugstream.h:
std::basic_ostreamcharT, traits operator[](Type t) {
if (debug::match(dt, t))
return *this;
return nullstream;
Try running LyX with a command line parameter -dbg any and inspect the
output when redrawing. If lots of stuff is coming out, review that
output to make sure it is not done like the above.
I started my LyX process 45 minutes ago with -dbg any, and the main
window has not come up yet - it's still reading the layout files and
dumping everything character by character.
So it's fair to conclude that debugstream is a piece of crap. I suspect
that even the tiniest lyxerr statement costs a billion cycles.
Maybe you have a point here. I haven't analysed this code in depth.
Abdel.
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: Asger Ottar Alstrup wrote: Try running LyX with a command line parameter -dbg any and inspect the output when redrawing. If lots of stuff is coming out, review that output to make sure it is not done like the above. Most of it was done wrong - some of it even using monsters like BOOST_CURRENT_FUNCTION. Who knows what voodoo that shit does? I've changed it. Please test. There is a fair chance this gives a nice speedup, maybe even on MacOS as well. That would be an easy way out but I am not convinced... Visually speaking, all these if are not very nice... Abdel.
Re: Can LyX handle large files ?
Abdelrazak Younes wrote:
I know but I was talking about this other debug info at line 240 of
QLPainter that is also using PAINTING:
if (isDrawingEnabled()) {
lyxerr[Debug::PAINTING] draw std::string(str.toUtf8())
at x , y std::endl;
drawText(x, y, str);
}
So I think I am right there... Well at least for 1.5.
I just got rid of that one as well. This one is particularly expensive:
2 memory allocations involved. I know that I originally wrote that line
for debugging, but it was never meant to be committed as you did in
15723. Sorry for not being clear about that.
This was my initial idea also but I am not sure if this is useful
because is the test is done in any case in the lyxerr operator. More
exactly this test is done at line 97 of debugstream.h:
std::basic_ostreamcharT, traits operator[](Type t) {
if (debug::match(dt, t))
return *this;
return nullstream;
I guess that's what the person who wrote debugstream thought. This is
probably good enough. But that person forgot to have a look at
nullstream. It is a piece of absolute crap.
So it boils down to a very simple message for all coders here:
** Don't use lyxerr[] in a critical code path. ***
I have said this many times. I guess I should try all caps:
** lyxerr[] IS **ALWAYS** EXPENSIVE LIKE HELL **
Regards,
Asger
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: I've changed it. Please test. There is a fair chance this gives a nice speedup, maybe even on MacOS as well. That would be an easy way out but I am not convinced... Visually speaking, all these if are not very nice... *You* are taking the easy way out. I guess it's time for a little C++ quiz. Look at this line of code: lyxerr[Debug::PAINTING] draw std::string(str.toUtf8()) at x , y std::endl; First, the easy question: How many memory allocations are involved? Then a little harder question: Do you know how expensive memory allocation is? And then the conclusion: Is it such a great idea to do that? Regards, Asger
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: I've changed it. Please test. There is a fair chance this gives a nice speedup, maybe even on MacOS as well. That would be an easy way out but I am not convinced... Visually speaking, all these if are not very nice... *You* are taking the easy way out. You misunderstood me. I don't deny you are right these are probably too expensive. I am just saying that I am not convinced that this is the major culprit for the slowness on Mac and on Windows for LyX file with a lot of big equation. But hey, every bit of speed we can gain is good :-) Abdel.
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: You misunderstood me. I don't deny you are right these are probably too expensive. I am just saying that I am not convinced that this is the major culprit for the slowness on Mac and on Windows for LyX file with a lot of big equation. But hey, every bit of speed we can gain is good :-) Try to make a test program that does nothing but allocate small pieces of memory, fill it up, and then free it again. Before you run it, guess how many allocations you can do in a second. Then run it and learn. Regards, Asger
Re: [1.5 PATCH] Re: [Bug 2882] not possible to delete row in ERT inset
Jean-Marc Lasgouttes wrote: * text.C (backspacePos0): rewrite to make it simple and allow deleting empty paragraphs even when keepempty is true. Do not rely on dEPM, since this was silly (bugs 2587 and 2882) (Delete): simplify also and avoid calling backspace. (backspace): small tweak. Could someone test it too? Michael? I did some basic testing (= OK!) and applied the patch. I will have a look at the CT-specific parts by the end of the week. Michael
Re: Can LyX handle large files ?
Georg Baum wrote: Am Dienstag, 7. November 2006 16:43 schrieb Abdelrazak Younes: As my painting investigation continue, it seems that this problem has _nothing_ to do with painting on screen at all. Modifying a text line between two huge formula exhibits the slow behaviour even if only the text line is repainted on screen (you can use -dbg painting to make sure of that. I guess this could be related to the data memory models used in mathed. Maybe some big tables created/deleted on the fly? AFAIK no big tables, but in mathed we have many of insets. A single formula can contain 20 or so (and then it is not too big), so a bigger document can contain a 4-digit number of math insets This is different from text, where we have only few insets and most stuff is composed of ordinary characters. Interesting. This could be a problem, but then we should keep in mind that the slowness was not there in 1.3.x, and the inset structure in mathed did not change. What did change is the cursor and dociterator stuff, but if that is the problem then I don't understand why cssrs.exe consumes so much time, in that case I would rather expect that it is only in lyx.exe The cursor and dociterator pist is a good one I think. I attach again the test file. At the end of file, appending characters at the end of the last line is _slow_ but hitting return and typing in a new line is very quick (as quick as usual I mean). So the relationship between two consecutive paragraph is the key to our problem I think. The good side of the problem is that 1.5svn is _really_ faster than 1.4.3 with this file. Abdel. attachment.lyx Description: application/lyx
missing qt-4 dependencies
I want to compile LyX under Windows using MSVC and SCons and followed the steps of INSTALL.Win32. There section 4 tells me: Download ftp://ftp.lyx.org/pub/lyx/contrib/lyx-windows-deps-msvc-qt4.zip But this file is not available. The available lyx-windows-deps-msvc.zip doesn't include the qt-4 stuff, only qt-3. Abdel, could you please upload or send me a version that includes the files. (I tried to build the missing qt-4 folder by myself from my Qt4-GPL installation but failed.) thanks and regards Uwe
Save as... with lyx-1.5.0svn
Hello, I compiled lyx-1.5.0svn (Debian/testing, autoconf 2.60a with autogen.sh correction, --with-extra-inc=/usr/X11R6/include where Xlib.h is located, french locale iso8859-1). I load an example (fr_exampls_lyxifie.lyx) and when I Save as... in /tmp to check the spellcheck behaviour, I get a Backup error popup about non writable /tmp, which is obviously not true. This IS not true: the file is there, and if I try to Save as again, I get the overwrite popup warning twice: once in English, once in French. May this be due to the autoconf 2.60a autogen twist ? -- Jean-Pierre
Re: missing qt-4 dependencies
Uwe Stöhr wrote: But this file is not available. The available lyx-windows-deps-msvc.zip doesn't include the qt-4 stuff, only qt-3. Abdel, could you please upload or send me a version that includes the files. I uploaded this file yesterday, along with the 1.4.3-5 release. Jean-Marc will soon move these files to ftp.lyx.org. Joost
Re: Save as... with lyx-1.5.0svn
Jean-Pierre Chrétien wrote: I load an example (fr_exampls_lyxifie.lyx) and when I Save as... in /tmp to check the spellcheck behaviour, I get a Backup error popup about non writable /tmp, which is obviously not true. This IS not true: the file is there, and if I try to Save as again, I get the overwrite popup warning twice: once in English, once in French. May this be due to the autoconf 2.60a autogen twist ? No. I get this warning sometimes, too (and use autoconf 2.59), but I could not see any pattern so far. Georg
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: Asger Ottar Alstrup wrote: Try running LyX with a command line parameter -dbg any and inspect the output when redrawing. If lots of stuff is coming out, review that output to make sure it is not done like the above. Most of it was done wrong - some of it even using monsters like BOOST_CURRENT_FUNCTION. Who knows what voodoo that shit does? Before writing this nonsense look it up in current_function.hpp. It expands via a compiler specific macro to a char * constant that is known at compile time. I've changed it. Please test. There is a fair chance this gives a nice speedup, maybe even on MacOS as well. I want to see numbers. How big is the speedup before and after this patch? Georg
Re: cutandpaste.C simplifications
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Mon, Nov 06, 2006 at 11:03:55PM +0100, Michael Gerz wrote: >> Hi, >> >> am I too stupid to see the brilliancy of the code or can >> cutandpaste.C be simplified? Martin> Probably both ;-) Yes, I suspect that someone wanted to play with all the new toys he read about in a C++ book. JMarc
Re: cutandpaste.C simplifications
Jean-Marc Lasgouttes wrote: > Yes, I suspect that someone wanted to play with all the new toys he > read about in a C++ book. No. resetParagraph was used in two places (see 1.4), therefore it made sense to not duplicate the code. Georg
Re: QT Translation
Michael Gerz wrote:
> Hi,
>
> this patch makes Qt strings translateable again (at least when using
> scons).
>
> Can I commit?
No. Adding qt_helpers.h to all includes is wrong. The attached patch
contains an example how to do it correctly (and how it was done in qt3) and
fixes the autotools part at the same time.
My uic (version 4.1.4) generates calls to the translation function with a
second argument. Did you not need that? I have no idea what it is supposed
to do.
GeorgIndex: src/frontends/qt4/qt_helpers.C
===
--- src/frontends/qt4/qt_helpers.C (Revision 15777)
+++ src/frontends/qt4/qt_helpers.C (Arbeitskopie)
@@ -155,8 +155,9 @@ void qstring_to_ucs4(QString const & qst
}
-QString const qt_(char const * str)
+QString const qt_(char const * str int dummy)
{
+ // FIXME: Look up in uic docs what dummy is supposed to do
return toqstr(_(str));
}
Index: src/frontends/qt4/qt_helpers.h
===
--- src/frontends/qt4/qt_helpers.h (Revision 15777)
+++ src/frontends/qt4/qt_helpers.h (Arbeitskopie)
@@ -104,7 +104,7 @@ void qstring_to_ucs4(QString const & qst
*
* Use this in qt4/ instead of qt_()
*/
-QString const qt_(char const * str);
+QString const qt_(char const * str, int dummy = 0);
/**
Index: src/frontends/qt4/ui/QAskForTextUi.ui
===
--- src/frontends/qt4/ui/QAskForTextUi.ui (Revision 15777)
+++ src/frontends/qt4/ui/QAskForTextUi.ui (Arbeitskopie)
@@ -103,6 +103,9 @@
+
+ qt_helpers.h
+
Index: src/frontends/qt4/ui/Makefile.am
===
--- src/frontends/qt4/ui/Makefile.am (Revision 15777)
+++ src/frontends/qt4/ui/Makefile.am (Arbeitskopie)
@@ -8,7 +8,7 @@ EXTRA_DIST = $(UIFILES)
BUILT_SOURCES = $(UIFILES:.ui=.h)
# Use _() for localization instead of tr() or trUtf8()
-UICFLAGS=-tr qt_
+UIC4FLAGS=-tr lyx::qt_
%.h: %.ui
$(UIC4) $(UIC4FLAGS) $< -o $@
Re: QT Translation
On Tuesday 07 November 2006 8:34 am, Georg Baum wrote:
> -QString const qt_(char const * str)
> +QString const qt_(char const * str int dummy)
> {
Isn't there a comma missing between str and int in the line above?
--
José Abílio
Re: QT Translation
José Matos wrote:
> On Tuesday 07 November 2006 8:34 am, Georg Baum wrote:
>> -QString const qt_(char const * str)
>> +QString const qt_(char const * str int dummy)
>> {
>
> Isn't there a comma missing between str and int in the line above?
Yes. I did not notice because the patch was incomplete anyway and I could
not compile all.
Georg
AW: Re: cutandpaste.C simplifications
>Jean-Marc Lasgouttes wrote: > >> Yes, I suspect that someone wanted to play with all the new toys he >> read about in a C++ book. > >No. resetParagraph was used in two places (see 1.4), therefore it made sense >to not duplicate the code. I dropped the second call to resetParagraph because I think it is pointless. There is nothing to reset. Agreed? Michael
Re: AW: Re: cutandpaste.C simplifications
[EMAIL PROTECTED] wrote: >>Jean-Marc Lasgouttes wrote: >> >>> Yes, I suspect that someone wanted to play with all the new toys he >>> read about in a C++ book. >> >>No. resetParagraph was used in two places (see 1.4), therefore it made >>sense to not duplicate the code. > > I dropped the second call to resetParagraph because I think it is > pointless. There is nothing to reset. > > Agreed? Yes, it looks like a single empty paragraph was reset. This was introduced by Andre, I guess either as result of some copy/paste, or because he did not know whether it was needed for change tracking. I am not sure of the latter either, but I am sure that you know :-) Georg
[patch] sledgehammer
With the attached brute force workaround, the doc and prefs dialogs are
resizing properly again in Qt 4.2.1.
Opinions?
Jürgen
P.S.: no, I don't like it either.
Index: src/frontends/qt4/QDocumentDialog.C
===
--- src/frontends/qt4/QDocumentDialog.C (Revision 15766)
+++ src/frontends/qt4/QDocumentDialog.C (Arbeitskopie)
@@ -402,6 +402,10 @@ QDocumentDialog::QDocumentDialog(QDocume
docPS->addPanel(branchesModule, _("Branches"));
docPS->addPanel(preambleModule, _("LaTeX Preamble"));
docPS->setCurrentPanel(_("Document Class"));
+// FIXME: hack to work around resizing bug in Qt >= 4.2
+#if QT_VERSION >= 0x040200
+ docPS->updateGeometry();
+#endif
}
Index: src/frontends/qt4/QPrefsDialog.C
===
--- src/frontends/qt4/QPrefsDialog.C (Revision 15766)
+++ src/frontends/qt4/QPrefsDialog.C (Arbeitskopie)
@@ -1887,6 +1887,10 @@ QPrefsDialog::QPrefsDialog(QPrefs * form
add(new PrefIdentity);
prefsPS->setCurrentPanel(_("User interface"));
+// FIXME: hack to work around resizing bug in Qt >= 4.2
+#if QT_VERSION >= 0x040200
+ prefsPS->updateGeometry();
+#endif
form_->bcview().setOK(savePB);
form_->bcview().setApply(applyPB);
Re: [patch] sledgehammer
Juergen Spitzmueller wrote: With the attached brute force workaround, the doc and prefs dialogs are resizing properly again in Qt 4.2.1. Opinions? Jürgen P.S.: no, I don't like it either. Better than nothing... Abdel.
Re: [patch] sledgehammer
Abdelrazak Younes wrote: > Better than nothing... I think so, too. However, for the character dialog, I didn't find an appropriate position where to insert the updateGeometry() call (i.e. it didn't work where I've tried). Jürgen
Re: r15778 - /lyx-devel/trunk/Status.15x
[EMAIL PROTECTED] wrote: > * There should be a close button on the tabs (Joost 3/11/06). > + There is now a Qt feature request: > + > http://www.trolltech.com/developer/task-tracker/index_html?id=137891 >d=entry BTW KTabbar has a nice HoverCloseButton feature (used by Quanta+, for instance). Perhaps we can borrow some ideas from this? http://api.kde.org/3.3-api/kdeui/html/ktabbar_8cpp-source.html http://api.kde.org/3.3-api/kdeui/html/ktabwidget_8cpp-source.html Jürgen
Re: Can LyX handle large files ?
[EMAIL PROTECTED] schrieb: On Tue, 7 Nov 2006, [EMAIL PROTECTED] wrote: So any help is appreciated. But the advice to turn instant preview off is equivalent to saying "quit LyX". Then you can try: * Use an older version of LyX (1.3.7 ?) * Split your document into several parts hope any of this helps. /Christian PS. It'd be even better if you could help us discover *why* it's so slow so that it can be fixed, but unfortunately I don't have any ideas on this. If you are interested in helping, you could however contact the developers' list and ask if there's any kind of debugging information you can give them. lyx-devel lists.lyx.org I would be happy to help with finding the bug, thats why I send a copy of this to the devel-list. Splitting the document into parts would only be a crutch, since I often need to manage references to earlier theorems, to equation numbers, etc.. I could imagine a feature like "folding away" a section, so the heading would be shown but the section is only opened when you double-click on the section heading. Another possibility, I could imagine, is making the generated pngs resident, so they need not be generated again when I start lyx with the same document next time. One problem, however, is that I am working on the same document at work during the day, and at home in the evening. (By the way, the reported behaviour is the same on both computers. It could not only be faulted to csrssexe, since during the 3.5 min. of "LyX not responding" the process manager only credits 25% to csrss.exe and 75% to lyx.exe ) I am indeed considering reinstalling some old version of LyX, although this is like withdrawing my chips from LyX ... H.Peter
Re: Can LyX handle large files ?
On Tue, 7 Nov 2006, [EMAIL PROTECTED] wrote: > Splitting the document into parts would only be a crutch, since I often > need to manage references to earlier theorems, to equation numbers, > etc.. Umm... as far as I know and remember from writing my thesis, this works just fine for a multi-part document. In order to access references to another sub-document you just need to have compiled the entire document once. Then LyX remembers what references etc the other sub-documents have. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Can LyX handle large files ?
[EMAIL PROTECTED] wrote: > I would be happy to help with finding the bug, thats why I send a copy > of this to the devel-list. > > Splitting the document into parts would only be a crutch, since I often > need to manage references > to earlier theorems, to equation numbers, etc.. That works well as long as you open the child documents from the master document. Then references etc are known across all parts. > I could imagine a feature like "folding away" a section, so the heading > would be shown but the > section is only opened when you double-click on the section heading. That would be nice to have anyway. > Another possibility, I could imagine, is making the generated pngs > resident, so they need not be > generated again when I start lyx with the same document next time. One > problem, however, is > that I am working on the same document at work during the day, and at > home in the evening. I don't think that the previews are the problem. Surely it takes some time ot process them, but this is done iun the background, and although LyX is a bit slower until they are generated it is still usable (at least on linux). > (By the way, the reported behaviour is the same on both computers. It > could not only be faulted > to csrssexe, since during the 3.5 min. of "LyX not responding" the > process manager only credits > 25% to csrss.exe and 75% to lyx.exe ) No, csrss.exe does not seem to be the problem, it only seems to be a symptom. See http://bugzilla.lyx.org/show_bug.cgi?id=2900 for more information. There was also a thread some time ago with a good explanation: http://www.mail-archive.com/lyx-users%40lists.lyx.org/msg51385.html What we know so far is that the slowness is related to math. It is improved by Instant Preview sometimes, but not completely solved. The reason is probably that the way how math insets are drawn on screen (and/or the metrics are calculated) is done in a way that is very expensive on windows. > I am indeed considering reinstalling some old version of LyX, although > this is like withdrawing my > chips from LyX ... That would be a pity, but I guess we can find the bug with the help of somebody who is able to do some profiling on windows. Unfortunately we did not really get started on that, since profilers on windows either seem to be expensive (glowcode), or complicated to use (kernrate). Georg
Re: Can LyX handle large files ?
Georg Baum wrote: [EMAIL PROTECTED] wrote: (By the way, the reported behaviour is the same on both computers. It could not only be faulted to csrssexe, since during the 3.5 min. of "LyX not responding" the process manager only credits 25% to csrss.exe and 75% to lyx.exe ) No, csrss.exe does not seem to be the problem, it only seems to be a symptom. See http://bugzilla.lyx.org/show_bug.cgi?id=2900 for more information. There was also a thread some time ago with a good explanation: http://www.mail-archive.com/lyx-users%40lists.lyx.org/msg51385.html What we know so far is that the slowness is related to math. It is improved by Instant Preview sometimes, but not completely solved. The reason is probably that the way how math insets are drawn on screen (and/or the metrics are calculated) is done in a way that is very expensive on windows. I've tested again this document and the good news is that the performance will soon be a bit better in 1.5 with my forthcoming painting performance patch. But the problem I think Georg is right in that the problem lies in how lines and symbols are painted on screen with mathed. Abdel.
Re: Lyx1.5 crashes in preferences
i've been trying to look into this weird crash and have added the
following to see which converters are there:
void PrefConverters::updateButtons()
{
lyxerr << "UPDATEBUTTONS START" << std::endl;
Converters::const_iterator ccit1 = form_->converters().begin();
Converters::const_iterator cend1 = form_->converters().end();
for (; ccit1 != cend1; ++ccit1) {
int type = form_->converters().getNumber(ccit1->From->name(),
ccit1->To->name());
lyxerr << "from: " << ccit1->From->name() << " to: " <<
ccit1->To->name() << " type " << type << std::endl;
}
lyxerr << "UPDATEBUTTONS END" << std::endl;
Converters::const_iterator ccit = form_->converters().begin();
Converters::const_iterator cend = form_->converters().end();
for (; ccit != cend; ++ccit) {
int type = form_->converters().getNumber(ccit->From->name(),
ccit->To->name());
lyxerr << "from: " << ccit->From->name() << " to: " <<
ccit->To->name() << " type " << type << std::endl;
}
the strange thing is that on initialisation it loops twice over the same
list:
UPDATEBUTTONS START
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
UPDATEBUTTONS END
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
but when i change something in the file formats (which then updates the
converters) the second loop over the converters shows no longer the same:
UPDATEBUTTONS START
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
UPDATEBUTTONS END
from: latex to: dvi type 0
from: pdflatex to: pdf2 type 1
from: latex to: lyx type 2
from: literate to: lyx type 3
from: latex to: wordhtml type 4
from: latex to: sxw type 5
from: ps to: pdf type 6
from: ps to: text3 type 7
from: dvi to: ps type 8
from: dvi to: pdf3 type 9
from: lyxpreview to: png type 10
from: eps to: pdf type 11
from: latex to: html type 12
from: lyxpreview to: ppm type 13
from: date to: dateout type 14
from: docbook to: docbook-xml type 15
from: fen to: asciichess type 16
from: fig to: pdftex type 17
from: fig to: pstex type 18
from: lyx to: lyx13x type 19
from: bmp to: dateout type -1
from: pbm to: asciiimage type -1
from: bmp to: png type -1
from: literate to: png type -1
from: bmp to: xpm type -1
from: bmp to: tiff type -1
from: text4 to: asciichess type -1
from: text4 to: pdf type -1
from: dateout to: text4 type -1
from: dateout to: textparagraph type -1
from: ppm to: agr type -1
from: text to: asciichess type -1
from: bmp to: text3 type -1
from: ppm to: html type -1
from: text2 to: lyxpreview type -1
from: word to: wordhtml type -1
from: dvi to: linuxdoc type -1
from: docbook to: program type -1
from: docbook to: tgif type -1
from: png to: ps type -1
anyone a clue what is happening here?
thanks, ed
Re: r15778 - /lyx-devel/trunk/Status.15x
Juergen Spitzmueller wrote: [EMAIL PROTECTED] wrote: * There should be a close button on the tabs (Joost 3/11/06). + There is now a Qt feature request: + http://www.trolltech.com/developer/task-tracker/index_html?id=137891 d=entry BTW KTabbar has a nice HoverCloseButton feature (used by Quanta+, for instance). Perhaps we can borrow some ideas from this? http://api.kde.org/3.3-api/kdeui/html/ktabbar_8cpp-source.html http://api.kde.org/3.3-api/kdeui/html/ktabwidget_8cpp-source.html This version is even better as it is for KDE4 and the dependency on other kde headers is very minimal: http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kdeui/html/classKTabWidget.html Abdel.
Question about wide inset...
Dear Martin, dear all,
While trying to understand how the inset metrics are updated I stumbled
on this potential problem:
Find all "wide_inset_", Match case, Whole word, Subfolders, Find Results
1, "lyx-trunk", "*.c;*.cpp;*.cxx;*.cc;*.tli;*.tlh;*.h;*.hpp;*.hxx;*.hh"
D:\devel\lyx\trunk\src\insets\insettext.h(136):
bool & Wide() const { return wide_inset_; }
D:\devel\lyx\trunk\src\insets\insettext.h(159):
mutable bool wide_inset_;
Matching lines: 2Matching files: 1Total files searched: 968
This means that the wide_inset_ variable is never set. By default, I
guess it is set to false on windows but I am not sure about other
platform. I seem to remember some discussion about this between Martin
and John; could you put some light on this matter?
Thanks in advance,
Abdel.
Re: Question about wide inset...
Abdelrazak Younes wrote:
Dear Martin, dear all,
While trying to understand how the inset metrics are updated I stumbled
on this potential problem:
Find all "wide_inset_", Match case, Whole word, Subfolders, Find Results
1, "lyx-trunk", "*.c;*.cpp;*.cxx;*.cc;*.tli;*.tlh;*.h;*.hpp;*.hxx;*.hh"
D:\devel\lyx\trunk\src\insets\insettext.h(136):
bool & Wide() const { return wide_inset_; }
D:\devel\lyx\trunk\src\insets\insettext.h(159):
mutable bool wide_inset_;
Matching lines: 2Matching files: 1Total files searched: 968
This means that the wide_inset_ variable is never set.
Hum... I missed the mutable tag... Ok, it is used in rc\rowpainter.C(888):
// If this is the only object on the row, we can make it wide
for (pos_type i = rit->pos() ; i != rit->endpos(); ++i) {
InsetBase const * const in = par.getInset(i);
if (in) {
InsetText const * const t = in->asTextInset();
if (t)
t->Wide() = in_inset_alone_on_row;
}
}
I stand corrected but a const method giving non-const reference access a
mutable variable is not very nice.
Abdel.
Re: Question about wide inset...
Abdelrazak Younes wrote:
// If this is the only object on the row, we can make it wide
for (pos_type i = rit->pos() ; i != rit->endpos(); ++i) {
InsetBase const * const in = par.getInset(i);
if (in) {
InsetText const * const t = in->asTextInset();
if (t)
t->Wide() = in_inset_alone_on_row;
}
}
I stand corrected but a const method giving non-const reference access a
mutable variable is not very nice.
I've changed that and added a FIXME.
Abdel.
Author: younes
Date: Tue Nov 7 16:21:47 2006
New Revision: 15779
URL: http://www.lyx.org/trac/changeset/15779
Log:
* InsetText:
- wide_inset_ is not mutable any more
- Wide(): split up in Wide() and setWide()
* rowpainter.C:
- paintPar(): use a const_cast instead of the mutable InsetText::Wide()
Modified:
lyx-devel/trunk/src/insets/insettext.h
lyx-devel/trunk/src/rowpainter.C
Modified: lyx-devel/trunk/src/insets/insettext.h
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/insettext.h?rev=15779
==
--- lyx-devel/trunk/src/insets/insettext.h (original)
+++ lyx-devel/trunk/src/insets/insettext.h Tue Nov 7 16:21:47 2006
@@ -133,7 +133,9 @@
///
InsetText(InsetText const &);
///
- bool & Wide() const { return wide_inset_; }
+ bool Wide() const { return wide_inset_; }
+ ///
+ void setWide(bool wide_inset) { wide_inset_ = wide_inset; }
protected:
///
@@ -156,7 +158,7 @@
///
static int border_;
///
- mutable bool wide_inset_;
+ bool wide_inset_;
public:
///
mutable LyXText text_;
Modified: lyx-devel/trunk/src/rowpainter.C
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/rowpainter.C?rev=15779
==
--- lyx-devel/trunk/src/rowpainter.C (original)
+++ lyx-devel/trunk/src/rowpainter.C Tue Nov 7 16:21:47 2006
@@ -880,12 +880,17 @@
text);
// If this is the only object on the row, we can make it wide
+ //
+ // FIXME: there is a const_cast here because paintPar() is not
supposed
+ // to touch the paragraph contents. So either we move this
"wide"
+ // property out of InsetText or we localize the feature to the
painting
+ // done here.
for (pos_type i = rit->pos() ; i != rit->endpos(); ++i) {
InsetBase const * const in = par.getInset(i);
if (in) {
- InsetText const * const t = in->asTextInset();
+ InsetText * t = const_cast(in->asTextInset());
if (t)
- t->Wide() = in_inset_alone_on_row;
+ t->setWide(in_inset_alone_on_row);
}
}
Re: Can LyX handle large files ?
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> I've tested again this document and the good news is that Abdelrazak> the performance will soon be a bit better in 1.5 with my Abdelrazak> forthcoming painting performance patch. But the problem I Abdelrazak> think Georg is right in that the problem lies in how lines Abdelrazak> and symbols are painted on screen with mathed. It would be interesting to know whether the situation improves when the TeX fonts are unavailable. This is the only difference I can think of between math and non-maths. It may be that these fonts are expensive to handle. JMarc
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: >> >> It would be interesting to know whether the situation improves when >> the TeX fonts are unavailable. This is the only difference I can think >> of between math and non-maths. It may be that these fonts are >> expensive to handle. That could be easily checked by letting symbolFamily() in GuiFontLoader.C return an empty string. That disables all symbol fonts. > You mean the Bakoma fonts, don't you? The Bakoma fonts are one package of the TeX fonts in truetype format. Others do exist, too. Georg
Re: QT Translation
Georg Baum wrote: Michael Gerz wrote: Hi, this patch makes Qt strings translateable again (at least when using scons). Can I commit? No. Adding qt_helpers.h to all includes is wrong. The attached patch contains an example how to do it correctly (and how it was done in qt3) and fixes the autotools part at the same time. I don't really see the benefit of replacing 30 #include statements by 70 XML include tags but if you like it that way, I will do so. Michael
Re: QT Translation
Michael Gerz wrote: Georg Baum wrote: Michael Gerz wrote: Hi, this patch makes Qt strings translateable again (at least when using scons). Can I commit? No. Adding qt_helpers.h to all includes is wrong. The attached patch contains an example how to do it correctly (and how it was done in qt3) and fixes the autotools part at the same time. I don't really see the benefit of replacing 30 #include statements by 70 XML include tags but if you like it that way, I will do so. This advantage of doing it Georg' way is that the uic generated files will remain self compilable. Abdel.
[Patch] About LyXText::drawSelection
Hello,
I was investigating what is going wring with text selection and I came
across a big #if 0. Svn blame tells me that:
At revision 9325, abraunst duplicated the LyXText::drawSelection()
method and commented out the first version.
At revision 10276 jug (who is Juergen Vigna I guess) changed
encapsulated the commented out code with #if 0/#else/#endif instead.
I think the code has already diverged too much so I am going to commit
the attached, any objection?
Abdel.
Index: text.C
===
--- text.C (revision 15743)
+++ text.C (working copy)
@@ -1953,89 +1953,7 @@
}
-#if 0
// only used for inset right now. should also be used for main text
-void LyXText::drawSelection(PainterInfo & pi, int x , int) const
-{
- LCursor & cur = pi.base.bv->cursor();
- if (!cur.selection())
- return;
- if (!ptr_cmp(cur.text(), this))
- return;
-
- lyxerr << "draw selection at " << x << endl;
-
- DocIterator beg = cur.selectionBegin();
- DocIterator end = cur.selectionEnd();
-
- BufferView & bv = pi.base.bv;
- Buffer const & buffer = *bv.buffer();
-
- // the selection doesn't touch the visible screen
- if (bv_funcs::status(, beg) == bv_funcs::CUR_BELOW
- || bv_funcs::status(, end) == bv_funcs::CUR_ABOVE)
- return;
-
- Paragraph const & par1 = pars_[beg.pit()];
- Paragraph const & par2 = pars_[end.pit()];
-
- Row const & row1 = par1.getRow(beg.pos(), beg.boundary());
- Row const & row2 = par2.getRow(end.pos(), end.boundary());
-
- int y1,x1,x2;
- if (bv_funcs::status(, beg) == bv_funcs::CUR_ABOVE) {
- y1 = 0;
- x1 = 0;
- x2 = 0;
- } else {
- y1 = bv_funcs::getPos(beg).y_ - row1.ascent();
- int const startx = cursorX(buffer, beg.top(), begin.boundary());
- if (isRTL(buffer, par1)) {
- x1 = startx;
- x2 = 0 + dim_.wid;
- }
- else {
- x1 = 0;
- x2 = startx;
- }
- }
-
- int y2,X1,X2;
- if (bv_funcs::status(, end) == bv_funcs::CUR_BELOW) {
- y2 = bv.workHeight();
- X1 = 0;
- X2 = 0;
- } else {
- y2 = bv_funcs::getPos(end).y_ + row2.descent();
- int const endx = cursorX(buffer, end.top(), end.boundary());
- if (isRTL(buffer, par2)) {
- X1 = 0;
- X2 = endx;
- }
- else {
- X1 = endx;
- X2 = 0 + dim_.wid;
- }
- }
-
- lyxerr << " y1: " << y1 << " y2: " << y2
- << " xo: " << xo_ << " wid: " << dim_.wid
- << endl;
-
- // paint big rectangle in one go
- pi.pain.fillRectangle(x, y1, dim_.wid, y2 - y1, LColor::selection);
-
- // reset background at begin of first selected line
- pi.pain.fillRectangle(x + x1, y1, x2 - x1, row1.height(),
- LColor::background);
-
- // reset background at end of last selected line
- pi.pain.fillRectangle(x + X1, y2 - row2.height(),
- X2 - X1, row2.height(), LColor::background);
-}
-
-#else
-
void LyXText::drawSelection(PainterInfo & pi, int x, int) const
{
LCursor & cur = pi.base.bv->cursor();
@@ -2133,7 +2051,6 @@
pi.pain.fillRectangle(x, y2, dim_.wid,
Y1 - y2, LColor::selection);
}
-#endif
bool LyXText::isLastRow(pit_type pit, Row const & row) const
{
Re: [Patch] About LyXText::drawSelection
Abdelrazak Younes wrote: Hello, I was investigating what is going wring with text selection and I came across a big #if 0. Svn blame tells me that: At revision 9325, abraunst duplicated the LyXText::drawSelection() method and commented out the first version. This was the "CoordBranch merge" and it seems that he did duplicate the method as a backup in case something goes wrong afterward. Conclusion 1: I will commit now. Conclusion 2: please people, resist the temptation of "#if 0" in SVN code. You can do it as much as you want in your local tree but _not_ in the official tree. Abdel.
Re: Question about wide inset...
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Modified: lyx-devel/trunk/src/insets/insettext.h
| URL:
| http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/insettext.h?rev=15779
| ==
| --- lyx-devel/trunk/src/insets/insettext.h (original)
| +++ lyx-devel/trunk/src/insets/insettext.h Tue Nov 7 16:21:47 2006
| @@ -133,7 +133,9 @@
| ///
| InsetText(InsetText const &);
| ///
| - bool & Wide() const { return wide_inset_; }
| + bool Wide() const { return wide_inset_; }
| + ///
| + void setWide(bool wide_inset) { wide_inset_ = wide_inset; }
I saw that you already change Wide to wide. nice.
I think you should also change setWide to wide...
void wide(bool wide_inset) { wide_inset_ = wide_inset; }
either both setX and getX, or just X and X (I like this last one
best.)
--
Lgb
