Re: reverting to 1.3.3 from 1.4cvs?
On Friday 03 October 2003 05:58, Nirmal Govind wrote: > Thanks Garst... that script works great! I think I'm still going to > stick with cvs, I feel a little more secure knowing that this script can > (hopefully) get me out of trouble if I do run into major problems with > cvs and need to go back to 1.3... > > nirmal That script is from André, and BTW Garst just because you call it .sh that doesn't make it a shell script. It is a perl script. :-) If this helps any of you I am working and will commit soon a process where lyx2lyx is able to downgrade gracefully to the previous stable version. -- José Abílio LyX and docbook, a perfect match. :-)
Re: [patch]: adding transformations to InsetExternal
On Thu, 2 Oct 2003, Angus Leeming wrote:
> Attached. The document describes the ideas behind the language and the
> rationale of the separation of Data from Transform. It does not (yet)
> describe how it all glues together. Instead I attach a small sample code
> illustrating how I think it should be done.
OK, thank you. A high-level summary:
LyX supports a fixed number of transformations, and a fixed number of
exporting formats for these. In the external material definition file, you
can define which transformations each template supports, and how to use
combine the exporters to produce the final output.
While this solves the problem, I feel that it is a strange mix of
hard-coding and not hard-coding.
The question is: Is the functionality of allowing the user to define
which exporters to use for each external material really useful? Of
course, it allows the advanced user to make it so that included
chess-boards can be rotated, resized and clipped. This is just grand, but
when the exporters are hard-coded, will he in fact be able to do that in
real life?
In other words, will it not be so that in practice, we will have to define
new exporters to allow this functionality to be used?
I'm not sure - it surely depends on how generally useful the exporters
are. Can they be reused for other templates?
In other words, will the ones you have now allow you to rotate, clip and
resize a chess-board?
If not, the options are
1) Keep the system as you propose - maybe the exporters are not so
reusable that we infact gain new functionality beyond extending the
graphics and xfig templates, but that in itself is great, and over time,
more exporters can be implemented, and we solve the problem that way. (It
is unlikely that a normal user will ever request a new exporter, because
they will not understand this.)
2) Extend the syntax to support defining exporters in the external
definition file. More general, but also much more complicated. Normal
users will not be able to use this, and it might scare them further away
from the external material insets all together.
3) Tie together the transform and export relation. In other words, only
keep the "transform X" lines. Then, each c++ transformer has a hardcoded
exporter, that knows how to extend the product of the template. I.e. rather
than introducing two concepts: Transformers and exporters for
transformers, instead collapse them into one concept "Transformers" by
doing the cartesian product.
So, we would have a RotateGraphicsStyle and RotateXFigStyle rather than
one Rotate and two exporters.
Implementation wise, these transformers would share the same dialog and
all that good stuff, but the user does not have to know about all this
export-business, substitutions of front-bits and back-bits. Instead, he
is told (this is from memory, so ignore syntax errors):
LyX supports a RotateGraphicsStyle transformer, which will change
\includegraphics{yadayada} into \includegraphics[rotation]{yadayada}
if you have produce \includegraphics{$$Filename} in your external template
file. It also does the right thing for other formats.
Also, LyX supports a RotateXFigStyle transformer, which will change
\foo{yadayada} into \bar[rotation]{\foo{yadayada}} if you have produce
\foo{yadayada} in your external material template file. It also does the
right thing for other formats.
That to me seems a lot simpler for the user, and it will probably also
simplify your C++ code.
Comments?
Best regards,
Asger
Re: CVS lyx-1.4 compile failure
Angus Leeming <[EMAIL PROTECTED]> writes: | Martin Vermeer wrote: >> Undoubtedly can be made to work... but it is 'politically' wise? If we >> go the way that Lars proposed and recommend people sticking to 2.95 to >> install and use stlport, than even the little extra hassle of >> writing/editing a configure_stlport script when a simple --use-stlport >> option to configure would be the 'least surprise' expectation, is too >> much. (And yes, I know this is for developers, not end users. But that >> includes, e.g., distribution packagers handling hundreds of packages >> and both unfamiliar with and uninterested in the LyX config/install >> system's idiosyncrasies.) > | Let's see how this all pans out first. I suspect Lars will give in and | commit a debugstream that works for you too... ...but now he has a LyX that works... -- Lgb
Re: CVS lyx-1.4 compile failure
On Thu, Oct 02, 2003 at 05:05:30PM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | Index: src/lyx_main.C
> | ===
> | RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_main.C,v
> | retrieving revision 1.177
> | diff -u -p -r1.177 lyx_main.C
> | --- src/lyx_main.C 26 Sep 2003 14:27:19 - 1.177
> | +++ src/lyx_main.C 2 Oct 2003 13:49:12 -
> | @@ -76,12 +76,13 @@ using std::endl;
> |
> | using std::vector;
> |
> | +#if 0
> | #ifndef CXX_GLOBAL_CSTD
> | using std::exit;
> | using std::signal;
> | using std::system;
> | #endif
> | -
> | +#endif
> |
> | extern void QuitLyX();
>
> We need to find out why this is needed, it shouldn't be.
It isn't. Cruft from earlier experimentation.
...
> | Index: src/mathed/math_streamstr.C
> | ===
> | RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_streamstr.C,v
> | retrieving revision 1.17
> | diff -u -p -r1.17 math_streamstr.C
> | --- src/mathed/math_streamstr.C 5 Sep 2003 16:18:57 - 1.17
> | +++ src/mathed/math_streamstr.C 2 Oct 2003 13:49:14 -
> | @@ -12,7 +12,7 @@
> |
> | #include "math_streamstr.h"
> | #include "math_mathmlstream.h"
> | -
> | +#include "support/std_ostream.h"
> |
> | WriteStream & operator<<(WriteStream & ws, string const & s)
> | {
>
> What are the errors when std_ostream.h are left out?
> but this change is ok.
Attached.
> | Index: src/support/lstrings.C
> | ===
> | RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/lstrings.C,v
> | retrieving revision 1.80
> | diff -u -p -r1.80 lstrings.C
> | --- src/support/lstrings.C 25 Sep 2003 23:01:43 - 1.80
> | +++ src/support/lstrings.C 2 Oct 2003 13:49:14 -
> | @@ -20,6 +20,7 @@
> | #include "tostr.h"
> |
> | #include
> | +#include
> |
> | #include
>
> what are the errors? (and why do we not see them with gcc 3.x?)
Attached.
What is the path through which lstrings.C gets assert.hpp included in
the absence of this #include? (Apparently it does; gcc3 compiles this
also for me without it.)
> but ok.
>
> --
> Lgb
- Martin
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c: In function `class
_STL::basic_ostream > & _STL::operator <<, _STL::allocator
>(_STL::basic_ostream > &, const
_STL::basic_string,_STL::allocator > &)':
math_streamstr.C:26: instantiated from here
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:45: invalid use of undefined type
`class _STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_iosfwd.h:39: forward declaration of `class
_STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:45: assignment (not initialization) in
declaration
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:48: `__sentry' undeclared (first use
this function)
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:48: (Each undeclared identifier is
reported only once
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:48: for each function it appears in.)
math_streamstr.C:26: instantiated from here
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:52: incomplete type
`_STL::basic_ostream >' does not have member `left'
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:52: invalid use of undefined type
`class _STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_iosfwd.h:39: forward declaration of `class
_STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:53: invalid use of undefined type
`class _STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_iosfwd.h:39: forward declaration of `class
_STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:54: invalid use of undefined type
`class _STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_iosfwd.h:39: forward declaration of `class
_STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c: In function `bool
_STL::__stlp_string_fill
>(_STL::basic_ostream > &,
_STL::basic_streambuf > *, unsigned int)':
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:61: instantiated from
`_STL::operator <<, _STL::allocator
>(_STL::basic_ostream > &, const
_STL::basic_string,_STL::allocator > &)'
math_streamstr.C:26: instantiated from here
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:28: invalid use of undefined type
`class _STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_iosfwd.h:39: forward declaration of `class
_STL::basic_ostream >'
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c:33: invalid use of undefined type
`class _STL::basic_streambuf >'
/home/mv/STLport-4.5.3/stlport/stl/_iosfwd.h:33: forward declaration of `class
_STL::basic_streambuf >'
/home/mv/STLport-4.5.3/stlport/stl/_string_io.c: In function `class
_STL::basic_ostream > & _STL::operator <<, _STL::allocator
>(_STL::basic_ostream > &, const
_STL::basic_stri
Re: CVS lyx-1.4 compile failure
On Fri, Oct 03, 2003 at 09:38:51AM +0200, Lars Gullik Bjønnes spake thusly: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Martin Vermeer wrote: > >> Undoubtedly can be made to work... but it is 'politically' wise? If we > >> go the way that Lars proposed and recommend people sticking to 2.95 to > >> install and use stlport, than even the little extra hassle of > >> writing/editing a configure_stlport script when a simple --use-stlport > >> option to configure would be the 'least surprise' expectation, is too > >> much. (And yes, I know this is for developers, not end users. But that > >> includes, e.g., distribution packagers handling hundreds of packages > >> and both unfamiliar with and uninterested in the LyX config/install > >> system's idiosyncrasies.) > > > | Let's see how this all pans out first. I suspect Lars will give in and > | commit a debugstream that works for you too... > > ...but now he has a LyX that works... > > -- > Lgb My first question is: does this only concern developers, or end users too? i.e., do we have any reason to produce binaries for end users on an old compiler, or is it possible to produce such a binary on a modern system? If it is only a developer issue, then I would posit that STLport is preferable to kludges. I can write up a cookbook recipe to get other developers on 2.95 up in no time. Producing binaries for end users shouldn't be too hard either: the RPM will have to have dependencies on libpthread and STLport, which will be both installed into system directories in the library search path. So the end user doesn't even notice it except as a couple of extra dependencies. RPM's for STLport appear to exist (and we could even link statically if must be to avoid this issue altogether.) (BTW would STLport itself have a dependency on libpthread?) The only possible issue I see with this is having to support two different STL/iostreams implementations with each their curious curiosities. But surely that's still better than supporting an old and broken such in addition to the modern gcc3 one. - Martin pgp0.pgp Description: PGP signature
Re: CVS lyx-1.4 compile failure
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | Let's see how this all pans out first. I suspect Lars will Lars> give in and | commit a debugstream that works for you too... Lars> ...but now he has a LyX that works... But I don't... Anyway, I have enough work focusing on 1.3.x now, but it would be nice at least to be able to test and commit on HEAD what goes to the branch. JMarc
Re: reverting to 1.3.3 from 1.4cvs?
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: Jose'> If this helps any of you I am working and will commit soon a Jose'> process where lyx2lyx is able to downgrade gracefully to the Jose'> previous stable version. Do you plan to make this available to 1.3.x? It would be nice. JMarc
Re: [patch]: adding transformations to InsetExternal
Asger Kunuk Alstrup wrote:
> OK, thank you. A high-level summary:
>
> LyX supports a fixed number of transformations, and a fixed number of
> exporting formats for these. In the external material definition file,
> you can define which transformations each template supports, and how to
> use combine the exporters to produce the final output.
An elegant summary.
> While this solves the problem, I feel that it is a strange mix of
> hard-coding and not hard-coding.
Me too.
> The question is: Is the functionality of allowing the user to define
> which exporters to use for each external material really useful? Of
> course, it allows the advanced user to make it so that included
> chess-boards can be rotated, resized and clipped. This is just grand, but
> when the exporters are hard-coded, will he in fact be able to do that in
> real life?
Two points.
* The vast majority of InsetExternal's users will be using it with one of
the graphics templates, of which RasterImage and Xfig are the two existing
templates, with VectorImage (for PostScript and Pdf images) and Tgif to
follow. These transformations most definitely will be used by this group
of users.
* I don't think that the commands \rotatebox and \resizebox are limited to
a subset of latex. So, to answer the specific question, I think it will
work with chessboards too.
> In other words, will it not be so that in practice, we will have to
> define new exporters to allow this functionality to be used?
You mean new transformers? Yes, of course. That's the hard coded part of
the scheme.
> I'm not sure - it surely depends on how generally useful the exporters
> are. Can they be reused for other templates?
The really important one is the Extra option which allows the user to pass
arbitrary options to the primary command. You had this functionality in
your original design but the data was stored on a Template level rather
than an output Format level.
Everything else, (rotate, resize, clip) could either be passed using the
Extra option (in the case of \includegraphics) or the user could use ERT
to wrap the InsetExternal (in the case of \input for example).
So, my take on this is that these three provide visual sugar both on the
LyX screen and (in the future this) on the _graphics_ dialog, allowing the
user to clip, rotate, and resize in a general way.
> In other words, will the ones you have now allow you to rotate, clip and
> resize a chess-board?
>
> If not, the options are
>
> 1) Keep the system as you propose - maybe the exporters are not so
> reusable that we infact gain new functionality beyond extending the
> graphics and xfig templates, but that in itself is great, and over time,
> more exporters can be implemented, and we solve the problem that way. (It
> is unlikely that a normal user will ever request a new exporter, because
> they will not understand this.)
Again, options are the key here. The user can always use ert for commands.
> 2) Extend the syntax to support defining exporters in the external
> definition file. More general, but also much more complicated. Normal
> users will not be able to use this, and it might scare them further away
> from the external material insets all together.
The difficulty here is defining how the GUI will accommodate this. I
thought about it and decided it was the GUI that was effectively
impossible.
> 3) Tie together the transform and export relation. In other words, only
> keep the "transform X" lines. Then, each c++ transformer has a hardcoded
> exporter, that knows how to extend the product of the template. I.e.
> rather than introducing two concepts: Transformers and exporters for
> transformers, instead collapse them into one concept "Transformers" by
> doing the cartesian product.
> So, we would have a RotateGraphicsStyle and RotateXFigStyle rather than
> one Rotate and two exporters.
LyX manipulates the Data. The user needs to be able to set the angle of
rotation. Everything else "should just work". So, I think that this idea
of yours doesn't help.
Remember, you have already mentioned that the syntax is not so scary after
all.
> Implementation wise, these transformers would share the same dialog and
> all that good stuff, but the user does not have to know about all this
> export-business, substitutions of front-bits and back-bits. Instead, he
> is told (this is from memory, so ignore syntax errors):
>
> LyX supports a RotateGraphicsStyle transformer, which will change
> \includegraphics{yadayada} into \includegraphics[rotation]{yadayada}
> if you have produce \includegraphics{$$Filename} in your external
> template file. It also does the right thing for other formats.
>
> Also, LyX supports a RotateXFigStyle transformer, which will change
> \foo{yadayada} into \bar[rotation]{\foo{yadayada}} if you have produce
> \foo{yadayada} in your external material template file. It also does the
> right thing for other formats.
>
> That to me seems a lot simpler for the user, and it
Re: reverting to 1.3.3 from 1.4cvs?
On Friday 03 October 2003 09:23, Jean-Marc Lasgouttes wrote: > > "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: > > Jose'> If this helps any of you I am working and will commit soon a > Jose'> process where lyx2lyx is able to downgrade gracefully to the > Jose'> previous stable version. > > Do you plan to make this available to 1.3.x? It would be nice. That can be done. For the most part lyx2lyx is independent of any lyx version. The only place where this is not true is that I assume that if the target format is not given then I am using the last format available, but this is just one line, so... :-) I am polishing lyx2lyx now, and I can backport this work to 1.3.x, mostly by copy and paste. > JMarc -- José Abílio LyX and docbook, a perfect match. :-)
Re: CVS lyx-1.4 compile failure
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | Lars> | Let's see how this all pans out first. I suspect Lars will | Lars> give in and | commit a debugstream that works for you too... > | Lars> ...but now he has a LyX that works... > | But I don't... You should try STLPort :-) I'll see if I can do something... -- Lgb
Re: Boss wanted!
John Levon wrote: > Insert->Branch does nothing on Qt. That's obviously a bug. > Luckily this sort of thing is easy as pie to fix. Certainly. The only reason it did not get around to it yet is that I do not have a good idea on the UI (especially the branches browser, which I'd like to be somehow different to the two-browser-approach in xforms). Jürgen.
Auxiliary scripts (not only archaeology) for LyX.
Hi, I am searching for scripts used to help LyX. For example one the latest was from Angus that converted a bibtex database to a lyx file with the corresponding bibliography items. I am searching for similar scripts that sometimes pop up in this list, as well as in lyx-users. I know that we have contribe in ftp where some of this can be found there, but usually for small scripts no one cares to do it. This is why I would like to have them all in a single place. Most of them are very useful and not only for the problem at hand. Comments? -- José Abílio LyX and docbook, a perfect match. :-)
Re: Auxiliary scripts (not only archaeology) for LyX.
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: Jose'> Hi, I am searching for scripts used to help LyX. For example Jose'> one the latest was from Angus that converted a bibtex database Jose'> to a lyx file with the corresponding bibliography items. Good idea. One that could be useful is a script to remove meaningful text from a .lyx file, so that people can send us their confidential documents for bug reports. I know I've seen one somewhere... JMarc
Help using Qt's designer...
I attach my attempts to modify the Qt External dialog. Two problems: * how do I specify accelerators? Adding the text "Forma&t:" clearly doesn't work. Moreover, I don't see how that would tell extraFormatCB anything. * how do I add new slots? I want to add a slot "formatChanged" that is invoked when extraFormatCB is changed. I also want to add a slot "extraChanged" that is invoked when extraED is changed. Regards, -- Angus QExternalDialogBase config.h qt_helpers.h QDialog name QExternalDialogBase geometry 0 0 279 569 caption External Material sizeGripEnabled true margin 11 spacing 6 QPushButton name editPB text &Edit file... toolTip Edit the file externally QLayoutWidget name Layout11 margin 0 spacing 6 QLayoutWidget name Layout8 margin 0 spacing 6 QLabel name fileLA text &File: buddy fileED toolTip Filename QLineEdit name fileED toolTip Filename QPushButton name browsePB text &Browse... name Spacer8 orientation Horizontal sizeType Expanding sizeHint 20 20 QGroupBox name GroupBox4 title LyX Display margin 11 spacing 6 QLayoutWidget name Layout11 margin 0 spacing 6 QLabel name scaleLA text Sca&le: buddy displayscale toolTip Percentage to scale by in LyX
Re: Help using Qt's designer...
Angus Leeming wrote: > Two problems: Problems solved. The internet is a great teacher. -- Angus
Re: reverting to 1.3.3 from 1.4cvs?
You're welcome, I gave up on cvs because it cleared my tables when I tried to insert a row, then crashed. Do you not have this problem? Garst Nirmal Govind wrote: > > Thanks Garst... that script works great! I think I'm still going to > stick with cvs, I feel a little more secure knowing that this script can > (hopefully) get me out of trouble if I do run into major problems with > cvs and need to go back to 1.3... > > nirmal >
Re: reverting to 1.3.3 from 1.4cvs?
Jose' Matos wrote: > If this helps any of you I am working and will commit soon a process where > lyx2lyx is able to downgrade gracefully to the previous stable version. > That will be nice. Thanks. Garst
Re: reverting to 1.3.3 from 1.4cvs?
Garst R. Reese wrote: You're welcome, I gave up on cvs because it cleared my tables when I tried to insert a row, then crashed. Do you not have this problem? I most certainly do... I also ended up going back to 1.3.3 due to this... I tried to work around this by creating the table in 1.3.3 and then copy/paste into cvs.. but copy/paste didn't work... guessing this is already a known problem... Jose - that converter will be just great.. thanks! nirmal
Re: [patch]: adding transformations to InsetExternal
I don't think you understood what I meant. I am not arguing to remove the
entering and configuration of the rotation angle, or crippling the
functionality to remove the "Extra" feature.
The GUI functionality is exactly the same as your current proposal.
The difference is only a question about what resides in the external
material definition file, and what resides in the code.
I'm basically saying that instead of having
template graphics
...
Transformer rotate
...
Product $$RotateMagic1
...
end_template
template xfig
...
Transformer rotate
...
Product $$RotateMagic2$$RotateMagic3
...
end_template
which is what you propose, you can instead just have
template graphics
...
Transformer rotate1
...
Product
...
end_template
template xfig
...
Transformer rotate2
...
Product
...
end_template
In other words, the task of adding support for a transformation to a
template is to add one extra line.
The task of making the magic to make sure that the LaTeX product makes
sense, including the coordination and bracing and collapsing with other
transformers, is pushed to the hard-coded part in C++.
So, the transformer basically has a policy for how to attach itself to a
given product.
The first rotate1 transformer knows that it has to attach itself before
the {} braces.
The second rotate2 transformer knows that it has to wrap the real-stuff
with magic.
These transformers also know how to talk together with the other
transformers, to make sure that it is sane.
Advantages:
- The users do not have to know about all of this magic.
- When adding new transformation types, you only have to change the C++
side - the external material templates do not have to change to
accomodate the interaction with the remaining transformers.
- You do not hide the real product of a template in a lot of magic to
make the transformers work. They just work if they are compatible with
the product.
- The entire concept of exporters is not relevant to the user
Disadvantages:
- The user can not define the exact syntax himself. However, they do not
need this functionality.
- Instead of having one Rotation transformer, you have several depending
on how they interact with the product from the template
Regarding the implementation: Internally, you can implement this using the
syntax you have made up, but the point is that the user should not have to
worry about this.
Keep the API to the user as simple as possible. You have not convinced
me that we need the complex syntax yet.
Best regards,
Asger
Re: [patch]: adding transformations to InsetExternal
Asger Kunuk Alstrup wrote:
> I don't think you understood what I meant. I am not arguing to remove the
> entering and configuration of the rotation angle, or crippling the
> functionality to remove the "Extra" feature.
Yes, I had misunderstood.
However, I really don't like your proposal either, now that you have
spelled it out. You are making the whole thing hard coded which means
the code has to know how and where to insert a transform into a new
template.
With my approach you get existing transformations in new templates for free,
even if the command has arbitrary complex syntax.
For example, how would you add rotation to this Product (which is quite
possible NOW by the way --- things have moved on in external_template land ;-)
PreambleDef WarnNotFound
%% Print a warning encased in an fbox.
\def\lyxstripprefix#1>{}
\newcommand{\warnNotFound}[1]{%
\def\lyxtempfilename{#1}%
\fbox{Could not find
\ttfamily\expandafter\lyxstripprefix\meaning\lyxtempfilename!}%
\typeout{Could not find \lyxtempfilename!}%
}
PreambleDefEnd
Template XFig
...
Format LaTeX
Product
"\IfFileExists{#1}{\input{$$BaseName.pstex_t}}{\warnNotFound{$$BaseName.pstex_t}}"
UpdateFormat pstex
UpdateResult "$$Basename.pstex_t"
Requirement "graphicx"
Preamble WarnNotFound
FormatEnd
TemplateEnd
For me, it is trivial:
Template XFig
...
Transform Rotate
Format LaTeX
TransformCommand Rotate RotationLatexCommand
Product
"\IfFileExists{#1}{$$RotateFront\input{$$BaseName.pstex_t}$$RotateBack}{\warnNotFound{$$BaseName.pstex_t}}"
UpdateFormat pstex
UpdateResult "$$Basename.pstex_t"
Requirement "graphicx"
Preamble WarnNotFound
FormatEnd
TemplateEnd
> Keep the API to the user as simple as possible. You have not convinced
> me that we need the complex syntax yet.
Shrug. Nobody is using InsetExternal and that isn't because it has
a complex API. Anyway, I think that the above example should get
you on my side.
--
Re: [Devel] [patch] std::string mamoth patch
On Friday 03 October 2003 2:34 pm, Lars Gullik Bjønnes wrote: > Object now or be silent forever! Why don't you post a patch to boost with all your bloody whitespace changes ;-) Apart from that --- go for it! Angus
Re: [patch]: adding transformations to InsetExternal
Angus Leeming wrote:
> "\IfFileExists{#1}{$$RotateFront\input{$$BaseName.pstex_t}$$RotateBack}{\warnNotFound{$$BaseName.pstex_t}}"
Of course, $$BaseName should have a lowercase 'n' and you should
also replace #1 in the above with $$Basename.pstex_t
--
[patch]: adding transformations to InsetExternal, version 2
This patch is IMO ready to go. So, to quote ze main man, "Object now or be silent forever!" It adds Resize, Rotate, Clip and an arbitrary Extra transformation to InsetExternal. Frontend support is provided (both xforms and Qt) for the Extra transform only. The rest will have to wait till the InsetExternal/InsetGraphics merger gets closer. I plan to commit it sometime over the w/e. Therafter, I'll probably be tied up with real work for some time to come. The sub-figure nonsense in InsetGraphics is the only real hurdle preventing an InsetExternal/InsetGraphics merger now. I plan to create a new InsetSubfigure derived from InsetCollapsable and write a bit of python for lyx2lyx. That should be fun ;-) -- Angus external.diff.gz Description: GNU Zip compressed data
Re: Auxiliary scripts (not only archaeology) for LyX.
On Fri, 3 Oct 2003, Jean-Marc Lasgouttes wrote: > > "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: > > Jose'> Hi, I am searching for scripts used to help LyX. For example > Jose'> one the latest was from Angus that converted a bibtex database > Jose'> to a lyx file with the corresponding bibliography items. > > Good idea. > I'll make a place for putting shell-scripts in the wiki area, and let you know where once it's done. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Auxiliary scripts (not only archaeology) for LyX.
On Friday 03 October 2003 17:30, Christian Ridderström wrote: > > I'll make a place for putting shell-scripts in the wiki area, and let you > know where once it's done. Thanks. I will search in the mailling list archives for it, but it will be interesting if others contribute. :-) > /Christian -- José Abílio LyX and docbook, a perfect match. :-)
Re: lyx-devel lib/: ChangeLog lib/lyx2lyx/: lyx2lyx lib/lyx2ly ...
On Fri, Oct 03, 2003 at 07:11:22PM +, [EMAIL PROTECTED] wrote: > support backward saving for 1.3.x format. Super stuff ! The users are gonna love this ... regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Backwards saving from cvs to 1.3
Hi, I have commited a patch that allows lyx2lyx from cvs to save in 1.3.x file format. To use it try: ./lyx2lyx -f 225 -t 221 lyx-1.4.lyx > lyx-1.3.lyx Where lyx-1.4.lyx is the filename of the 1.4 file and lyx-1.3.lyx is the file name of the new file, with the same format of 1.3. This is a convertion with losses, all the new features are lost, but not its content. This is by design. Say that you one of the fanciest notes from Martin, I garantee you that its content (the text inside) will be preserved. Examples: All the new comments and Greyedout insets are converted to Notes. The tracking changes are lost, and so on. Please test it. If this proves to be as stable as I expect we can backport it to 1.3.x completly. Have a nice weekend testing the feature (me duck and runs ) ;-) -- José Abílio LyX and docbook, a perfect match. :-)
Area for development scripts (was Re: Auxiliary ...)
On Fri, 3 Oct 2003, Christian Ridderström wrote: > I'll make a place for putting shell-scripts in the wiki area, and let you > know where once it's done. > Ok, I've created a group where we can add useful scripts for development here: http://wiki.lyx.org/pmwiki.php/DevelScripts/DevelScripts The URI above should give you enough information, and if it doesn't e-mail me and I'll add what is needed. I will now proceed and add a similar group for scripts that might also be useful for ordinarey users. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Area for development scripts (was Re: Auxiliary ...)
> > I will now proceed and add a similar group for scripts that might also be > useful for ordinarey users. Ok, so scripts that are useful for normal users as well should go here instead: http://wiki.lyx.org/pmwiki.php/Scripts/Scripts /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [Devel] [patch] std::string mamoth patch
Angus Leeming <[EMAIL PROTECTED]> writes: | On Friday 03 October 2003 2:34 pm, Lars Gullik Bjønnes wrote: >> Object now or be silent forever! > | Why don't you post a patch to boost with all your | bloody whitespace changes ;-) O, forgot to get rid of those | Apart from that --- go for it! I will... -- Lgb
Re: Using the Makefil
> | Is there a description of what the different targets in the Makefile(s) do > | anywhere? For instance, what's the difference between the different > | 'clean'-targets, i.e. when should you use what? After reading various documentation, I ended up putting a description of the targets here: http://wiki.lyx.org/pmwiki.php/DevelTips/MakeTargets /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [patch]: adding transformations to InsetExternal
Angus Leeming <[EMAIL PROTECTED]> writes: | Shrug. Stop shrugging! -- Lgb
Re: [patch]: adding transformations to InsetExternal, version 2
Angus Leeming <[EMAIL PROTECTED]> writes: | This patch is IMO ready to go. | So, to quote ze main man, "Object now or be silent forever!" So assuuming (the ass in you and me): I never said that! -- Lgb
