Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Sat, Aug 24, 2002 at 01:47:47PM +0900, Rob Lahaye wrote: Any idea what patch has caused that? Seems like any mouse clicks inside minipages/floats etc are eaten. So it might be my fault whith the use lfuns for mouse clicks change and the cause might be found in insets/insettext.C... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
Andre Poenitz wrote:
On Sat, Aug 24, 2002 at 01:47:47PM +0900, Rob Lahaye wrote:
Any idea what patch has caused that?
Seems like any mouse clicks inside minipages/floats etc are eaten.
So it might be my fault whith the use lfuns for mouse clicks change
and the cause might be found in insets/insettext.C...
Have you tried John's patch from yesterday? It works for me here!
Index: insets/insettabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v
retrieving revision 1.224
diff -u -r1.224 insettabular.C
--- insets/insettabular.C 20 Aug 2002 20:30:45 - 1.224
+++ insets/insettabular.C 25 Aug 2002 00:37:03 -
-920,7 +920,6
return DISPATCHED;
case LFUN_MOUSE_RELEASE:
-
lfunMouseRelease(cmd);
return lfunMouseRelease(cmd) ? DISPATCHED : UNDISPATCHED;
case LFUN_SHIFT_TAB:
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.327
diff -u -r1.327 insettext.C
--- insets/insettext.C 21 Aug 2002 17:35:24 - 1.327
+++ insets/insettext.C 25 Aug 2002 00:37:24 -
-1239,6 +1240,18
int updwhat = 0;
int updflag = false;
switch (ev.action) {
+
+
case LFUN_MOUSE_PRESS:
+
lfunMousePress(ev);
+
return DISPATCHED;
+
+
case LFUN_MOUSE_MOTION:
+
lfunMouseMotion(ev);
+
return DISPATCHED;
+
+
case LFUN_MOUSE_RELEASE:
+
return lfunMouseRelease(ev) ? DISPATCHED : UNDISPATCHED;
+
// Normal chars
case LFUN_SELFINSERT:
if (bv-buffer()-isReadonly()) {
cvs.lyx.org: connection refused!
Jean-Marc Lasgouttes wrote: Rob == Rob Lahaye [EMAIL PROTECTED] writes: Rob I use Rob :pserver:[EMAIL PROTECTED]:/cvs/lyx Rob What else is there? I use cvs.lyx.org, which is the real cvs (because I am an important person and have an account there :). I think anoncvs has a delay of a few dozens of minutes. Jean-Marc, This doesn't work for me: $ setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvs/lyx $ cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvs/lyx CVS password: cvs [login aborted]: connect to cvs.lyx.org(213.203.58.29):2401 failed: Connection refused I use lyx (without quotes) as password. What's wrong? BTW: If this server is supposed to work, why is it not mentioned on the LyX-devel webpages? Thanks, Rob.
lyx2lyx
Cool stuff. I just translated a few docs written in 1998 with 0.12 and they all look fine. Andre' PS: [Numbers like '20136' or '41648' get written to the console, but that's not really a problem]. -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Mon, Aug 26, 2002 at 03:49:12PM +0900, Rob Lahaye wrote: Have you tried John's patch from yesterday? It works for me here! No. I've just seen it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx
On Mon, Aug 26, 2002 at 08:52:52AM +0200, Andre' Poenitz wrote: I just translated a few docs written in 1998 with 0.12 and they all look fine. Hm... I just wonder: Is it a good idea to do the conversion automatically without a warning? After all, saving the doc after conversion destroys it, as it possibly can't be read by the version of LyX that originally created it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Off for the weekend
Andre Poenitz wrote: Because Lars started doing the paragraph list changes here and this stuff is strongly related? And the paragraph cleanup probably can't bve done without this kind of stuff? That's no excuse. IMO that it was a _really_ bad move of Lars to introduce that ParagraphList stuff right now! We still suffer from bugs in that code and he promised us that there will be *no* problem. _Any_ add of code is a potential point for new bugs! A branch would be really good, for this type of stuff (also for the ParagraphList stuff) until we really see that it works. I may be able to download a branch and test it but I surely will not apply monster patches to some version of the sourcetree. I *really* think we should help John to get the Qt version out and be done with a second working GUII implementation. We should already now try to fix some of the *long* buglist on bugzilla and get 1.3.0 out of the door as fast as possible. Done the GUII part we can concentratre on adding new stuff and makeing the core even cleaner. So if you want to try out new stuff now just create a branch and commit to that branch. Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] fix for mouse in insettext (ERT, etc.)
John Levon wrote: Andre, Jug, please review, test and apply. Also there is a new bug that where you have a cell selection in a table and click inside on of the insettexts in a cell, a selection is made within the actual text. I didn't see the immediate fix for this (if you can't fix this now, please let me know so I can open a bugzilla bug on it). I will apply this as it seems the right fix ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: removing extern bool undo_frozen
John Levon wrote:
Can't we just do :
freezeUndo()
{
if (++undo_frozen_count == 1)
undo_frozen = true;
}
unfreezeUndo()
}{
if (--undo_frozen_count == 0)
undo_frozen = false;
}
IMO this counting is error prone. Anyway we could just put the whole
stuff into a class with private static members (does this exist?) and
instead of using the external bool use a function, but at the end IMO
it's just the same.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Qt C-S-Z woes
John Levon wrote: On Sun, Aug 25, 2002 at 06:53:36AM +0100, John Levon wrote: OK, after several hours on the damn thing, I give up. I cannot fix this bug. w00t ! I got it. I was looking in totally the wrong place, and it was very very simple. Oh well You see it helps talking to people (also if you do autoconverstation), but at the end we did point you in the right direction (mentally) and you could find it #:OP Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
tooltips won't go away
The yellow tooltip box that pops up after hoveering over e.g. the width field in the graphics dialog doesn't go away if the dialog is closed by pressing Escape Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: tooltips won't go away
Andre Poenitz wrote: The yellow tooltip box that pops up after hoveering over e.g. the width field in the graphics dialog doesn't go away if the dialog is closed by pressing Escape Yep, here too. I think there may be a list of problems with tooltips in a tabbed dialog. E.g: when moving the dialog-window to somewhere else, will pop up the tooltips as if the dialog has not been moved. This and your problem do not exist in untabbed dialogs, such as the BibTeX Database dialog. Do the Xforms-devel people know about this? Rob.
problem with Docbook export
Hi all, I'm not sure if this is the correct place to send this, so please forgive me it is my first time to try and submit a bug report. this may be old news, I know when exporting docbook documents LyX 1.2.1 and 1.2.0 before it uses sect4title /title/sect4 instead of para /para fixing the sgml output is not simply a matter of replacing strings since LyX messes up the tags more when lists or other elements are embedded inside the paragraph. I solved this problem by editing the layout/db_stdsections.inc file and changing the paragraph and subparagraph style definitions to # Paragraph style definition Style Paragraph LatexType Paragraph LatexName para End # Subparagraph style definition Style Subparagraph LatexType Paragraph LatexName para End this of course means that paragraph and subparagraph will be the same in the sgml output, I found no equivalent to subparagraph in the docbook reference but maybe I didn't look hard enough. another error LyX produces is putting the toc/toc tags for table of contents inside bookinfo,articleinfo,etc. tag, and within a paragraph. the bookinfo articleinfo and all the other *info tags are not parents to toc it would be better to put it outside as a child of the book or article, etc. tag I've failed to find the intery for the table of contents in the layout files. keep the good work and sorry for bothering you, Alaa -- Perilous to all of us are the devices of an art deeper than we ourselves possess. -- Gandalf the Grey [J.R.R. Tolkien, Lord of the Rings]
preview-latex chrashes with xforms
Dear developpers, I compiled lyx-1.3.0cvs under SuSE 8.0 and RedHat with xfroms 0.89 and 1.0RC4. I tested the instant preview funnction on some textes. With small textes I have no problems. But I have a longer text with the following behavior of lyx and X-Windows: I start lyx-1.3.0cvs in a terminal. The text is opened and displayed (without preview) correctly. In the terminal a latex run is done on 0lyxpreview.tex. Dvipsk 5.86 generated 0lyxpreview.ps. Many ppm-files and a 0lyxpreview.metrics file are generated in a subdirectory of the tmp-directory. For short textes, now starts the recplacing of the math-formulas by the preview pictures. For the longer text (about 960 math formulas), sometimes the head of the lyx-windows changes the colors, the buttons disappear. After some seconds, the X-Windows collapses. However, sometimes preview latex works with these textes, too. So I don't believe that it is an error in the text, maybe a memory error? Norbert
Re: lyx2lyx not found?
On Mon, Aug 26, 2002 at 10:50:44AM +0900, Rob Lahaye wrote: So I conclude that lyx2lyx is not at all installed with gmake install-strip. Is this an bug in the install script? I know. I didn't created the necessary configure*/Makefile* files needed to install the script. Since I don't know much about this, I leave it to someone else. (The lyxconvert*.py lyx2lyx files should be installed in LYXDIR/lyx2lyx/ Then, a symbolic link should be created from LYXDIR/lyx2lyx/lyx2lyx into $PREFIX/bin/lyx2lyx)
cutpaste in math
Any reason why cutpaste should not work anymore in math, Mr Levon? ;-} 1.373(levon24-Aug-02): case LFUN_CUT: 1.373(levon24-Aug-02): case LFUN_COPY: 1.373(levon24-Aug-02): disable = !view()-getLyXText()-selection.set(); 1.373(levon24-Aug-02): break; Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BUG ALARM: begin_deeper/end_deeper botched
John Levon [EMAIL PROTECTED] writes: | On Fri, Aug 23, 2002 at 05:45:06PM +0300, Martin Vermeer wrote: Just noticed this now. It goes deeper and deeper in a nested enumerate, but doesn't come back up. This happens during a write/read cycle of a .lyx file. I did a test, and it happens during writing. Actually the pattern can be more complex than painted above. | I /think/ Lars broke it. I might have, but then it is just some tiny detail. | I've already lost one document to it... Life on the bleeding edge... -- Lgb
Re: Two graphics layout issues: display mode / subfigure
On Mon, Aug 26, 2002 at 02:10:22PM +0900, Rob Lahaye wrote: Proposal two has two interaction widgets. To handle this properly, we have to add an additional keyword to store the value of the two widgets (e.g. choicelist=color; checkbutton=don't display). This means: one more bool-variable is needed in the code (easy task), but also storing the extra keyword in the Graphics-inset and Preferences-file. The latter means a format change. Please don't make the file format more complicated. A non-float graphics inset currently allows the use of the Subfigure input. However, this causes errors in the LaTeX export, since Subfigure is only allowed within floats. LyX should handle this more gracefully by - ignoring the subfigure outside a float, when writing the LaTeX output or [...] The first one seems to be better to me, since it is simpler to implement. But then the subcaption disappears without getting a feedback. Even the current situation, in which you get an (obscure) latex error is better.
Re: Core cleaning
Andre Poenitz [EMAIL PROTECTED] writes: | On Fri, Aug 23, 2002 at 04:54:02PM +0200, Jean-Marc Lasgouttes wrote: Yes. Until you support all old functionality, you will probably not be able to remove any code. Therefore you are just adding bloat :) | User definable environments are valuable as such. Not if existing environments cannot be moved to that scheme. -- Lgb
Re: Core cleaning
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Andre == Andre Poenitz [EMAIL PROTECTED] writes: | Andre On Fri, Aug 23, 2002 at 04:46:41PM +0200, Jean-Marc Lasgouttes | Andre wrote: I guess that's why you are maintaining the stable branch | Andre ;-} That's not the point. When you are removing features, it is a bad excuse to say that you don't care because the code is now simpler. And proper displaying of lists is a basic feature, I think. | Andre I am talking about _temporarily_ breaking features in the | Andre _development_ branch (and not even about that, rather about | Andre adding half-functional stuff) and I am fairly confident to be | Andre able to resolve resulting issues. So you tell me that is | Andre wrong? | The temporarily was not clear in your posting. What I want to be sure | is that you know about all pitfalls you may encounter when designing | your code (non-rectangular insettext, ...) We already have one breakage now... begin_deeper end_deeper, let's not add another before this one is fixed. -- Lgb
Re: Core cleaning
On Mon, Aug 26, 2002 at 11:11:25AM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | On Fri, Aug 23, 2002 at 04:54:02PM +0200, Jean-Marc Lasgouttes wrote: Yes. Until you support all old functionality, you will probably not be able to remove any code. Therefore you are just adding bloat :) | User definable environments are valuable as such. Not if existing environments cannot be moved to that scheme. User definable environments are valuable as such _even if existing environments cannot be moved to that scheme_. Alas, the point is mood, as existing environments could be moved to that scheme easily (and I even provided proof-of-concept code with the NewItemize environment). Unfortunately, last Friday the conservative bunch had a majority which did not like touching existing things at all (and rather opted to break CutPaste in math - SCNR, John ;-)). So this comment was there to make the idea to both sides more platable. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Off for the weekend
Juergen Vigna [EMAIL PROTECTED] writes: | Andre Poenitz wrote: Because Lars started doing the paragraph list changes here and this stuff is strongly related? And the paragraph cleanup probably can't bve done without this kind of stuff? | That's no excuse. IMO that it was a _really_ bad move of Lars to introduce | that ParagraphList stuff right now! Why? I have taken a lot of care to not change neigher input/display/output of lyx, but of course I do have bugs in my code.. (I am perfectly willing to admit that.) | We still suffer from bugs in that code | and he promised us that there will be *no* problem. Please find the quote on that... | _Any_ add of code is | a potential point for new bugs! Sure... (what kind of an argument is this at this stage of development, we haven't even had a feature freeze yet.) | A branch would be really good, for this type of stuff (also for the | ParagraphList stuff) until we really see that it works. I have effectvely worked in a branch with the ParagraphList stuff all along, I have alos posted patches to this list with the complete diff... have you tried it? (or even looked at it.) I also stated several months ago that I have now done all the changes that I dare to do... without getting it into HEAD... | I may be able | to download a branch and test it but I surely will not apply monster | patches to some version of the sourcetree. What is the real difference? | I *really* think we should help John to get the Qt version out and | be done with a second working GUII implementation. Please do... we are waiting for your patches. | We should already | now try to fix some of the *long* buglist on bugzilla and get 1.3.0 | out of the door as fast as possible. Done the GUII part we can concentratre | on adding new stuff and makeing the core even cleaner. even cleaner... hilarious... -- Lgb
Re: [PATCH] Once again: New xforms Graphics-dialog
Dekel Tsur [EMAIL PROTECTED] writes: | On Sat, Aug 24, 2002 at 08:00:16PM +0900, Rob Lahaye wrote: You need to put the figure inside a figure float. So when writing LaTeX output, the code should detect if the graphics is inside a float or not. Is that possible? | It would be better to disable the subfigure buttons in the dialog when the | figure is not inside a float (and we also need to handle copypaste of a | figure with subfigure caption into a position outside a float). Or just realize that subfigure has nothing to do with graphics at all... it is a logical entity of its own. It really does not belong in any graphics dialog. -- Lgb
Re: No \end_deeper gets output into lyx file
Martin Vermeer [EMAIL PROTECTED] writes:
| On Sat, Aug 24, 2002 at 02:32:27PM +0300, Martin Vermeer wrote:
Fix should be easy. Left as an exercise for the reader :-)
Martin, off to Thessaloniki for a week!
| Yep, this does it. Couldn't resist -- patch attached.
| 2002-08-24Martin Vermeer [EMAIL PROTECTED]
| * paragraph.C:
| * insets/insettext.C: fixed the 'deeper and deeper...' bug in nested
| environments.
Yes, this looks correct.
| Martin
| --
| Martin Vermeer [EMAIL PROTECTED]
| Helsinki University of Technology
| Department of Surveying
| P.O. Box 1200, FIN-02015 HUT, Finland
| :wq
| Index: paragraph.C
| ===
| RCS file: /cvs/lyx/lyx-devel/src/paragraph.C,v
| retrieving revision 1.226
| diff -u -p -r1.226 paragraph.C
| --- paragraph.C 2002/08/23 09:05:31 1.226
| +++ paragraph.C 2002/08/24 11:46:56
| @@ -177,7 +177,7 @@ Paragraph::~Paragraph()
| void Paragraph::write(Buffer const * buf, ostream os,
| BufferParams const bparams,
| - depth_type dth) const
| + depth_type dth) const
| {
| // The beginning or end of a deeper (i.e. nested) area?
| if (dth != params().depth()) {
| Index: insettext.C
| ===
| RCS file: /cvs/lyx/lyx-devel/src/insets/insettext.C,v
| retrieving revision 1.327
| diff -u -p -r1.327 insettext.C
| --- insettext.C 2002/08/21 17:35:24 1.327
| +++ insettext.C 2002/08/24 11:55:35
| @@ -239,8 +239,9 @@ void InsetText::writeParagraphData(Buffe
| {
| ParagraphList::iterator it = paragraphs.begin();
| ParagraphList::iterator end = paragraphs.end();
| + Paragraph::depth_type dth = 0;
| for (; it != end; ++it) {
| - it-write(buf, os, buf-params, 0);
| + it-write(buf, os, buf-params, dth);
| }
| }
--
Lgb
Re: Core cleaning
On Mon, Aug 26, 2002 at 11:12:11AM +0200, Lars Gullik Bjønnes wrote: We already have one breakage now... begin_deeper end_deeper, let's not add another before this one is fixed. This seems to be fixed by Martin's patch. I'll just commit as it makes things working at least for me (and looks right btw...) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx
Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Aug 26, 2002 at 08:52:52AM +0200, Andre' Poenitz wrote: I just translated a few docs written in 1998 with 0.12 and they all look fine. | Hm... I just wonder: Is it a good idea to do the conversion automatically | without a warning? I think there should be a warning, and the original file should not be replaced. | After all, saving the doc after conversion destroys it, as it possibly | can't be read by the version of LyX that originally created it. doc should be renamed. -- Lgb
Re: lyx2lyx
On Mon, Aug 26, 2002 at 11:33:51AM +0200, Lars Gullik Bjønnes wrote: | Hm... I just wonder: Is it a good idea to do the conversion automatically | without a warning? I think there should be a warning, and the original file should not be replaced. It is only overwritten if one saves. But as everything is silent, this might be totally unexpected. | After all, saving the doc after conversion destroys it, as it possibly | can't be read by the version of LyX that originally created it. doc should be renamed. Or like this... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Core cleaning
Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Aug 26, 2002 at 11:12:11AM +0200, Lars Gullik Bjønnes wrote: We already have one breakage now... begin_deeper end_deeper, let's not add another before this one is fixed. | This seems to be fixed by Martin's patch. I'll just commit as it makes | things working at least for me (and looks right btw...) Yes, it does. -- Lgb
Re: lyx2lyx
On Mon, Aug 26, 2002 at 08:52:52AM +0200, Andre Poenitz wrote: Cool stuff. I just translated a few docs written in 1998 with 0.12 and they all look fine. Andre' PS: [Numbers like '20136' or '41648' get written to the console, but that's not really a problem]. Those are just debug numbers, as usually the file gets bigger since the new tabular format is more verbose. Ignore those numbers for the moment (I will remove them soon). -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: problem with Docbook export
On Mon, Aug 26, 2002 at 11:40:28AM +0300, Alaa The Great wrote: Hi all, I'm not sure if this is the correct place to send this, so please forgive me it is my first time to try and submit a bug report. this may be old news, I know when exporting docbook documents LyX 1.2.1 and 1.2.0 before it uses sect4title /title/sect4 instead of para /para fixing the sgml output is not simply a matter of replacing strings since LyX messes up the tags more when lists or other elements are embedded inside the paragraph. I solved this problem by editing the layout/db_stdsections.inc file and changing the paragraph and subparagraph style definitions to # Paragraph style definition Style Paragraph LatexType Paragraph LatexName para End # Subparagraph style definition Style Subparagraph LatexType Paragraph LatexName para End this of course means that paragraph and subparagraph will be the same in the sgml output, I found no equivalent to subparagraph in the docbook reference but maybe I didn't look hard enough. This is just a question of terminology, akin to the latex version paragraph and subparagraph are the 4th and 5th section level, this is sect4 and sect5 of docbook. The usual paragraph is called Standard, as it is the standard paragraph. :-= another error LyX produces is putting the toc/toc tags for table of contents inside bookinfo,articleinfo,etc. tag, and within a paragraph. the bookinfo articleinfo and all the other *info tags are not parents to toc it would be better to put it outside as a child of the book or article, etc. tag I've failed to find the intery for the table of contents in the layout files. toc is just a legacy tag as it concern to docbook since most of the transformation tools ignore it. I am not too concern about this... keep the good work and sorry for bothering you, Alaa All ht efeedback is welcome. -- Perilous to all of us are the devices of an art deeper than we ourselves possess. -- Gandalf the Grey [J.R.R. Tolkien, Lord of the Rings] -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Off for the weekend
Lars Gullik Bjønnes wrote: | That's no excuse. IMO that it was a _really_ bad move of Lars to introduce | that ParagraphList stuff right now! Why? I have taken a lot of care to not change neigher input/display/output of lyx, but of course I do have bugs in my code.. (I am perfectly willing to admit that.) Because I think we agreed to have a fast release this time. We still have lot's of bugs to fix and IMO this could have waited a bit longer. Sure... (what kind of an argument is this at this stage of development, we haven't even had a feature freeze yet.) I accept this, but then this shouldn't be a one sided thing. You tell us that we are in developement and so can shove in all we like. I don't think that is really what we want. I have effectvely worked in a branch with the ParagraphList stuff all along, I have alos posted patches to this list with the complete diff... have you tried it? (or even looked at it.) I didn't see any branch for this I could check out and compile. What is the real difference? Less work. I don't have to resolve conflicts because I only have time to look at your patch 2 days after and someone already changed the source. Please do... we are waiting for your patches. I would love to do it. And I think you've seen that I try to send bugfixes from time to time. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Off for the weekend
Juergen Vigna [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | That's no excuse. IMO that it was a _really_ bad move of Lars to introduce | that ParagraphList stuff right now! Why? I have taken a lot of care to not change neigher input/display/output of lyx, but of course I do have bugs in my code.. (I am perfectly willing to admit that.) | Because I think we agreed to have a fast release this time. We still | have lot's of bugs to fix and IMO this could have waited a bit longer. The thing is that my patch was beginning to grow stale, just as it would if I had it in a branch. It was time to get it in now. And I have done it piece by piece, and the larger onces I also sent as patches to the list before committing them. Sure... (what kind of an argument is this at this stage of development, we haven't even had a feature freeze yet.) | I accept this, but then this shouldn't be a one sided thing. You tell | us that we are in developement and so can shove in all we like. I don't | think that is really what we want. No I do not tell you that. The ParagraphList stuff is patches I have been working on for several months. What is the real difference? | Less work. I don't have to resolve conflicts because I only have time | to look at your patch 2 days after and someone already changed the source. I'd like to look at your patch now, can you send me an updated one? Yes, sure, just give me five minutes. -- Lgb
Re: Off for the weekend
On Mon, Aug 26, 2002 at 02:00:55PM +0200, Juergen Vigna wrote: Because I think we agreed to have a fast release this time. We still have lot's of bugs to fix and IMO this could have waited a bit longer. There are a few things that cannot be fixed properly without these kind of change. One that annoyed me this morning is the Comment layout that of course loses information about the contained lists and section headings. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
move cutpaste handling from BufferView to LyXText
This somewhat changes semantics as the original version dispatches to
the main LyXText, whereas this patch dispatches to the one returned by
getLyXText(). I have played a bit around and could not find any problem so
I would guess it is safe. But as I am not sure it would be nice if somebody
could have a look and/or give it a try.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.101
diff -u -p -r1.101 BufferView.h
--- BufferView.h22 Aug 2002 13:02:13 - 1.101
+++ BufferView.h26 Aug 2002 12:50:35 -
-130,12 +130,6 public:
///
bool gotoLabel(string const label);
///
- void paste();
- ///
- void cut(bool realcut = true);
- ///
- void copy();
- ///
void pasteEnvironment();
///
void copyEnvironment();
Index: BufferView2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView2.C,v
retrieving revision 1.146
diff -u -p -r1.146 BufferView2.C
--- BufferView2.C 20 Aug 2002 17:18:17 - 1.146
+++ BufferView2.C 26 Aug 2002 12:50:35 -
-391,57 +391,7 void BufferView::pasteEnvironment()
}
-void BufferView::copy()
-{
- if (available()) {
- getLyXText()-copySelection(this);
- owner()-message(_(Copy));
- }
-}
-
-
-void BufferView::cut(bool realcut)
-{
- if (available()) {
- hideCursor();
- update(text, BufferView::SELECT|BufferView::FITCUR);
- text-cutSelection(this, true, realcut);
- update(text, BufferView::SELECT|BufferView::FITCUR|BufferView::CHANGE);
- owner()-message(_(Cut));
- }
-}
-
-
-void BufferView::paste()
-{
- if (!available())
- return;
-
- owner()-message(_(Paste));
-
- hideCursor();
- // clear the selection
- toggleSelection();
- text-clearSelection();
- update(text, BufferView::SELECT|BufferView::FITCUR);
-
- // paste
- text-pasteSelection(this);
- // bug 393
- text-clearSelection();
- update(text, BufferView::SELECT|BufferView::FITCUR|BufferView::CHANGE);
-// why fake a selection only I think it should be a real one and not only
-// a painted one (Jug 20020318).
-#if 0
- // clear the selection
- toggleSelection();
- text-clearSelection();
- update(text, BufferView::SELECT|BufferView::FITCUR);
-#endif
-}
-
-
-/* these functions are for the spellchecker */
+// these functions are for the spellchecker
WordLangTuple const BufferView::nextWord(float value)
{
if (!available()) {
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.293
diff -u -p -r1.293 BufferView_pimpl.C
--- BufferView_pimpl.C 23 Aug 2002 09:05:27 - 1.293
+++ BufferView_pimpl.C 26 Aug 2002 12:50:35 -
-1442,19 +1442,6 bool BufferView::Pimpl::dispatch(FuncReq
break;
}
- case LFUN_PASTE:
- bv_-paste();
- switchKeyMap();
- break;
-
- case LFUN_CUT:
- bv_-cut();
- break;
-
- case LFUN_COPY:
- bv_-copy();
- break;
-
case LFUN_LAYOUT_COPY:
bv_-copyEnvironment();
break;
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.6
diff -u -p -r1.6 text3.C
--- text3.C 22 Aug 2002 15:04:27 - 1.6
+++ text3.C 26 Aug 2002 12:50:35 -
-485,7 +485,9 Inset::RESULT LyXText::dispatch(FuncRequ
// just comment out the line below...
bv-showCursor();
} else {
- bv-cut(false);
+ update(bv, false);
+ cutSelection(bv, true);
+ update(bv);
}
bv-moveCursorUpdate(false);
bv-owner()-view_state_changed();
-518,15 +520,16 Inset::RESULT LyXText::dispatch(FuncRequ
cursorLeft(bv);
Delete(bv);
selection.cursor = cursor;
- update(bv);
}
} else {
Delete(bv);
selection.cursor = cursor;
- update(bv);
}
-
Re: move cutpaste handling from BufferView to LyXText
Andre Poenitz [EMAIL PROTECTED] writes: | This somewhat changes semantics as the original version dispatches to | the main LyXText, whereas this patch dispatches to the one returned by | getLyXText(). I have played a bit around and could not find any problem so | I would guess it is safe. But as I am not sure it would be nice if somebody | could have a look and/or give it a try. It looks ok, but I have no time to try it. -- Lgb
Re: [Patch] autogen.sh
I'm not too much of an autotool expert, but I'm actually wondering why this autogen.sh script is still used. Why can't the regular Makefile do the same, by simply adding the required dependencies? For example, why not having in the Makefile something like: Because there's no Makefile in the distribution (it's a file generated by the autotools' generated configure :-), and it would be *bad* to have it distributed just so that autotools could work. Alas, there can be something like Makefile.auto which would be fixed and not auto-generated. Then autogen.sh could just be #!/bin/sh exec make -f Makefile.auto Cheers, Kuba Ober
Re: move cutpaste handling from BufferView to LyXText
On Mon, Aug 26, 2002 at 03:15:40PM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | This somewhat changes semantics as the original version dispatches to | the main LyXText, whereas this patch dispatches to the one returned by | getLyXText(). I have played a bit around and could not find any problem so | I would guess it is safe. But as I am not sure it would be nice if somebody | could have a look and/or give it a try. It looks ok, but I have no time to try it. No problem. All of the other text related lfuns dispatch to getLyXText() and I can't see (yet) a technical reason why this should be different for cutpaste... The funny thing is, almost every LFUN in BufferView_pimpl/LyXText seem to use its own sequence of cursor hiding, local dispatching, updating, etc... And most of them seem to work interchangably, so I'd guess in the end a lot of those could be simplified. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: eps-png-eps conversion
On sobota 24 sierpie 2002 12:34 am, Rod Pinna wrote: AFAIK, epsi is an EPS file with a bitmap thumbnail (stored as a Postscript comment). Yup. I have some files in that format, as I sometimes have a need to share graphs with word users. Using .epsi means that they get a nice preview in word. Also, Word can print them out on non-ps printers. Side note: Word prints the previews only on non-ps printers. These look butt ugly and make many not-knowing-any-better people think that you've sent them some crap-quality graphics. Word doesn't really work with .eps files unless you've got a way to print out postscript files. For majority of users that means that .eps files and Word are a big no-no. Cheers, Kuba Ober
Re: Off for the weekend
Lars Gullik Bjønnes wrote: No I do not tell you that. The ParagraphList stuff is patches I have been working on for several months. I believe you nevertheless it would have been nice to have in a branch before that. IMO you should start now a branch an put all your further changes there. So first you don't need to send patches to the list and second we can have a look at it at any time. I'd like to look at your patch now, can you send me an updated one? Yes, sure, just give me five minutes. Well and you are online 24 hours a day and read you email all the time isn't it? Maybe I have time a Saturday night and I do it there, then how would you send me the patch in 5 minutes. IMO we have the tools and we should use them. If you don't like to use branches then tell us so. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: move cutpaste handling from BufferView to LyXText
Andre Poenitz wrote: No problem. All of the other text related lfuns dispatch to getLyXText() and I can't see (yet) a technical reason why this should be different for cutpaste... I guess you tried it with multiple InsetText's (say a noteinset inside a tabular inside a float). The funny thing is, almost every LFUN in BufferView_pimpl/LyXText seem to use its own sequence of cursor hiding, local dispatching, updating, etc... And most of them seem to work interchangably, so I'd guess in the end a lot of those could be simplified. If I'm not wrong (and I think I am not ;) this is because before I cleaned up the CutPaste stuff and put all of it inside it's own class the buffer was inside the main LyXText (it has to be a global buffer otherwise you aren't able to copy between different LyXText's). But it could also be that a BufferView does only have 1 LyXText and the lfuns are handled directly inside InsetText too so the ones coming to BufferView did handle only the ones for it's LyXText so it was not neccessary to specify the getLyXText() stuff. What we could do is have a look if we could also remove the handling in InsetText of this lfuns IMO it should work. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Debian packages [was: [ANNOUNCE] LyX 1.2.1 is released]
[EMAIL PROTECTED] (Jean-Marc Lasgouttes) writes: Paul == Paul Seelig [EMAIL PROTECTED] writes: Paul Updated *unofficial* Debian packages compiled with Paul libforms_1.0-RC4.1 are available here: Do you want them to go on ftp.lyx.org? I'd need the approval of Jules Bean, the official Debian maintainer for this package. But unfortunately he doesn't seem to be reachable. So better don't. Thanks, P. *8^)
Re: Off for the weekend
On Mon, Aug 26, 2002 at 03:37:06PM +0200, Juergen Vigna wrote: I believe you nevertheless it would have been nice to have in a branch before that. IMO you should start now a branch an put all your further changes there. So first you don't need to send patches to the list and second we can have a look at it at any time. [Even if this was not directed to me] Branches do not get the same testing as the main tree. The changes to the paragraph list are not fundamentally in the sense that they can break everything which can't be fixed in a few minutes or so. [They are of course fundamentally in the sense that many other cleaning and new features depend on getting this right] It _has_ to be done some time, and there is no real reason why that time should not be now. I, for starters, do not want do work on the Qt frontend (for various reasons, not the least of which is no fun). Inset unification was postponed, there are not too many show stoppers within mathed, and 5 out of 14 mathed bugs/feature requests on bugzilla are fixable only in the interface core-mathed or only in the core. So shuffling stuff around in the core does not look unreasonable to me. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: move cutpaste handling from BufferView to LyXText
On Mon, Aug 26, 2002 at 03:46:11PM +0200, Juergen Vigna wrote: I guess you tried it with multiple InsetText's (say a noteinset inside a tabular inside a float). I just tired nested tabulars, but that should have the same effect... But it could also be that a BufferView does only have 1 LyXText and the lfuns are handled directly inside InsetText too so the ones coming to BufferView did handle only the ones for it's LyXText so it was not neccessary to specify the getLyXText() stuff. Maybe. What we could do is have a look if we could also remove the handling in InsetText of this lfuns IMO it should work. I am currently moving things the other way round: Changes to the text (and cutpaste is a change to the _text_) should be done in the LyXText. But that's conceptually not very different except that things take care of their own business (BufferView handling text manipulation simply does not look right). Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [Patch] autogen.sh
Kuba Ober [EMAIL PROTECTED] writes: I'm not too much of an autotool expert, but I'm actually wondering why this autogen.sh script is still used. Why can't the regular Makefile do the same, by simply adding the required dependencies? For example, why not having in the Makefile something like: | Because there's no Makefile in the distribution (it's a file generated by the | autotools' generated configure :-), and it would be *bad* to have it | distributed just so that autotools could work. | Alas, there can be something like Makefile.auto which would be fixed and not | auto-generated. Then autogen.sh could just be | #!/bin/sh | exec make -f Makefile.auto autogen script is only needed for CVS users, it is used to create the configure script. -- Lgb
[Patch] factory.diff
This moves the generation of a few insets behind a common interface.
[The Plan is, of course, to have most/all of them there at some point of
time...]
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.294
diff -u -p -r1.294 BufferView_pimpl.C
--- BufferView_pimpl.C 26 Aug 2002 13:25:47 - 1.294
+++ BufferView_pimpl.C 26 Aug 2002 15:19:34 -
-41,6 +41,7
#include undo_funcs.h
#include funcrequest.h
#include language.h
+#include factory.h
#include insets/insetbib.h
#include insets/insettext.h
-50,22 +51,11
#include insets/insetref.h
#include insets/insetparent.h
#include insets/insetindex.h
-#include insets/insetnote.h
#include insets/insetinclude.h
#include insets/insetcite.h
-#include insets/insetert.h
-#include insets/insetexternal.h
#include insets/insetgraphics.h
-#include insets/insetfoot.h
#include insets/insetmarginal.h
-#include insets/insetminipage.h
-#include insets/insetfloat.h
#include insets/insettabular.h
-#include insets/insetoptarg.h
-#if 0
-#include insets/insettheorem.h
-#include insets/insetlist.h
-#endif
#include insets/insetcaption.h
#include insets/insetfloatlist.h
-1626,67 +1616,41 bool BufferView::Pimpl::dispatch(FuncReq
}
break;
+#if 0
+ case LFUN_INSET_LIST:
+ case LFUN_INSET_THEOREM:
+#endif
+ case LFUN_INSERT_NOTE:
case LFUN_INSET_ERT:
- insertAndEditInset(new InsetERT(buffer_-params));
- break;
-
case LFUN_INSET_EXTERNAL:
- insertAndEditInset(new InsetExternal);
- break;
-
+ case LFUN_INSET_FLOAT:
case LFUN_INSET_FOOTNOTE:
- insertAndEditInset(new InsetFoot(buffer_-params));
- break;
-
case LFUN_INSET_MARGINAL:
- insertAndEditInset(new InsetMarginal(buffer_-params));
- break;
-
case LFUN_INSET_MINIPAGE:
- insertAndEditInset(new InsetMinipage(buffer_-params));
- break;
-
- case LFUN_INSERT_NOTE:
- insertAndEditInset(new InsetNote(buffer_-params));
- break;
-
case LFUN_INSET_OPTARG:
- insertAndEditInset(new InsetOptArg(buffer_-params));
- break;
-
- case LFUN_INSET_FLOAT:
- // check if the float type exist
- if (floatList.typeExist(ev.argument)) {
- insertAndEditInset(new InsetFloat(buffer_-params,
- ev.argument));
- } else {
- lyxerr Non-existent float type:
- ev.argument endl;
- }
- break;
-
case LFUN_INSET_WIDE_FLOAT:
- // check if the float type exist
- if (floatList.typeExist(ev.argument)) {
- InsetFloat * new_inset =
- new InsetFloat(buffer_-params, ev.argument);
- new_inset-wide(true);
- insertAndEditInset(new_inset);
- } else {
- lyxerr Non-existent float type:
- ev.argument endl;
- }
- break;
+ {
+ FuncRequest cmd = ev;
+ cmd.setView(bv_);
+ Inset * inset = createInset(cmd);
+ if (inset) {
+ bool gotsel = false;
-#if 0
- case LFUN_INSET_LIST:
- insertAndEditInset(new InsetList);
- break;
+ if (bv_-getLyXText()-selection.set()) {
+ bv_-getLyXText()-cutSelection(bv_, true, false);
+ gotsel = true;
+ }
- case LFUN_INSET_THEOREM:
- insertAndEditInset(new InsetTheorem);
+ if (insertInset(inset)) {
+ inset-edit(bv_);
+ if (gotsel)
+
+owner_-dispatch(FuncRequest(LFUN_PASTESELECTION));
+ }
+ else
+ delete inset;
+ }
break;
-#endif
+ }
case LFUN_INSET_CAPTION:
{
-1991,32 +1955,6 void BufferView::Pimpl::smartQuote()
pos).language()-lang() == hebrew ||
(!insertInset(new InsetQuotes(c, buffer_-params
bv_-owner()-dispatch(FuncRequest(LFUN_SELFINSERT, \));
-}
-
-
-void BufferView::Pimpl::insertAndEditInset(Inset * inset)
-{
-#if 0
- if (insertInset(inset))
- inset-edit(bv_);
-
Re: [Patch] factory.diff
Andre Poenitz [EMAIL PROTECTED] writes: | This moves the generation of a few insets behind a common interface. | [The Plan is, of course, to have most/all of them there at some point of | time...] This changes behavious as well? -- Lgb
Re: [Patch] factory.diff
On Mon, Aug 26, 2002 at 05:31:24PM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | This moves the generation of a few insets behind a common interface. | [The Plan is, of course, to have most/all of them there at some point of | time...] This changes behavious as well? No. Should be completely unvisible. It does not even move the creation from BufferView to LyXText::dispatch() Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [Patch] factory.diff
Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Aug 26, 2002 at 05:31:24PM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | This moves the generation of a few insets behind a common interface. | [The Plan is, of course, to have most/all of them there at some point of | time...] This changes behavious as well? | No. Should be completely unvisible. It does not even move the creation | from BufferView to LyXText::dispatch() What about the insertAndEdit thing? -- Lgb
Re: [Patch] factory.diff
On Mon, Aug 26, 2002 at 05:47:44PM +0200, Lars Gullik Bjønnes wrote: | No. Should be completely unvisible. It does not even move the creation | from BufferView to LyXText::dispatch() What about the insertAndEdit thing? Used to be a private member of BufferView_pimpl. It's just moved down from the beginning of the file to the case branch. As I was planning to move it to text3.C it's better to have it in a single chunk, makes cutpaste errors less likely... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [Patch] autogen.sh
On poniedziałek 26 sierpień 2002 11:15 am, Lars Gullik Bjønnes wrote: Kuba Ober [EMAIL PROTECTED] writes: I'm not too much of an autotool expert, but I'm actually wondering why this autogen.sh script is still used. Why can't the regular Makefile do the same, by simply adding the required dependencies? For example, why not having in the Makefile something like: | | Because there's no Makefile in the distribution (it's a file generated by | the autotools' generated configure :-), and it would be *bad* to have it | distributed just so that autotools could work. | | Alas, there can be something like Makefile.auto which would be fixed and | not auto-generated. Then autogen.sh could just be | | #!/bin/sh | exec make -f Makefile.auto autogen script is only needed for CVS users, it is used to create the configure script. s/distribution/CVS tree/ ;-) Still, the question is whether it wouldn't make sense to move autogen.sh into a Makefile.auto? (no, lazy me hasn't looked at autogen.sh in any detail...) Cheers, Kuba Ober
Re: Graphics: LyX-display Grayscale != Grayscale ?
On 23 Aug 2002, Jean-Marc Lasgouttes wrote:
Allan == Allan Rae [EMAIL PROTECTED] writes:
Allan On Thu, 22 Aug 2002, Rob Lahaye wrote:
Ah got it; a break missing in insetgraphicsParams.C:
switch (display) { [...] case InsetGraphicsParams::GRAYSCALE:
pars.display = grfx::GrayscaleDisplay; = break; missing here
case InsetGraphicsParams::COLOR: pars.display = grfx::ColorDisplay;
break;
So the GRAYSCALE falls immediately into the COLOR case! Will add
this to my upcoming patch to the new Graphics dialog!
Allan Is this needed for 1.2.2cvs also?
I did not find this code in 1.2.x, but maybe I did not look at the
right place.
I might have been misremembering but I thought there had been a report
about 1.2.1 having grayscale displayed in colour also. Easy enough to
test though if I find time...
Allan. (ARRae)
Re: New default.ui menu (the right one)
On Fri, 23 Aug 2002, John Levon wrote: I also couldn't find where `Menu layout' was used. Those functions in it don't appear to duplicated elsewhere either. What is this ? grep layout johns.ui and you'll find that it is a menu containing entries for the charcter styles: noun, emphasis and something else. Allan. (ARRae)
Re: [PATCH] Once again: New xforms Graphics-dialog
Lars Gullik Bjønnes wrote: Or just realize that subfigure has nothing to do with graphics at all... it is a logical entity of its own. It really does not belong in any graphics dialog. Shall I then remove the entire Subfigure entry from the Graphics dialog? What is the alternative? Should another inset be coded, called something like Subcaption; which allows additional subcaptions when having more than one figure, table etc. within one float? Rob. PS: I can remove the Subfigure entries from the Graphics dialog, but I have no idea about coding new Insets!!
[Patch] SIGEGV in BibTeX Database dialog.
Hi, Open the BibTeX Database dialog and immediately click on [Choose] (without selecting one of the available styles). Bang: SIGSEGV. We need to catch whether a selection for style has been made (i.e. fl_get_browser(dialog_-browser_styles) 0). Patch to FormBibtex.C attached. Rob. BibtexFix.diff.gz Description: application/gzip
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Sat, Aug 24, 2002 at 01:47:47PM +0900, Rob Lahaye wrote: > Any idea what patch has caused that? Seems like any mouse clicks inside minipages/floats etc are eaten. So it might be my fault whith the "use lfuns for mouse clicks" change and the cause might be found in insets/insettext.C... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
Andre Poenitz wrote:
> On Sat, Aug 24, 2002 at 01:47:47PM +0900, Rob Lahaye wrote:
>
>>Any idea what patch has caused that?
>
>
> Seems like any mouse clicks inside minipages/floats etc are eaten.
> So it might be my fault whith the "use lfuns for mouse clicks" change
> and the cause might be found in insets/insettext.C...
Have you tried John's patch from yesterday? It works for me here!
Index: insets/insettabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v
retrieving revision 1.224
diff -u -r1.224 insettabular.C
--- insets/insettabular.C 20 Aug 2002 20:30:45 - 1.224
+++ insets/insettabular.C 25 Aug 2002 00:37:03 -
@@ -920,7 +920,6 @@
return DISPATCHED;
case LFUN_MOUSE_RELEASE:
-
lfunMouseRelease(cmd);
return lfunMouseRelease(cmd) ? DISPATCHED : UNDISPATCHED;
case LFUN_SHIFT_TAB:
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.327
diff -u -r1.327 insettext.C
--- insets/insettext.C 21 Aug 2002 17:35:24 - 1.327
+++ insets/insettext.C 25 Aug 2002 00:37:24 -
@@ -1239,6 +1240,18 @@
int updwhat = 0;
int updflag = false;
switch (ev.action) {
+
+
case LFUN_MOUSE_PRESS:
+
lfunMousePress(ev);
+
return DISPATCHED;
+
+
case LFUN_MOUSE_MOTION:
+
lfunMouseMotion(ev);
+
return DISPATCHED;
+
+
case LFUN_MOUSE_RELEASE:
+
return lfunMouseRelease(ev) ? DISPATCHED : UNDISPATCHED;
+
// Normal chars
case LFUN_SELFINSERT:
if (bv->buffer()->isReadonly()) {
cvs.lyx.org: connection refused!
Jean-Marc Lasgouttes wrote: >>"Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes: > > > Rob> I use > > Rob> :pserver:[EMAIL PROTECTED]:/cvs/lyx > > Rob> What else is there? > > I use cvs.lyx.org, which is the real cvs (because I am an important > person and have an account there :). I think anoncvs has a delay of a > few dozens of minutes. Jean-Marc, This doesn't work for me: $ setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvs/lyx $ cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvs/lyx CVS password: cvs [login aborted]: connect to cvs.lyx.org(213.203.58.29):2401 failed: Connection refused I use "lyx" (without quotes) as password. What's wrong? BTW: If this server is supposed to work, why is it not mentioned on the LyX-devel webpages? Thanks, Rob.
lyx2lyx
Cool stuff. I just translated a few docs written in 1998 with 0.12 and they all look fine. Andre' PS: [Numbers like '20136' or '41648' get written to the console, but that's not really a problem]. -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Mon, Aug 26, 2002 at 03:49:12PM +0900, Rob Lahaye wrote: > Have you tried John's patch from yesterday? It works for me here! No. I've just seen it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx
On Mon, Aug 26, 2002 at 08:52:52AM +0200, Andre' Poenitz wrote: > I just translated a few docs written in 1998 with 0.12 and they all > look fine. Hm... I just wonder: Is it a good idea to do the conversion automatically without a warning? After all, saving the doc after conversion "destroys" it, as it possibly can't be read by the version of LyX that originally created it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Off for the weekend
Andre Poenitz wrote: > Because Lars started doing the paragraph list changes here and this stuff > is strongly related? And the paragraph cleanup probably can't bve done > without this kind of stuff? That's no excuse. IMO that it was a _really_ bad move of Lars to introduce that ParagraphList stuff right now! We still suffer from bugs in that code and he promised us that there will be *no* problem. _Any_ add of code is a potential point for new bugs! A branch would be really good, for this type of stuff (also for the ParagraphList stuff) until we really see that it works. I may be able to download a branch and test it but I surely will not apply monster patches to some version of the sourcetree. I *really* think we should help John to get the Qt version out and be done with a second working GUII implementation. We should already now try to fix some of the *long* buglist on bugzilla and get 1.3.0 out of the door as fast as possible. Done the GUII part we can concentratre on adding new stuff and makeing the core even cleaner. So if you want to try out new stuff now just create a branch and commit to that branch. Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] fix for mouse in insettext (ERT, etc.)
John Levon wrote: > Andre, Jug, please review, test and apply. Also there is a new bug that > where you have a cell selection in a table and click inside on of the > insettexts in a cell, a selection is made within the actual text. I > didn't see the immediate fix for this (if you can't fix this now, please > let me know so I can open a bugzilla bug on it). I will apply this as it seems the right fix ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: removing extern bool undo_frozen
John Levon wrote:
> Can't we just do :
>
> freezeUndo()
> {
> if (++undo_frozen_count == 1)
> undo_frozen = true;
> }
>
> unfreezeUndo()
> }{
> if (--undo_frozen_count == 0)
> undo_frozen = false;
> }
>
IMO this counting is error prone. Anyway we could just put the whole
stuff into a class with private static members (does this exist?) and
instead of using the external bool use a function, but at the end IMO
it's just the same.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Qt C-S-Z woes
John Levon wrote: > On Sun, Aug 25, 2002 at 06:53:36AM +0100, John Levon wrote: > > >>OK, after several hours on the damn thing, I give up. I cannot fix this >>bug. >> > > > w00t ! I got it. I was looking in totally the wrong place, and it was > very very simple. Oh well You see it helps talking to people (also if you do autoconverstation), but at the end we did point you in the right direction (mentally) and you could find it #:OP Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
tooltips won't go away
The yellow tooltip box that pops up after hoveering over e.g. the width field in the graphics dialog doesn't go away if the dialog is closed by pressing Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: tooltips won't go away
Andre Poenitz wrote: > The yellow tooltip box that pops up after hoveering over e.g. the width > field in the graphics dialog doesn't go away if the dialog is closed by > pressing Yep, here too. I think there may be a list of problems with tooltips in a tabbed dialog. E.g: when moving the dialog-window to somewhere else, will pop up the tooltips as if the dialog has not been moved. This and your problem do not exist in untabbed dialogs, such as the BibTeX Database dialog. Do the Xforms-devel people know about this? Rob.
problem with Docbook export
Hi all, I'm not sure if this is the correct place to send this, so please forgive me it is my first time to try and submit a bug report. this may be old news, I know when exporting docbook documents LyX 1.2.1 and 1.2.0 before it uses instead of fixing the sgml output is not simply a matter of replacing strings since LyX messes up the tags more when lists or other elements are embedded inside the paragraph. I solved this problem by editing the layout/db_stdsections.inc file and changing the paragraph and subparagraph style definitions to # Paragraph style definition Style Paragraph LatexType Paragraph LatexName para End # Subparagraph style definition Style Subparagraph LatexType Paragraph LatexName para End this of course means that paragraph and subparagraph will be the same in the sgml output, I found no equivalent to subparagraph in the docbook reference but maybe I didn't look hard enough. another error LyX produces is putting the tags for table of contents inside ,,etc. tag, and within a paragraph. the and all the other *info tags are not parents to it would be better to put it outside as a child of the or , etc. tag I've failed to find the intery for the table of contents in the layout files. keep the good work and sorry for bothering you, Alaa -- Perilous to all of us are the devices of an art deeper than we ourselves possess. -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]
preview-latex chrashes with xforms
Dear developpers, I compiled lyx-1.3.0cvs under SuSE 8.0 and RedHat with xfroms 0.89 and 1.0RC4. I tested the instant preview funnction on some textes. With small textes I have no problems. But I have a longer text with the following behavior of lyx and X-Windows: I start lyx-1.3.0cvs in a terminal. The text is opened and displayed (without preview) correctly. In the terminal a latex run is done on 0lyxpreview.tex. Dvipsk 5.86 generated 0lyxpreview.ps. Many ppm-files and a 0lyxpreview.metrics file are generated in a subdirectory of the tmp-directory. For short textes, now starts the recplacing of the math-formulas by the preview pictures. For the longer text (about 960 math formulas), sometimes the head of the lyx-windows changes the colors, the buttons disappear. After some seconds, the X-Windows collapses. However, sometimes preview latex works with these textes, too. So I don't believe that it is an error in the text, maybe a memory error? Norbert
Re: lyx2lyx not found?
On Mon, Aug 26, 2002 at 10:50:44AM +0900, Rob Lahaye wrote: > So I conclude that lyx2lyx is not at all installed with "gmake install-strip". > Is this an bug in the install script? I know. I didn't created the necessary configure*/Makefile* files needed to install the script. Since I don't know much about this, I leave it to someone else. (The lyxconvert*.py & lyx2lyx files should be installed in LYXDIR/lyx2lyx/ Then, a symbolic link should be created from LYXDIR/lyx2lyx/lyx2lyx into $PREFIX/bin/lyx2lyx)
cut in math
Any reason why cut should not work anymore in math, Mr Levon? ;-} 1.373(levon24-Aug-02): case LFUN_CUT: 1.373(levon24-Aug-02): case LFUN_COPY: 1.373(levon24-Aug-02): disable = !view()->getLyXText()->selection.set(); 1.373(levon24-Aug-02): break; Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BUG ALARM: begin_deeper/end_deeper botched
John Levon <[EMAIL PROTECTED]> writes: | On Fri, Aug 23, 2002 at 05:45:06PM +0300, Martin Vermeer wrote: > >> Just noticed this now. It goes deeper and deeper in a nested enumerate, >> but doesn't come back up. This happens during a write/read cycle of a .lyx >> file. I did a test, and it happens during writing. Actually the pattern >> can be more complex than painted above. > | I /think/ Lars broke it. I might have, but then it is just some tiny detail. | I've already lost one document to it... Life on the bleeding edge... -- Lgb
Re: Two graphics layout issues: display mode / subfigure
On Mon, Aug 26, 2002 at 02:10:22PM +0900, Rob Lahaye wrote: > Proposal two has two interaction widgets. To handle this properly, we have > to add an additional keyword to store the value of the two widgets > (e.g. choicelist=color; checkbutton=don't display). > This means: one more bool-variable is needed in the code (easy task), > but also storing the extra keyword in the Graphics-inset and Preferences-file. > The latter means a format change. Please don't make the file format more complicated. > A non-float graphics inset currently allows the use of the Subfigure input. > However, this causes errors in the LaTeX export, since Subfigure is only > allowed within floats. LyX should handle this more gracefully by > - ignoring the subfigure outside a float, when writing the LaTeX output > or >[...] > The first one seems to be better to me, since it is simpler to implement. But then the subcaption disappears without getting a feedback. Even the current situation, in which you get an (obscure) latex error is better.
Re: Core cleaning
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Fri, Aug 23, 2002 at 04:54:02PM +0200, Jean-Marc Lasgouttes wrote: >> Yes. Until you support all old functionality, you will probably not be >> able to remove any code. Therefore you are just adding bloat :) > | User definable environments are valuable as such. Not if existing environments cannot be moved to that scheme. -- Lgb
Re: Core cleaning
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > | Andre> On Fri, Aug 23, 2002 at 04:46:41PM +0200, Jean-Marc Lasgouttes | Andre> wrote: I guess that's why you are maintaining the stable branch | Andre> ;-} >>> That's not the point. When you are removing features, it is a bad >>> excuse to say that you don't care because the code is now simpler. >>> And proper displaying of lists is a basic feature, I think. > | Andre> I am talking about _temporarily_ breaking features in the | Andre> _development_ branch (and not even about that, rather about | Andre> adding half-functional stuff) and I am fairly confident to be | Andre> able to resolve resulting "issues". So you tell me that is | Andre> wrong? > | The temporarily was not clear in your posting. What I want to be sure | is that you know about all pitfalls you may encounter when designing | your code (non-rectangular insettext, ...) We already have one breakage now... begin_deeper end_deeper, let's not add another before this one is fixed. -- Lgb
Re: Core cleaning
On Mon, Aug 26, 2002 at 11:11:25AM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | On Fri, Aug 23, 2002 at 04:54:02PM +0200, Jean-Marc Lasgouttes wrote: > >> Yes. Until you support all old functionality, you will probably not be > >> able to remove any code. Therefore you are just adding bloat :) > > > | User definable environments are valuable as such. > > Not if existing environments cannot be moved to that scheme. User definable environments are valuable as such _even if existing environments cannot be moved to that scheme_. Alas, the point is mood, as existing environments could be moved to that scheme easily (and I even provided proof-of-concept code with the NewItemize environment). Unfortunately, last Friday the conservative bunch had a majority which did not like touching existing things at all (and rather opted to break Cut in math - SCNR, John ;-)). So this comment was there to make the idea to both sides more platable. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Off for the weekend
Juergen Vigna <[EMAIL PROTECTED]> writes: | Andre Poenitz wrote: >> Because Lars started doing the paragraph list changes here and this stuff >> is strongly related? And the paragraph cleanup probably can't bve done >> without this kind of stuff? > | That's no excuse. IMO that it was a _really_ bad move of Lars to introduce | that ParagraphList stuff right now! Why? I have taken a lot of care to not change neigher input/display/output of lyx, but of course I do have bugs in my code.. (I am perfectly willing to admit that.) | We still suffer from bugs in that code | and he promised us that there will be *no* problem. Please find the quote on that... | _Any_ add of code is | a potential point for new bugs! Sure... (what kind of an argument is this at this stage of development, we haven't even had a feature freeze yet.) | A branch would be really good, for this type of stuff (also for the | ParagraphList stuff) until we really see that it works. I have effectvely worked in a branch with the ParagraphList stuff all along, I have alos posted patches to this list with the complete diff... have you tried it? (or even looked at it.) I also stated several months ago that "I have now done all the changes that I dare to do"... without getting it into HEAD... | I may be able | to download a branch and test it but I surely will not apply monster | patches to some version of the sourcetree. What is the real difference? | I *really* think we should help John to get the Qt version out and | be done with a second working GUII implementation. Please do... we are waiting for your patches. | We should already | now try to fix some of the *long* buglist on bugzilla and get 1.3.0 | out of the door as fast as possible. Done the GUII part we can concentratre | on adding new stuff and makeing the core even cleaner. "even cleaner"... hilarious... -- Lgb
Re: [PATCH] Once again: New xforms Graphics-dialog
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Sat, Aug 24, 2002 at 08:00:16PM +0900, Rob Lahaye wrote: >> > You need to put the figure inside a figure float. >> >> So when writing LaTeX output, the code should detect if the graphics is inside >> a float or not. Is that possible? >> > | It would be better to disable the subfigure buttons in the dialog when the | figure is not inside a float (and we also need to handle copy of a | figure with subfigure caption into a position outside a float). Or just realize that subfigure has nothing to do with graphics at all... it is a logical entity of its own. It really does not belong in any graphics dialog. -- Lgb
Re: No \end_deeper gets output into lyx file
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Sat, Aug 24, 2002 at 02:32:27PM +0300, Martin Vermeer wrote:
>
>> Fix should be easy. Left as an exercise for the reader :-)
>>
>> Martin, off to Thessaloniki for a week!
>
| Yep, this does it. Couldn't resist -- patch attached.
>
| 2002-08-24Martin Vermeer <[EMAIL PROTECTED]>
>
| * paragraph.C:
| * insets/insettext.C: fixed the 'deeper and deeper...' bug in nested
| environments.
Yes, this looks correct.
| Martin
| --
| Martin Vermeer [EMAIL PROTECTED]
| Helsinki University of Technology
| Department of Surveying
| P.O. Box 1200, FIN-02015 HUT, Finland
| :wq
>
| Index: paragraph.C
| ===
| RCS file: /cvs/lyx/lyx-devel/src/paragraph.C,v
| retrieving revision 1.226
| diff -u -p -r1.226 paragraph.C
| --- paragraph.C 2002/08/23 09:05:31 1.226
| +++ paragraph.C 2002/08/24 11:46:56
| @@ -177,7 +177,7 @@ Paragraph::~Paragraph()
>
| void Paragraph::write(Buffer const * buf, ostream & os,
| BufferParams const & bparams,
| - depth_type dth) const
| + depth_type & dth) const
| {
| // The beginning or end of a deeper (i.e. nested) area?
| if (dth != params().depth()) {
| Index: insettext.C
| ===
| RCS file: /cvs/lyx/lyx-devel/src/insets/insettext.C,v
| retrieving revision 1.327
| diff -u -p -r1.327 insettext.C
| --- insettext.C 2002/08/21 17:35:24 1.327
| +++ insettext.C 2002/08/24 11:55:35
| @@ -239,8 +239,9 @@ void InsetText::writeParagraphData(Buffe
| {
| ParagraphList::iterator it = paragraphs.begin();
| ParagraphList::iterator end = paragraphs.end();
| + Paragraph::depth_type dth = 0;
| for (; it != end; ++it) {
| - it->write(buf, os, buf->params, 0);
| + it->write(buf, os, buf->params, dth);
| }
| }
>
--
Lgb
Re: Core cleaning
On Mon, Aug 26, 2002 at 11:12:11AM +0200, Lars Gullik Bjønnes wrote: > We already have one breakage now... begin_deeper end_deeper, let's not > add another before this one is fixed. This seems to be fixed by Martin's patch. I'll just commit as it makes things working at least for me (and looks right btw...) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Mon, Aug 26, 2002 at 08:52:52AM +0200, Andre' Poenitz wrote: >> I just translated a few docs written in 1998 with 0.12 and they all >> look fine. > | Hm... I just wonder: Is it a good idea to do the conversion automatically | without a warning? I think there should be a warning, and the original file should not be replaced. | After all, saving the doc after conversion "destroys" it, as it possibly | can't be read by the version of LyX that originally created it. doc should be renamed. -- Lgb
Re: lyx2lyx
On Mon, Aug 26, 2002 at 11:33:51AM +0200, Lars Gullik Bjønnes wrote: > | Hm... I just wonder: Is it a good idea to do the conversion automatically > | without a warning? > > I think there should be a warning, and the original file should not be > replaced. It is only overwritten if one saves. But as everything is silent, this might be totally unexpected. > | After all, saving the doc after conversion "destroys" it, as it possibly > | can't be read by the version of LyX that originally created it. > > doc should be renamed. Or like this... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Core cleaning
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Mon, Aug 26, 2002 at 11:12:11AM +0200, Lars Gullik Bjønnes wrote: >> We already have one breakage now... begin_deeper end_deeper, let's not >> add another before this one is fixed. > | This seems to be fixed by Martin's patch. I'll just commit as it makes | things working at least for me (and looks right btw...) Yes, it does. -- Lgb
Re: lyx2lyx
On Mon, Aug 26, 2002 at 08:52:52AM +0200, Andre Poenitz wrote: > > Cool stuff. > > I just translated a few docs written in 1998 with 0.12 and they all look fine. > > Andre' > > PS: [Numbers like '20136' or '41648' get written to the console, but > that's not really a problem]. Those are just debug numbers, as usually the file gets bigger since the new tabular format is more verbose. Ignore those numbers for the moment (I will remove them soon). > -- > Those who desire to give up Freedom in order to gain Security, > will not have, nor do they deserve, either one. (T. Jefferson) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: problem with Docbook export
On Mon, Aug 26, 2002 at 11:40:28AM +0300, Alaa The Great wrote: > Hi all, > > I'm not sure if this is the correct place to send this, so please forgive me it is >my first time to try and submit a bug report. > > this may be old news, I know > when exporting docbook documents LyX 1.2.1 and 1.2.0 before it uses > instead of > > fixing the sgml output is not simply a matter of replacing strings since LyX messes >up the tags more when lists or other elements are embedded inside the paragraph. > > I solved this problem by editing the layout/db_stdsections.inc file and changing the >paragraph and subparagraph style definitions to > > # Paragraph style definition > Style Paragraph > LatexType Paragraph > LatexName para > End > > # Subparagraph style definition > Style Subparagraph > LatexType Paragraph > LatexName para > End > > this of course means that paragraph and subparagraph will be the same in the sgml >output, I found no equivalent to subparagraph in the docbook reference but maybe I >didn't look hard enough. This is just a question of terminology, akin to the latex version paragraph and subparagraph are the 4th and 5th section level, this is sect4 and sect5 of docbook. The usual paragraph is called Standard, as it is the standard paragraph. :-= > another error LyX produces is putting the tags for table of contents >inside ,,etc. tag, and within a paragraph. > the and all the other *info tags are not parents to >it would be better to put it outside as a child of the or , etc. tag > I've failed to find the intery for the table of contents in the layout files. toc is just a legacy tag as it concern to docbook since most of the transformation tools ignore it. I am not too concern about this... > keep the good work and sorry for bothering you, > Alaa All ht efeedback is welcome. > -- > Perilous to all of us are the devices of an art deeper than we ourselves > possess. > -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"] -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Off for the weekend
Lars Gullik Bjønnes wrote: > | That's no excuse. IMO that it was a _really_ bad move of Lars to introduce > | that ParagraphList stuff right now! > > Why? I have taken a lot of care to not change neigher > input/display/output of lyx, but of course I do have bugs in my code.. > (I am perfectly willing to admit that.) Because I think we agreed to have a fast release this time. We still have lot's of bugs to fix and IMO this could have waited a bit longer. > Sure... > (what kind of an argument is this at this stage of development, we > haven't even had a feature freeze yet.) I accept this, but then this shouldn't be a one sided thing. You tell us that we are in developement and so can shove in all we like. I don't think that is really what we want. > I have effectvely worked in a branch with the ParagraphList stuff all > along, I have alos posted patches to this list with the complete > diff... have you tried it? (or even looked at it.) I didn't see any branch for this I could check out and compile. > What is the real difference? Less work. I don't have to resolve conflicts because I only have time to look at your patch 2 days after and someone already changed the source. > Please do... we are waiting for your patches. I would love to do it. And I think you've seen that I try to send bugfixes from time to time. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Off for the weekend
Juergen Vigna <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | That's no excuse. IMO that it was a _really_ bad move of Lars to introduce >> | that ParagraphList stuff right now! >> Why? I have taken a lot of care to not change neigher >> input/display/output of lyx, but of course I do have bugs in my code.. >> (I am perfectly willing to admit that.) > | Because I think we agreed to have a fast release this time. We still | have lot's of bugs to fix and IMO this could have waited a bit longer. The thing is that my patch was beginning to grow stale, just as it would if I had it in a branch. It was time to get it in now. And I have done it piece by piece, and the larger onces I also sent as patches to the list before committing them. >> Sure... >> (what kind of an argument is this at this stage of development, we >> haven't even had a feature freeze yet.) > | I accept this, but then this shouldn't be a one sided thing. You tell | us that we are in developement and so can shove in all we like. I don't | think that is really what we want. No I do not tell you that. The ParagraphList stuff is patches I have been working on for several months. >> What is the real difference? > | Less work. I don't have to resolve conflicts because I only have time | to look at your patch 2 days after and someone already changed the source. "I'd like to look at your patch now, can you send me an updated one?" "Yes, sure, just give me five minutes." -- Lgb
Re: Off for the weekend
On Mon, Aug 26, 2002 at 02:00:55PM +0200, Juergen Vigna wrote: > Because I think we agreed to have a fast release this time. We still > have lot's of bugs to fix and IMO this could have waited a bit longer. There are a few things that cannot be fixed properly without these kind of change. One that annoyed me this morning is the "Comment" layout that "of course" loses information about the contained lists and section headings. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
move cut handling from BufferView to LyXText
This somewhat changes semantics as the original version "dispatches" to
the "main" LyXText, whereas this patch dispatches to the one returned by
getLyXText(). I have played a bit around and could not find any problem so
I would guess it is safe. But as I am not sure it would be nice if somebody
could have a look and/or give it a try.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.101
diff -u -p -r1.101 BufferView.h
--- BufferView.h22 Aug 2002 13:02:13 - 1.101
+++ BufferView.h26 Aug 2002 12:50:35 -
@@ -130,12 +130,6 @@ public:
///
bool gotoLabel(string const & label);
///
- void paste();
- ///
- void cut(bool realcut = true);
- ///
- void copy();
- ///
void pasteEnvironment();
///
void copyEnvironment();
Index: BufferView2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView2.C,v
retrieving revision 1.146
diff -u -p -r1.146 BufferView2.C
--- BufferView2.C 20 Aug 2002 17:18:17 - 1.146
+++ BufferView2.C 26 Aug 2002 12:50:35 -
@@ -391,57 +391,7 @@ void BufferView::pasteEnvironment()
}
-void BufferView::copy()
-{
- if (available()) {
- getLyXText()->copySelection(this);
- owner()->message(_("Copy"));
- }
-}
-
-
-void BufferView::cut(bool realcut)
-{
- if (available()) {
- hideCursor();
- update(text, BufferView::SELECT|BufferView::FITCUR);
- text->cutSelection(this, true, realcut);
- update(text, BufferView::SELECT|BufferView::FITCUR|BufferView::CHANGE);
- owner()->message(_("Cut"));
- }
-}
-
-
-void BufferView::paste()
-{
- if (!available())
- return;
-
- owner()->message(_("Paste"));
-
- hideCursor();
- // clear the selection
- toggleSelection();
- text->clearSelection();
- update(text, BufferView::SELECT|BufferView::FITCUR);
-
- // paste
- text->pasteSelection(this);
- // bug 393
- text->clearSelection();
- update(text, BufferView::SELECT|BufferView::FITCUR|BufferView::CHANGE);
-// why fake a selection only I think it should be a real one and not only
-// a painted one (Jug 20020318).
-#if 0
- // clear the selection
- toggleSelection();
- text->clearSelection();
- update(text, BufferView::SELECT|BufferView::FITCUR);
-#endif
-}
-
-
-/* these functions are for the spellchecker */
+// these functions are for the spellchecker
WordLangTuple const BufferView::nextWord(float & value)
{
if (!available()) {
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.293
diff -u -p -r1.293 BufferView_pimpl.C
--- BufferView_pimpl.C 23 Aug 2002 09:05:27 - 1.293
+++ BufferView_pimpl.C 26 Aug 2002 12:50:35 -
@@ -1442,19 +1442,6 @@ bool BufferView::Pimpl::dispatch(FuncReq
break;
}
- case LFUN_PASTE:
- bv_->paste();
- switchKeyMap();
- break;
-
- case LFUN_CUT:
- bv_->cut();
- break;
-
- case LFUN_COPY:
- bv_->copy();
- break;
-
case LFUN_LAYOUT_COPY:
bv_->copyEnvironment();
break;
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.6
diff -u -p -r1.6 text3.C
--- text3.C 22 Aug 2002 15:04:27 - 1.6
+++ text3.C 26 Aug 2002 12:50:35 -
@@ -485,7 +485,9 @@ Inset::RESULT LyXText::dispatch(FuncRequ
// just comment out the line below...
bv->showCursor();
} else {
- bv->cut(false);
+ update(bv, false);
+ cutSelection(bv, true);
+ update(bv);
}
bv->moveCursorUpdate(false);
bv->owner()->view_state_changed();
@@ -518,15 +520,16 @@ Inset::RESULT LyXText::dispatch(FuncRequ
cursorLeft(bv);
Delete(bv);
selection.cursor = cursor;
- update(bv);
}
} else {
Delete(bv);
selection.cursor = cursor;
-
Re: move cut handling from BufferView to LyXText
Andre Poenitz <[EMAIL PROTECTED]> writes: | This somewhat changes semantics as the original version "dispatches" to | the "main" LyXText, whereas this patch dispatches to the one returned by | getLyXText(). I have played a bit around and could not find any problem so | I would guess it is safe. But as I am not sure it would be nice if somebody | could have a look and/or give it a try. It looks ok, but I have no time to try it. -- Lgb
Re: [Patch] autogen.sh
> I'm not too much of an autotool expert, but I'm actually wondering why this > autogen.sh script is still used. Why can't the regular Makefile do the > same, by simply adding the required dependencies? > For example, why not having in the Makefile something like: Because there's no Makefile in the distribution (it's a file generated by the autotools' generated configure :-), and it would be *bad* to have it distributed just so that autotools could work. Alas, there can be something like Makefile.auto which would be fixed and not auto-generated. Then autogen.sh could just be #!/bin/sh exec make -f Makefile.auto Cheers, Kuba Ober
Re: move cut handling from BufferView to LyXText
On Mon, Aug 26, 2002 at 03:15:40PM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | This somewhat changes semantics as the original version "dispatches" to > | the "main" LyXText, whereas this patch dispatches to the one returned by > | getLyXText(). I have played a bit around and could not find any problem so > | I would guess it is safe. But as I am not sure it would be nice if somebody > | could have a look and/or give it a try. > > It looks ok, but I have no time to try it. No problem. All of the other text related lfuns dispatch to getLyXText() and I can't see (yet) a technical reason why this should be different for cut The funny thing is, almost every LFUN in BufferView_pimpl/LyXText seem to use its own sequence of cursor hiding, "local dispatching", updating, etc... And most of them seem to work interchangably, so I'd guess in the end a lot of those could be simplified. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: eps->png->eps conversion
On sobota 24 sierpie 2002 12:34 am, Rod Pinna wrote: > > AFAIK, epsi is an EPS file with a bitmap thumbnail (stored as a > > Postscript comment). > > Yup. I have some files in that format, as I sometimes have a need to share > graphs with word users. Using .epsi means that they get a nice preview in > word. Also, Word can print them out on non-ps printers. Side note: Word prints the previews only on non-ps printers. These look butt ugly and make many not-knowing-any-better people think that you've sent them some crap-quality graphics. Word doesn't really work with .eps files unless you've got a way to print out postscript files. For majority of users that means that .eps files and Word are a big no-no. Cheers, Kuba Ober
Re: Off for the weekend
Lars Gullik Bjønnes wrote: > No I do not tell you that. The ParagraphList stuff is patches I have > been working on for several months. I believe you nevertheless it would have been nice to have in a branch before that. IMO you should start now a branch an put all your further changes there. So first you don't need to send patches to the list and second we can have a look at it at any time. > "I'd like to look at your patch now, can you send me an updated one?" > "Yes, sure, just give me five minutes." Well and you are online 24 hours a day and read you email all the time isn't it? Maybe I have time a Saturday night and I do it there, then how would you send me the patch in 5 minutes. IMO we have the tools and we should use them. If you don't like to use branches then tell us so. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: move cut handling from BufferView to LyXText
Andre Poenitz wrote: > No problem. All of the other text related lfuns dispatch to getLyXText() > and I can't see (yet) a technical reason why this should be different for > cut I guess you tried it with multiple InsetText's (say a noteinset inside a tabular inside a float). > The funny thing is, almost every LFUN in BufferView_pimpl/LyXText seem to > use its own sequence of cursor hiding, "local dispatching", updating, > etc... And most of them seem to work interchangably, so I'd guess in the > end a lot of those could be simplified. If I'm not wrong (and I think I am not ;) this is because before I cleaned up the Cut stuff and put all of it inside it's own class the buffer was inside the main LyXText (it has to be a global buffer otherwise you aren't able to copy between different LyXText's). But it could also be that a BufferView does only have 1 LyXText and the lfuns are handled directly inside InsetText too so the ones coming to BufferView did handle only the ones for it's LyXText so it was not neccessary to specify the getLyXText() stuff. What we could do is have a look if we could also remove the handling in InsetText of this lfuns IMO it should work. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Debian packages [was: [ANNOUNCE] LyX 1.2.1 is released]
[EMAIL PROTECTED] (Jean-Marc Lasgouttes) writes: > > "Paul" == Paul Seelig <[EMAIL PROTECTED]> writes: > > Paul> Updated *unofficial* Debian packages compiled with > Paul> libforms_1.0-RC4.1 are available here: > > Do you want them to go on ftp.lyx.org? > I'd need the approval of Jules Bean, the official Debian maintainer for this package. But unfortunately he doesn't seem to be reachable. So better don't. Thanks, P. *8^)
Re: Off for the weekend
On Mon, Aug 26, 2002 at 03:37:06PM +0200, Juergen Vigna wrote: > I believe you nevertheless it would have been nice to have in a branch > before that. IMO you should start now a branch an put all your further > changes there. So first you don't need to send patches to the list and > second we can have a look at it at any time. [Even if this was not directed to me] Branches do not get the same testing as the main tree. The changes to the paragraph list are not "fundamentally" in the sense that they can break everything which can't be fixed in a few minutes or so. [They are of course "fundamentally" in the sense that many other cleaning and new features depend on getting this right] It _has_ to be done some time, and there is no real reason why that time should not be now. I, for starters, do not want do work on the Qt frontend (for various reasons, not the least of which is "no fun"). "Inset unification" was postponed, there are not too many show stoppers within mathed, and 5 out of 14 mathed bugs/feature requests on bugzilla are fixable only in the interface core<->mathed or only in the core. So shuffling stuff around in the core does not look unreasonable to me. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: move cut handling from BufferView to LyXText
On Mon, Aug 26, 2002 at 03:46:11PM +0200, Juergen Vigna wrote: > I guess you tried it with multiple InsetText's (say a noteinset inside a > tabular inside a float). I just tired nested tabulars, but that should have the same effect... > But it could also be that a BufferView does only have 1 LyXText and the > lfuns are handled directly inside InsetText too so the ones coming to > BufferView did handle only the ones for it's LyXText so it was not > neccessary > to specify the getLyXText() stuff. Maybe. > What we could do is have a look if we could also remove the handling > in InsetText of this lfuns IMO it should work. I am currently moving things the other way round: Changes to the text (and cut is a change to the _text_) should be done in the LyXText. But that's conceptually not very different except that things take care of their own business (BufferView handling text manipulation simply does not look right). Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [Patch] autogen.sh
Kuba Ober <[EMAIL PROTECTED]> writes: >> I'm not too much of an autotool expert, but I'm actually wondering why this >> autogen.sh script is still used. Why can't the regular Makefile do the >> same, by simply adding the required dependencies? >> For example, why not having in the Makefile something like: > | Because there's no Makefile in the distribution (it's a file generated by the | autotools' generated configure :-), and it would be *bad* to have it | distributed just so that autotools could work. > | Alas, there can be something like Makefile.auto which would be fixed and not | auto-generated. Then autogen.sh could just be > | #!/bin/sh | exec make -f Makefile.auto autogen script is only needed for CVS users, it is used to create the configure script. -- Lgb
[Patch] factory.diff
This moves the generation of a few insets behind a common interface.
[The Plan is, of course, to have most/all of them there at some point of
time...]
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.294
diff -u -p -r1.294 BufferView_pimpl.C
--- BufferView_pimpl.C 26 Aug 2002 13:25:47 - 1.294
+++ BufferView_pimpl.C 26 Aug 2002 15:19:34 -
@@ -41,6 +41,7 @@
#include "undo_funcs.h"
#include "funcrequest.h"
#include "language.h"
+#include "factory.h"
#include "insets/insetbib.h"
#include "insets/insettext.h"
@@ -50,22 +51,11 @@
#include "insets/insetref.h"
#include "insets/insetparent.h"
#include "insets/insetindex.h"
-#include "insets/insetnote.h"
#include "insets/insetinclude.h"
#include "insets/insetcite.h"
-#include "insets/insetert.h"
-#include "insets/insetexternal.h"
#include "insets/insetgraphics.h"
-#include "insets/insetfoot.h"
#include "insets/insetmarginal.h"
-#include "insets/insetminipage.h"
-#include "insets/insetfloat.h"
#include "insets/insettabular.h"
-#include "insets/insetoptarg.h"
-#if 0
-#include "insets/insettheorem.h"
-#include "insets/insetlist.h"
-#endif
#include "insets/insetcaption.h"
#include "insets/insetfloatlist.h"
@@ -1626,67 +1616,41 @@ bool BufferView::Pimpl::dispatch(FuncReq
}
break;
+#if 0
+ case LFUN_INSET_LIST:
+ case LFUN_INSET_THEOREM:
+#endif
+ case LFUN_INSERT_NOTE:
case LFUN_INSET_ERT:
- insertAndEditInset(new InsetERT(buffer_->params));
- break;
-
case LFUN_INSET_EXTERNAL:
- insertAndEditInset(new InsetExternal);
- break;
-
+ case LFUN_INSET_FLOAT:
case LFUN_INSET_FOOTNOTE:
- insertAndEditInset(new InsetFoot(buffer_->params));
- break;
-
case LFUN_INSET_MARGINAL:
- insertAndEditInset(new InsetMarginal(buffer_->params));
- break;
-
case LFUN_INSET_MINIPAGE:
- insertAndEditInset(new InsetMinipage(buffer_->params));
- break;
-
- case LFUN_INSERT_NOTE:
- insertAndEditInset(new InsetNote(buffer_->params));
- break;
-
case LFUN_INSET_OPTARG:
- insertAndEditInset(new InsetOptArg(buffer_->params));
- break;
-
- case LFUN_INSET_FLOAT:
- // check if the float type exist
- if (floatList.typeExist(ev.argument)) {
- insertAndEditInset(new InsetFloat(buffer_->params,
- ev.argument));
- } else {
- lyxerr << "Non-existent float type: "
- << ev.argument << endl;
- }
- break;
-
case LFUN_INSET_WIDE_FLOAT:
- // check if the float type exist
- if (floatList.typeExist(ev.argument)) {
- InsetFloat * new_inset =
- new InsetFloat(buffer_->params, ev.argument);
- new_inset->wide(true);
- insertAndEditInset(new_inset);
- } else {
- lyxerr << "Non-existent float type: "
- << ev.argument << endl;
- }
- break;
+ {
+ FuncRequest cmd = ev;
+ cmd.setView(bv_);
+ Inset * inset = createInset(cmd);
+ if (inset) {
+ bool gotsel = false;
-#if 0
- case LFUN_INSET_LIST:
- insertAndEditInset(new InsetList);
- break;
+ if (bv_->getLyXText()->selection.set()) {
+ bv_->getLyXText()->cutSelection(bv_, true, false);
+ gotsel = true;
+ }
- case LFUN_INSET_THEOREM:
- insertAndEditInset(new InsetTheorem);
+ if (insertInset(inset)) {
+ inset->edit(bv_);
+ if (gotsel)
+
+owner_->dispatch(FuncRequest(LFUN_PASTESELECTION));
+ }
+ else
+ delete inset;
+ }
break;
-#endif
+ }
case LFUN_INSET_CAPTION:
{
@@ -1991,32 +1955,6 @@ void BufferView::Pimpl::smartQuote()
pos).language()->lang() == "hebrew" ||
(!insertInset(new InsetQuotes(c, buffer_->params
bv_->owner()->dispatch(FuncRequest(LFUN_SELFINSERT, "\""));
-}
-
-
-void
Re: [Patch] factory.diff
Andre Poenitz <[EMAIL PROTECTED]> writes: | This moves the generation of a few insets behind a common interface. | [The Plan is, of course, to have most/all of them there at some point of | time...] This changes behavious as well? -- Lgb
