Re: Insert xfig
On Fri, Jun 16, 2000 at 12:09:48AM +0300, Dekel Tsur wrote: > > Sorry, python scripts aren't on my radar screen :) > > So I guess I'll have to write it ... > > PS (to Asger) The need for writing scripts for the external inset is a little > annoying. Can't we just add an option to define UpdateCommand to be > "cmd1;cmd2;.." with the meanning to execute cmd1, then cmd2 etc. ? > And what is the difference between pic2png_eps.py and pic2png_eps.sh ? I have created some of the scripts with Asger, so... The security is our main concern. With the shell script there is nothing to prevent you from running other commands using an appropriate choice of parameters. The pic2png_eps.sh shouldn't be there, since it is insecure. We forgot to remove it. What do you think Asger? -- José
Re: Batchjob .lyx -> .dvi howto?
> How does one make a batch job for .lyx -> .dvi "conversion" ? lyx2dvi: #!/bin/sh lyx --export latex $1 latex $1 latex $1 latex $1 or something like that. Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: Random results from the fourth international LyX developers
On 15-Jun-2000 Dekel Tsur wrote: > On Mon, Jun 12, 2000 at 02:54:33PM +0200, Asger K. Alstrup Nielsen wrote: >> >> The highlights include: >> >> - Mayor clean up in the LyXText and inset handling by Juergen and >> Lgb. This leads in the direction of a lot of new posibilities >> for nesting different constructs in great ways. Stay tuned for >> more information about this work. > > I tried the tabular inset, and it seems to function WORSE than before the > meeting! (the cursor is now always misplaced). Well this is subjective, I think it works much better then before, it just has still some cosmetic faults #:O) (sometime you have to look at what is behind a face ;) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Mystics always hope that science will some day overtake them. -- Booth Tarkington -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Random results from the fourth international LyX developers
On 15-Jun-2000 Dekel Tsur wrote: > I also want to add that routines for building forms automatically, can also > be used for adding support for arbitrary latex packages: a text file will > define the arguments/config commands to the package, and a form for changing > these values will be created automatically. Sounds like a very good idea ! Jürgen P.S.: I already proposed something like that in the meeting (we did also a lot of talking and planing for the future, as always in this meetings ;) -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug I don't want to be young again, I just don't want to get any older. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Random results from the fourth international LyX developersmeeting in Norway
On Thu, 15 Jun 2000, Dekel Tsur wrote: > To be more specific, lyxrc.C should contain a big array with entries for the > lyxrc variables, each entry contains information like token name, default > value, etc. Another field will be type (e.g. "printer", "screen fonts", etc.) > which will be used for building the form automatically. > I'm thinking about writing this soon, unless someone else wants to do it. Internally, the design might be a hash table mapping strings to entries, and the extrnal interface should be something like: string LyXRC::query_string (string & key) bool LyXRC::query_boolean (string & key) etc. I think the entries should have a type in the regular sense (integer, string, ...), while the above "type" is better termed a "family". Keybindings can be handled by having the "bind" entry in the table be an object which performs keybindings (rather than have an instance for each keybind). The same should go for other bindings (e.g. reading a bind_file or setting colors). Lior.
kde frontend: LyXFunc or LyXView
current CVS does not compile with KDE frontend due to the difference in Dialogs class definition for KDE and Xforms frontends. Namely, Dialogs class constructor expects LyXView* as its argument in Xforms frontend (src/frontends/Dialogs.h src/frontends/xforms/Dialogs.C) and LyXFunc* as an argument in KDE frontend (src/frontends/kde/Dialogs.C). Error message: # ./configure --with-frontend=kde ... # make ... g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../.. -I../../.. -I/usr/lib/qt-1.44/include -I/usr/include/kde -I/usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/Dialogs.pp -c Dialogs.C -o Dialogs.o Dialogs.C:13: prototype for `Dialogs::Dialogs(class LyXFunc *)' does not match any in class `Dialogs' ../../../src/frontends/Dialogs.h:119: candidates are: Dialogs::Dialogs(class Dialogs &) ../../../src/frontends/Dialogs.h:117: Dialogs::Dialogs() ../../../src/frontends/Dialogs.h:55: Dialogs::Dialogs(class LyXView *) Regards, Marko
Re: Batchjob .lyx -> .dvi howto?
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> How does one make a batch job for .lyx -> .dvi "conversion" ? Andre> lyx2dvi: Andre> #!/bin/sh lyx --export latex $1 BTW andre, did you document this flag somewhere? I found nothing in the man page (hint!). JMarc
Re: Clean CVS get still does not compile
Kayvan> This is on RH 6.1, default compiler/linker/etc.: Kayvan> /bin/sh ./libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -I./.. -O2 -m486 -fno-strength-reduce -ansi -W -Wall -Wno-return-type -c marshal.cc Kayvan> c++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -I./.. -O2 -m486 -fno-strength-reduce -ansi -W -Wall -Wno-return-type -c marshal.cc -o marshal.o Kayvan> In file included from ../sigc++/marshal.h:14, from marshal.cc:1: Kayvan> ../sigc++/thread.h:124: type specifier omitted for parameter Kayvan> .../sigc++/thread.h:124: parse error before `*' Kayvan> mmake[4]: *** [marshal.lo] Error 1 Kayvan> make[4]: Leaving directory `/home/kayvan/src/rpm/BUILD/lyx-1.1.6cvs/sigc++' Kayvan> I have to add cite.[hC] to src/Makefile.am to make it work as far as Kayvan> that and then I get the error. Kayvan, I can't help too much with the error, but cite.[hC] should not be added to the Makefile. They were generated by some drunk hacker from cite.fd in the forms/ directory and should go back there! As for the error, your compiler is complaining about "struct timespec" which it can't find. On my system, it's in usr/include/pthread.h. Near the top of sigc++/thread.h you'll find the lines: #ifdef SIGC_THREAD_IMPL #include #else #include #endif Does your system not include pthread.h? Might this be the problem? Placing a #warning "got to here" inside the ifdef would perhaps help to track down just what is going on. Angus
configure error
using configure --with-frontend=kde configuration falls over if QT or KDE aren't installed in certain hardwired locations. This is daft, since two shell variables are defined when running KDE but not employed by the configure script. Why not test $KDEDIR (=/usr/local/kde on my system) $QTDIR (=/usr/local/qt on my system) before falling over with an error message. Angus
Re: Batchjob .lyx -> .dvi howto?
> Andre> #!/bin/sh lyx --export latex $1 > > BTW andre, did you document this flag somewhere? I found nothing in > the man page (hint!). Of course not ;-) There had been some discussion on the naming of the flags and I did not have the impression that the issue was settled. Until then I did not want to "officially" document the flag in order to prevent people from hard-wiring it into too many scripts. On the other hand, nobody has complained during the last couple of months, so maybe we could make the current naming official, i.e. I write some documentation. Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: Batchjob .lyx -> .dvi howto?
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> There had been some discussion on the naming of the flags and I Andre> did not have the impression that the issue was settled. Until Andre> then I did not want to "officially" document the flag in order Andre> to prevent people from hard-wiring it into too many scripts. Andre> On the other hand, nobody has complained during the last couple Andre> of months, so maybe we could make the current naming official, Andre> i.e. I write some documentation. Since you raise this point, we should probably change LyX options to use reasonable short/long forms for options. It is strange that some commands need '-', while others take '--'. Maybe a general way to accept either will be good. JMarc
Re: Batchjob .lyx -> .dvi howto?
On Fri, Jun 16, 2000 at 09:12:08AM +0200, Andre Poenitz wrote: > > How does one make a batch job for .lyx -> .dvi "conversion" ? > > lyx2dvi: > > #!/bin/sh > lyx --export latex $1 > latex $1 > latex $1 > latex $1 > Why there is now lyx --export dvi option? However, it is possible to use lyx --execute "command-sequence buffer-export dvi;lyx-quit;"
RE: configure error
On 16-Jun-2000 Angus Leeming wrote: > using configure --with-frontend=kde > configuration falls over if QT or KDE aren't installed in certain hardwired > locations. This is daft, since two shell variables are defined when running KDE > but not employed by the configure script. > > Why not test > $KDEDIR (=/usr/local/kde on my system) > $QTDIR (=/usr/local/qt on my system) > before falling over with an error message. Therefor we have the option: --with-qt-dir where the root of qt is installed --with-qt-includes where the Qt includes are. --with-qt-libraries where the Qt library is installed. --with-extra-includes adds non standard include paths --with-extra-libs adds non standard library paths Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug A homeowner's reach should exceed his grasp, or what's a weekend for? -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Batchjob .lyx -> .dvi howto?
> Why there is now lyx --export dvi option? Erm... now that you mention it... I think lyx --export dvi is possible, too. Stupid me... Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: Insert xfig
> > PS (to Asger) The need for writing scripts for the external inset is a little > > annoying. Can't we just add an option to define UpdateCommand to be > > "cmd1;cmd2;.." with the meanning to execute cmd1, then cmd2 etc. ? > > And what is the difference between pic2png_eps.py and pic2png_eps.sh ? > > I have created some of the scripts with Asger, so... > > The security is our main concern. With the shell script there is nothing to > prevent you from running other commands using an appropriate choice of parameters. > > The pic2png_eps.sh shouldn't be there, since it is insecure. > We forgot to remove it. What do you think Asger? Yes, that should be removed. The problem with having more powerful shell scripts in the external insets is that they would allow ILOVEYOU kind of viruses. You would load a downloaded document, and when you view, export or print it, an arbitrary command could be executed on your machine. This could be a command that mailed the document to all people in your netscape address book. Since the $$Filename and $$Parameters are substituted into the command line, and the filename and parameters are specified in the document, the document would be able to execute arbitrary commands. We do not want to allow that. Therefore, we have to be very careful with the scripts that are run by the external inset scripts. If what you meant was to provide a small facility to allow the "safe" script constructs, sure we could do that. We already showed the way with the script for the external date inset which uses a general Python script as a wrapper for commands that want to pipe input and output somewhere, i.e. to similate some of the shell facilities. It would be fairly trivial to extend this script to support ;'s for command separation. You are welcome to do this, if you want to. Greets, Asger
Re: Insert xfig
> However, I think that resizing/rotation options should be added to the
> external inset.
Yes, I think so to. If you read the ExternalTemplate.lyx file, you will
notice that this is mentioned as a feature to implement for a volunteer.
I think it should be designed such that there are optional parameters
for all commands, and another for a products. In the dialog, there
should be two parameter boxes, and a drop-down list where you can choose
which export format, you are parameterizing. Such a setup would also
allow for previewing of all different export formats.
At the moment, there is only one general parameter box, and you can
only preview the primary format, and that obvious sucks.
We did not have time to implement the full parameter version at the
meeting, and I don't have time to do this now.
But at the same time, I feel that the external inset is not completely
finished without this feature, so I would be very happy if somebody
picked up the torch, and did this small refinement.
> Format LaTeX
> Product "\\begin{picture}(0,0)\\includegraphics{$$Basename.eps}\<-no break
> \\end{picture}\\input{$$Basename.pstex_t}"
> Requirement "graphics"
> UpdateCommand "python $$Sysdir/scripts/fig2pstex.py $$FName $$Parameters"
> FormatEnd
>
> No. You should write a python script that generates both the pstex and the
> pstex_t files automatically (in the example above, the suffix of the
> Postscript file should be changed from pstex to eps).
By now, it would come as no surprise that I'd like to ask Dekel to submit
a patch that improves the XFig external inset ;-)
If you need to add a certain package to the LaTeX preamble, you have
two options: Either just insert it with a Preamble command in the
external_templates file (and make sure that it is robust enough to
be included several times), or extend LaTeXFeatures.[Ch] with a new
package, and use the name in the Requires command in the external_
templates file.
When I get some more feedback on the external inset, I will find time
to update the documentation accordingly. BTW, if somebody is messing
around with the documentation anyway, they would be welcome to insert
the ExternalTemplates.lyx document into the User guide, or whatever
existing help document is appropriate.
Greets,
Asger
Keyboard problems (lyx-1.1.5 and below)
It is very sad that LyX still can't support X keyboard other than
ISO-8859-1. It is one of those broken program for which I still need a
broken xmodmap. And I also don't think using LyX own keymaps is a good
thing, as the Xserver is ment to handle the keyboard.
The problem is, that when I have eg. Polish keyboard layout defined in
my Xserver configuration, and Polish locale (LC_CTYPE) chosen I should
get my national (iso-8859-2) characters entered properly. But LyX seems
to accept iso-8859-1 characters only, so I have to set my xmodmap so
the keys generates iso-8859-1 characters corresponding to the same codes
in iso-8859-2.
GNOME, Qt applications and demos from xforms-0.89 don't suffer this
problem. Even in LyX keyboard in dialog boxes seems to work OK for me.
I was searching for the problem, using xforms-0.88 and 0.89, and
chacking the LyX source. I hace prepared an analysis of the problems I
found for the author of xforms. It is also attached to this mail (I dont
thing it is neccessery do describe the problem twice).
I hope it will help You inprove LyX.
Greets,
Jacek
PS.
The LyX is the best program for writting text document I have
ever seen. Thanks for that!
Date: Fri, 16 Jun 2000 13:12:08 +0200
From: Jacek Konieczny <[EMAIL PROTECTED]>
To: "T.C. Zhao" <[EMAIL PROTECTED]>
Subject: Re: Keyboard bug in xforms
On Sun, Jun 11, 2000 at 02:36:26PM -0700, T.C. Zhao wrote:
> You can download and try the current version
> from http://world.std.com/~xforms
> and let me know if there is any improvement.
>
> Added some code to handle locale, but not
> entire sure got it right.
The demos seem to work better --- keyboard is read properly (ISO-8859-2
characters), but the font "iso-8859-1" is always used. It is ok, as most
programs allow to change font, so the font charset can also be set.
But maybe it would be better if the font encoding would be taken from
locale too? But it can make problems too: how would english menu look
like written i chinesee font?
The new version however don't seem to fix keyboard problems in LyX.
There is a separate keyboard support in the main window, but it seems
xforms keyboard support is still used in dialogs. But even using
xforms-0.88 I got ISO-8859-2 characters there (in dialogs). But not in
the main window.
I have checked the LyX code, and I found out that it uses X input
method. However XOpenIM always fails. I have written a little prog
(attached) to check how does it work. I found out XOpenIM fails if no
"@im" locale modifier is set. In the attached program if "" is given to
SetLocaleModifiers, setting XMODIFIERS enviroment variable to "@im=none"
helps. In LyX however it does not. XOpenIM does not fail, but still no
ISO-8859-2 characters are entered.
The funniest thin is, that setting this variable breakes xforms handling
of keyboard. Both in xforms demos and in LyX dialog boxes: instead of
one iso-8859-2 character four characters are entered --- one proper, and
other random. It seems it is a bug of xforms-0.89 (xform-0.88 doesn't
suffer this problem). It can also be a bug in XFree86-4.0, as xedit
(using Xt) has the sum problem, but even when XMODIFIERS is not set.
The little test program is attached. It seems to properly recognize
typed characters.
I hope I was at leas a little bit helpful.
Greets,
Jacek
#include
#include
#include
int DoEvents(Display* display,XIC xic){
XEvent ev;
char key[11];
do{
XNextEvent(display,&ev);
fprintf(stderr,"Event: %i\n",ev.type);
if (ev.type==KeyPress){
fprintf(stderr,"KeyPress: \n");
XLookupString(&ev,key,10,NULL,NULL);
fprintf(stderr,"XLookupString: '%s'\n",key);
XmbLookupString(xic,&ev.xkey,key,10,NULL,NULL);
fprintf(stderr,"XmbLookupString: '%s'\n",key);
}
}while(key[0]!='q');
return 0;
}
int DoIC(Display *display,XIM xim){
XIC xic;
Window window;
XSetWindowAttributes atr;
int r;
atr.background_pixel=0;
atr.event_mask=KeyPress|KeyRelease|ButtonPress|ButtonRelease|CreateNotify;
atr.do_not_propagate_mask=0;
window=XCreateWindow(display,DefaultRootWindow(display),0,0,100,100,1,CopyFromParent,InputOutput,CopyFromParent,CWBackPixel|CWEventMask|CWDontPropagate,&atr);
fprintf(stderr,"Window: %i\n",window);
XMapWindow(display,window);
xic=XCreateIC( xim,XNInputStyle, XIMPreeditNothing | XIMStatusNothing
, XNClientWindow, window
, XNFocusWindow, window,0);
fprintf(stderr,"XIC: %i\n",xic);
if (xic) {
r=DoEvents(display,xic);
XDestroyIC(xic);
return r;
}
return 1;
}
int DoIM(Display *display){
XIM xim;
int r;
xim=XOpenIM(display,NULL,"XIMTest","XIMTest");
fprintf(stderr,"XIM: %i\n",xim);
Re: kde frontend: LyXFunc or LyXView
Marko> current CVS does not compile with KDE frontend due to the difference in
Marko> Dialogs class definition for KDE and Xforms frontends. Namely, Dialogs
Marko> class constructor expects LyXView* as its argument in Xforms frontend
Marko> (src/frontends/Dialogs.h src/frontends/xforms/Dialogs.C) and LyXFunc* as
Marko> an argument in KDE frontend (src/frontends/kde/Dialogs.C).
Marko,
all development has been done with the xforms code. The code in the kde
directory was written as proof of concept a long, long time ago. As such, it
has lagged behind...
You are correct to report that the code in kde/Dialogs.C is inconsistent with
that in xforms/Dialogs.C. It is wrong and should be
Dialogs::Dialogs(LyXView * lv)
{
dialogs_.push_back(new FormCopyright(lv, this));
dialogs_.push_back(new FormPrint(lv, this));
dialogs_.push_back(new FormPreferences(lv, this));
// reduce the number of connections needed in
// dialogs by a simple connection here.
hideAll.connect(hideBufferDependent.slot());
}
Note, however, that this code won't compile either as no Print and
Preferences dialogs for kde. Commenting them out will allow the code to compile
(and maybe even link??) but the resulting executable will not have these
dialogs. Seems a bit pointless, no?
If, of course, you wish to write the missing dialogs...
Angus
Re: Random results from the fourth international LyX developers meeting in Norway
On Fri, Jun 16, 2000 at 11:04:52AM +0300, Lior Silberman wrote:
> On Thu, 15 Jun 2000, Dekel Tsur wrote:
>
> > To be more specific, lyxrc.C should contain a big array with entries for the
> > lyxrc variables, each entry contains information like token name, default
> > value, etc. Another field will be type (e.g. "printer", "screen fonts", etc.)
> > which will be used for building the form automatically.
> >
>
> I'm thinking about writing this soon, unless someone else wants to do it.
>
> Internally, the design might be a hash table mapping strings to entries,
You can use the STL map container. It is not a hash table, but it is fast
enough.
> and the extrnal interface should be something like:
> string LyXRC::query_string (string & key)
> bool LyXRC::query_boolean (string & key)
This approach has two problems:
1. There is no compile time check that you use the correct lyxrc variable
name in the query_*() calls.
2. Some lyxrc variables are accessed in the screen rendering routines, so
access to them should be extremely fast. So these variables should be kept as
member variables in the LyXRC class (these variables are also kept in the
map container, but after parsing the lyxrc file their values are copied to
the member variables).
An alternative approach would be to keep all the member variables, without
having the query_* methods.
The only disadvantage of this (comparing to your suggestion) is that adding
a new variable requires adding two lines (one in lyxrc.C and one in lyxrc.h)
instead of one (in lyxrc.C), and also the editing of lyxrc.h causes
recompilation of many files.
To clarify my suggestion, here is what I mean: we first define an array
A[] =
// name address default-value
{ "var1" , &var1, "str1", ...},
{ "var2" , &var2, "str2" , ..},
...
Then, from A we build a mapping M,
And then, we have
LyXRC::read()
{
...
while(1) {
string token = lexrc.GetString();
if (token.empty()) break;
map::iterator it = M.find(token);
if (it != M.end())
*(*it).address = lexrc.GetString();
else
lexrc.printError("Unknown tag "+token);
}
}
(in this example I assumed that all variables are strings).
Re: kde frontend: LyXFunc or LyXView
> all development has been done with the xforms code. The code in the kde
> directory was written as proof of concept a long, long time ago. As such, it
> has lagged behind...
>
> You are correct to report that the code in kde/Dialogs.C is inconsistent with
> that in xforms/Dialogs.C. It is wrong and should be
>
> Dialogs::Dialogs(LyXView * lv)
> {
> dialogs_.push_back(new FormCopyright(lv, this));
> dialogs_.push_back(new FormPrint(lv, this));
> dialogs_.push_back(new FormPreferences(lv, this));
>
> // reduce the number of connections needed in
> // dialogs by a simple connection here.
> hideAll.connect(hideBufferDependent.slot());
> }
>
> Note, however, that this code won't compile either as no Print and
> Preferences dialogs for kde. Commenting them out will allow the code to compile
> (and maybe even link??) but the resulting executable will not have these
> dialogs. Seems a bit pointless, no?
>
> If, of course, you wish to write the missing dialogs...
>
> Angus
>
The attached small patch allows to compile kde frontend. The resulting
executable misses FormPrint and FormPreferences dialogs but shows
FormCopyright using kde libs.
Marko
patch.gz
[Q] How to generate the character « and »?
Hello, I have imported a text document in lyx which contains « and » "french quote" How can i input them in my lyx document compose + <+< does not works is there a tips There are a few things you need to know about this table. This manual is set up --- by hand, mind you --- to print all of these characters. That ain't the default. Nowhere near, in fact. Here are some of the details you'll need to bear in mind when using characters from the Latin1 character set: * The characters at entries A2, A4, A5, A6 and AD -- the cent, the yen, the generic-currency-symbol, the broken vertical bar, and the short dash -- are just plain missing in the default encodings. We don't know where they are or why this is the case. * Even if you've selected latin1 in the Document Layout popup, users who have only the OT1-fonts for LaTeX [or who have the T1-fonts but aren't using them] will still be missing a few characters: D0, F0, DE, FE, AB, and BB -- the uppercase and lowercase eth and thorn, and the french quotes -- won't show up. * Users of OT1-fonts can, however, get the french quotes [characters AB and BB] if they include the either the package umlaute.sty or german.sty in their documents i've got these character in my dvi files, but how can i type them directly thanks Yann -- "Y faut liiirrreee, Arlequin, Champion de l'amou" Dany Boon --- (Yann MORERE mailto:[EMAIL PROTECTED] ) (Doctorant Automatique http://www.multimania.com/ymorere/ )
Re: [Q] How to generate the character « and »?
>>Date: Fri, 16 Jun 2000 17:59:14 +0100 >>From: Yann MORERE <[EMAIL PROTECTED]> >>To: LyX Users <[EMAIL PROTECTED]>, LyX devel <[EMAIL PROTECTED]> >>Subject: [Q] How to generate the character « and »? >> >>Hello, >> >>I have imported a text document in lyx which contains « and » "french >>quote" >> >>How can i input them in my lyx document Select the required quote in the Layout->Quotes menu, then " will provide the right « guillemet » >> >>compose + <+< does not works lyx-1.1.5 lyxrc allows to use the compoe key: uncomment override_x_deadkeys false Didnt't check it however, should allow to type in the whole isolatin set (Copyright, Yen, etc.) -- Jean-Pierre
Re: Insert xfig
> > No. You should write a python script that generates both the pstex and the > > pstex_t files automatically (in the example above, the suffix of the > > Postscript file should be changed from pstex to eps). > > By now, it would come as no surprise that I'd like to ask Dekel to submit > a patch that improves the XFig external inset ;-) > I've written the script, taking pic2png_eps.py as the base script. However I did find two problems with that script: 1. The "import os.path" command causes an error on my machine (python 1.5.1) It works fine without it. 2. The handling of optional arguments was wrong Now, I have two complaints about the inset: 1. The UpdateCommand is always called, even if we already generated the product files. 2. When use_tempdir is true, the inset generates the files in the directory of the source file and not in the temp. directory (this may be intentional, as the generation process make be costly in some cases). patch.gz fig2psfig.py.gz
Re: Insert xfig
On Fri, Jun 16, 2000 at 07:52:08PM +0300, Dekel Tsur wrote: > > > No. You should write a python script that generates both the pstex and the > > > pstex_t files automatically (in the example above, the suffix of the > > > Postscript file should be changed from pstex to eps). > > > > By now, it would come as no surprise that I'd like to ask Dekel to submit > > a patch that improves the XFig external inset ;-) > > > > I've written the script, taking pic2png_eps.py as the base script. > However I did find two problems with that script: > For some strange reason, I named the script fig2psfig.py, where it should be fig2pstex.py. Here is a fixed patch. fig2pstex.py.gz patch.gz
Re: Insert xfig
On Fri, Jun 16, 2000 at 01:08:47PM +0200, Asger K. Alstrup Nielsen wrote: > If what you meant was to provide a small facility to allow the > "safe" script constructs, sure we could do that. We already showed > the way with the script for the external date inset which uses > a general Python script as a wrapper for commands that want to > pipe input and output somewhere, i.e. to similate some of the > shell facilities. > It would be fairly trivial to extend this script to support ;'s > for command separation. You are welcome to do this, if you want to. Why not have support for ";" in the external figure code? (i.e. define UpdateCommand as "cmd1 parameters;cmd2 parameters;..." ) This will save a call to python.
Table size
Is there any idea when we might get visual feedback to the "size" attribute for table cells? Or even a horizontal scrollbar when tables go off-screen? Currently editing tables is virtually impossible. I use the size for when I have a longer piece of text for a table cell and I believe there is no other reasonable way of doing this. Of course one might claim that it would be useful if this was handled in a more abstract way aswell. Ie. that I could have a table which horizontally uses as much space as is on offer (much in the same way as in HTML, without a specific size, works. - -- = = -//--+ |/ Kristoffer Lawson | www.fishpool.fi|.com +-> |[EMAIL PROTECTED] | - - --+-- |-- Fishpool Creations Ltd - / | + = - - - = - /~setok/
Re: Insert xfig
On Fri, Jun 16, 2000 at 08:07:18PM +0300, Dekel Tsur wrote: > > Why not have support for ";" in the external figure code? > (i.e. define UpdateCommand as "cmd1 parameters;cmd2 parameters;..." ) > This will save a call to python. Better yet is, perhaps, to create a python secure module, that could be used as a wrapper around safe system calls. What do you think? (Asger and others...) -- José
LyX segfaults on color allocation failure
Hello, Just upgraded to 1.1.5 after 1.0.2 started segfaulting on me. Turned out that 1.1.5 segfaulted as well. So I tried starting another X client, and got a long stream of color allocation failure messages. Realized I had a vnc session up, shut that down, and tried again. Presto, LyX works fine. Here are the details: System LyX running on: Linux: 2.2.14smp glibc: 2.1.1-6 XFree86: 3.3.5-1.6.0 compiler: egcs-1.1.2 System LyX displaying on: AIX: 4.3.3.10 Communication via ssh-1.2.27 Sorry about the number of variables, didn't want to leave out anything important. Though its probably just error handling on color allocation failure and not dependent on local vs. remote or any of the other variables. Thanks you all for your work on LyX. Regards, Simon Hill ([EMAIL PROTECTED]) http://www.metasystema.org/
Re: Insert xfig
On Fri, Jun 16, 2000 at 01:18:49PM +0200, Asger K. Alstrup Nielsen wrote: > > However, I think that resizing/rotation options should be added to the > > external inset. > > Yes, I think so to. If you read the ExternalTemplate.lyx file, you will > notice that this is mentioned as a feature to implement for a volunteer. I've added more options to the external inset: the ability to resize/rotate the result (the resize buttons doesn't work yet). I also changed the file format for storing InsetExternal: I use the same file format of InsetFig. patch.gz
Re: Insert xfig
> > Why not have support for ";" in the external figure code? > > (i.e. define UpdateCommand as "cmd1 parameters;cmd2 parameters;..." ) > > This will save a call to python. > > Better yet is, perhaps, to create a python secure module, that could be used as > a wrapper around safe system calls. What do you think? (Asger and others...) Both approaches have merits. I didn't have a closer look at the scripts to see if we could completely do without Python scripts for the most part, but it this is the case, it would be natural to extend the external inset commands to allow multiple commands, since we could then relieve the need for Python. However, if it would only give us an advantage on 1 or 2 scripts, we would still need Python in practice, and then it might just be better to extend the Python script. In particular, it seems that we have to support pipes, and it would be a mistake to reimplement a complete secure shell in C++. Python is much better suited for this. In conclusion: I don't have strong feelings either way. I'll let it be up to the people that do the work. Preferably, I'd want people to work on the finer-grained parameters, but of course, I can't dictate what people should spend their free time on. I can only suggest to focus on the important things. After all, that was the basic premise of the external inset: Forget about OpenParts, Bonobo or other sophisticated, complicated, but essentially unfinished and unproven technologies. Do things the simple way, and focus on what will bring results. Greets, Asger
Re: Insert xfig
> For some strange reason, I named the script fig2psfig.py, where it should be > fig2pstex.py. > Here is a fixed patch. This patch set is good. Thanks Dekel ;-) Could somebody please apply it to the cvs? Thanks, Asger
Re: Insert xfig
> > Yes, I think so to. If you read the ExternalTemplate.lyx file, you will > > notice that this is mentioned as a feature to implement for a volunteer. > > I've added more options to the external inset: the ability to resize/rotate > the result (the resize buttons doesn't work yet). > > I also changed the file format for storing InsetExternal: I use the same > file format of InsetFig. I'm sorry, but I think we have misunderstood each other. I did not mean that we should have resize/rotate buttons literately. I meant that we should have a way of specifying these things. The problem with having them literally, is that the external inset is more general than just for graphics. For instance, it does not make sense to specify size or rotation for the date template. Therefore, I would much rather prefer to have generic parameter fields for both the product commands, and the update commands. In conclusion, this patch is moving in the wrong direction, IMO, but it's entirely my fault, because I wasn't clear enough the first time. Having said that, I am willing to discuss the issue. Obviously, most of the external insets *will* be using a picture of some kind, and therefore, it might be justified to have these specialized controls in there -- even if some templates won't use it. What do others think? Is it a good idea to have resizing and rotating available for all external insets, when maybe 90% will be able to use one or both options? Maybe it would be best to provide a bool in the template definition for each control, to allow the template to dictate whether the controls make sense? I think that might be the way to go, because it *is* nicer to specify size and rotating directly rahter than with some strange parameters... So I think I've convinced myself that the patch is moving in the right direction after all. It just needs some spit and polish, and I'd accept it. In particular, if the controls are optional from the point of view of the template, the patch is excellent. Greets, Asger
Re: Random results from the fourth international LyX developers meetingin Norway
> An alternative approach would be to keep all the member variables, without
> having the query_* methods.
> The only disadvantage of this (comparing to your suggestion) is that adding
> a new variable requires adding two lines (one in lyxrc.C and one in lyxrc.h)
> instead of one (in lyxrc.C), and also the editing of lyxrc.h causes
> recompilation of many files.
>
> To clarify my suggestion, here is what I mean: we first define an array
>
> A[] =
> // name address default-value
> { "var1" , &var1, "str1", ...},
> { "var2" , &var2, "str2" , ..},
> ...
>
> Then, from A we build a mapping M,
>
> And then, we have
>
> LyXRC::read()
> {
> ...
>while(1) {
> string token = lexrc.GetString();
> if (token.empty()) break;
> map::iterator it = M.find(token);
> if (it != M.end())
> *(*it).address = lexrc.GetString();
> else
> lexrc.printError("Unknown tag "+token);
> }
> }
>
> (in this example I assumed that all variables are strings).
This approach sounds like a plan. I assume that you want
separate arrays for each type, but that's cool with me.
One suggestion though: We *could* extent the approach with
a map as originally proposed. This would give us two advantages:
1) For the lazy people that don't want to introduce a
recompile of everything just because a new, non-performance
critical, lyxrc value is introduced, it would be a bargain.
2) It allows us to have run-time introduced lyxrc variables.
Those could come in handy at many different times.
To be specific, I'd do this:
map::iterator it = M.find(token);
if (it != M.end()) {
string * ad = (*it).address;
if (adr == 0) {
map[token] = lexrc.GetString();
} else {
*adr = lexrc.GetString();
}
} else
lexrc.printError("Unknown tag "+token);
and the array would have 0 as the address for the "lazy"
lyxrc values.
This way, we get the best of both worlds.
Greets,
Asger
