Re: Inset::isTextInset?
On Sat, Mar 08, 2003 at 07:03:52PM +0100, Lars Gullik Bjønnes wrote: What does Inset::isTextInset really signify? - That it really is a InsetText? - That it contains a InsetText somewhere inside? I don't know. I believe this was a weird way to say this thing has a 'local cursor'. [Obvious from the name, isn't 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: more on lyxtext
On Sat, Mar 08, 2003 at 07:39:17PM +0100, Alfredo Braunstein wrote: Also remember that the cursor selection are members of LyXTexts, Which is completely broken. Both cursor and selection should be implemented on top of proper document iterators, not as some collection of LyXText members... 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: QT-Frontend Buglet
John Levon wrote: Good spotting, fixed now. thanks john I just checked cvs and as far as I can tell the patch made it into lyx-devel, but not into the 1_3_X-branch. I think that the patch should go in before 1.3.1. Michael -- Michael Abshoff - MRB - Universität Dortmund - Telefon 755-3463 (intern) Where do you want to RTFM today?
Re: more on lyxtext
Hi André. Andre Poenitz wrote: As a first step, I propose the removal of constness to all methods that are _not_ const, like cursorRight etc. I think that's a move in the wrong direction and 'mutable' is indeed the way to go here. I strongly disagree with you here. The document is _logically_ unchanged after a CursorRight. This is mildly true (a space was eliminated maybe), the _buffer_ can be const along the change. But the lyxtext, well (from lyxtext.h): /** This class holds the mapping between buffer paragraphs and screen rows. */ So after a cursor movement (which can imply double space removal, and then rebreak) _nothing_ has remained const in lyxtext. The whole point of the lyxtext is the rebreaks. It is certainly *not* logically unchanged. The problem I think is that we all are too much used to the fact that cursor movemement should be const in any way, and the double space/empty par removal should be eliminated. But hiding the head on the ground by ignoring the fact that the methods are not const at all is not the way to go (in my opinion). And anyway, the const keyword is not only to clarify the logic of the implementation. It is there also (primarily, again in my opinion) to be able to make stability assumptions about methods. I believe so, too. That's why I am not going to throw anything in your head ;-} A pitty. I almost started building a house with all bricks I have ;-) Alfredo
Re: more on lyxtext
On Sat, Mar 08, 2003 at 09:03:31PM +0100, Lars Gullik Bjønnes wrote: Because when you change documents you have to rebreak... rebreaking is expensive and takes time. As it is now. I don't believe there are hard technical reasons why rebreaking has to be expensive. I think all we need is the two-phase drawing machinery metrics/draw ... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Updated da.po
This is a new updated Danish da.po for LyX 1.3.1pre. Michael Smiths new perl script found a couple of errors, (thanks!) Claus -- Claus Hindsgaul [EMAIL PROTECTED] da.po.gz Description: GNU Zip compressed data
Re: QT-Frontend Buglet
Michael == Michael Abshoff [EMAIL PROTECTED] writes: Michael John Levon wrote: Good spotting, fixed now. thanks john Michael I just checked cvs and as far as I can tell the patch made it Michael into lyx-devel, but not into the 1_3_X-branch. I think that Michael the patch should go in before 1.3.1. John, could you do that? JMarc
Re: clean-up a 'gross hack'
Andre Poenitz wrote: On Fri, Mar 07, 2003 at 10:14:43PM +, Angus Leeming wrote: The attached patch works beautifully. Ok to apply? Have you checked math? No. I just assumed that you did the tight thing already ;-) -- Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Angus == Angus Leeming [EMAIL PROTECTED] writes: Icon dialog-show-new-inset graphics graphics.xpm Why ? Angus Because it's three lines of code and it's done in Angus ToolbarDefaults.C (which, as you note, is where this code Angus should be). Shall I do it? Jean-Marc Thqt does not mqke sense, IMO. This means that everybody Jean-Marc who needs to add an icon will have to hunt for the right Jean-Marc icon. Please, if you lfun names are too long, it's your Jean-Marc fault :) Now that I have access to a proper qwerty keyboard, I'd like to add that it may be a compelling reason why this lfun should be named inset-insert. Did anybody feel the need to rename file-insert to file-dialog-show-and-insert-file? For the same reasons, I think that inset-insert is a perfectly reasonable name for the purpose of inserting interactively any inset whether it needs a dialog or not. And for internal communication (the case where you pass the inset contents as argument) we could use inset-parse or soemthing like that. That said, I agree that the magic code to get the icon name should go to ToolbarDefaults. Also, Angus, if you feel like it, the menu and toolbar backends should really be changed into some controller and use proper signals instead of this stupid pimpls. JMarc
Re: questions about setting paragraph parameters
On Sun, Mar 09, 2003 at 06:39:51PM +, Angus Leeming wrote: * Can I split Paragraph::read,write into two and move the params parts to ParagraphParams? Will make it easy to pass the params to the frontends as a string. I think this is sensible in any case. 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: lyxtext mutables and consts
On Sun, Mar 09, 2003 at 08:15:09PM +0100, Alfredo Braunstein wrote: This patch removes the const keyword to a lot of methods in LyXText. The methods are not const at all, because they do cursor placements that imply double space/empty paragraph removal and then rebreaks (so almost no part of the lyxtext remains constant!). But the doc is _logically_ unchanged. I don't think I agree with you here. 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: toolbars
John == John Levon [EMAIL PROTECTED] writes: John On Fri, Mar 07, 2003 at 08:08:35PM +0100, Alfredo Braunstein John wrote: OT, but talking about toolbars, what happened to the math/table toolbars? Will they become default or something? John We've had some discussion about this and JMarc has some plans. Erm, I did _propose_ some plans! I will probably not have time to implement them in the near future. Proposing plans for other people to implement is something I really like to do. JMarc
Re: Xforms: Changes tracking dialog doesn't open anymore !
Rob Lahaye wrote:
Angus,
The Changes-dialog in Xforms doesn't open at all anymore with present CVS.
You have applied some modifications to the dialog Form files; did that
break anything?
BTW: I've sent a patch-prettified version of this dialog to this list, but
that has become slightly out-of-date. Shall I sent a more up-to-date
version? If yes, please first fix the problem with the dialog then.
Regards,
Rob.
You are lucky. I cannot open any document at all using the xforms frontend.
Trying to do so I get:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 1491)]
LyXView::updateLayoutChoice() (this=0xbfffe110)
at ../../../boost/boost/shared_ptr.hpp:209
209 return *this;
(gdb)
Which is absolutely nothing at all to do with me.
All works fine with the Qt frontend, so the Changes bug is probably
trivial... Yup. Should be fine now.
Angus
diff -u -p -r1.16 Dialogs3.C
--- src/frontends/xforms/Dialogs3.C 10 Mar 2003 03:13:26 - 1.16
+++ src/frontends/xforms/Dialogs3.C 10 Mar 2003 08:49:44 -
@@ -78,12 +78,11 @@
namespace {
-char const * const dialognames[] = { about, bibitem, bibtex,
citation,
-error, ert, external, float,
-graphics, include, index,
label,
-minipage, ref, tabular,
+char const * const dialognames[] = { about, bibitem, bibtex,
changes,
+citation, error, ert, external,
+float, graphics, include,
index,
+label, minipage, ref, tabular,
tabularcreate, toc, url, wrap
};
-
char const * const * const end_dialognames =
dialognames + (sizeof(dialognames) / sizeof(char *));
Re: autoconf errors in current cvs
Michael == Michael A Koziarski [EMAIL PROTECTED] writes: I needed to install autoconf 2.57 and automake 1.7 to get rid of these messages... Michael So have we moved autoconf 2.13 to unsupported now? I think it is supposed to work, but there is a bug. Anyway, it may be a good idea to decide that we get rid of ac 2.13 in 1.4.0cvs. JMarc
Re: lyxtext mutables and consts
Andre Poenitz wrote: On Sun, Mar 09, 2003 at 08:15:09PM +0100, Alfredo Braunstein wrote: This patch removes the const keyword to a lot of methods in LyXText. The methods are not const at all, because they do cursor placements that imply double space/empty paragraph removal and then rebreaks (so almost no part of the lyxtext remains constant!). But the doc is _logically_ unchanged. The doc (the buffer) maybe (and not so really... if you save before and after cursor movement you get different results). The lyxtext, no. Let's continue the discussion on the other thread (I've made a more complete argument there). Alfredo
Re: more on lyxtext
Andre Poenitz [EMAIL PROTECTED] writes: | On Sat, Mar 08, 2003 at 04:06:54PM +0100, Alfredo Braunstein wrote: | It seems to me that lots of the const/mutable confusion in lyxtext comes | from the fact that cursor movement methods are declared const but are not | const at all, mostly because of the double space/double paragraph removal | mechanism. | | As a first step, I propose the removal of constness to all methods that are | _not_ const, like cursorRight etc. | | I think that's a move in the wrong direction and 'mutable' is indeed the | way to go here. mutable has be overused in lyxtext. | The document is _logically_ unchanged after a CursorRight. It is not the document we talk about, it is the lyxtext. -- Lgb
Re: clean-up a 'gross hack'
On Mon, Mar 10, 2003 at 08:38:07AM +, Angus Leeming wrote: Have you checked math? No. I just assumed that you did the tight thing already ;-) Juergen explained to me how edit() works and how it should work already twice or so. Then I took another beer, and watched him fixing the current problem, hoping I'll learn something in the process. As far as I remember I learned that a single bottle is not enough. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
autogen and build error
on current cvs with gcc 2.95.3. After make distclean. Jürgen. - ./autogen.sh - Using Autoconf version 2.13 [...] autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_HELP_STRING ***BUG in Autoconf--please report*** AC_HELP_STRING ***BUG in Autoconf--please report*** AC_HELP_STRING lib/reLyX done. Building lib/configure ... done. run ./configure ; make ./configure --with-pspell --with-qt-dir=/usr/lib/qt3 --with-frontend=qt make - [...] In file included from c_regex_traits_common.cpp:31: ../../../../boost/boost/regex/regex_traits.hpp:27: boost/regex/v3/regex_traits.hpp: No such file or directory c_regex_traits_common.cpp:32: boost/regex/v3/regex_synch.hpp: No such file or directory make[4]: *** [c_regex_traits_common.lo] Error 1 make[4]: Leaving directory `/home/juergen/lyx-qt/boost/libs/regex/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/juergen/lyx-qt/boost/libs/regex' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/juergen/lyx-qt/boost/libs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/juergen/lyx-qt/boost' make: *** [all-recursive] Error 1
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Jean-Marc Lasgouttes wrote: Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Angus == Angus Leeming [EMAIL PROTECTED] writes: Icon dialog-show-new-inset graphics graphics.xpm Why ? Angus Because it's three lines of code and it's done in Angus ToolbarDefaults.C (which, as you note, is where this code Angus should be). Shall I do it? Jean-Marc Thqt does not mqke sense, IMO. This means that everybody Jean-Marc who needs to add an icon will have to hunt for the right Jean-Marc icon. Please, if you lfun names are too long, it's your Jean-Marc fault :) Now that I have access to a proper qwerty keyboard, I'd like to add that it may be a compelling reason why this lfun should be named inset-insert. Did anybody feel the need to rename file-insert to file-dialog-show-and-insert-file? For the same reasons, I think that inset-insert is a perfectly reasonable name for the purpose of inserting interactively any inset whether it needs a dialog or not. And for internal communication (the case where you pass the inset contents as argument) we could use inset-parse or soemthing like that. I have thought quite hard about this. Here's my take on it. We have two sorts of insets. 1. Insets which can contain data that can be entered in the LyX screen. 2. Insets whose data can be input only from a dialog. I think these two types of insets require two different creation mechanisms. Type 1 insets should just be inserted and the user can get to work filling them with fine words. Subsequently, the user can tweak their properties by popping up the dialog. Such insets should have an inset-insert lfun. It makes no sense at all to have such an lfun for the Type 2 insets. Instead we should pop up a dialog to fill the proposed inset with sensible values. 'Apply' then dispatches an lfun that actually creates the thing with valid parameters. Such insets should therefore have a dialog-show-new-inset lfun. This is exactly what happens now. In the past some of the Type 2 insets used this, correct, mechanism but others used the incorrect, second mechanism. All are how consistent I believe. That being said, it might indeed make sense to have a single insert-inset name lfun although at present the code for these different lfuns is very different. That said, I agree that the magic code to get the icon name should go to ToolbarDefaults. Also, Angus, if you feel like it, the menu and toolbar backends should really be changed into some controller and use proper signals instead of this stupid pimpls. Yes, I think that I could do this although I have come to the conclusion that signals just obfuscated the Dialogs code. I suspect that this is also true of the Menubar code and believe that we should use something like the Timout code to proceed. Anyway, this is all for the future. The current and real problem is that the stuff that creates the psuedo action from dialog-show-new-inset graphics is returneing it as dialog-show-next-inset graphics which is absolutely wrong :-( -- Angus
Re: more on lyxtext
On Mon, Mar 10, 2003 at 10:05:27AM +0100, Lars Gullik Bjønnes wrote: | The document is _logically_ unchanged after a CursorRight. It is not the document we talk about, it is the lyxtext. Ok, I was still mixing up lyxtext and insettext. Sorry for the confusion. 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: Towards LyX 1.3.1 [status update #1]
Jean-Marc Lasgouttes wrote: Michael Well, 1.3.0 has some really nasty cursor problems, e.g., if Michael there are two minipages inside a float and you use the mouse Michael to switch between both minipages, you notice two kinds of Michael misbehavior: 1. Some text is selected erroneously 2. The Michael cursor is placed at the wrong place. You may say this is not Michael a real showstopper. But if there are only a few days left Michael before you have to submit your PhD thesis and you have to Michael make some final fixes, you think different. Did you submit this to bugzilla? Well, it seems that the QT frontend behaves much better than xforms. At least, I cannot reproduce the first error case. The cursor problems when leaving a math formula (with preview mode activated) have also vanished. I think (read: hope) that Alfredo's patch that I just commited will take care of this. I will check it. Michael
Re: lyx-devel src/: ChangeLog lyxrow.C paragraph.C paragraph.h row ...
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars John Levon [EMAIL PROTECTED] writes: Lars | On Sun, Mar 09, 2003 at 05:34:49PM +0100, Lars Gullik Bj?nnes wrote: Lars | Lars | | /usr/bin/cvs -f diff -kk -u -r 1.1083 -r 1.1084 Lars lyx-devel/src/ChangeLog Lars | Lars | won't help you need a checked out tree, rdiff does not cut Lars it. (it | does not allow to specify specific files) Lars | Lars | I meant so I could cut-n-paste it and see what changed in the Lars mean | time. Lars And why can't you do that now? And what if cvs is not in /usr/bin/ ? JMarc
Re: autogen and build error
Juergen Spitzmueller wrote: on current cvs with gcc 2.95.3. After make distclean. Jrgen. - ./autogen.sh - Using Autoconf version 2.13 [...] autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_HELP_STRING ***BUG in Autoconf--please report*** AC_HELP_STRING ***BUG in Autoconf--please report*** AC_HELP_STRING lib/reLyX done. Building lib/configure ... done. run ./configure ; make ./configure --with-pspell --with-qt-dir=/usr/lib/qt3 --with-frontend=qt make - [...] In file included from c_regex_traits_common.cpp:31: ../../../../boost/boost/regex/regex_traits.hpp:27: boost/regex/v3/regex_traits.hpp: No such file or directory c_regex_traits_common.cpp:32: boost/regex/v3/regex_synch.hpp: No such file or directory Create a .cvsrc file in your home directory and fill it with diff -upN rdiff -upN update -dP cvs will only Prune dead dirs and populate New ones if you tell it to do so. -- Angus
Re: Current CVS core dumps very easily
Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Mon, Mar 10, 2003 at 02:51:35AM +, John Levon wrote: | On Sun, Mar 09, 2003 at 06:19:45PM -0800, Kayvan A. Sylvan wrote: | | lyx --export, among other things, seems to dump core. | | cvs up, make again | | Do I need to make clean? | | I did a cvs update -dP; make and the exact same symptoms remain. | | i.e. lyx --export program foo.lyx core-dumps. This kind of reports are currently not wanted unless you can give some kind of backtrace. If you get a core dump or not (or an abort) depends heavily on what kind of document you have and what elements it contains. -- Lgb
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 09:08:12AM +, Angus Leeming wrote: We have two sorts of insets. 1. Insets which can contain data that can be entered in the LyX screen. 2. Insets whose data can be input only from a dialog. Which Inset belong to which group? [I think this division is arbitrary and maybe a consequence how things are done right now, but not necessarily inherent] It makes no sense at all to have such an lfun for the Type 2 insets. Instead we should pop up a dialog to fill the proposed inset with sensible values. M-x inset-manipulate graphics set filename foo.eps 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: more on lyxtext
John Levon wrote: deleteEmptyParagraphMechanism. I'm really tempted to try your idea myself, just to have the pleasure oof the death of DEPM, but I think you should have the glory (I think reading the Three Musketeers has made me all chivalrous or something) Hey, be my guest! I don't have the skills. I would certainly like to help though. I shall serve thee until death, sir! (of DEPM). Alfredo
Re: more on lyxtext
Alfredo == Alfredo Braunstein [EMAIL PROTECTED] writes: Alfredo What about removing the double space/par removal mechanism? Alfredo Before you throw me something in the head, I have some Alfredo proposals to replace it: Alfredo Proposal 1) Plain forbid 3 spaces / 2 empty paragraphs (in Alfredo order to discourage space/newline formatting abuse, do not Alfredo load nor save double spaces, empty paragraphs). Alfredo Proposal 2) Mark double/triple/... spaces and empty pars with Alfredo some disgusting mark or colour, to encourage their removal. Alfredo Can be combined with 1) Alfredo Proposal 3) A space after a space is forbidden, a space Alfredo before makes the cursor move to the right. Same for Alfredo paragraphs: an enter after a newline forbidden, an enter Alfredo before a newline goes down. Alfredo Proposal 4) The same as 3) plus the following: with some kind Alfredo of visual feedback (a somewhat different cursor maybe) the Alfredo about-to-be-added space is remembered but not added yet. If Alfredo the user types something, then it's added and the space is Alfredo added after it. Alfredo I think that 4) is my prefered option, because it keeps the Alfredo same concrete behaviour than now. (but not the same visual) Something I do not understand: you have aa b cc and remove the b. How do you remove the double space? JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Andre Poenitz wrote: On Mon, Mar 10, 2003 at 09:08:12AM +, Angus Leeming wrote: We have two sorts of insets. 1. Insets which can contain data that can be entered in the LyX screen. 2. Insets whose data can be input only from a dialog. Which Inset belong to which group? A little thought on your part and you would not need to ask that question. All insets caontaining an insettext are filled with 'normal' typing are they not? To pop up a dialog to create sush things is meaningless. All button insets can be filled only from 'outside'. To creat such things and then require an additional mouse press to pop up a dialog to fill them with valid data is also meaningless. [I think this division is arbitrary and maybe a consequence how things are done right now, but not necessarily inherent] Well I disagree strongly with you. And I have thought about this hard. It makes no sense at all to have such an lfun for the Type 2 insets. Instead we should pop up a dialog to fill the proposed inset with sensible values. M-x inset-manipulate graphics set filename foo.eps Sure. Whatever. The handle 'dialog-show-next-inset name' currently exists in analogy to the collapsible inset 'toggle' lfun. The idea is to move the cursor up to the next inset and open the dilaog. At present it is empty. -- Angus
Re: more on lyxtext
Jean-Marc Lasgouttes wrote: Something I do not understand: you have aa b cc and remove the b. How do you remove the double space? In option 4), I would remove also one space when removing the 'b' and remember the space to be added for if the user wants to insert something. Or remove it and place the cursor after the remaining space in option 3. Alfredo
Re: lyx-devel src/: ChangeLog lyxrow.C paragraph.C paragraph.h row ...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | | Lars And why can't you do that now? | | And what if cvs is not in /usr/bin/ ? And this is not really indented for you anyway, it is indented for the script that I am trying to generate. -- Lgb
Re: autogen and build error
Angus Leeming wrote: update -dP Argh, silly me. Thanks. Jrgen. P.S.: ***BUG in Autoconf--please report*** AC_HELP_STRING ***BUG in Autoconf--please report*** AC_HELP_STRING ***BUG in Autoconf--please report*** AC_HELP_STRING lib/reLyX I just have detected the thread about this. Sorry for duplicating.
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus That being said, it might indeed make sense to have a single
Angus insert-inset name lfun although at present the code for these
Angus different lfuns is very different.
That's what I mean. As long as only one of the lfuns makes sense to
each inset, there is no reason to differentiate the cases from an
user's point of view. The fact that the underlying code is different
is not a problem IMO.
Angus Yes, I think that I could do this although I have come to the
Angus conclusion that signals just obfuscated the Dialogs code. I
Angus suspect that this is also true of the Menubar code and believe
Angus that we should use something like the Timout code to proceed.
I would be interested by any idea.
Angus Anyway, this is all for the future. The current and real
Angus problem is that the stuff that creates the psuedo action from
Angus dialog-show-new-inset graphics is returneing it as
Angus dialog-show-next-inset graphics which is absolutely wrong :-(
A hint. Stare very intensely at the two following lines from
LyXAction.C. Do you see something weird?
{ LFUN_DIALOG_SHOW_NEW_INSET, dialog-show-new-inset,
N_(Show the inset's dialog), Noop },
{ LFUN_DIALOG_SHOW_NEW_INSET, dialog-show-next-inset,
N_(Show the inset's dialog), Noop },
JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 9:32 am, Jean-Marc Lasgouttes wrote:
A hint. Stare very intensely at the two following lines from
LyXAction.C. Do you see something weird?
{ LFUN_DIALOG_SHOW_NEW_INSET, dialog-show-new-inset,
N_(Show the inset's dialog), Noop },
{ LFUN_DIALOG_SHOW_NEW_INSET, dialog-show-next-inset,
N_(Show the inset's dialog), Noop },
Good man!
Angus
Re: more on lyxtext
Alfredo == Alfredo Braunstein [EMAIL PROTECTED] writes: Alfredo Jean-Marc Lasgouttes wrote: Something I do not understand: you have aa b cc and remove the b. How do you remove the double space? Alfredo In option 4), I would remove also one space when removing the Alfredo 'b' and remember the space to be added for if the user wants Alfredo to insert something. Alfredo Or remove it and place the cursor after the remaining space Alfredo in option 3. Hmm, we definitely have to see it to know whether it would work well... But like the others, I am definitely for anything the demoves dEPM. This stuff causes a nearly infinite number of bugs, although they seem to be much more difficult to trigger now. JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 09:20:58AM +, Angus Leeming wrote: We have two sorts of insets. 1. Insets which can contain data that can be entered in the LyX screen. 2. Insets whose data can be input only from a dialog. Which Inset belong to which group? A little thought on your part and you would not need to ask that question. Maybe. But maybe not. All insets caontaining an insettext are filled with 'normal' typing are they not? So do most MathNestInsets. To pop up a dialog to create sush things is meaningless. Like MathSqrtInset ( : public MathNestInset ) ? Well I disagree strongly with you. And I have thought about this hard. Good. So I presume you are right and I just did not understand what you said. That's why I asked for clarification. 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 10:32:12AM +0100, Jean-Marc Lasgouttes wrote:
A hint. Stare very intensely at the two following lines from
LyXAction.C. Do you see something weird?
{ LFUN_DIALOG_SHOW_NEW_INSET, dialog-show-new-inset,
N_(Show the inset's dialog), Noop },
{ LFUN_DIALOG_SHOW_NEW_INSET, dialog-show-next-inset,
N_(Show the inset's dialog), Noop },
Looks pretty consistent with the rest of LyX, doesn't it?
SCNR,
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: lyx-devel src/: ChangeLog lyxrow.C paragraph.C paragraph.h row ...
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars | Lars | Lars And why can't you do that now? Lars | Lars | And what if cvs is not in /usr/bin/ ? Lars And this is not really indented for you anyway, it is indented Lars for the script that I am trying to generate. But I do not care about indentation! I though we settled to tabs anyway! JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 9:29 am, Andre Poenitz wrote: On Mon, Mar 10, 2003 at 09:20:58AM +, Angus Leeming wrote: We have two sorts of insets. 1. Insets which can contain data that can be entered in the LyX screen. 2. Insets whose data can be input only from a dialog. Which Inset belong to which group? A little thought on your part and you would not need to ask that question. Maybe. But maybe not. Re-reading my words I find them a little too strong. Sorry for that. Also my spelling is shot this morning. All insets caontaining an insettext are filled with 'normal' typing are they not? So do most MathNestInsets. Sure. Would you be happy if I popped up a dialog each time you created such a beast? Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 9:31 am, Andre Poenitz wrote: SCNR, I don't know this one. What's it mean? Angus
Re: lyx-devel src/: ChangeLog lyxrow.C paragraph.C paragraph.h row ...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars And this is not really indented for you anyway, it is indented | Lars for the script that I am trying to generate. | | But I do not care about indentation! I though we settled to tabs | anyway! I choose to have no indentation in this case, so what's your problem? -- Lgb
Re: [Patch] no.po - translation of menus
Helge == Helge Hafting [EMAIL PROTECTED] writes: Helge Attached is a diff for no.po, it translates the remaining menu Helge items to Norwegian. I hope it makes it for 1.3.1. Thanks. I am applying it. JMarc
Re: Updated da.po
Claus == Claus Hindsgaul [EMAIL PROTECTED] writes: Claus This is a new updated Danish da.po for LyX 1.3.1pre. Thanks, I am applying it now. JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 09:41:10AM +, Angus Leeming wrote: We have two sorts of insets. 1. Insets which can contain data that can be entered in the LyX screen. 2. Insets whose data can be input only from a dialog. [...] So do most MathNestInsets. Sure. Would you be happy if I popped up a dialog each time you created such a beast? I take this as Most MathNestInsets belong to 1., and most other MathInsets not derived from MathNestInset belong to 2. and we'll talk about borderline cases later 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: lyx-devel src/: ChangeLog lyxrow.C paragraph.C paragraph.h row ...
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Lars And this is not really indented for you anyway, it is Lars indented | Lars for the script that I am trying to generate. Lars | Lars | But I do not care about indentation! I though we settled to Lars tabs | anyway! Lars I choose to have no indentation in this case, so what's your Lars problem? You say that it is not indented for me, and I think I should protest, since I have the same right to indentation as the others, after all! JMarc PS: ;)
Re: lyx-devel src/: ChangeLog text.C
On Mon, Mar 10, 2003 at 02:46:41AM +, [EMAIL PROTECTED] wrote: Modified files: lyx-devel/src/: ChangeLog text.C Log message: fix the row breaking. Sorry all ! Anyway, this *should* have one bug less, and be understandable. Guess if my opinion on the cleverness of inset-as-metachar has changed (hint: I wasn't a fan) BTW, row breaking in 1.3.x is broken: the row can be broken after protected space.
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Andre Poenitz wrote: On Mon, Mar 10, 2003 at 09:41:10AM +, Angus Leeming wrote: We have two sorts of insets. 1. Insets which can contain data that can be entered in the LyX screen. 2. Insets whose data can be input only from a dialog. [...] So do most MathNestInsets. Sure. Would you be happy if I popped up a dialog each time you created such a beast? I take this as Most MathNestInsets belong to 1., and most other MathInsets not derived from MathNestInset belong to 2. and we'll talk about borderline cases later Ok. I did not understand you correctly before. Anyway, this is all rather hypothetical at the moment since only the RefInset is currently connected to a dialog. (And that should call Dialogs::hide in its d-tor but doesn't at the moment...) Incidentally, the Tabular dialog now expects a string so you should now be able to have a woking dialog for math arrays. See insettabular.C for the details, but basically it expects to extract the current active cell and stuff generated by Tabular::Write. Is this good enough for you? -- Angus
Re: lyx-devel src/: ChangeLog lyxrow.C paragraph.C paragraph.h row ...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars I choose to have no indentation in this case, so what's your | Lars problem? | | You say that it is not indented for me, and I think I should protest, | since I have the same right to indentation as the others, after all! Then you can have a brick as well. You can create your own indentations with it. Or come here and I'll apply a small hammer. -- Lgb
Re: lyx-devel src/: ChangeLog text.C
Dekel == Dekel Tsur [EMAIL PROTECTED] writes: Dekel On Mon, Mar 10, 2003 at 02:46:41AM +, [EMAIL PROTECTED] wrote: Modified files: lyx-devel/src/: ChangeLog text.C Log message: fix the row breaking. Sorry all ! Anyway, this *should* have one bug less, and be understandable. Guess if my opinion on the cleverness of inset-as-metachar has changed (hint: I wasn't a fan) Dekel BTW, row breaking in 1.3.x is broken: the row can be broken Dekel after protected space. Yes, I think this is the kind of bugs John was interested in fixing. JMarc
Re: lyx-devel src/: ChangeLog
On Monday 10 March 2003 12:03 pm, [EMAIL PROTECTED] wrote: CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel Repository: lyx-devel/src/ Changes by: [EMAIL PROTECTED] 03/03/10 12:03:25 Modified files: lyx-devel/src/: ChangeLog Log message: delete bogus entry Patches: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ChangeLog?r1=1.1094r2 =1.1095 These urls come up with '- No changes -'. Is that what you expect? Angus
Re: [PATCH] tgif support is broken
Michael == Michael Schmitt [EMAIL PROTECTED] writes: Michael Dear Jean-Marc, it seems that the current tgif converters do Michael not work with the QT frontend (which means they are broken in Michael general). Michael Could you please apply the attached patch to 1.4.0cvs and Michael 1.3.1cvs? If Christian agrees that this works for him too. JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 10:01:38AM +, Angus Leeming wrote:
Incidentally, the Tabular dialog now expects a string so you should now be
able to have a woking dialog for math arrays. See insettabular.C for the
details, but basically it expects to extract the current active cell and
stuff generated by Tabular::Write.
Is this good enough for you?
I try to understand the logic right now.
What's the benefit of
virtual string const name() const { return name_; }
///
static string const name_;
...
string const InsetTabularMailer:: name_(tabular);
over
virtual string const name() const { return tabular; }
?
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: lyx-devel src/: ChangeLog
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 10 March 2003 12:03 pm, [EMAIL PROTECTED] wrote: | CVSROOT:/usr/local/lyx/cvsroot | Module name:lyx-devel | Repository: lyx-devel/src/ | Changes by: [EMAIL PROTECTED] 03/03/10 12:03:25 | | Modified files: | lyx-devel/src/: ChangeLog | | Log message: | delete bogus entry | | Patches: | http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ChangeLog?r1=1.1094r2 | =1.1095 | | These urls come up with '- No changes -'. Is that what you expect? No, and that must really be wrong... -- Lgb
Re: User interface guidelines bookmarks
John == John Levon [EMAIL PROTECTED] writes: John JMarc requested a long time ago that I put up a page containing John some of my UI references I pull out of a hat. Well I finally got John round to it. John Hope some of it is useful or even mildly diverting. The Fly UI John is your first port of call, naturally. John http://movementarian.org/links/ Thanks. JMarc
Re: lyx-devel src/: DepTable.C DepTable.h LaTeX.C ChangeLog
Michael == Michael Schmitt [EMAIL PROTECTED] writes: Michael On Fri, 7 Mar 2003 [EMAIL PROTECTED] wrote: Log message: Fix a bug where the DVI file was not updated due to an old format .dep file. Michael Should this patch also be applied to 1.3.X? It is now. JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 11:04 am, Andre Poenitz wrote:
On Mon, Mar 10, 2003 at 10:01:38AM +, Angus Leeming wrote:
Incidentally, the Tabular dialog now expects a string so you should now
be able to have a woking dialog for math arrays. See insettabular.C for
the details, but basically it expects to extract the current active cell
and stuff generated by Tabular::Write.
Is this good enough for you?
I try to understand the logic right now.
What's the benefit of
virtual string const name() const { return name_; }
///
static string const name_;
...
string const InsetTabularMailer:: name_(tabular);
over
virtual string const name() const { return tabular; }
Can you return a reference to this? But you're right, it's probably specious.
Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 10:01:38AM +, Angus Leeming wrote:
Incidentally, the Tabular dialog now expects a string so you should now be
able to have a woking dialog for math arrays. See insettabular.C for the
details, but basically it expects to extract the current active cell and
stuff generated by Tabular::Write. Is this good enough for you?
class MailInset {
[...]
protected:
///
virtual Inset inset() const = 0;
[...]
Ideally, I don't have Insets, only InsetBases.
The reason of using these MailInsets instead of LFUNs directed to the some
high level dispatch() (the one in lyxfunc?) is to be able to pass an inset
reference around, isn't it?
If so, wouldn't it be easier to put a weak_ptrInsetBase* in the
FuncRequest and pass ordinary FuncRequests by ordinary dispatches instead
of implementing all these Mailer classes?
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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 11:14:33AM +, Angus Leeming wrote:
///
static string const name_;
...
string const InsetTabularMailer:: name_(tabular);
over
virtual string const name() const { return tabular; }
Can you return a reference to this? But you're right, it's probably specious.
Uh, no. But returning by value should do no harm.
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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 11:11 am, Andre Poenitz wrote:
On Mon, Mar 10, 2003 at 10:01:38AM +, Angus Leeming wrote:
Incidentally, the Tabular dialog now expects a string so you should now
be able to have a woking dialog for math arrays. See insettabular.C for
the details, but basically it expects to extract the current active cell
and stuff generated by Tabular::Write. Is this good enough for you?
class MailInset {
[...]
protected:
///
virtual Inset inset() const = 0;
[...]
Ideally, I don't have Insets, only InsetBases.
Sure. That would work too.
The reason of using these MailInsets instead of LFUNs directed to the some
high level dispatch() (the one in lyxfunc?) is to be able to pass an inset
reference around, isn't it?
The reason I created MailInset was simply to avoid adding yet more shit to the
Inset classes. SInce there function is clear, it made sense to create a class
to encompass it. I don't pass a MailInset anywhere but use it to create a
string and mail that string to the Dialogs class. I also pass/store an
InsetBase* in the Dialogs class but I'd rather not :-( You suggested some
sort of InsetID before...
If so, wouldn't it be easier to put a weak_ptrInsetBase* in the
FuncRequest and pass ordinary FuncRequests by ordinary dispatches instead
of implementing all these Mailer classes?
Then effectively you are saying that storing InsetBase* in the frontends is
the way to go. The whole point of doing this stuff was to try and move away
from that.
Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 11:13 am, Andre Poenitz wrote:
On Mon, Mar 10, 2003 at 11:14:33AM +, Angus Leeming wrote:
///
static string const name_;
...
string const InsetTabularMailer:: name_(tabular);
over
virtual string const name() const { return tabular; }
Can you return a reference to this? But you're right, it's probably
specious.
Uh, no. But returning by value should do no harm.
I agree that it would simplify things. Would you return a string or a
char const* ?
Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Angus Leeming [EMAIL PROTECTED] writes: | Uh, no. But returning by value should do no harm. | | I agree that it would simplify things. Would you return a string or a | char const* ? A string. A const string even... -- Lgb
Re: lyxtext mutables and consts
Alfredo Braunstein [EMAIL PROTECTED] writes: | This patch removes the const keyword to a lot of methods in LyXText. The | methods are not const at all, because they do cursor placements that imply | double space/empty paragraph removal and then rebreaks (so almost no part | of the lyxtext remains constant!). | It also removes the mutable keyword when not needed. Actually we passed from | 25 mutable vars to 6. All 6 remaining belong to the rtl code, that I don't | understand well enough (on draw(), the rtl code generate some kind of | tables that are kept in the lyxtext). | Of course, this patch implies no behaviour change whatsoever. If we can a agree that this patch is the right way forward it should be applied regardless of what it does to my BufferView* patch. I have multitudes of conflicts with every commit as it is, so a few more will not be a problem for me. -- Lgb
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 11:25:52AM +, Angus Leeming wrote: Ideally, I don't have Insets, only InsetBases. Sure. That would work too. So can you change that to InsetBase? And the rest now is idle talk: The reason of using these MailInsets instead of LFUNs directed to the some high level dispatch() (the one in lyxfunc?) is to be able to pass an inset reference around, isn't it? The reason I created MailInset was simply to avoid adding yet more shit to the Inset classes. What would it add to the Inset classes? SInce there function is clear, it made sense to create a class to encompass it. I don't pass a MailInset anywhere but use it to create a string and mail that string to the Dialogs class. Together with an InsetBase * if I understand correctly. For mailing strings alone, a FuncRequest looks reasonable, doesn't it? I also pass/store an InsetBase* in the Dialogs class but I'd rather not :-( Because you need to figure out to which Inset the Dialog belongs. Ok, I think I understood that. You suggested some sort of InsetID before... Something string-like at least... but I still don't have a clue what would be a proper solution. Maybe an external (Dialog::static) map Inset - active Dialog would do... I don't think I would like numeric InsetIDs too much. If so, wouldn't it be easier to put a weak_ptrInsetBase* in the FuncRequest and pass ordinary FuncRequests by ordinary dispatches instead of implementing all these Mailer classes? Then effectively you are saying that storing InsetBase* in the frontends is the way to go. The whole point of doing this stuff was to try and move away from that. I know, that's why I am trying to device a way to pass the Inset-Dialog association without actually passing Inset pointers. Just losing the association and re-create it by some kind of lookup/search if needed seems to be one option. 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 11:29:25AM +, Angus Leeming wrote: Uh, no. But returning by value should do no harm. I agree that it would simplify things. Would you return a string or a char const* ? _I_ would return a char const *. But Lars would return a string. To keep the speed of the current progress, I'd suggest to use a string. 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 12:32:46PM +0100, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Uh, no. But returning by value should do no harm. | | I agree that it would simplify things. Would you return a string or a | char const* ? A string. A const string even... I knew 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Mar 10, 2003 at 12:32:46PM +0100, Lars Gullik Bjønnes wrote: | Angus Leeming [EMAIL PROTECTED] writes: | | | Uh, no. But returning by value should do no harm. | | | | I agree that it would simplify things. Would you return a string or a | | char const* ? | | A string. | | A const string even... | | I knew it. One reason: inset1-name() == inset2-name() Would that work with char const *? -- Lgb
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 12:43:08PM +0100, Lars Gullik Bjønnes wrote: One reason: inset1-name() == inset2-name() Would that work with char const *? I am aware of the pitfalls. I suggested to use your preference to avoid this kind of discussion ;-) 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 11:30 am, Andre Poenitz wrote: On Mon, Mar 10, 2003 at 11:25:52AM +, Angus Leeming wrote: Ideally, I don't have Insets, only InsetBases. Sure. That would work too. So can you change that to InsetBase? I'll try and make this change and the name one this lunch time. And the rest now is idle talk: The reason of using these MailInsets instead of LFUNs directed to the some high level dispatch() (the one in lyxfunc?) is to be able to pass an inset reference around, isn't it? The reason I created MailInset was simply to avoid adding yet more shit to the Inset classes. What would it add to the Inset classes? SInce there function is clear, it made sense to create a class to encompass it. I don't pass a MailInset anywhere but use it to create a string and mail that string to the Dialogs class. Together with an InsetBase * if I understand correctly. For mailing strings alone, a FuncRequest looks reasonable, doesn't it? Well, we mail strings back from the frontends using a FuncRequest, yes. But I don't see the advantage of going through a dispatch method to call Dialogs::show(name, data, inset*) or Dialogs::update(name, data) or Dialogs::hide(name, inset*) from the lyx kernel itself. I also pass/store an InsetBase* in the Dialogs class but I'd rather not :-( Because you need to figure out to which Inset the Dialog belongs. Ok, I think I understood that. You suggested some sort of InsetID before... Something string-like at least... but I still don't have a clue what would be a proper solution. Maybe an external (Dialog::static) map Inset - active Dialog would do... That's what I have now. I think of class Dialogs as part of the lyx kernel and it is this that stores the InsetBase* in just such a map. The dialogs themselves derive from class Dialog (note, no 's'). I think of them as separate from the lyx kernel and they know nothing about these pointers or, indeed, whether they are 'connected' to anything at all. I don't think I would like numeric InsetIDs too much. If so, wouldn't it be easier to put a weak_ptrInsetBase* in the FuncRequest and pass ordinary FuncRequests by ordinary dispatches instead of implementing all these Mailer classes? Then effectively you are saying that storing InsetBase* in the frontends is the way to go. The whole point of doing this stuff was to try and move away from that. I know, that's why I am trying to device a way to pass the Inset-Dialog association without actually passing Inset pointers. Just losing the association and re-create it by some kind of lookup/search if needed seems to be one option. Andre'
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 11:53:30AM +, Angus Leeming wrote: That's what I have now. I think of class Dialogs as part of the lyx kernel and it is this that stores the InsetBase* in just such a map. The dialogs themselves derive from class Dialog (note, no 's'). I think of them as separate from the lyx kernel and they know nothing about these pointers or, indeed, whether they are 'connected' to anything at all. Ok. I did not know where you draw the line between kernel and gui. With this explanation it sounds sensible. 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Andre Poenitz [EMAIL PROTECTED] writes: Lars | On Mon, Mar 10, 2003 at 12:32:46PM +0100, Lars Gullik Bjønnes wrote: Lars | Angus Leeming [EMAIL PROTECTED] writes: Lars | Lars | | Uh, no. But returning by value should do no harm. Lars | | Lars | | I agree that it would simplify things. Would you return a Lars string or a | | char const* ? Lars | Lars | A string. Lars | Lars | A const string even... Lars | Lars | I knew it. Lars One reason: inset1- name() == inset2-name() Lars Would that work with char const *? It would work if the name is always the same char array, defined once in the inset .C file. And the addresses can be used as inset codes too. JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Andre Poenitz wrote:
What's the benefit of
virtual string const name() const { return name_; }
///
static string const name_;
...
string const InsetTabularMailer:: name_(tabular);
over
virtual string const name() const { return tabular; }
A. I remember now. The bulk of the work is actually done in the _static_
methods params2string and string2params. If I did as you suggest, then I'd
have to create a temporary MailInset just to extract the name. Or hard code
it of course. Do you have any preferences over leaving this name stuff
as-is or having string literals in 3 places?
InsetTabularMailer::params2string(InsetTabular const inset)
{
BufferView * const bv = inset.view();
Buffer const * const buffer = bv ? bv-buffer() : 0;
if (!buffer)
return string();
ostringstream data;
data name_ active_cell inset.getActCell() '\n';
inset.write(buffer, data);
data \\end_inset\n;
return data.str();
}
--
Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 01:45:35PM +0100, Jean-Marc Lasgouttes wrote: It would work if the name is always the same char array, defined once in the inset .C file. And the addresses can be used as inset codes too. But the cicumstances where this is guaranteed to work are rather fragile... Lars has a point here... 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 12:47:34PM +, Angus Leeming wrote: A. I remember now. The bulk of the work is actually done in the _static_ methods params2string and string2params. If I did as you suggest, then I'd have to create a temporary MailInset just to extract the name. The name function could be static as well, couldn't it? [I don't like static class function too much, either...] Or hard code it of course. Do you have any preferences over leaving this name stuff as-is or having string literals in 3 places? Leave it as it is, we could have a look again later. 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 12:13 pm, Andre Poenitz wrote: On Mon, Mar 10, 2003 at 11:53:30AM +, Angus Leeming wrote: That's what I have now. I think of class Dialogs as part of the lyx kernel and it is this that stores the InsetBase* in just such a map. The dialogs themselves derive from class Dialog (note, no 's'). I think of them as separate from the lyx kernel and they know nothing about these pointers or, indeed, whether they are 'connected' to anything at all. Ok. I did not know where you draw the line between kernel and gui. ;-) I draw this distinction because I can imagine the hypothetical situation when class Dialogs is simply an interface to a lyxserver pair of pipes. The thing on the other end should have no idea about anything other than the string it is to manipulate. Ditto, class Kernel in frontends/controllers could also be turned into an interface to a lyxserver pair of pipes receiving/returning this info, although I haven't proceeded with any seriousness down this line. I'm not suggesting actually creating a separate process to run the dialogs, but it does help clarify the rationale. With this explanation it sounds sensible. You mean that things are in a 'reasonable' state as we stand? Good. Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 12:48 pm, Andre Poenitz wrote: On Mon, Mar 10, 2003 at 12:47:34PM +, Angus Leeming wrote: A. I remember now. The bulk of the work is actually done in the _static_ methods params2string and string2params. If I did as you suggest, then I'd have to create a temporary MailInset just to extract the name. The name function could be static as well, couldn't it? [I don't like static class function too much, either...] No. MailInset uses name(), but different daughter classes have different names... Or hard code it of course. Do you have any preferences over leaving this name stuff as-is or having string literals in 3 places? Leave it as it is, we could have a look again later. Ok. I'll do the InsetBase* thing though. Angus
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 12:56:59PM +, Angus Leeming wrote: I'm not suggesting actually creating a separate process to run the dialogs, but it does help clarify the rationale. Yes, keeping in mind that we just have a pipe between Gui and Kernel is a good aid to decide where things belong... With this explanation it sounds sensible. You mean that things are in a 'reasonable' state as we stand? Good. Modulo my ignorance, yes. 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] tgif support is broken
On Mon, 10 Mar 2003, Michael Schmitt wrote: Dear Jean-Marc, Could you please apply the attached patch to 1.4.0cvs and 1.3.1cvs? Hi Michael The patch works in LyX and for DVI, PS and PDF, but there's something strange with PDF-LATEX (see below). Also, I think you only need the switch '-color' when creating Postscript. (I just tested, and it seems to produce colour without that switch for .png). About PDF-latex, there is a strange thing when I do View-PDF-latex though, and I'm not sure if that's because of the conversion. If you look at this file: http://www.md.kth.se/~chr/lyx/test/using_TGif/export_pdflatex.pdf you'll see that the images aren't scaled properly. (They're fine in normal PDF) Could you perhaps download this http://www.md.kth.se/~chr/lyx/test/using_TGif.tar.gz and see if you get the same behaviour when exporting with PDF Latex? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
Andre Poenitz wrote:
class MailInset {
[...]
protected:
///
virtual Inset inset() const = 0;
[...]
Ideally, I don't have Insets, only InsetBases.
To do this I had to move these into InsetBase. Ok with this?
/// Methods to cache and retrieve a cached BufferView.
virtual void cache(BufferView *) const {}
///
virtual BufferView * view() const { return 0; }
--
Angus
Re: [PATCH] tgif support is broken
On Mon, 10 Mar 2003, Christian Ridderström wrote: On Mon, 10 Mar 2003, Michael Schmitt wrote: The patch works in LyX and for DVI, PS and PDF, but there's something strange with PDF-LATEX (see below). I'm probably being stupid here.. changing the image setting to 100% COL changes the size of the figure... So I guess the question is what should happen to the figure when it is exported from TGif - png - ... - pdf? I guess the size isn't preserved. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: PO Files Consistency Checker
Michael == Michael Schmitt [EMAIL PROTECTED] writes: Michael Hello, I have written a tiny Perl script (pochecks.pl) that Michael checks the consistency of a given po file: [...] Nicely done. I tried it on fr.po and indeed it uncovers a few things. What would be nice (but probably difficult) is to handle the case where there are more than two translations for the same word, like in Different translations for 'above': 'Above' = 'Avant' 'Above' = 'Au dessus' Different translations for 'below': 'Below' = 'Après' 'Below' = 'En dessous' Different translations for 'above': 'Above' = 'Avant' 'Above' = 'Au dessus' Different translations for 'below': 'Below' = 'Après' 'Below' = 'En dessous' Here there should be two entries, each with 3 lines. Also here Missing or redundant QT shortcut: QT should be Qt, since this is after all a script for the pedantics among us. Michael PS: Jean-Marc, if you like it, could you please add it to Michael 1.3.1cvs as well? I added it to the tree, but I do not think it will go in the distribution. Feel free to propose a patch for that. JMarc
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 01:11:29PM +, Angus Leeming wrote: To do this I had to move these into InsetBase. Ok with this? Yes. 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: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Monday 10 March 2003 1:17 pm, Andre Poenitz wrote: On Mon, Mar 10, 2003 at 01:11:29PM +, Angus Leeming wrote: To do this I had to move these into InsetBase. Ok with this? Yes. Incidentally, does the xforms frontend work for you? I get an instant crash when I try to load a buffer (any buffer) and it's been like this for days. I'm amazed that no-one else has been complaining so it suggests that just I am suffering. The wierd thing is that my tree and cvs are the same. Totally confused. Angus
Re: [Patch] Fix and prettify Xforms Changes dialog.
John Levon wrote:
On Mon, Mar 03, 2003 at 02:36:18AM +0900, Rob Lahaye wrote:
The attached patch prettifies the Xforms Changes dialog.
I think it also fixes the dis/enable-buttons, when nothing is in the
changed list.
I got a crash from this I didn't get in my other tree. Maybe not the
patches fault, but I'm going to drop it off the radar for now anyway.
John,
I got the (same?) crash here with both plain-CVS and CVS with my patch applied.
So let's assume it's not my patch that causes the crash :):
start lyx
File-New document
type something (with Change toggled on)
Close the document, don't save
File-New document
type something, then switch on Change toggle
type something before and after existing text
put the cursor at the start of the line
BANG!
With most recent CVS, the backtrace is:
#0 0x288577b4 in kill () from /usr/lib/libc.so.4
#1 0x28897b26 in abort () from /usr/lib/libc.so.4
#2 0x844de6f in lyx::abort () at abort.C:9
#3 0x809e135 in AuthorList::get (this=0x883a194, id=0) at support/LAssert.h:24
#4 0x80cdad0 in currentState (bv=0x8693f90) at bufferview_funcs.C:163
#5 0x812fb2e in LyXFunc::view_status_message (this=0x862a980) at lyxfunc.C:1935
#6 0x83512be in XFormsView::show_view_state (this=0xbfbff794) at XFormsView.C:196
#7 0x8520e5c in
boost::detail::function::void_function_obj_invoker0boost::_bi::bind_tvoid,
boost::_mfi::mf0void, XFormsView,
boost::_bi::list1boost::_bi::valueXFormsView * , void::invoke (
function_obj_ptr={obj_ptr = 0x86af290, const_obj_ptr = 0x86af290, func_ptr =
0x86af290, data = \220})
at ../../../boost/boost/bind/mem_fn_template.hpp:46
#8 0x848001e in boost::signal0void, boost::last_valuevoid, int, lessint,
boost::function0void, allocatorboost::function_base ::operator()
(this=0xbfbff7b8)
at ../../boost/boost/function/function_template.hpp:319
#9 0x81a2980 in LyXText::dispatch (this=0x883dc00, [EMAIL PROTECTED]) at text3.C:1489
#10 0x8060663 in BufferView::Pimpl::dispatch (this=0x86a9400, [EMAIL PROTECTED]) at
BufferView_pimpl.C:1280
#11 0x8481faa in
boost::detail::function::void_function_obj_invoker1boost::_bi::bind_tbool,
boost::_mfi::mf1bool, BufferView::Pimpl, FuncRequest const ,
boost::_bi::list2boost::_bi::valueBufferView::Pimpl *, boost::arg1 , void,
FuncRequest::invoke (
function_obj_ptr={obj_ptr = 0x86af200, const_obj_ptr = 0x86af200, func_ptr =
0x86af200, data = }, a0=0xbfbfece4)
at ../boost/boost/bind.hpp:176
#12 0x852605d in boost::signal1void, FuncRequest, boost::last_valuevoid, int,
lessint, boost::function1void, FuncRequest, allocatorboost::function_base
::operator() (this=0xbfbff2a0, a1=0xbfbff2a0)
at ../../../boost/boost/function/function_template.hpp:319
#13 0x8356c56 in XWorkArea::work_area_handler (ob=0x86ac800, event=3, key=1,
xev=0x286cc520) at XWorkArea.C:300
#14 0x8355e82 in C_work_area_handler (ob=0x86ac800, event=3, key=1, xev=0x286cc520) at
XWorkArea.C:84
#15 0x28696ada in fl_handle_it () from /usr/X11R6/lib/libforms.so.1
#16 0x28696b9c in fl_handle_object () from /usr/X11R6/lib/libforms.so.1
#17 0x28686eb9 in fl_handle_form () from /usr/X11R6/lib/libforms.so.1
#18 0x28687d65 in do_interaction_step () from /usr/X11R6/lib/libforms.so.1
#19 0x2868804d in fl_treat_interaction_events () from /usr/X11R6/lib/libforms.so.1
#20 0x28688095 in fl_check_forms () from /usr/X11R6/lib/libforms.so.1
#21 0x835c71d in lyx_gui::start ([EMAIL PROTECTED], [EMAIL PROTECTED]) at lyx_gui.C:301
#22 0x8105dc7 in LyX::LyX (this=0xbfbffac0, [EMAIL PROTECTED], argv=0xbfbffb3c) at
../src/lyx_main.C:163
#23 0x8156e52 in main (argc=1, argv=0xbfbffb3c) at ../src/main.C:31
#24 0x8050b35 in _start ()
Does this help?
Rob.
Re: lyx-devel lib/: ChangeLog lib/ui/: default.ui src/: BufferView ...
On Mon, Mar 10, 2003 at 01:30:04PM +, Angus Leeming wrote: Incidentally, does the xforms frontend work for you? No, I have currently 1.3.0 running (real work ;-}) But I'll have a look. 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: PO Files Consistency Checker
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Also here | Missing or redundant QT shortcut: | QT should be Qt, since this is after all a script for the pedantics | among us. What is a redundant shortcut? Note that missing shortcut is perfectly sane... -- Lgb
Re: About linking problems in cygwin (Kayvan?)
Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes: Kayvan I guess it does not matter much. The make process is slightly Kayvan broken for Cygwin and for some Solaris machines (2.5.1) that I Kayvan build on. Kayvan Then I edit src/BUILD, removing everything but the final link Kayvan step, and rearrange the library order (-lflimage before Kayvan -lforms, add the missing -lintl). So you mean that you edit the link line by hand to work around the problems introduced by _your_ patch? OK, I'll just remove it and see whether somebody complains. JMarc
Re: PO Files Consistency Checker
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Also here | Missing or redundant QT shortcut: | QT should be Qt, Lars since this is after all a script for the pedantics | among us. Lars What is a redundant shortcut? Note that missing shortcut is Lars perfectly sane... There should be two different warnings - shortcut in msgid but not msgstr (missing) - shortcut in msgstr but not msgid (redundant) I agree that it may be intentional, but it is nice to see them anyway. JMarc
Re: Re: PO Files Consistency Checker
Lars Gullik Bjønnes [EMAIL PROTECTED] schrieb am 10.03.2003, 15:06:53: What is a redundant shortcut? A shortcut that is introduced in the translated message but does not occur in the orignal (English) message. I apologize if the word redundant is inappropriate in this context. Note that missing shortcut is perfectly sane... Well, a translated messages that lacks a shortcut may be OK but it may also mean that the translator simply forgot to add it. I am a pedant, I like to be warned about such things :-) I told you that the script produces false positives... However, Claus, Alfredo, and Jean-Marc already found a few real mistakes in their po files. Michael
Re: [Bug 365] linebreak (wrap) with insets boundaries
[EMAIL PROTECTED] wrote: http://bugzilla.lyx.org/show_bug.cgi?id=365 --- Additional Comments From [EMAIL PROTECTED] 2003-03-09 23:07 --- Fixed this. Juergen please test it. Looks good! Thanks, Jürgen.
Re: PO Files Consistency Checker
On Monday 10 March 2003 14:16, [EMAIL PROTECTED] wrote: I told you that the script produces false positives... However, Claus, Alfredo, and Jean-Marc already found a few real mistakes in their po files. You can add me to such set. ;-) Michael -- José Abílio
LFUN_GREEK and LFUN_GREEK_TOGGLE are broken
Andre', since you did not answer to Serge Winitzki's report about it, I re-send the description of the problem: using math-greek-toggle (for example with the binding M-m S-G) leads to the following messages to the console. this should not really happen - 1: 0 0 in: 0x8969c30 idx_ 0 not valid idx_ 0 not valid I don't have a cell 1 MathInset::getPos() called directly! MathInset::getPos() called directly! MathInset::getPos() called directly! MathInset::getPos() called directly! MathInset::getPos() called directly! MathInset::getPos() called directly! MathInset::getPos() called directly! MathInset::getPos() called directly! MathInset::getPos() called directly! [...again and again...] The lyx canvas has a math inset with a red lyxgreek inside it. math-greek leads to the same problem. This happens with 1.3.1cvs and presumably 1.4.0cvs. Is this easily fixable? JMarc
Re: Preview mechanism does not honor latex-dvi converter
Angus == Angus Leeming [EMAIL PROTECTED] writes: I think it is too complicated for its own good. However, having the programs set in variables at the top of the script would be a good start. Angus Next thought. reLyX is generated from reLyX.in for exactly the Angus reasons you describe. Should we do the same for this script Angus too? It would not help me anyway, since configure is not able to guess the name of the latex program I have to use here. I think defining the variables at the top of the script would be a good first step. JMarc
Re: LFUN_GREEK and LFUN_GREEK_TOGGLE are broken
On Mon, Mar 10, 2003 at 04:19:01PM +0100, Jean-Marc Lasgouttes wrote:
Andre', since you did not answer to Serge Winitzki's report about it,
I have it still in my inbox...
Is this easily fixable?
By disabling the LFUN, yes.
We don't have the 'greek_mode' flag anymore, so if people _really_ need
it, it need to be re-added together with that hardwired latin-greek char
mapping (which I don't like).
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: formulabase.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/formulabase.C,v
retrieving revision 1.251
diff -u -p -r1.251 formulabase.C
--- formulabase.C 6 Mar 2003 10:02:40 - 1.251
+++ formulabase.C 10 Mar 2003 15:27:39 -
@@ -652,7 +652,7 @@ dispatch_result InsetFormulaBase::localD
break;
// Math fonts
- case LFUN_GREEK_TOGGLE: handleFont(bv, cmd.argument, lyxgreek); break;
+ //case LFUN_GREEK_TOGGLE: handleFont(bv, cmd.argument, lyxgreek); break;
case LFUN_BOLD: handleFont(bv, cmd.argument, mathbf); break;
case LFUN_SANS: handleFont(bv, cmd.argument, mathsf); break;
case LFUN_EMPH: handleFont(bv, cmd.argument, mathcal); break;
@@ -664,11 +664,11 @@ dispatch_result InsetFormulaBase::localD
case LFUN_FREE: handleFont(bv, cmd.argument, textrm); break;
case LFUN_DEFAULT: handleFont(bv, cmd.argument, textnormal); break;
- case LFUN_GREEK:
- handleFont(bv, cmd.argument, lyxgreek1);
- if (cmd.argument.size())
- mathcursor-insert(asArray(cmd.argument));
- break;
+ //case LFUN_GREEK:
+ // handleFont(bv, cmd.argument, lyxgreek1);
+ // if (cmd.argument.size())
+ // mathcursor-insert(asArray(cmd.argument));
+ // break;
case LFUN_MATH_MODE:
if (mathcursor-currentMode() == MathInset::TEXT_MODE) {
Re: Preview mechanism does not honor latex-dvi converter
Jean-Marc Lasgouttes wrote:
I think defining the variables at the top of the script would be a
good first step.
I've applied this to cvs. Perhaps you could do the same for 1.3?
--
Angus? lib/reLyX-safe
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.397
diff -u -p -u -r1.397 ChangeLog
--- lib/ChangeLog 10 Mar 2003 09:46:23 - 1.397
+++ lib/ChangeLog 10 Mar 2003 16:06:21 -
@@ -1,5 +1,11 @@
2003-03-10 Angus Leeming [EMAIL PROTECTED]
+ * scripts/lyxpreview2bitmap.sh: use variables for the names of
+ 'latex', 'dvips', 'gs' and 'pnmcrop' and move their definition to
+ the top of the script.
+
+2003-03-10 Angus Leeming [EMAIL PROTECTED]
+
* images/graphics-insert.xpm: rename as
dialog-show-new-inset_graphics.xpm.
Index: lib/scripts/lyxpreview2bitmap.sh
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/scripts/lyxpreview2bitmap.sh,v
retrieving revision 1.9
diff -u -p -u -r1.9 lyxpreview2bitmap.sh
--- lib/scripts/lyxpreview2bitmap.sh 6 Jan 2003 17:40:46 - 1.9
+++ lib/scripts/lyxpreview2bitmap.sh 10 Mar 2003 16:06:24 -
@@ -51,6 +51,14 @@
#\converter lyxpreview ${FORMAT} lyxpreview2bitmap.sh
# where ${FORMAT} is either ppm or png.
+# These four programs are used by the script.
+# Adjust their names to suit your setup.
+LATEX=latex
+DVIPS=dvips
+GS=gs
+PNMCROP=pnmcrop
+readonly LATEX DVIPS GS PNMCROP
+
# Three helper functions.
FIND_IT ()
{
@@ -65,7 +73,7 @@ FIND_IT ()
BAIL_OUT ()
{
# Remove everything except the original .tex file.
- FILES=`ls ${BASE}* | sed -e /${BASE}.tex/d`
+ FILES=`ls ${BASE}* | sed -e /${BASE}\.tex/d`
rm -f ${FILES} texput.log
echo Leaving ${BASE}.tex in ${DIR}
exit 1
@@ -73,8 +81,10 @@ BAIL_OUT ()
REQUIRED_VERSION ()
{
+ test $# -eq 1 || exit 1
+
echo We require preview.sty version 0.73 or newer. You're using
- grep 'Package: preview' ${LOGFILE}
+ grep 'Package: preview' $1
}
# Preliminary check.
@@ -101,9 +111,9 @@ else
fi
# We use latex, dvips and gs, so check that they're all there.
-FIND_IT latex
-FIND_IT dvips
-FIND_IT gs
+FIND_IT ${LATEX}
+FIND_IT ${DVIPS}
+FIND_IT ${GS}
# Initialise some variables.
TEXFILE=${BASE}.tex
@@ -111,12 +121,13 @@ LOGFILE=${BASE}.log
DVIFILE=${BASE}.dvi
PSFILE=${BASE}.ps
METRICSFILE=${BASE}.metrics
+readonly TEXFILE LOGFILE DVIFILE PSFILE METRICSFILE
# LaTeX - DVI.
cd ${DIR}
-latex ${TEXFILE} ||
+${LATEX} ${TEXFILE} ||
{
- echo Failed: latex ${TEXFILE}
+ echo Failed: ${LATEX} ${TEXFILE}
BAIL_OUT
}
@@ -127,7 +138,7 @@ latex ${TEXFILE} ||
grep -E 'Preview: [ST]' ${LOGFILE} ${METRICSFILE} ||
{
echo Failed: grep -E 'Preview: [ST]' ${LOGFILE}
- REQUIRED_VERSION
+ REQUIRED_VERSION ${LOGFILE}
BAIL_OUT
}
@@ -138,7 +149,7 @@ grep -E 'Preview: [ST]' ${LOGFILE} ${M
LINE=`grep 'Preview: Fontsize' ${LOGFILE}` ||
{
echo Failed: grep 'Preview: Fontsize' ${LOGFILE}
- REQUIRED_VERSION
+ REQUIRED_VERSION ${LOGFILE}
BAIL_OUT
}
# The sed script strips out everything that won't form a decimal number
@@ -166,9 +177,9 @@ RESOLUTION=`echo scale=2; \
| bc`
# DVI - PostScript
-dvips -o ${PSFILE} ${DVIFILE} ||
+${DVIPS} -o ${PSFILE} ${DVIFILE} ||
{
- echo Failed: dvips -o ${PSFILE} ${DVIFILE}
+ echo Failed: ${DVIPS} -o ${PSFILE} ${DVIFILE}
BAIL_OUT
}
@@ -185,12 +196,12 @@ if [ ${INT_RESOLUTION} -gt 150 ]; then
ALPHA=2
fi
-gs -q -dNOPAUSE -dBATCH -dSAFER \
+${GS} -q -dNOPAUSE -dBATCH -dSAFER \
-sDEVICE=${GSDEVICE} -sOutputFile=${BASE}%d.${GSSUFFIX} \
-dGraphicsAlphaBit=${ALPHA} -dTextAlphaBits=${ALPHA} \
-r${RESOLUTION} ${PSFILE} ||
{
- echo Failed: gs ${PSFILE}
+ echo Failed: ${GS} ${PSFILE}
BAIL_OUT
}
@@ -203,7 +214,7 @@ rm -f ${FILES} texput.log
# The bitmap files can have large amounts of whitespace to the left and
# right. This can be cropped if so desired.
CROP=1
-type pnmcrop /dev/null || CROP=0
+type ${PNMCROP} /dev/null || CROP=0
# There's no point cropping the image if using PNG images. If you want to
# crop, use PPM.
@@ -211,8 +222,8 @@ type pnmcrop /dev/null || CROP=0
if [ ${CROP} -eq 1 -a ${GSDEVICE} = pnmraw ]; then
for FILE in ${BASE}*.${GSSUFFIX}
do
- if pnmcrop -left ${FILE} 2 /dev/null |\
- pnmcrop -right 2 /dev/null ${BASE}.tmp; then
+ if ${PNMCROP} -left ${FILE} 2 /dev/null |\
+ ${PNMCROP} -right 2 /dev/null ${BASE}.tmp; then
mv ${BASE}.tmp ${FILE}
else
rm -f ${BASE}.tmp
Re: lyx-devel src/mathed/: math_gridinset.C
[EMAIL PROTECTED] wrote: CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel Repository: lyx-devel/src/mathed/ Changes by: [EMAIL PROTECTED]03/03/10 17:23:34 Modified files: lyx-devel/src/mathed/: math_gridinset.C Log message: Angus: What code should handle the mailer.show() request? localDispatch(LFUN_MOUSE_RELEASE)? (is that what you meant?) -- Angus
Re: Preview mechanism does not honor latex-dvi converter
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: I think defining the variables at the top of the script would be a good first step. Angus I've applied this to cvs. Perhaps you could do the same for Angus 1.3? Will do. Thanks. BTW, wasn't there some patch you were supposed to apply for me to 1.3.1cvs? JMarc
Re: Preview mechanism does not honor latex-dvi converter
Jean-Marc Lasgouttes wrote: BTW, wasn't there some patch you were supposed to apply for me to 1.3.1cvs? If there was then I have no idea what. I sent you something recently that you appled yourself, turning status.13x into something sensible. Is that what you're thinking about? -- Angus
Re: lyx-devel src/mathed/: math_gridinset.C
On Mon, Mar 10, 2003 at 04:26:43PM +, Angus Leeming wrote: Angus: What code should handle the mailer.show() request? localDispatch(LFUN_MOUSE_RELEASE)? (is that what you meant?) No... I see the lyxerr mailer mailer.name() active\n; message (mailer tabular) then nothing happens. Instead the math panel shows... hm. Is taht the reaction to mailer.showDialog()? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Unable to insert a tabular
It seems that the ok button is always disabled in current CVS. Is this due to the Dialog work? -- Lgb
Re: lyx-devel src/mathed/: math_gridinset.C
Andre Poenitz wrote: On Mon, Mar 10, 2003 at 04:26:43PM +, Angus Leeming wrote: Angus: What code should handle the mailer.show() request? localDispatch(LFUN_MOUSE_RELEASE)? (is that what you meant?) No... I see the lyxerr mailer mailer.name() active\n; message (mailer tabular) then nothing happens. Instead the math panel shows... hm. Is taht the reaction to mailer.showDialog()? Not from me it isn't. Add a debug statement to the top of ControlTabular::initialiseParams. lyxerr ControlTabular::initialiseParams\n data std::endl; It expects to see a string like tabular active_cell 3 [output from Tabular::Write] but I haven't attempted to make it robust. -- Angus
Re: lyx-devel src/mathed/: math_gridinset.C
On Mon, Mar 10, 2003 at 04:40:22PM +, Angus Leeming wrote: Add a debug statement to the top of ControlTabular::initialiseParams. lyxerr ControlTabular::initialiseParams\n data std::endl; Ok, that's the information I was looking for. It expects to see a string like tabular active_cell 3 [output from Tabular::Write] but I haven't attempted to make it robust. No problem right now. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
