Guys
Qt has a nice xml reader
Also one with a nice stream like interface that would fit nicely in ours
parser. And it quite fast too.
I will discuss that face2face during the meeting.
Abdel
On May 9, 2013 11:26 PM, "Richard Heck" wrote:
> On 05/09/2013 02:25 PM, Pave
classes are likely to be pretty stable.
QXmlStreamReader looks perfect for parsing LyX XML. QXmlStreamWriter
looks perfect for writing it.
I seriously doubt these will be unstable. Note that writing [valid]
XML is much easier than reading it, so you could write your own stream
writer. Read
Georg Baum wrote:
> With the same reasoning you could conclude that we need to ship Qt within
> the sources. If there is a bug at the right place in Qt, you can get all
> sorts of problems including severe data loss as well. But, we don't include
Well, indirectly yes, but still, we don't use Qt
Richard Heck wrote:
> No, I just meant that we would have to include it in our sources, since
> we cannot rely upon libxml to be available on actual machines that are
> running non-Linux OSs. It's available for that OS, yes, but it's not
> actually going to be installed. Unlike on Linux, where it
Thanks to one of LyX's best friends (can you guess who?), I have
discovered that Qt already provides exactly the sort of XML library we
need in the QXmlStreamReader and QXmlStreamWriter classes. These are
part of QtCore, which is allowed in src/ and is already present there:
./lyx-2
On Friday 10 May 2013 02:19:40 Pavel Sanda wrote:
> But jokes aside, you have to rely on arbitrary decision of third party which
> can do whatever is pleased to do so in new versions, if some problem arises
> you
> can't stick to version known to work, because the other guys have the library
> on
it?
As Pavel said, if we are using some XML library to read and write LyX
files, then we have to be especially careful that LyX does not get
broken by some external change over which we have no control. (I'll add
to his mention of python the whole mess over losing fork() on OSX.) This
is y
On 09-05-2013 18:52, Richard Heck wrote:
On 05/08/2013 06:24 PM, José Matos wrote:
On Wednesday 08 May 2013 17:43:41 Richard Heck wrote:
Thinking ahead, however: Should we use some SAX library to read the
XML? Or should we just adapt the Lexer for this purpose?
Richard
Lars had that working
José Matos wrote:
> Or are you thinking about any other system that is not included in this list?
> :-)
I don't see Haiku, where we currently compile ;)
> What would be the disadvantage of relying on it? I mean what are concerns
> about depending on it?
But jokes aside, you have to rely on arb
On Thursday 09 May 2013 14:21:37 Richard Heck wrote:
> On Linux, of course, it is different. One would just expect this library
> already to be installed. But things do not work that way on the other OSs.
>
> Richard
>From the webpage:
"Libxml2 is known to be very portable, the library should bu
I should add that while *writing* XML is easy enough (valid XML too),
it's reading that's hard, so you can't avoid using a library.
would be as much work to adapt what he did as to re-write it, so I
> propose to do the latter.
I agree. I wrote my own Python XML output class for my script. That
was quite easy. Most of the logic in my script is about fixing things
that need to be fixed, like rewriting a sequence of \series
'
approach. I think is the correct way to follow.
He has. The consensus is that XML support needs to be native.
That doesn't settle other issues, like: how much should LyX internals
change to accommodate XML. The approach I'd take would be to adjust
the document on output to m
On 05/09/2013 02:25 PM, Pavel Sanda wrote:
Richard Heck wrote:
On Linux, of course, it is different. One would just expect this library
already to be installed. But things do not work that way on the other OSs.
I belive we should actually _include_ some leightweight library in our sources
so i
he correct way to follow.
He has. The consensus is that XML support needs to be native.
That doesn't settle other issues, like: how much should LyX internals
change to accommodate XML. The approach I'd take would be to adjust
the document on output to match the strict containership requir
Richard Heck wrote:
> On Linux, of course, it is different. One would just expect this library
> already to be installed. But things do not work that way on the other OSs.
I belive we should actually _include_ some leightweight library in our sources
so it is fixed and we do not rely in any versi
On 05/09/2013 01:39 PM, Rob Oakes wrote:
On Thu, May 9, 2013 at 10:52 AM, Richard Heck wrote:
I just had a look at those. He had an XML parser here:
http://www.lyx.org/trac/browser/lyxsvn/lyx-devel/branches/personal/larsbj/xml/src/support/xmlparser.h?rev=19478
but it appears to be based
On Thu, May 9, 2013 at 10:52 AM, Richard Heck wrote:
I just had a look at those. He had an XML parser here:
http://www.lyx.org/trac/browser/lyxsvn/lyx-devel/branches/personal/larsbj/xml/src/support/xmlparser.h?rev=19478
but it appears to be based upon xmlpp, which I cannot get to compile
on
On 05/08/2013 06:24 PM, José Matos wrote:
On Wednesday 08 May 2013 17:43:41 Richard Heck wrote:
Thinking ahead, however: Should we use some SAX library to read the XML? Or
should we just adapt the Lexer for this purpose?
Richard
Lars had that working for a previous version of lyx with lexer
>
> I have started to think seriously about moving to XML for LyX's native
> file format. I doubt that we will want to do this for 2.1, as it is too
> late, really, so I am thinking about doing it for some time early in the
> 2.2 cycle, which means starting now.
>
First
Reading will be easier, I think, for the reasons I've described before.
Also, you could use lyx2xml to write so you can test the read path, but I
don't know of an xml2lyx tool you could use for the reverse.
Just my 2c.
On Wednesday 08 May 2013 17:43:41 Richard Heck wrote:
> Thinking ahead, however: Should we use some SAX library to read the XML?
> Or should we just adapt the Lexer for this purpose?
>
> Richard
Lars had that working for a previous version of lyx with lexer. His branches
are still
I have started to think seriously about moving to XML for LyX's native
file format. I doubt that we will want to do this for 2.1, as it is too
late, really, so I am thinking about doing it for some time early in the
2.2 cycle, which means starting now.
My plan is first to write rou
On Mon, 4 Oct 2010 07:49:26 +0200
>> "Jürgen" == Jürgen Spitzmüller wrote:
Jürgen> LaTeX3 is a new macro collection (so it aims to replace
Jürgen> LateX2e and is comparable to ConTeXt).
Ahh...I got this one now. Thanks.
btw, is it comparable in the sense of being more complete than LateX2e
Gour D. wrote:
> btw, is it comparable in the sense of being more complete than LateX2e
> preventing clashes between different packages or just 'another macro
> package' ?
I'm not so much into the internals of latex3 development. I think they try to
generally overcome some fundamental limitations
Gour D. wrote:
> OT: Can someone explain me what is the aim of latex-3 development in
> the light of LuaTeX or LuaTeX will be just another implementation?
LaTeX3 is a new macro collection (so it aims to replace LateX2e and is
comparable to ConTeXt). LuaTeX is a processor (such as XeTeX or PDFTeX
nning team.
Now, I've discovered this thread about XML as LyX's native format...
Peter> I would prefer a more readable format than XML like json, even I
Peter> would use Lua, because it is the future scripting languange in
Peter> LaTeX, but I assume we could never explain the rest
Sam Liddicott wrote:
> Thanks - you give me good hope.
> It is ironic that I want to use Lyx to avoid having to know docbook too
> well, but may have to learn it to fixup lyx!
we are waiting for your mail :)
pavel
good luck these days.
If that is no longer true, I'd be glad to know!
It is still true.
its not maintained, but it should work. the problem is that it outputs
docbook sgml, version 4.x. if i understand correctly transforming
it into docbook xml is oneliner patch in lyx sources. wha
Sam Liddicott wrote:
>> I would prefer a more readable format than XML like json, even I would
>> use Lua, because it is the future scripting languange in LaTeX, but
>> I assume we could never explain the rest of the world, why we we don't
>> use beloved XML. So let&#x
ng told that it wasn't supported and that if it
> > still worked it was pretty much by good luck these days.
>
> > If that is no longer true, I'd be glad to know!
>
> It is still true.
its not maintained, but it should work. the problem is that it outputs
doc
On 2010-06-08, Sam Liddicott wrote:
> This is a multi-part message in MIME format.
> --050502020101020702060201
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> On 08/06/10 15:27, Pavel Sanda wrote:
>> Sam Liddicott wrote:
>>> I also s
/2010 03:27 PM, Vincent van Ravesteijn wrote:
What is the current status or thinking of the XML format for lyx 2?
Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.
As far as I know, we didn't really decide when and how to d
> >>> On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote:
> >>>
> >>>>> What is the current status or thinking of the XML format for lyx 2?
> >>>>>
> >>>>>
> >>>> Ideally, LyX 2 wo
XML format for lyx 2?
Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.
As far as I know, we didn't really decide when and how to do the transition.
I worked recently with JSon format (www.json.org), cl
Am Dienstag, den 08.06.2010, 20:52 +0200 schrieb Andre Poenitz:
> On Tue, Jun 08, 2010 at 04:29:21PM +0200, Abdelrazak Younes wrote:
> > On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote:
> > >>What is the current status or thinking of the XML format for lyx 2?
> > &
On Tue, Jun 08, 2010 at 04:29:21PM +0200, Abdelrazak Younes wrote:
> On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote:
> >>What is the current status or thinking of the XML format for lyx 2?
> >>
> >Ideally, LyX 2 would have an XML file format. However, no-one is
On 08/06/10 15:29, Abdelrazak Younes wrote:
On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote:
What is the current status or thinking of the XML format for lyx 2?
Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.
As far as
On 08/06/10 15:27, Pavel Sanda wrote:
Sam Liddicott wrote:
I also still dream about lyx being the first decent docbook editor.
are you aware of the fact that lyx already have output routines for docbook?
Yes, but I recall being told that it wasn't supported and that if it
still worked it wa
On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote:
What is the current status or thinking of the XML format for lyx 2?
Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.
As far as I know, we didn't really decide
Sam Liddicott wrote:
> I also still dream about lyx being the first decent docbook editor.
are you aware of the fact that lyx already have output routines for docbook?
pavel
On 08/06/10 14:27, Vincent van Ravesteijn wrote:
What is the current status or thinking of the XML format for lyx 2?
Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.
As far as I know, we didn't really decide when and h
> What is the current status or thinking of the XML format for lyx 2?
>
Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.
As far as I know, we didn't really decide when and how to do the transition.
Are you intereste
What is the current status or thinking of the XML format for lyx 2?
Sam
--
*Sam's signature*
Guenter Milde wrote:
> Thanks for this tip.
>
> However, trying this in the minibuffer of my LyX 1.6.5, with a lyx file
> from my home dir, I did get no reaction from LyX (except mirroring the
> command in the status bar) and the line
>
> Das Verzeichnis ist nicht lesbar.
>
> (The directory
s with locate to search the whole system:
grep my-pattern `locate *path-pattern*lyx`
...
> Anyway, I think an XML file-format would almost certainly preserve the
> "grep" ability, and within certain boundaries I guess also a
> regex-based replace.
I even think a properly wr
On 2010-02-03, Pavel Sanda wrote:
> Guenter Milde wrote:
>> This is why I would greatly welcome improved support for external
>> editing of the lyx source:
>> * open file of current buffer in a configurable application,
>> reload buffer once this application is closed.
> i feel this is task for
Guenter Milde wrote:
> This is why I would greatly welcome improved support for external
> editing of the lyx source:
>
> * open file of current buffer in a configurable application,
> reload buffer once this application is closed.
i feel this is task for only very advanced users and we shouldn
oked at a LyX document in VI. The LyX native file
format is simple, easily understandable and parsable, and you can recover all
styles. It would be trivial to write an app to convert LyX code to XML."
Never underestimate the power and desirability of a native format that's
readable, parseable and writeable.
SteveT
Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt
code base, however it will
involve having LyX load all the files one by one, and doing the search,
something which -- as said -- will be much slower than a grep. Anyway, I
think an XML file-format would almost certainly preserve the "grep"
ability, and within certain boundaries I gues
On 2010-02-02, Tommaso Cucinotta wrote:
> Guenter Milde wrote:
>> This is why I would greatly welcome improved support for external
>> editing of the lyx source:
>> * open a lyx file in LyX and jump to a specified place/line, so that I
>> can easily go to `grep` results or the place I have been
Guenter Milde wrote:
This is why I would greatly welcome improved support for external
editing of the lyx source:
* open a lyx file in LyX and jump to a specified place/line, so that I
can easily go to `grep` results or the place I have been editing in
my valued text editor.
such use-case
On 2010-02-01, Steve Litt wrote:
> On Monday 01 February 2010 05:24:30 Vincent van Ravesteijn - TNW wrote:
>> >OK, I guess my question is this: If LyX were using
>> >LuaTex, what would my LyX document look like in Vim?
>> I'd rather make sure you won't need vim anymore :).
> That's not gonna wor
Steve Litt wrote:
> In that case I have no opinion on LuaTeX because it doesn't affect me.
Note that, if we gonna support luatex, it will be supported as just another
backend (next to latex and xetex).
Jürgen
On Monday 01 February 2010 05:25:14 Jürgen Spitzmüller wrote:
> Steve Litt wrote:
> > OK, I guess my question is this: If LyX were using LuaTex, what would my
> > LyX document look like in Vim?
>
> A LuaTeX backend would not affect the content of the LyX file, apart from
> some
>
> \use_luatex
On Monday 01 February 2010 05:24:30 Vincent van Ravesteijn - TNW wrote:
> >OK, I guess my question is this: If LyX were using
> >LuaTex, what would my LyX document look like in Vim?
>
> I'd rather make sure you won't need vim anymore :).
>
> Vincent
That's not gonna work. One of my reasons for
>OK, I guess my question is this: If LyX were using
>LuaTex, what would my LyX document look like in Vim?
I'd rather make sure you won't need vim anymore :).
Vincent
Steve Litt wrote:
> OK, I guess my question is this: If LyX were using LuaTex, what would my
> LyX document look like in Vim?
A LuaTeX backend would not affect the content of the LyX file, apart from some
\use_luatex 1
statement.
Jürgen
On Monday 01 February 2010 04:06:17 Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
> > > On Friday 29 January 2010 18:41:57 Peter Kümmel wrote:
> > >> Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
> > >
> > > This example has no content. I'd be interested to see a real LuaTeX
> > >
Guenter Milde wrote:
> > On Friday 29 January 2010 18:41:57 Peter Kümmel wrote:
> >> Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
> >
> > This example has no content. I'd be interested to see a real LuaTeX
> > document in its native format.
>
> AFAIK LuaTeX is an engine (TeX to PDF
On 2010-01-30, Steve Litt wrote:
> On Friday 29 January 2010 18:41:57 Peter Kümmel wrote:
>> Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
> This example has no content. I'd be interested to see a real LuaTeX
> document in its native format.
AFAIK LuaTeX is an engine (TeX to PDF con
On Sunday 31 January 2010 10:31:37 Stefano Franchi wrote:
> >So please, don't be shy, show me an example of this format :-)
>
> A couple of examples from the ConTeXt wiki:
>
> http://wiki.contextgarden.net/User:Luigi.scarso#Luatex_examples
>
>
>
>
> S.
That's some pretty ugly stuff. It would
>
>So please, don't be shy, show me an example of this format :-)
>
A couple of examples from the ConTeXt wiki:
http://wiki.contextgarden.net/User:Luigi.scarso#Luatex_examples
S.
>SteveT
>
>Steve Litt
>Recession Relief Package
>http://www.recession-relief.US
>Twitter: http://www.twitter.co
>
> So please, don't be shy, show me an example of this format :-)
>
> SteveT
>
It's really hard to find some examples!
Seems thy need a better marketing ;)
But there is a German blog with some code snips
http://www.luatex.de/
And find attached a luatex file from
http://code.google.com/p/min
>> >> Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
> >> >> > Hi Peter,
> >> >> >
> >> >> > As a LyX user who often parses LyX native code in documents,
> >> >> > programmatically writes LyX native code
>> > Hi Peter,
>> >> >
>> >> > As a LyX user who often parses LyX native code in documents,
>> >> > programmatically writes LyX native code, and uses Vim to change LyX
>> >> > native code, I have the same reservations about lua a
> As a LyX user who often parses LyX native code in documents,
> >> > programmatically writes LyX native code, and uses Vim to change LyX
> >> > native code, I have the same reservations about lua as I do with XML
> >> > -- it might make my job as a user a lo
On Fri, Jan 29, 2010 at 08:41:52PM -0500, John Levon wrote:
> On Fri, Jan 29, 2010 at 11:18:02PM +0100, Peter Kümmel wrote:
>
> > Again, maybe I'm too late, but:
> > Is a switch to XML is really a good idea?
>
> XML is everywhere. That simple.
A lot of stuff that
On Fri, Jan 29, 2010 at 11:18:02PM +0100, Peter Kümmel wrote:
> Again, maybe I'm too late, but:
> Is a switch to XML is really a good idea?
XML is everywhere. That simple.
regards
john
cally writes LyX native code, and uses Vim to change LyX
>> > native code, I have the same reservations about lua as I do with XML --
>> > it might make my job as a user a lot harder. Starting from your link I
>> > tried to find an example of luatex and couldn't.
&g
LyX
> > native code, I have the same reservations about lua as I do with XML --
> > it might make my job as a user a lot harder. Starting from your link I
> > tried to find an example of luatex and couldn't.
> >
> > When the talk turns of embedding LUA within TeX, I s
Am Samstag, den 30.01.2010, 00:30 +0100 schrieb Peter Kümmel:
> just google for these to words. Lua and
> JavaScript are very similar.
First Google hit (here) is
"JSON: The Fat-Free Alternative to XML":
http://www.json.org/xml.html
Peter
Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
>
> Hi Peter,
>
> As a LyX user who often parses LyX native code in documents, programmatically
> writes LyX native code, and uses Vim to change LyX native code, I have the
> same reservations about lua as I do wi
Am Freitag, den 29.01.2010, 17:50 -0500 schrieb rgheck:
> On 01/29/2010 05:18 PM, Peter Kümmel wrote:
> > Again, maybe I'm too late, but:
> > Is a switch to XML is really a good idea?
> >
> > The XML hype is over, we don't use Java, LyX
> > doesn't
On 01/29/2010 05:18 PM, Peter Kümmel wrote:
Again, maybe I'm too late, but:
Is a switch to XML is really a good idea?
The XML hype is over, we don't use Java, LyX
doesn't run on a Application-Server, and we
live now in a App/web-app world where Json
is more common than XML.
An
On Friday 29 January 2010 17:18:02 Peter Kümmel wrote:
> Again, maybe I'm too late, but:
> Is a switch to XML is really a good idea?
>
> The XML hype is over, we don't use Java, LyX
> doesn't run on a Application-Server, and we
> live now in a App/web-app world
Again, maybe I'm too late, but:
Is a switch to XML is really a good idea?
The XML hype is over, we don't use Java, LyX
doesn't run on a Application-Server, and we
live now in a App/web-app world where Json
is more common than XML.
And living in the Latex world this means we sho
On Monday 25 January 2010 12:44:23 rgheck wrote:
> >
> > Using this idea the first step should probably be to swap the
> > meta-characters, for the current lyx format we have the backslash and
> > for xml we have the three characters you mentioned.
> >
> > T
On 01/22/2010 01:42 PM, José Matos wrote:
On Tuesday 19 January 2010 20:11:56 rgheck wrote:
While just beginning to think about xml, it occurred to me that probably
the first thing we have to do is modify the read and write routines so
that they write entities for&,<, and>, at w
On Tuesday 19 January 2010 20:11:56 rgheck wrote:
> While just beginning to think about xml, it occurred to me that probably
> the first thing we have to do is modify the read and write routines so
> that they write entities for &, <, and >, at which point we'll need
&g
Am 19.01.2010 um 21:11 schrieb rgheck:
On 01/13/2010 01:36 PM, José Matos wrote:
Hi all,
I would like to start working on the goal of having lyx with an xml
file
format.
While just beginning to think about xml, it occurred to me that
probably
the first thing we have to do is modify
On 01/13/2010 01:36 PM, José Matos wrote:
Hi all,
I would like to start working on the goal of having lyx with an xml file
format.
While just beginning to think about xml, it occurred to me that probably
the first thing we have to do is modify the read and write routines so
that they
On 01/15/2010 08:02 AM, Steve Litt wrote:
On Friday 15 January 2010 07:34:02 Philiрp Rеichmuth wrote:
Am Fri, 15 Jan 2010 10:28:10 + (UTC) schrieb Guenter Milde:
If ever we want to switch to a XML like math format, it should use
Unicode where available. For an incremental
On Friday 15 January 2010 07:34:02 Philiрp Rеichmuth wrote:
> Am Fri, 15 Jan 2010 10:28:10 + (UTC) schrieb Guenter Milde:
> > If ever we want to switch to a XML like math format, it should use
> > Unicode where available. For an incremental transition, we could use
> > U
Am Fri, 15 Jan 2010 10:28:10 + (UTC) schrieb Guenter Milde:
> If ever we want to switch to a XML like math format, it should use
> Unicode where available. For an incremental transition, we could use
> Unicode chars in LaTeX format right now.
I think this is a fundamentally bad id
e point of writing Unicode to the LyX file, only
> to have to translate it back.
If ever we want to switch to a XML like math format, it should use
Unicode where available. For an incremental transition, we could use
Unicode chars in LaTeX format right now.
Günter
On 01/14/2010 05:28 PM, Guenter Milde wrote:
On 2010-01-14, rgheck wrote:
On 01/14/2010 03:05 AM, Guenter Milde wrote:
We could consider using Unicode characters for LaTeX macros which are
supported by our 'unicodesymbols' file, e.g. β for \beta and ∫ for \int.
Here again
On 2010-01-14, rgheck wrote:
> On 01/14/2010 03:05 AM, Guenter Milde wrote:
>> We could consider using Unicode characters for LaTeX macros which are
>> supported by our 'unicodesymbols' file, e.g. β for \beta and ∫ for \int.
> Here again, unless we're proposing to write \beta as β and then read
Steve Litt wrote:
On Thursday 14 January 2010 09:13:04 Abdelrazak Younes wrote:
rgheck wrote:
On 01/13/2010 01:36 PM, José Matos wrote:
- how to proceed in the mean time?
+ using an iterative approach we will have a file that will be
xml-ized by
parts
I think
On Thursday 14 January 2010 09:13:04 Abdelrazak Younes wrote:
> rgheck wrote:
> > On 01/13/2010 01:36 PM, José Matos wrote:
> >>- how to proceed in the mean time?
> >> + using an iterative approach we will have a file that will be
> >> xml-iz
rgheck wrote:
On 01/13/2010 01:36 PM, José Matos wrote:
- how to proceed in the mean time?
+ using an iterative approach we will have a file that will be
xml-ized by
parts
I think the incremental approach will actually be much less intrusive
than it might at first seem, and some
rgheck wrote:
Anyway, for now, it seems to me, we should leave math alone and just
do the boring thing I suggested earlier:
a+b=2^x
That's the best option indeed.
Abdel.
On 01/14/2010 03:05 AM, Guenter Milde wrote:
On 2010-01-13, Andre Poenitz wrote:
Try to use the 'layout oriented' bits of MathML and invent our own for
the few cases where there is no clean match.
I suggest keeping math in LaTeX format (inside a
tag). (This can be changed later, if th
One other thought about the format.
In thinking about this, it occurred to me that there might be reasons to
have different tags for different sorts of insets. E.g.:
This would save the need to do some long switch on the "type" before we
can figure out where to go next. All the command ins
That is, unless you think that there is a pressing need to change the
way math is represented, a need that is part of what is driving the
change to XML.
And perhaps another thing to say here is that any XML-like
representation of math will definitely make sed-like script processing
of LyX files harder.
Richard
rgheck wrote:
On 01/14/2010 05:18 AM, Pavel Sanda wrote:
Steve Litt wrote:
How does one tell what version of Qt is on his computer?
package manager of the distribution you use will tell.
Or launch qtconfig-qt4 and go to Help>About Qt.
Or "qmake -v"
Abdel.
On 01/14/2010 05:18 AM, Pavel Sanda wrote:
Steve Litt wrote:
How does one tell what version of Qt is on his computer?
package manager of the distribution you use will tell.
Or launch qtconfig-qt4 and go to Help>About Qt.
rh
Pavel Sanda writes:
> Steve Litt wrote:
>> How does one tell what version of Qt is on his computer?
>
> package manager of the distribution you use will tell.
Or the command "lyx -version".
JMarc
Steve Litt wrote:
> How does one tell what version of Qt is on his computer?
package manager of the distribution you use will tell.
pavel
because while its acceptible that we have multiple ifdefs which
fixes changing
behaviour of Qt in UI it would be really nightmare if we read/
write .lyx file
wrongly because the shiny new qt version contains some unfortunate
bug. this
kind of stability seems to me as critical enough to contai
101 - 200 of 580 matches
Mail list logo
