Re: [Cvslog] r20346 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
Enrico Forestieri wrote: On Tue, Sep 18, 2007 at 05:04:48PM -, [EMAIL PROTECTED] wrote: +- Add a pixmap cache to speed up text drawing on screen. This cache is + enabled on Mac and Windows platform using a version of Qt greater + than 4.2. This should be rephrased as "... platform using Qt 4.2 or higher." Done, thanks. Abdel.
Re: [Cvslog] r20346 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
Enrico Forestieri wrote: > I was not objecting the style, but the fact that the previous wording > suggests that you need Qt 4.3 at least. This was rather a general remark. Jürgen
Re: [Patch-1.5] Fix bug 4211: Unexpected window closing when typing space after switching between 2 documents with the file->Open dialog
Juergen Spitzmueller wrote: Abdelrazak Younes wrote: Simple and straight forward. Indeed. Go ahead. Done.
Re: 1.5.X Patch Candidate List #3
Richard Heck wrote: > I've committed this. OK. Thanks. Jürgen
Re: View Menu proposal
Andre Poenitz wrote: On Thu, Sep 20, 2007 at 01:00:57AM -0400, Richard Heck wrote: Tommaso Cucinotta wrote: Richard Heck ha scritto: OK. Tommaso, do you want to commit this, then? I can do it Thursday if you don't have time. And Jurgen, what about branch? I have only read-access to your svn repository, so far. So, either you commit it by yourself, or sb. should give me write permissions so that I can do that. I think JMarc is the person to ask. JMarc? It's a bit early. The Bromarv Cowboys decreed that handing out write permissions will be handled a bit more restrictive again. It's very nice to be informed of this important decision one month after the fact. As a rule of thumb, hanging "actively" around for half a year or more and getting in three or four non-trivial (say > 15 lines of "real stuff") patches should be (again) the required minimum. And even then, if you didn't shy away, or if you didn't loose interest, you'll have to ask many times. You'll have to show that you truly deserve the great honor to become a 'real' LyX developer. Abdel.
Re: View Menu proposal
On Thu, Sep 20, 2007 at 01:00:57AM -0400, Richard Heck wrote: > Tommaso Cucinotta wrote: > >Richard Heck ha scritto: > >>OK. Tommaso, do you want to commit this, then? I can do it Thursday > >>if you don't have time. And Jurgen, what about branch? > >I have only read-access to your svn repository, so far. So, either > >you commit it by yourself, or sb. should give me write permissions so > >that I can do that. > > I think JMarc is the person to ask. JMarc? It's a bit early. The Bromarv Cowboys decreed that handing out write permissions will be handled a bit more restrictive again. As a rule of thumb, hanging "actively" around for half a year or more and getting in three or four non-trivial (say > 15 lines of "real stuff") patches should be (again) the required minimum. > By the way, Tommaso, if you haven't already done so, can you send a note > to the list saying you agree to license your contributions to LyX under GPL? That'd be needed nevertheless. Thanks for asking. Andre'
Re: --disable-shared
On Thu, Sep 20, 2007 at 12:46:03AM -0400, Richard Heck wrote: > When compiling with --disable-shared, it seems the shared libraries are > being built and installed anyway, which wastes rather a lot of time. > Could this be disabled? It shouldn't, and it didn't last time I tried. Is this a fairly clean tree? Andre'
[PATCH] Remove LFUN_FONT_CODE
Per previous discussion, as a first step towards rationalizing this
stuff. No lyx2lyx is necessary here, because font-code simply invoked
texttt or mathtt as appropriate. Killing LFUN_FONT_NOUN etc will be more
fun for that reason.
For those not privy to the earlier discussion, the rationale here is
that such things ought to be replaced by character styles. We now have
such a style for code in the logicalmkup module, and with this included
one could bind a key to that charstyle if one wished.
Views? Shall I?
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: src/lfuns.h
===
--- src/lfuns.h (revision 20368)
+++ src/lfuns.h (working copy)
@@ -199,7 +199,7 @@
LFUN_LAYOUT,
LFUN_LAYOUT_PARAGRAPH,
LFUN_DROP_LAYOUTS_CHOICE, // used in bindings as of 20060905
- LFUN_FONT_CODE,
+ LFUN_BUFFER_WRITE_ALL, // rgh, gpothier 200707XX
// 125
LFUN_FONT_SANS,
LFUN_FONT_DEFAULT,
@@ -397,15 +397,14 @@
LFUN_CLEARDOUBLEPAGE_INSERT, // Ugras 20061125
LFUN_LISTING_INSERT, // Herbert 2000, bpeng 20070502
LFUN_TOOLBAR_TOGGLE, // Edwin 20070521
- LFUN_BUFFER_WRITE_ALL, // rgh, gpothier 200707XX
- // 290
LFUN_PARAGRAPH_PARAMS, // rgh, 200708XX
+ // 290
LFUN_LAYOUT_MODULES_CLEAR, // rgh, 20070825
LFUN_LAYOUT_MODULE_ADD, // rgh, 20070825
LFUN_LAYOUT_RELOAD, // rgh, 20070903
LFUN_MASTER_BUFFER_VIEW, // Tommaso, 20070920
- // 295
LFUN_MASTER_BUFFER_UPDATE, // Tommaso, 20070920
+ // 295
LFUN_LASTACTION // end of the table
};
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp (revision 20366)
+++ src/LyXAction.cpp (working copy)
@@ -169,7 +169,6 @@
{ LFUN_FLOAT_WIDE_INSERT, "float-wide-insert", Noop },
{ LFUN_WRAP_INSERT, "wrap-insert", Noop },
{ LFUN_FONT_BOLD, "font-bold", Noop },
- { LFUN_FONT_CODE, "font-code", Noop },
{ LFUN_FONT_DEFAULT, "font-default", Noop },
{ LFUN_FONT_EMPH, "font-emph", Noop },
{ LFUN_FONT_FREE_APPLY, "font-free-apply", Noop },
Index: src/Text3.cpp
===
--- src/Text3.cpp (revision 20364)
+++ src/Text3.cpp (working copy)
@@ -1302,13 +1302,6 @@
break;
}
- case LFUN_FONT_CODE: {
- Font font(Font::ALL_IGNORE);
- font.setFamily(Font::TYPEWRITER_FAMILY); // no good
- toggleAndShow(cur, this, font);
- break;
- }
-
case LFUN_FONT_SANS: {
Font font(Font::ALL_IGNORE);
font.setFamily(Font::SANS_FAMILY);
@@ -1770,10 +1763,6 @@
flag.setOnOff(font.family() == Font::ROMAN_FAMILY);
return true;
- case LFUN_FONT_CODE:
- flag.setOnOff(font.family() == Font::TYPEWRITER_FAMILY);
- return true;
-
case LFUN_CUT:
case LFUN_COPY:
enable = cur.selection();
Index: src/insets/InsetERT.cpp
===
--- src/insets/InsetERT.cpp (revision 20364)
+++ src/insets/InsetERT.cpp (working copy)
@@ -301,7 +301,6 @@
case LFUN_FLOAT_WIDE_INSERT:
case LFUN_WRAP_INSERT:
case LFUN_FONT_BOLD:
- case LFUN_FONT_CODE:
case LFUN_FONT_DEFAULT:
case LFUN_FONT_EMPH:
case LFUN_FONT_FREE_APPLY:
Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp (revision 20364)
+++ src/insets/InsetTabular.cpp (working copy)
@@ -3449,7 +3449,6 @@
case LFUN_FONT_NOUN:
case LFUN_FONT_ITAL:
case LFUN_FONT_FRAK:
- case LFUN_FONT_CODE:
case LFUN_FONT_SANS:
case LFUN_FONT_FREE_APPLY:
case LFUN_FONT_FREE_UPDATE:
Index: src/mathed/InsetMathNest.cpp
===
--- src/mathed/InsetMathNest.cpp (revision 20364)
+++ src/mathed/InsetMathNest.cpp (working copy)
@@ -813,12 +813,6 @@
else
handleFont(cur, cmd.argument(), "mathrm");
break;
- case LFUN_FONT_CODE:
- if (currentMode() == TEXT_MODE)
- handleFont(cur, cmd.argument(), "texttt");
- else
- handleFont(cur, cmd.argument(), "mathtt");
- break;
case LFUN_FONT_FRAK:
handleFont(cur, cmd.argument(), "mathfrak");
break;
@@ -1043,7 +1037,6 @@
case LFUN_FONT_BOLD:
case LFUN_FONT_SANS:
case LFUN_FONT_EMPH:
- case LFUN_FONT_CODE:
case LFUN_FONT_NOUN:
case LFUN_FONT_ROMAN:
case LFUN_FONT_DEFAULT:
Index: lib/bind/cua.bind
===
--- lib/bind/cua.bind (revision 20367)
+++ lib/bind/cua.bind (working copy)
@@ -60,7 +60,6 @@
# used below for line-delete
Re: View Menu proposal
Tommaso Cucinotta wrote: Richard Heck ha scritto: OK. Tommaso, do you want to commit this, then? I can do it Thursday if you don't have time. And Jurgen, what about branch? I have only read-access to your svn repository, so far. So, either you commit it by yourself, or sb. should give me write permissions so that I can do that. I think JMarc is the person to ask. JMarc? I've committed this patch to trunk. By the way, Tommaso, if you haven't already done so, can you send a note to the list saying you agree to license your contributions to LyX under GPL? rh -- == 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
--disable-shared
When compiling with --disable-shared, it seems the shared libraries are being built and installed anyway, which wastes rather a lot of time. Could this be disabled? rh -- == 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: View Menu proposal
Richard Heck ha scritto: OK. Tommaso, do you want to commit this, then? I can do it Thursday if you don't have time. And Jurgen, what about branch? I have only read-access to your svn repository, so far. So, either you commit it by yourself, or sb. should give me write permissions so that I can do that. T.
Re: View Menu proposal
Jean-Marc Lasgouttes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: I am personally OK with it, at least on the code side. Concerning the binding, I'd prefer to make master-preview the default (using pdflatex). But this is another story. I think it can go in now. Juergen, you could consider it for branch too (just a new lfun). OK. Tommaso, do you want to commit this, then? I can do it Thursday if you don't have time. And Jurgen, what about branch? 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: 1.5.X Patch Candidate List #3
Abdelrazak Younes wrote: Juergen Spitzmueller wrote: http://www.lyx.org/trac/changeset/20267 - Somehow this got missed when (partially) fixing the recursive include problem. Possibly yes. I've committed this. I don't know that it was causing problems. I don't even know that this function gets used---it's the non-const version of getMasterBuffer(). But it ought to parallel the const version, and there easily could be problems here. The more serious question is how best to check for recursive includes in general, as opposed just to a document that includes itself. 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: DocBook
Neal Becker wrote: > You may want to look at db2latex. Sorry, make that dblatex
Re: DocBook
You may want to look at db2latex.
Unicode woes
Using LyX 1.4, create a new file containing only a non-ascii character (à will do). Save and try to reopen it with 1.6 latest svn (there's no problem with 1.5). You can't. Traceback (most recent call last): File "/usr/local/src/lyx/lyx-1.6.0svn/lib/lyx2lyx/lyx2lyx", line 77, in ? doc = LyX.File(**options.__dict__) File "/usr/local/src/lyx/lyx-1.6.0svn/lib/lyx2lyx/LyX.py", line 615, in __init__ self.read() File "/usr/local/src/lyx/lyx-1.6.0svn/lib/lyx2lyx/LyX.py", line 290, in read line = self.input.readline().decode(self.encoding) File "encodings/utf_8.py", line 16, in decode UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: unexpected end of data Error: Conversion script failed /home/ef/newfile1.lyx is from a different version of LyX, but the lyx2lyx script failed to convert it. This is with: Python 2.4.4 (#2, Aug 16 2007, 02:03:40) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 -- Enrico
Re: [Cvslog] r20346 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
On Wed, Sep 19, 2007 at 11:27:47PM +0200, Juergen Spitzmueller wrote: > Enrico Forestieri wrote: > > > This should be rephrased as "... platform using Qt 4.2 or higher." > > Just do it ;-) > (btw if anyone notices style issues, feel free to improve the wording. > Where's Angus when you need him?) I was not objecting the style, but the fact that the previous wording suggests that you need Qt 4.3 at least. -- Enrico
Re: 1.5.X Patch Candidate List #3
On Wed, Sep 19, 2007 at 06:56:34PM +0200, Michael Gerz wrote: > http://www.lyx.org/trac/changeset/20260 - Darken vertical stroke on + > sign as it disappears on some graphic cards. Not applicable. This only happens with png images and not xpm ones. In general, it seems that xpm images are better rendered on various platforms. For example, png images really suck with Qt4 on Solaris, whereas xpm images are Ok (however, I must say that Qt4 sucks on Solaris). -- Enrico
[Patch-1.5] Fix bug 4211: Unexpected window closing when typing space after switching between 2 documents with the file->Open dialog
Simple and straight forward. Juergen? Index: LyXView.cpp === --- LyXView.cpp (revision 20349) +++ LyXView.cpp (working copy) @@ -192,6 +192,7 @@ updateTab(); busy(false); work_area_->redraw(); + setFocus(); }
Re: [Cvslog] r20346 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
Enrico Forestieri wrote: > This should be rephrased as "... platform using Qt 4.2 or higher." Just do it ;-) (btw if anyone notices style issues, feel free to improve the wording. Where's Angus when you need him?) Jürgen
Re: not possible to fix the g-brief layout
Uwe Stöhr wrote: > I did this now and sent him a patch to fix marvosym.sty. Very good. Thanks. > The problem is > indeed that the new marvosym maintainer changed the command definitions > from \providecommand to \newcommand with the actual release from 2006. I think it used \def in earlier versions. Jürgen
Re: [Patch-1.5] Fix bug 4211: Unexpected window closing when typing space after switching between 2 documents with the file->Open dialog
Abdelrazak Younes wrote: > Simple and straight forward. Indeed. Go ahead. Jürgen
Re: Small puzzle.
On Wed, Sep 19, 2007 at 12:30:31AM +0200, Andre Poenitz wrote: > > Little puzzle for you: > > What belongs together? > > Configurations: > > (A) current svn, --enable-pch > (B) current svn, --disable-pch > > Compile times/size of build tree part frontend/qt4: > > (1) real 7m35s user 6m25s sys 0m23s58.5 MB > (2) real 6m12s user 5m12s sys 0m19s19.9 MB > > > > Solution: (A)-(1), (B)-(2). This is gcc (GCC) 4.1.2. > > > Possible conclusions: Precompiled headers are a waste of time and space. > 22% increase on compile times, ~300% increase on disk space. > > Could somebody please try the same test with a different compiler? Results for frontend/controllers: pch as-is: real3m34.209s user2m47.630s sys 0m11.185s pch without boost: real2m46.650s user2m15.288s sys 0m9.193s empty pch: real2m43.938s user2m8.272s sys 0m8.577s without pch: real2m43.244s user2m11.160s sys 0m8.761s So boost really sucks, otherwise pch are "mostly harmless" but do not actually help. Do MSVC people use pch from pch.h or are they generated somehow else? And can somebody please test another compiler/OS/whatever? Andre'
Re: [Cvslog] r20346 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
On Tue, Sep 18, 2007 at 05:04:48PM -, [EMAIL PROTECTED] wrote: > +- Add a pixmap cache to speed up text drawing on screen. This cache is > + enabled on Mac and Windows platform using a version of Qt greater > + than 4.2. This should be rephrased as "... platform using Qt 4.2 or higher." -- Enrico
Re: not possible to fix the g-brief layout
>> For now I'll add a hint to the docs, when this is OK by you. > > Yes, please add a note that g-brief and the current version of marvosym are > incompatible. We could also add a similar note to the g-brief templates. I'll wait for a reply of the marvosym-maintainer before I proceed. > BTW I think the best solution would be to hassle the marvosym.sty maintainer > with bug reports and pleas to change the \newcommand's in marvosym.sty to > \providecommand's. I did this now and sent him a patch to fix marvosym.sty. The problem is indeed that the new marvosym maintainer changed the command definitions from \providecommand to \newcommand with the actual release from 2006. regars Uwe
Re: 1.5.X Patch Candidate List #3
Juergen Spitzmueller wrote: Michael Gerz wrote: here comes a new 1.5.X patch candidate list. Please tell me which patches are (ir)relevant/(not) applicable. I think (but others might correct me), none of these (except for those that are aready in or on the list I sent last week) are relevant, Agreed. except perhaps for these: http://www.lyx.org/trac/changeset/20267 - Somehow this got missed when (partially) fixing the recursive include problem. Possibly yes. http://www.lyx.org/trac/changeset/20277 - Fix Cursor::setCurrentFont() within mathed. No. Abdel.
Re: Index as flex inset
Martin Vermeer wrote: On Wed, Sep 19, 2007 at 06:15:42PM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Martin Vermeer <[EMAIL PROTECTED]> writes: The attached does this experimentally. It looks good... what we lose is the possibility to get the previous word automatically into the index inset. But I suspect there's a trick even for that if we go this way. The question is, do we? Personally, I do not think do. An index is not just yet another collapsable inset. We should decide what UI we want and write the code necessary to get it. Not change the UI so that it fits what we have in store... Are we 100% sure that we will get the right UI? We could also define a tag for the dialog: InsetLayout Index LabelString Idx LatexType command LatexName index Decorationclassic LabelFont Color Red SizeSmall EndFont Dialogindex End Abdel. A dialog what for? Index has one only to allow you to enter the content... but in a collapsable inset you enter it directly. Right, I was just proposing a way to have a specific dialog if need be. Now we may want to have user-specifyable dialogs for insets anyway... I could think of many uses. Exactly ;-) Abdel.
Re: can't find version info
On Tue, Sep 18, 2007 at 11:35:46AM +0200, Joost Verburg wrote: > S J Collins wrote: > > I need a little more information than your website seems to provide - simply > > to work out which was the latest version for Win95 ... > > I don't think there is any native version that works with Win95. The > best option would be to try Cygwin. The cygwin xforms version has been reported to work on Win98, dunno about Win95. -- Enrico
Re: 1.5.X Patch Candidate List #3
Michael Gerz wrote: > here comes a new 1.5.X patch candidate list. Please tell me which > patches are (ir)relevant/(not) applicable. I think (but others might correct me), none of these (except for those that are aready in or on the list I sent last week) are relevant, except perhaps for these: > http://www.lyx.org/trac/changeset/20267 - Somehow this got missed when > (partially) fixing the recursive include problem. > http://www.lyx.org/trac/changeset/20277 - Fix Cursor::setCurrentFont() > within mathed. > http://www.lyx.org/trac/changeset/20279 - lyx2lyx: use parseopt instead > of getopt Jürgen
Re: DocBook
> - It corrects LyX' exported SGML code, so that you can use it (otherwise you > will get tons of errors). I tried to use docbook with lyx but the exported SGML code can not compile. It there anything specific lyx can do to produce the correct code? Are there bugzilla entries for them? Bo
Re: Small puzzle.
On Wed, Sep 19, 2007 at 03:07:48PM +0200, Jean-Marc Lasgouttes wrote: > "Bo Peng" <[EMAIL PROTECTED]> writes: > > >> Possible conclusions: Precompiled headers are a waste of time and space. > >> 22% increase on compile times, ~300% increase on disk space. > >> > >> Could somebody please try the same test with a different compiler? > > > > I tried a while ago with gcc 3.4 on linux. Autotools' pch did not show > > any advantage in compile time. This was why I did not add pch to > > scons. > > I compile without pch for this reason. > > But I remember that Lars had some good numbers when he wanted to push > pch. I have good numbers when I want to push something as well... Andre'
Re: DocBook
On Wed, Sep 19, 2007 at 10:04:41AM +0200, Chris Karakas wrote: > > > > > > Is DocBook anywhere in active use? > > > > André, > > I use LyX and DocBook to Get What I Mean in both professional and > private life - from software documentation to club newsletters, from > prose to scientific papers. I want to write in LyX, then press a > button and get everything done. My lyxtox script does this. Ok.. thanks for the feedback. Andre'
Re: [EMAIL PROTECTED]: Re: problem with odt export on Windows Lyx 1.5.1-1]
On Wed, Sep 19, 2007 at 08:10:54AM +0100, José Matos wrote: > On Wednesday 19 September 2007 07:26:06 Abdelrazak Younes wrote: > > Why does he run an assertion enabled binary anyway? The packager > > (scons?) should disable assertion for Release mode. > > > > I mean, either we disable the assertion or we do something useful with > > it, like warn the user about a problem and let him choose to ignore the > > problem or not. If we implement the later, we should replace all non > > obvious assertions (like the one in the example) with exceptions. > > You are right, assertions are disabled for releases. If they are not then > that is a bug. I don't agree at all. Andre'
Re: LFUN_FONT_*
On Wed, Sep 19, 2007 at 08:07:02AM +0100, José Matos wrote:
> On Wednesday 19 September 2007 06:48:10 Martin Vermeer wrote:
> > >
> > > IIRC is (emph = {}, noun = []):
> > >
> > > [aaa { bbb ] ccc}
> > >
> > > will be translated as
> > >
> > > [aaa { bbb }]{ ccc}
> > >
> > > what is the problem?
> >
> > Yes, that's how to do it if you insist. And that's how a font attribute
> > to inset converter has to handle it.
>
> There are other more subtle problems, I have hit them before with docbook.
>
> Using the same notation let us suppose that some range has two properties
> applied, which version do we mean?
>
> [{range}] or {[range...]}
>
> The only sane procedure is to look to the export code (latex) to see which
> is applied first and which is applied later.
Insets-in-insets magically solve this problem...
Andre'
Re: [EMAIL PROTECTED]: Re: problem with odt export on Windows Lyx 1.5.1-1]
On Wed, Sep 19, 2007 at 08:26:06AM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >Seen on the user's list. > > > > > >We definitely should _not_ crash on asserts. This is about the most > >annoying behaviour one can get. > > Why does he run an assertion enabled binary anyway? The packager > (scons?) should disable assertion for Release mode. I never really understood why assertion are generally disabled for release mode (as in "release to the customer") unless (they are really computationally expensive of course). At best one gets a crahs shortly after, at worst one gets silent data corruption. > I mean, either we disable the assertion or we do something useful with > it, like warn the user about a problem and let him choose to ignore the > problem or not. Or even make an educated guess ourself whether we might ignore the problem. E.g. not being able so insert something into the main text warrants a warning, but not the choice to abort, let alone to crash. If the user sees the warning and sees that whatever he wanted to insert got not inserted, he can File->Quit himself, if he likes to. > If we implement the later, we should replace all non > obvious assertions (like the one in the example) with exceptions. Such exceptions should be caught at top level of the event handlers, not "fall through" completely. Andre'
1.5.X Patch Candidate List #3
Hi, here comes a new 1.5.X patch candidate list. Please tell me which patches are (ir)relevant/(not) applicable. Regards, Michael New --- http://www.lyx.org/trac/changeset/20260 - Darken vertical stroke on + sign as it disappears on some graphic cards. http://www.lyx.org/trac/changeset/20261 - Force current font to red typewriter in ERT http://www.lyx.org/trac/changeset/20264 - amsmaths.inc: fix copy and paste bug spotted by Georg http://www.lyx.org/trac/changeset/20267 - Somehow this got missed when (partially) fixing the recursive include problem. http://www.lyx.org/trac/changeset/20274 - Text::breakParagraph wants a bool as second parameter, not an int http://www.lyx.org/trac/changeset/20277 - Fix Cursor::setCurrentFont() within mathed. http://www.lyx.org/trac/changeset/20279 - lyx2lyx: use parseopt instead of getopt http://www.lyx.org/trac/changeset/20283 - Give PageDown/Up scrolling a sane behaviour. Does not work with selection yet... http://www.lyx.org/trac/changeset/20287 - Give a sane behaviour to page up/down scrolling when clicking in the page scroll area of the scrollbar. http://www.lyx.org/trac/changeset/20288 - LFUN_SCREEN_UP/DOWN: Take into account the off-screen cursor case. http://www.lyx.org/trac/changeset/20296 - [...] prevent double deletion of socket notifier http://www.lyx.org/trac/changeset/20326 - Cleanup the TEXT_TO_INSET_OFFSET mess. This correction is done now once in InsetText. http://www.lyx.org/trac/changeset/20327 - remove InsetCollapsable::drawSelection(): this was not used. http://www.lyx.org/trac/changeset/20328 - remove InsetCaption::drawSelection(): this was not used. http://www.lyx.org/trac/changeset/20329 - little simplification http://www.lyx.org/trac/changeset/20331 - InsetCollapsable::draw(): replace use of dim_ with InsetText::dimension(). http://www.lyx.org/trac/changeset/20332 - small simplification http://www.lyx.org/trac/changeset/20334 - Fix InsetBox drawing and remove remnant of the wide() hack. http://www.lyx.org/trac/changeset/20353 - Pick up some stitches dropped by Abdel http://www.lyx.org/trac/changeset/20354 - Polish http://www.lyx.org/trac/changeset/20357 - make sure formats are sorted and converters up-to-date
Re: Index as flex inset
On Wed, Sep 19, 2007 at 03:06:30PM +0200, Jean-Marc Lasgouttes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> > The attached does this experimentally. It looks good... what we lose is
> > the possibility to get the previous word automatically into the index
> > inset. But I suspect there's a trick even for that if we go this way.
> >
> > The question is, do we?
>
> Personally, I do not think do. An index is not just yet another
> collapsable inset. We should decide what UI we want and write the code
> necessary to get it. Not change the UI so that it fits what we have in
> store...
Actually have a look at the attached. I somewhat changed my mind since
the previous reply: what is inside an index inset is real LaTeX, so
logically it should be a real LyXText. (Yes, there are some limitations
such as no linebreaks allowed; but you get the idea.)
The attached does everything the old index inset does wrt. indexing the
selection and the previous/surrounding word. And it collapses to a
really small button, and can be opened by "Open all insets". Which the
old one did not...
- Martin
Index: src/insets/InsetCollapsable.cpp
===
--- src/insets/InsetCollapsable.cpp (revision 20354)
+++ src/insets/InsetCollapsable.cpp (working copy)
@@ -351,6 +351,8 @@
void InsetCollapsable::cursorPos(BufferView const & bv,
CursorSlice const & sl, bool boundary, int & x, int & y) const
{
+ if (geometry() == ButtonOnly)
+ status_ = Open;
BOOST_ASSERT(geometry() != ButtonOnly);
InsetText::cursorPos(bv, sl, boundary, x, y);
Index: src/Text3.cpp
===
--- src/Text3.cpp (revision 20348)
+++ src/Text3.cpp (working copy)
@@ -49,6 +49,7 @@
#include "frontends/Clipboard.h"
#include "frontends/Selection.h"
+#include "insets/InsetCollapsable.h"
#include "insets/InsetCommand.h"
#include "insets/InsetFloatList.h"
#include "insets/InsetNewline.h"
@@ -211,23 +212,34 @@
return false;
recordUndo(cur);
- bool gotsel = false;
- if (cur.selection()) {
- lyx::dispatch(FuncRequest(LFUN_CUT));
- gotsel = true;
- }
- text->insertInset(cur, inset);
+ TextClass tclass = cur.buffer().params().getTextClass();
+ InsetLayout il = tclass.insetlayout(from_utf8(cmd.getArg(0)));
+ if (il.lyxtype == "indexing") {
+ docstring const ds = text->getStringToIndex(cur);
+ text->insertInset(cur, inset);
+ if (edit)
+ inset->edit(cur, true);
+ // Now put this into inset
+ static_cast(inset)->text_.insertStringAsParagraphs(cur, ds);
+ } else {
+ bool gotsel = false;
+ if (cur.selection()) {
+ lyx::dispatch(FuncRequest(LFUN_CUT));
+ gotsel = true;
+ }
+ text->insertInset(cur, inset);
- if (edit)
- inset->edit(cur, true);
+ if (edit)
+ inset->edit(cur, true);
- if (gotsel && pastesel) {
- lyx::dispatch(FuncRequest(LFUN_PASTE, "0"));
- // reset first par to default
- if (cur.lastpit() != 0 || cur.lastpos() != 0) {
- LayoutPtr const layout =
-cur.buffer().params().getTextClass().defaultLayout();
- cur.text()->paragraphs().begin()->layout(layout);
+ if (gotsel && pastesel) {
+ lyx::dispatch(FuncRequest(LFUN_PASTE, "0"));
+ // reset first par to default
+ if (cur.lastpit() != 0 || cur.lastpos() != 0) {
+LayoutPtr const layout =
+ cur.buffer().params().getTextClass().defaultLayout();
+cur.text()->paragraphs().begin()->layout(layout);
+ }
}
}
return true;
@@ -1682,7 +1694,8 @@
InsetLayout il = cur.buffer().params().getTextClass().insetlayout(from_utf8(s));
if (il.lyxtype != "charstyle" &&
il.lyxtype != "custom" &&
- il.lyxtype != "element")
+ il.lyxtype != "element" &&
+ il.lyxtype != "indexing")
enable = false;
break;
}
Index: lib/layouts/stdinsets.inc
===
--- lib/layouts/stdinsets.inc (revision 20348)
+++ lib/layouts/stdinsets.inc (working copy)
@@ -101,4 +101,15 @@
EndFont
End
+InsetLayout Index
+ LyXType indexing
+ LabelString Idx
+ LatexType command
+ LatexName index
+ Decorationminimalistic
+ LabelFont
+ Color Red
+ SizeSmall
+ EndFont
+End
Index: lib/ui/stdmenus.inc
===
--- lib/ui/stdmenus.inc (revision 20348)
+++ lib/ui/stdmenus.inc (working copy)
@@ -304,7 +304,7 @@
Item "Cross-Reference...|R" "dialog-show-new-inset ref"
Item "Label...|L" "label-insert"
Item "Caption" "caption-insert"
- Item "Index Entry|d" "index-insert"
+ Item "Index Entry|d" "flex-insert Index"
Item "Nomenclature Entry...|y" "nomencl-insert"
Separator
Item "Table...|T" "tabular-insert"
Re: Index as flex inset
On Wed, Sep 19, 2007 at 06:15:42PM +0200, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > >Martin Vermeer <[EMAIL PROTECTED]> writes: > > > >>The attached does this experimentally. It looks good... what we lose is > >>the possibility to get the previous word automatically into the index > >>inset. But I suspect there's a trick even for that if we go this way. > >> > >>The question is, do we? > > > >Personally, I do not think do. An index is not just yet another > >collapsable inset. We should decide what UI we want and write the code > >necessary to get it. Not change the UI so that it fits what we have in > >store... > > > >Are we 100% sure that we will get the right UI? > > We could also define a tag for the dialog: > > InsetLayout Index > LabelString Idx > LatexType command > LatexName index > Decorationclassic > LabelFont > Color Red > SizeSmall > EndFont > Dialogindex > End > > Abdel. A dialog what for? Index has one only to allow you to enter the content... but in a collapsable inset you enter it directly. Now we may want to have user-specifyable dialogs for insets anyway... I could think of many uses. - Martin
Re: Index as flex inset
Jean-Marc Lasgouttes wrote: Martin Vermeer <[EMAIL PROTECTED]> writes: The attached does this experimentally. It looks good... what we lose is the possibility to get the previous word automatically into the index inset. But I suspect there's a trick even for that if we go this way. The question is, do we? Personally, I do not think do. An index is not just yet another collapsable inset. We should decide what UI we want and write the code necessary to get it. Not change the UI so that it fits what we have in store... Are we 100% sure that we will get the right UI? We could also define a tag for the dialog: InsetLayout Index LabelString Idx LatexType command LatexName index Decorationclassic LabelFont Color Red SizeSmall EndFont Dialogindex End Abdel.
Re: LFUN_FONT_*
José Matos wrote:
There are other more subtle problems, I have hit them before with docbook.
Using the same notation let us suppose that some range has two properties
applied, which version do we mean?
[{range}] or {[range...]}
The only sane procedure is to look to the export code (latex) to see which
is applied first and which is applied later.
There are a variety of bug reports related to this fact: They're
blockers of the meta text settings bug. Using insets here instead of
font settings solves the problem immediately, since nesting is
determined by the insets rather than by magic in the export code.
Richard
Re: Compression and other assorted bits
> It is the save/saveas part that annoys me most. My understanding is that > embedding or not, I am working on the same file. A possible solution to the save/saveas problem might be linking .lyx and .lyz tightly and say 'save a bundled copy' instead of 'save in bundled format'. Then, .lyx will always be saved and .lyz will be saved if requested. This is also confusing because 'save as' might save two files, and the logic has to be changed if .lyz is opened directly. So, whoever proposes the use of a separate file extension has to give me a clear logic how to handle save and save as. Bo
Re: Index as flex inset
Richard Heck <[EMAIL PROTECTED]> writes: > Yes. But what if you insert an index inset and then change the > preceding word? Then it just says "Idx", because auto=true, which is > (I take it) supposed to indicate that the index entry is just what it > should be. But now that's misleading. Yes, this is a problem. And unfortunately, our code is not in a shape that would allow the index to change its appearance depending on what is around it (all it would take is have a Cursor handy at one or two places). JMarc
Re: Index as flex inset
Jean-Marc Lasgouttes wrote: The index inset could have a "auto" boolean property which is set to true when the index contents was derived by LyX. In this case, the inset would be shown as plain "Idx". This would require an additional checkbox in the index dialog, which would be unset automatically when the index contents gets edited. Does this make sense? Yes. But what if you insert an index inset and then change the preceding word? Then it just says "Idx", because auto=true, which is (I take it) supposed to indicate that the index entry is just what it should be. But now that's misleading. Richard (Sorry if this is a second post of the same idea. Not sure if the other message went)
RE: trunk broken
my fault (or bill's actually ;-) fixed in trunk: http://www.lyx.org/trac/changeset/20359 sorry
trunk broken
hi, it seems that http://www.lyx.org/trac/changeset/20356 is causing this: make[6]: Entering directory `/home/paf/mac/ledpar/src/frontends/qt4' /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tpo -c -o Dialogs.lo Dialogs.cpp g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tpo -c Dialogs.cpp -o Dialogs.o In file included from GuiDocument.h:23, from Dialogs.cpp:27: ui_TextLayoutUi.h:30:25: error: lengthcombo.h: No such file or directory make[6]: *** [Dialogs.lo] Error 1 pavel
Re: Index as flex inset
Martin Vermeer <[EMAIL PROTECTED]> writes: >> Also, we need to disable font changing inside, right? > > No... why? You may want to have font changes inside an index entry. I > tried and it works in LaTeX too. OK then. But I would think there are things that not useable there. The index inset could have a "auto" boolean property which is set to true when the index contents was derived by LyX. In this case, the inset would be shown as plain "Idx". This would require an additional checkbox in the index dialog, which would be unset automatically when the index contents gets edited. Does this make sense? JMarc
Re: Compression and other assorted bits
> In case it is not clear (and I agree that it is not) the question about > secondary argument refers to unpacking in place. Unpacking will prompt for overwrite if file.lyx already exists. It is the save/saveas part that annoys me most. My understanding is that embedding or not, I am working on the same file. Bo
Re: Index as flex inset
On Wed, 19 Sep 2007 15:06:30 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > The attached does this experimentally. It looks good... what we lose is > > the possibility to get the previous word automatically into the index > > inset. But I suspect there's a trick even for that if we go this way. > > > > The question is, do we? > > Personally, I do not think do. An index is not just yet another > collapsable inset. We should decide what UI we want and write the code > necessary to get it. Not change the UI so that it fits what we have in > store... Actually I tend to agree somewhat. What we should especially do is create the front end to enter all those things legally that an index entry may contain. This is quite complex and a single field in a dialogue is quite an oversimplification. > Are we 100% sure that we will get the right UI? Hmmm, we don't have now either. > Also, we need to disable font changing inside, right? No... why? You may want to have font changes inside an index entry. I tried and it works in LaTeX too. > JMarc - Martin
Re: Small puzzle.
"Bo Peng" <[EMAIL PROTECTED]> writes: >> Possible conclusions: Precompiled headers are a waste of time and space. >> 22% increase on compile times, ~300% increase on disk space. >> >> Could somebody please try the same test with a different compiler? > > I tried a while ago with gcc 3.4 on linux. Autotools' pch did not show > any advantage in compile time. This was why I did not add pch to > scons. I compile without pch for this reason. But I remember that Lars had some good numbers when he wanted to push pch. JMarc
Re: Index as flex inset
Martin Vermeer <[EMAIL PROTECTED]> writes: > The attached does this experimentally. It looks good... what we lose is > the possibility to get the previous word automatically into the index > inset. But I suspect there's a trick even for that if we go this way. > > The question is, do we? Personally, I do not think do. An index is not just yet another collapsable inset. We should decide what UI we want and write the code necessary to get it. Not change the UI so that it fits what we have in store... Are we 100% sure that we will get the right UI? Also, we need to disable font changing inside, right? JMarc
Re: Bug 3700 - Graphic updates sometimes extremely slow
Pavel Sanda wrote: In an ideal world, we of course would like to have as less redraws as possible. Of course this is not an ideal world... You may think this whole painting stuff is easy to fix but believe me, with current LyX architecture, it is very complicated. Anyway, I think those missing optimizations have nothing to do with your present slowness problem. btw is it expected that computing redraws on paragraph edit with maths takes 2x higher load of cpu compared to the situation no math ivolved ? Yes because the mathed drawing is not (yet) optimized so any row that contains a single math inset will trigger a full screen redraw; while a text only row will be redraw only current row in general. it seems we triggered threshold of 100% load on older boxes (last comments in bug 4054). In those boxes I really recommend to enable 'Instant preview'. This will allow the text oppmization to proceed. Abdel.
Re: Question (Re: Index as flex inset)
On Wed, 19 Sep 2007 11:19:55 +0200 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Martin Vermeer wrote: > > On Wed, 19 Sep 2007 00:28:27 +0300 > > Martin Vermeer <[EMAIL PROTECTED]> wrote: > > > >> The attached does this experimentally. It looks good... what we lose is > >> the possibility to get the previous word automatically into the index > >> inset. But I suspect there's a trick even for that if we go this way. > >> > >> The question is, do we? > >> > >> - Martin > >> > >> (Some other rough edges still. It's the idea that counts) > > > > > > Looking at this some more, I have been trying to find the code (for the > > existing index inset) that does 1) the copying of the word the cursor is > > in to inside the inset, and 2) the copying of the selection, if there is > > any. > > > > I don't see it. Am I dumb (no, don't answer that) > > My guess is: look at InsetCommandMailer and ControlCommand... > > Abdel. Found it! The method is called getStringToIndex() and is called from factory.cpp. - Martin
RE: crash in trunk (preferences->converters)
this http://www.lyx.org/trac/changeset/20357 should take care of it... -Original Message- From: Jürgen Spitzmüller [mailto:[EMAIL PROTECTED] Sent: Tue 9/18/07 11:50 To: LyX Devel Subject: crash in trunk (preferences->converters) - Go to Preferences->Converters - Select a converter, say LaTeX (plain) -> DVI - Modify this converter - Hit the "Change" button => CRASH.
Re: Bug 3700 - Graphic updates sometimes extremely slow
> In an ideal world, we of course would like to have as less redraws as > possible. Of course this is not an ideal world... > > You may think this whole painting stuff is easy to fix but believe me, > with current LyX architecture, it is very complicated. Anyway, I think > those missing optimizations have nothing to do with your present > slowness problem. btw is it expected that computing redraws on paragraph edit with maths takes 2x higher load of cpu compared to the situation no math ivolved ? it seems we triggered threshold of 100% load on older boxes (last comments in bug 4054). pavel
Re: Question (Re: Index as flex inset)
On Wed, 19 Sep 2007 11:19:55 +0200 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Martin Vermeer wrote: > > On Wed, 19 Sep 2007 00:28:27 +0300 > > Martin Vermeer <[EMAIL PROTECTED]> wrote: > > > >> The attached does this experimentally. It looks good... what we lose is > >> the possibility to get the previous word automatically into the index > >> inset. But I suspect there's a trick even for that if we go this way. > >> > >> The question is, do we? > >> > >> - Martin > >> > >> (Some other rough edges still. It's the idea that counts) > > > > > > Looking at this some more, I have been trying to find the code (for the > > existing index inset) that does 1) the copying of the word the cursor is > > in to inside the inset, and 2) the copying of the selection, if there is > > any. > > > > I don't see it. Am I dumb (no, don't answer that) > > My guess is: look at InsetCommandMailer and ControlCommand... > > Abdel. No, I cannot say that I see it. - Martin
Re: Bug 3700 - Graphic updates sometimes extremely slow
Darren Freeman wrote: On Wed, 2007-09-19 at 11:26 +0200, Abdelrazak Younes wrote: Darren Freeman wrote: On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: I'm now going to test the patched version to see if the slowness comes back at all. Okay it came back fairly soon but I can't always clear it by resizing the window.. why, oh why? The phase of the moon. More seriously.. :) One thing that has nagged at me for a little while, is could it be swap-related? If LyX occupies more than 40 megs of RAM and keeps increasing then there is a memory leak and that could well be the origin of your problem. Here, LyX only occupies 34 megs with the UserGuide loaded... With 1Gb of RAM, LyX should not ever put into swap if you are actually using it. If it goes to swap then your system is crappy. Just look at the memory occupation of LyX and you'll get an immediate answer. Abdel.
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 11:26 +0200, Abdelrazak Younes wrote: > Darren Freeman wrote: > > On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: > >> I'm now going to test the patched version to see if the slowness comes > >> back at all. > > > > Okay it came back fairly soon but I can't always clear it by resizing > > the window.. why, oh why? > > The phase of the moon. More seriously.. :) One thing that has nagged at me for a little while, is could it be swap-related? I have 3 or 4 major apps each using >1/3 of the physical memory (1 GB). What if some of the memory used by LyX gets swapped out due to disuse, and the act of resizing triggers LyX/Qt to inspect much of this and so the pages get swapped in? It could possibly explain why LyX gets slower and slower except I don't see why pages should get swapped out of an app that's being actively used. Unless something else is misbehaving. (I blame Firefox which idles at 10% CPU when no part of it is being displayed.) Also, I don't notice the usual pause and disc activity that would indicate swapping when LyX is in use. The fact that I can scroll over the same page of text again and again and see that it is too slow would hopefully rule out a swap issue. When I have zero swap in use, I'll verify the problem is still as described. Have fun, Darren
Re: [patch] bug 4222: LyX cannot parse file:line:error style messages
Bernhard Roider wrote: > if we know the possible extensions we could parse for them exactly (to > avoid false matches). We don't know really. There might be specific extendions from packages (but I'm not sure about that). > otherwise i see no problem to keep your first version. I've committed that. I think the code is rather safe. If it turns out that we miss some corner cases, we can improve that later. What would be worse are false positives that break compilation. However, I've tried to make sure this does not happen (in the worst case, people can use the -no-file-line-error flag). Jürgen
Re: Bug 3700 - Graphic updates sometimes extremely slow
> Okay I'll have to look into profiling. Any tips? Extra build options, > preferred profiling tool? basic is configure with --enable-profile and i think --disable-stdlib-debug too. gprof /usr/bin/lyx gmon.out > gprof.out maybe you could try it on both cases and then compare where is the difference. pavel
Re: Bug 3700 - Graphic updates sometimes extremely slow
Darren Freeman wrote:
Hi all,
Can anybody explain why there are several repaints involved in a window
resize? (On Linux, Qt-4.2.1)
Starting from a small window, maximise it.
1. Window jumps to full size, Qt widgets are correctly drawn at new
sizes, but the document view is old size with old contents.
2. Document view resizes to new size, new contents.
3. Qt widgets such as scroll bar and bottom toolbar are redrawn. They
were grey in step 2.
Surely this sort of thing ought to be atomic in the sense that redraws
aren't allowed until all parameters are updated.
You can also see some shameful wasted repaints using View->{Open,Close}
All Insets. There is time spent without any repaints, while the insets
above the current view change state, then there is a string of insets
opening/closing in the current view, with text moving around, and
finally a delay while the insets below are changed and nothing much
happens. Again, shouldn't this sort of thing be done atomically without
any screen redraws until the final state is reached?
In an ideal world, we of course would like to have as less redraws as
possible. Of course this is not an ideal world...
You may think this whole painting stuff is easy to fix but believe me,
with current LyX architecture, it is very complicated. Anyway, I think
those missing optimizations have nothing to do with your present
slowness problem.
Abdel.
Re: Bug 3700 - Graphic updates sometimes extremely slow
Darren Freeman wrote: On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: I'm now going to test the patched version to see if the slowness comes back at all. Okay it came back fairly soon but I can't always clear it by resizing the window.. why, oh why? The phase of the moon. I don't know what else has changed. Can anybody blame the patch? This patch strictly does *nothing* but disabling 'mouse hover' feature. So if anything you should see _less_ painting happening when you move your mouse. Strictly unrelated to your resize problem. Abdel.
Re: Question (Re: Index as flex inset)
Martin Vermeer wrote: On Wed, 19 Sep 2007 00:28:27 +0300 Martin Vermeer <[EMAIL PROTECTED]> wrote: The attached does this experimentally. It looks good... what we lose is the possibility to get the previous word automatically into the index inset. But I suspect there's a trick even for that if we go this way. The question is, do we? - Martin (Some other rough edges still. It's the idea that counts) Looking at this some more, I have been trying to find the code (for the existing index inset) that does 1) the copying of the word the cursor is in to inside the inset, and 2) the copying of the selection, if there is any. I don't see it. Am I dumb (no, don't answer that) My guess is: look at InsetCommandMailer and ControlCommand... Abdel.
Question (Re: Index as flex inset)
On Wed, 19 Sep 2007 00:28:27 +0300 Martin Vermeer <[EMAIL PROTECTED]> wrote: > The attached does this experimentally. It looks good... what we lose is > the possibility to get the previous word automatically into the index > inset. But I suspect there's a trick even for that if we go this way. > > The question is, do we? > > - Martin > > (Some other rough edges still. It's the idea that counts) Looking at this some more, I have been trying to find the code (for the existing index inset) that does 1) the copying of the word the cursor is in to inside the inset, and 2) the copying of the selection, if there is any. I don't see it. Am I dumb (no, don't answer that) - Martin
Re: Compression and other assorted bits
On Wednesday 19 September 2007 09:09:10 Darren Freeman wrote: > On Wed, 2007-09-19 at 08:28 +0100, José Matos wrote: > > On Tuesday 18 September 2007 21:45:07 Bo Peng wrote: > > > Remember, if you have file.lyz and file.lyx in the same directory, > > > unpacking file.lyz will overwrite file.lyx. You also have to decide if > > > you want to save file.lyx along with file.lyz if you edit file.lyx and > > > then enable embedding. A single extension is easier to understand. > > > > At least to me this is a secondary argument. :-) In case it is not clear (and I agree that it is not) the question about secondary argument refers to unpacking in place. -- José Abílio
Re: Bug 3700 - Graphic updates sometimes extremely slow
(Just added the following to bugz..) Now I've seen the speed-up happen with opening the Outline. It seems to be specifically related to resizing the document view within the main window, not only resizing the whole thing. Also, resizing can result in slow-downs too. This is probably why I usually notice a slowdown straight after opening the Outline. It's probably just luck as to whether it gets faster or slower. Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
Hi all,
Can anybody explain why there are several repaints involved in a window
resize? (On Linux, Qt-4.2.1)
Starting from a small window, maximise it.
1. Window jumps to full size, Qt widgets are correctly drawn at new
sizes, but the document view is old size with old contents.
2. Document view resizes to new size, new contents.
3. Qt widgets such as scroll bar and bottom toolbar are redrawn. They
were grey in step 2.
Surely this sort of thing ought to be atomic in the sense that redraws
aren't allowed until all parameters are updated.
You can also see some shameful wasted repaints using View->{Open,Close}
All Insets. There is time spent without any repaints, while the insets
above the current view change state, then there is a string of insets
opening/closing in the current view, with text moving around, and
finally a delay while the insets below are changed and nothing much
happens. Again, shouldn't this sort of thing be done atomically without
any screen redraws until the final state is reached?
Have fun,
Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: > I'm now going to test the patched version to see if the slowness comes > back at all. Okay it came back fairly soon but I can't always clear it by resizing the window.. why, oh why? I don't know what else has changed. Can anybody blame the patch? Have fun, Darren
Re: Compression and other assorted bits
On Wed, 2007-09-19 at 08:28 +0100, José Matos wrote: > On Tuesday 18 September 2007 21:45:07 Bo Peng wrote: > > Remember, if you have file.lyz and file.lyx in the same directory, > > unpacking file.lyz will overwrite file.lyx. You also have to decide if > > you want to save file.lyx along with file.lyz if you edit file.lyx and > > then enable embedding. A single extension is easier to understand. > > At least to me this is a secondary argument. :-) I have been deliberately keeping out of this stuff, but I would like to point out that there was a thread back in late 2002 in which all this stuff came up. Back when use of XML was being debated, I suggested that we could use gzip for compression and then it wouldn't matter if the tags were long or short as the file size would be about the same. The use of .lyx.gz or .lyz was debated although I forget the outcome. I think .lyx.gz makes perfect sense to anybody who looks at it. They can take a stack of .lyx files they haven't needed for a while and gzip them legitimately. They can for whatever reason do the reverse. Just as long as the correct datestamp is written into the .gz so gunzip will keep the right stamp on the unpacked file (or is it better to omit this?). The filename shouldn't be written or if it was renamed, gunzip might change it back. I think in the case of unpacking, the user should be warned if an overwrite is taking place, just as for File->Save As or File->Save if it was externally modified. Have fun, Darren
Re: DocBook
> > > Is DocBook anywhere in active use? > André, I use LyX and DocBook to Get What I Mean in both professional and private life - from software documentation to club newsletters, from prose to scientific papers. I want to write in LyX, then press a button and get everything done. My lyxtox script does this. http://www.karakas-online.de/mySGML/ There are at least two official HOWTOs from the Linux Documentation Project that were written with this method: The PHP-Nuke Guide: http://www.karakas-online.de/EN-Book/ The GNU/Linux Command-Line Tools Summary: http://www.karakas-online.de/gnu-linux-tools-summary/ lyxtox currently needs an outdated version of LyX (1.2.0), but the results are nevertheless excellent. It works as follows: - It corrects LyX' exported SGML code, so that you can use it (otherwise you will get tons of errors). - It lets you include images, admonitions, callouts from LyX. - It lets you write and publish Mathematics: http://www.karakas-online.de/mySGML/lyx-mathematics.html on the Web and in print with TeX quality! - It produces a PDF with all bells and whistles: bookmarks, thumbnails, hyperrefs, cross-refs, images, embedded (Computer Modern) fonts for optimal viewing *and* printing etc. See http://www.karakas-online.de/mySGML/explain-optimal-pdf.html - It produces *valid HTML*. That's not to be taken for granted with the standard tools - just check a document produced by openjade with W3C's HTML validator. See http://www.karakas-online.de/mySGML/html-validation.html - It produces HTML code that passes the guidelines for accessibility - that's also not the case for the standard tools, see http://www.karakas-online.de/mySGML/accessibility.html - It creates the index automatically for you. LyX offers a very comfortable way of inserting index entries. But if you ever need to create an Index for a 500 page document like this one: http://www.karakas-online.de/EN-Book/i21330.html then even LyX' manual approach will not serve you. For such cases, the scripts offer an automatic Index generation: http://www.karakas-online.de/mySGML/lyx-automatic-index-generation.html And what about the Bibliography? We have BibTeX, don't we? ;-) Yes, but BibTeX won't help you with SGML. Instead, the scripts use RefDB ( http://refdb.sourceforge.net ), the only available tool to create HTML, PostScript, PDF, DVI, MIF, or RTF output from DocBook or TEI sources with fully formatted citations and bibliographies according to publisher's specifications. RefDB is integrated transparently: you build you bibliographic database, you define your bibliographic style, i.e. the style accepted by the journal you want to submit your work, then the lyxtox script http://www.karakas-online.de/mySGML/lyxtox will create (through RefDB) the bibliography SGML file according to that style, then it will create (on-the-fly!) the necessary extra DSSSL customization layers that will, in turn, format everything correctly: http://www.karakas-online.de/mySGML/lyx-bibliography-with-refdb.html If you'd rather not use RefDB, the scripts will still offer you a solution to your bibliography problem: http://www.karakas-online.de/mySGML/lyx-bibliography-without-refdb.html Thus, what you get is a *complete* solution to your writing needs: - GUI (LyX), don't bother about SGML. - Table of Contents, - cross-references, - Index, - Bibliography, - Mathematics everything is covered. You press the button, lyxtox does the rest - enjoy! :-) Chris -- Regards Chris Karakas http://www.karakas-online.de
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 08:36 +0200, Abdelrazak Younes wrote: > Darren Freeman wrote: > I don't think this is the problem but you can try to disable the 'hover' > with the attached patch. I verified the bug with the original version, and then patched and compiled, tried again. I found the slowness to be much worse, and couldn't be cleared by resizing (I think some gain was had by copying from within LyX). What's worse is the un-patched (installed) version was then hideously slow and wouldn't speed up either! I don't know what was going on, even repainting the window decorations was slow. Bringing up the citation dialogue took a second or more to paint everything!! But then I recompiled the un-patched version, and it was back to usual, bug intact but workaround succeeded. Then I compiled the patched version, and it was fast. I haven't seen it exhibit the bug yet. I'm now going to test the patched version to see if the slowness comes back at all. What could be lingering after the normal closure of the slightly patched LyX? I did notice it failed to reconfigure when I ran the different version, so I guess it is only triggered by a hard-coded version number rather than a hash of the binary etc. > What could could be a problem though is the automatic work area resizing > when a toolbar (mathed or tabular) pops up. Do you use this feature? If > yes, try to disable it and report back. I don't know this feature. If it's off by default, then I'm not using it. I haven't seen toolbars coming and going by themselves. > Darren, I appreciate your reports but I am sorry to say they are not > very useful at this point. The only thing we need is a profile report > when you see this slowdown. Without experimenting this slowdown I cannot > solve it, as simple as that. Okay I'll have to look into profiling. Any tips? Extra build options, preferred profiling tool? Have fun, Darren
Re: LFUN_FONT_*
On Wed, 19 Sep 2007 08:07:02 +0100
José Matos <[EMAIL PROTECTED]> wrote:
> On Wednesday 19 September 2007 06:48:10 Martin Vermeer wrote:
> > >
> > > IIRC is (emph = {}, noun = []):
> > >
> > > [aaa { bbb ] ccc}
> > >
> > > will be translated as
> > >
> > > [aaa { bbb }]{ ccc}
> > >
> > > what is the problem?
> >
> > Yes, that's how to do it if you insist. And that's how a font attribute
> > to inset converter has to handle it.
>
> There are other more subtle problems, I have hit them before with docbook.
>
> Using the same notation let us suppose that some range has two properties
> applied, which version do we mean?
>
> [{range}] or {[range...]}
>
> The only sane procedure is to look to the export code (latex) to see which
> is applied first and which is applied later.
Yes... "interesting" is the word I remember using ;-)
- Martin
Re: Compression and other assorted bits
On Tuesday 18 September 2007 21:45:07 Bo Peng wrote: > I am not in favor of a separate file extension partly because of the > extra work (document, .cpp etc). I am not either. > If it is decided to use one, I would > prefer .lyz. 'z' is after 'x', it means 'compression', and '.lyz' > actually sounds like '.lyx'. 'z' is after 'x' but there is 'y' in the middle. :-) In a sense lyx ir our "trade mark" and I think we should not dilute that with another suffix like lyz. That is why I had propose that if we go with another suffix we keep the ending lyx ([^\.]*lyx using a regular expression form). > Remember, if you have file.lyz and file.lyx in the same directory, > unpacking file.lyz will overwrite file.lyx. You also have to decide if > you want to save file.lyx along with file.lyz if you edit file.lyx and > then enable embedding. A single extension is easier to understand. At least to me this is a secondary argument. :-) > Bo -- José Abílio
Re: DocBook
On Tuesday 18 September 2007 21:54:57 Andre Poenitz wrote: > Is DocBook anywhere in active use? As I found out through the years the answer is yes but those users will not report back. I have found that when googling, searching for other related issues. That meant that we never had the critical mass to be in cruise control. A funny experience, to say the least. :-) > Andre' -- José Abílio
Re: [EMAIL PROTECTED]: Re: problem with odt export on Windows Lyx 1.5.1-1]
On Wednesday 19 September 2007 07:26:06 Abdelrazak Younes wrote: > Why does he run an assertion enabled binary anyway? The packager > (scons?) should disable assertion for Release mode. > > I mean, either we disable the assertion or we do something useful with > it, like warn the user about a problem and let him choose to ignore the > problem or not. If we implement the later, we should replace all non > obvious assertions (like the one in the example) with exceptions. You are right, assertions are disabled for releases. If they are not then that is a bug. > Abdel. -- José Abílio
Re: LFUN_FONT_*
On Wednesday 19 September 2007 06:48:10 Martin Vermeer wrote:
> >
> > IIRC is (emph = {}, noun = []):
> >
> > [aaa { bbb ] ccc}
> >
> > will be translated as
> >
> > [aaa { bbb }]{ ccc}
> >
> > what is the problem?
>
> Yes, that's how to do it if you insist. And that's how a font attribute
> to inset converter has to handle it.
There are other more subtle problems, I have hit them before with docbook.
Using the same notation let us suppose that some range has two properties
applied, which version do we mean?
[{range}] or {[range...]}
The only sane procedure is to look to the export code (latex) to see which
is applied first and which is applied later.
> - Martin
--
José Abílio
