Lothar M. Schmitt wrote:
> "I've no idea what the problem is."
>
> If that is the case, you should not act.
Yes, he should; there is no point to have milion unresolvable bugs open. Your
report is very unsufficient and you do not react to our questions. In such case
there is no way how to help you
hing for embedded TeX-Makros in Lyx
> 1.6.3 on a recent Mac
> To: l...@lmschmitt.de, nob...@lyx.org
> Cc: quietbritish...@yahoo.co.uk
> Date: Tuesday, December 22, 2009, 2:45 AM
> #6196: Formulae show nothing for
> embedded
>Working with fedora 11 an a x86_64 architecture, lyx
>crashes every time that I browse the document. It
>looks like that it is due to the pictures.
This is a bug in qt4.5.[0,2].
See bug #5957: http://www.lyx.org/trac/ticket/5957.
This happens when you scale the image to 1,2,5,10,20,25 or 50%
Hello,
Working with fedora 11 an a x86_64 architecture, lyx crashes every time
that I browse the document. It looks like that it is due to the pictures.
They are in a separated directory and compressed with gzip.
1) When I try to select the picture, it works fine, but them lyx
complains: "file no
Hi all,
Before entering a bug report, I thought I'd check and see if this is a
known phenomenon (since I've seen other reports of issues with recent
versions of Qt).
In LyX 1.6.3-1 on Win XP, with the LyX window maximized (and with or
without a document open), if I change anyth
W. Bentley MacLeod wrote:
> Many thanks this worked! Many thanks for posting this to the suse repos.
>
> I notice that I still have the pdf/dvi menu shooting off to the right when
> I move it up one (each time I open lyx I have to drag it back to the left
> to see it completely.)
This will change
b.
Professor W. Bentley MacLeod
Columbia University in the City of New York, NY 10027
http://www.columbia.edu/~wbm2103/
On Thu, 11 Jun 2009, Jürgen Spitzmüller wrote:
W. Bentley MacLeod wrote:
However, I tried to install lyx 1.6.3 on my
W. Bentley MacLeod wrote:
> However, I tried to install lyx 1.6.3 on my opensuse 11.1 system and it
> did not work? I have kde 4.2.3 installed and had to reinstall lyx 1.6.2
> to get my system running again.
How did you install it (i.e., where did you get the binary)?
I'd recommen
SW
- more compatible with latex and lots of useful features.)
However, I tried to install lyx 1.6.3 on my opensuse 11.1 system and it
did not work? I have kde 4.2.3 installed and had to reinstall lyx 1.6.2
to get my system running again.
many thanks in advance.
bm
Georg Baum wrote:
> > i just grep -i thread of our sources and havent seen a single occurence of
> > thread related code. can't this introduce some performance penalties?
>
> In theory yes. In practice I don't think so, qt is not available without
> thread support since version 4, and the single t
Pavel Sanda wrote:
> Georg Baum wrote:
>> That depends. If the subset of boost that LyX uses is inherently
>> threadsafe, or if LyX does not use boost in two threads at the same time,
>> it could work
>
> i just grep -i thread of our sources and havent seen a single occurence of
> thread related
Georg Baum wrote:
> That depends. If the subset of boost that LyX uses is inherently threadsafe,
> or if LyX does not use boost in two threads at the same time, it could work
i just grep -i thread of our sources and havent seen a single occurence of
thread
related code. can't this introduce some
Georg Baum wrote:
> > So let's wait. If we put the patch in early in the 1.6.4 cycle, we have
> > at least the chance to test it.
>
> I put it in now.
OK, thanks. So external-boost people, please give it a try.
Jürgen
Pavel Sanda wrote:
> Georg Baum wrote:
>> I don't know what happens if you
>> link against a true single threaded boost, you might be lucky, or get
>> spurious problems at runtime).
>
> btw are we supposed to link against the multithreaded version? i just
> checked that i have 1.6 linked against
Public release of LyX version 1.6.3
===
We are pleased to announce the release of LyX 1.6.3. This is the third
maintenance release in the 1.6.x series. Besides the usual improvements
of stability, the highlights of this release are:
* tex2lyx is now able to read
Uwe Stöhr schrieb:
The MikTeX developer is not willing to fix this since it is not his
fault. So I have to contact the author of the file "hyph-es.tex".
MiKTeX works now again:
http://article.gmane.org/gmane.comp.tex.ctan.announce/6950
regards Uwe
Le 01/06/2009 11:53, Jürgen Spitzmüller a écrit :
I propose to change that to gcc-3.4.x for the time being. If we really manage
to make older compilers work, we can change it back later.
This makes sense.
JMarc
Peter Kümmel wrote:
> The template support of GCC <3.4 is very broken.
> Boost doesn't support GCC < 3.4 it, therefore I don't think
> we could support GCC 3.3 without many changes and #ifdefs.
I see. Actually, we have diverging information anyway. While INSTALL states
that gcc 3.x is required, R
Jürgen Spitzmüller wrote:
>> Yes, the same as I currently also do for JabRef and GSview.
>
> OK, in this case I stick with my initial point of view:
>
> * no specific html format for eLyXer, aLyXer should be checked as one
> alternative HTML export converter.
Here's the patch I propose for 1.6.
Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:
>>> Stephan Witt wrote:
Personally I prefer to change the LyX source to make it compileable
again.
But I cannot do it, because I don't know enough C++ (templates
stuff etc.).
If nobody changes that I think the requ
Jean-Marc Lasgouttes wrote:
> > Stephan Witt wrote:
> >> Personally I prefer to change the LyX source to make it compileable
> >> again.
> >> But I cannot do it, because I don't know enough C++ (templates
> >> stuff etc.).
> >> If nobody changes that I think the requirements should be updated.
Georg Baum wrote:
> I learned that Sven Hoexter has already a workaround, so I believe it can
> wait for 1.6.4.
So let's wait. If we put the patch in early in the 1.6.4 cycle, we have at
least the chance to test it.
Jürgen
Jürgen Spitzmüller wrote:
> So if nobody comes up with really severe issues, I plan to release LyX
> 1.6.3 on June 1.
I will need one or two days more to sort out some remaining issues.
Jürgen
Georg Baum wrote:
> I don't know what happens if you
> link against a true single threaded boost, you might be lucky, or get
> spurious problems at runtime).
btw are we supposed to link against the multithreaded version? i just checked
that i have 1.6 linked against single threaded boost here. wha
On Tue, May 26, 2009 at 11:23:56PM +0200, Pavel Sanda wrote:
> Sven Hoexter wrote:
> > I don't know what other distributions currently do with relation to the
> > boost
> > changes. At least Fedora seems to provide the single threaded version with
> > the old naming and the multi threaded version
Jürgen Spitzmüller writes:
> Georg Baum wrote:
>> > A short message: I think we are ready.
>>
>> What about this small fix for external boost detection?
>
> Since I do not feel competent for the build stuff, I'd like to hear someone
> else's (JMarc's?) take on this.
I do not have much ideas at
Richard heck writes:
> I don't think JMarc and I really know quite what to do yet. This is in
> part because tex2lyx does not produce a suitable format. Until it
> does
I thought you would try to backport some of the code from trunk... This
is enough for this bug AFAIR.
JMarc
Uwe Stöhr schrieb:
configure.py breaks at this check:
checking LaTeX configuration... default values
+checking list of textclasses...
Layout file C:/Program Files (x86)/LyX
1.6.3/bin/../Resources\layouts\manpage.layout has no \DeclareXXClass line.
done
Can anybody please take
Georg Baum wrote:
>>> What about this small fix for external boost detection?
>>
>> Since I do not feel competent for the build stuff, I'd like to hear
>> someone else's (JMarc's?) take on this.
>>
>> In any case, at this stage in the cycle, this should only go in if we are
>> really sure it doe
I just noticed that I can no longer export to any PDF format. I therefore reconfigured LyX but
configure.py breaks at this check:
checking LaTeX configuration... default values
+checking list of textclasses...
Layout file C:/Program Files (x86)/LyX 1.6.3/bin/../Resources\layouts
Sven Hoexter wrote:
> I don't know what other distributions currently do with relation to the boost
> changes. At least Fedora seems to provide the single threaded version with
> the old naming and the multi threaded version in the same package.
please can you be more verbose about the whole issue
On Tue, May 26, 2009 at 10:02:12PM +0200, Georg Baum wrote:
Hi,
> I learned that Sven Hoexter has already a workaround, so I believe it can
> wait for 1.6.4.
I'm just adding the -mt suffix in all .in and the common.am file. This
doesn't ensure any portability it just keeps it building on the cur
Jürgen Spitzmüller wrote:
> Georg Baum wrote:
>> What about this small fix for external boost detection?
>
> Since I do not feel competent for the build stuff, I'd like to hear
> someone else's (JMarc's?) take on this.
>
> In any case, at this stage in the cycle, this should only go in if we ar
On Mon, 25 May 2009, Alex Fernandez wrote:
Anything wrong with joint distribution?
I don't think so when't it's in Uwe's combined installer.
(In the general case I don't have an opinion, to much work at the
moment:-)
/Christian
PS. Nice that there is/will be a Debian package.
--
Christian
Uwe Stöhr wrote:
> > So what are your plans exactly? The user of your installer can chose
> > whether
>
> > he wants install eLyXer or not?
>
> Yes, the same as I currently also do for JabRef and GSview.
OK, in this case I stick with my initial point of view:
* no specific html format for eLyXer
Guenter Milde wrote:
> A user without eLyXer will not see any change. A user with eLyXer will be
> glad to see the alternative.
I won't repeat myself again. I'm arguing from a developer POV, not a user's.
Jürgen
On 2009-05-23, Jürgen Spitzmüller wrote:
> Kornel Benko wrote:
>> Please no. We would have to change preferences every time if the html
>> output is dissatisfying.
> We have to do this for all other converter alternatives as well.* Why should
> eLyXer be specific?
> * I agree this is annoying, b
On 2009-05-23, Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
>> No, for HTML we have tex4ht, latex2html, hevea and eLyXer. I don't see
>> why eLyXer is different. Either we provide the possibility to chose
>> from all,
+1
>> or none.
> the reason was
> 1. that tex4ht, latex2html, hevea have
> So what are your plans exactly? The user of your installer can chose whether
> he wants install eLyXer or not?
Yes, the same as I currently also do for JabRef and GSview.
regards Uwe
Hi Jean-Marc,
On Sun, May 24, 2009 at 11:30 PM, Jean-Marc Lasgouttes
wrote:
> Actually, I do not see the point of doing it specifically on the Win
> platform.
> I fear this is just going to create more confusion. Is there any reason
> besides
> working around the decision of not including it in L
Le 21 mai 09 à 18:08, Jürgen Spitzmüller a écrit :
Stephan Witt wrote:
Personally I prefer to change the LyX source to make it compileable
again.
But I cannot do it, because I don't know enough C++ (templates
stuff etc.).
If nobody changes that I think the requirements should be updated.
W
Le 23 mai 09 à 16:59, Pavel Sanda a écrit :
i understood that elyxer is going to be installed by default on win
platform.
pavel
Actually, I do not see the point of doing it specifically on the Win
platform.
I fear this is just going to create more confusion. Is there any
reason besides
w
Le 23 mai 09 à 08:03, Jürgen Spitzmüller a écrit :
Kornel Benko wrote:
Please no. We would have to change preferences every time if the html
output is dissatisfying.
We have to do this for all other converter alternatives as well.*
Why should
eLyXer be specific?
+1
JMarc
Uwe Stöhr wrote:
> > Hm. I forgot this (even though Uwe told me just two days ago).
>
> I haven't told you this. eLyXer is not installed by default.
So what are your plans exactly? The user of your installer can chose whether
he wants install eLyXer or not?
> > Actually, this probably is indeed
>> i understood that elyxer is going to be installed by default on win
>> platform.
>
> Hm. I forgot this (even though Uwe told me just two days ago).
I haven't told you this. eLyXer is not installed by default. And even when I deliver it with my
installer as optional program, I guess it won't b
Pavel Sanda wrote:
> > Actually, this probably is indeed an argument for using a separate
> > format. Since otherwise, win people will shout at us with "where is my
> > tex4ht output converter?"
>
> and maybe it would be correct if elyxer installation would be on demand as
> for example ghostview o
Jürgen Spitzmüller wrote:
> > i understood that elyxer is going to be installed by default on win
> > platform.
>
> Hm. I forgot this (even though Uwe told me just two days ago).
>
> Actually, _this_ probably is indeed an argument for using a separate format.
> Since otherwise, win people will s
Pavel Sanda wrote:
> i understood that elyxer is going to be installed by default on win
> platform.
Hm. I forgot this (even though Uwe told me just two days ago).
Actually, _this_ probably is indeed an argument for using a separate format.
Since otherwise, win people will shout at us with "wher
Jürgen Spitzmüller wrote:
> >so the next fight would be whether the first or last one
>
> Probably first. tex4ht is probably the one that's preinstalled, and if
> someone
> installs eLyXer, I'd assume he likes to use it.
i understood that elyxer is going to be installed by default on win platf
Pavel Sanda wrote:
> your are the chief here
Certainly not. I'm just arguing, nothing else.
>so the next fight would be whether the first or last one
Probably first. tex4ht is probably the one that's preinstalled, and if someone
installs eLyXer, I'd assume he likes to use it.
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > i agree here, but the discussion now goes about the branch.
>
> Yes. My take on this is:
your are the chief here, my reasoning is known.
>as long as we do not have a better (general)
> solution, eLyXer is to be handled as any other HTML convert
Pavel Sanda wrote:
> i agree here, but the discussion now goes about the branch.
Yes. My take on this is: as long as we do not have a better (general)
solution, eLyXer is to be handled as any other HTML converter.
This is the "rather than introducing exceptions" part you ommitted in the
quote ;
Jürgen Spitzmüller wrote:
> we should rather aim at a
> general solution
i agree here, but the discussion now goes about the branch.
pavel
Pavel Sanda wrote:
> the reason was
>
> 1. that tex4ht, latex2html, hevea have latex interstage in common so i
> reagarded them as one family. this implies some things you can expect from
> these convertors to be similar.
>
> 2. elyxer seems to have different purpose - it looks to be designed for
>
Jürgen Spitzmüller wrote:
> No, for HTML we have tex4ht, latex2html, hevea and eLyXer. I don't see why
> eLyXer is different. Either we provide the possibility to chose from all, or
> none.
>
> (I know Pavel is of other opinion, but I don't really understand the reasons).
the reason was
1. tha
Uwe Stöhr wrote:
> I forced Pavel to introduce html2 to be consistent with e.g. PDF. For PDF
> there are 3 different programs we support, every one has its own format to
> avoid conflicts and I like this solution. For HTML this is the same, html
> is tex4ht and html2 eLyXer.
No, for HTML we have t
Jürgen Spitzmüller schrieb:
I think eLyXer should not be a separate format (html2) but simply a html
alternative
I forced Pavel to introduce html2 to be consistent with e.g. PDF. For PDF there are 3 different
programs we support, every one has its own format to avoid conflicts and I like this
Georg Baum wrote:
> > A short message: I think we are ready.
>
> What about this small fix for external boost detection?
Since I do not feel competent for the build stuff, I'd like to hear someone
else's (JMarc's?) take on this.
In any case, at this stage in the cycle, this should only go in if
Jürgen Spitzmüller wrote:
> A short message: I think we are ready.
What about this small fix for external boost detection? The debian packagers
discovered that the current detection does not work for boost installations
with default settings anymore: The single threaded versions are not built
any
Kornel Benko wrote:
> Please no. We would have to change preferences every time if the html
> output is dissatisfying.
We have to do this for all other converter alternatives as well.* Why should
eLyXer be specific?
* I agree this is annoying, but this needs a general solution, no eLyXer-
specif
Am Samstag 23 Mai 2009 schrieb Jürgen Spitzmüller:
> Uwe Stöhr wrote:
> > > Post a patch first.
> >
> > See attached.
>
> I think eLyXer should not be a separate format (html2) but simply a html
> alternative
Please no. We would have to change preferences every time if the html output
is dissatis
Uwe Stöhr wrote:
> > Post a patch first.
>
> See attached.
I think eLyXer should not be a separate format (html2) but simply a html
alternative
Jürgen
> Post a patch first.
See attached.
regards Uwe
Index: configure.py
===
--- configure.py (revision 29792)
+++ configure.py (working copy)
@@ -382,6 +382,14 @@
rc_entry = [r'''\converter literate latex "%%" ""
\conve
Uwe Stöhr wrote:
> > Does this fit everybody?
>
> Fine with me.
> I plan to bundle eLyXer with my installer or at least use it if it is
> installed, can therefore the check for eLyXer in configure.py also go to
> branch?
Post a patch first.
Jürgen
> Does this fit everybody?
Fine with me.
I plan to bundle eLyXer with my installer or at least use it if it is installed, can therefore the
check for eLyXer in configure.py also go to branch?
regards Uwe
Jürgen Spitzmüller wrote:
A short message: I think we are ready.
There is still one critical bug (#5046), but I cannot reproduce that ATM.
Also, I think we cannot wait for the tex2lyx module fix any longer.
I don't think JMarc and I really know quite what to do yet. This is in
part because
A short message: I think we are ready.
There is still one critical bug (#5046), but I cannot reproduce that ATM.
Also, I think we cannot wait for the tex2lyx module fix any longer.
So if nobody comes up with really severe issues, I plan to release LyX 1.6.3
on June 1.
Does this fit everybody
Stephan Witt wrote:
> Personally I prefer to change the LyX source to make it compileable again.
> But I cannot do it, because I don't know enough C++ (templates stuff etc.).
> If nobody changes that I think the requirements should be updated.
What compiler version do we require nowadays?
Jürgen
Richard Heck writes:
> Come to think of it, none. The changes, as I recall, were pretty
> large, and we deferred committing to branch at that time. I'll prepare
> a patch for branch, but I won't have time until later this week.
OK.
> OK. Maybe an even simpler, brute force solution would be just
Jean-Marc Lasgouttes wrote:
rgheck writes:
I did the necessary infrastructure bits, but I'll at least need a lot
of help on the tex2lyx part. I don't know anything about tex2lyx, at
this point, anyway.
What part of it is in branch, BTW?
Come to think of it, none. The changes, as I
rgheck writes:
> I did the necessary infrastructure bits, but I'll at least need a lot
> of help on the tex2lyx part. I don't know anything about tex2lyx, at
> this point, anyway.
What part of it is in branch, BTW?
> Perhaps some conversation about how to approach the problem would help.
I woul
Jürgen Spitzmüller wrote:
Enrico Forestieri wrote:
There is a patch attached to the bug. The accompanying comment got lost
in the transition to trac. Essentially, all $...$ occurring in math are
translated to \ensuremath{...}. This avoids nested math hulls and thus
the cause of the crash. I t
Enrico Forestieri wrote:
> There is a patch attached to the bug. The accompanying comment got lost
> in the transition to trac. Essentially, all $...$ occurring in math are
> translated to \ensuremath{...}. This avoids nested math hulls and thus
> the cause of the crash. I think that this is a good
On Fri, May 08, 2009 at 12:33:35PM +0200, Jürgen Spitzmüller wrote:
> #5392 Assertion in InsetMathGrid
There is a patch attached to the bug. The accompanying comment got lost
in the transition to trac. Essentially, all $...$ occurring in math are
translated to \ensuremath{...}. This avoids neste
Jürgen Spitzmüller wrote:
#5888 Repeatable crash when pressing space while cursor out of view
I think this is a must-fix. Vincent had a kind of fix at one point, if I
remember, but I don't know if it was the proper fix.
Also, I think this is a severe issue:
#5702 tex2lyx cannot deal
On Fri, May 8, 2009 at 3:04 PM, Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn - TNW wrote:
> > In short, I think we should backport these before 1.6.3.
>
> I think I should keep you motivated ...
>
> Go ahead.
wise decision ;-)
Abdel.
Vincent van Ravesteijn - TNW wrote:
> In short, I think we should backport these before 1.6.3.
I think I should keep you motivated ...
Go ahead.
Jürgen
>Actually, I'd like to focus on severe issues now. None of these are really
>urgent, right?
>
>jürgen
I think these issues are pretty severe:
* Handle autosave files of unnamed documents correctly:
(dataloss)
* Bug #5131: Remember last file active.
(very annoying, frustrating, amateurish)
Stephan Witt wrote:
> Personally I prefer to change the LyX source to make it compileable again.
> But I cannot do it, because I don't know enough C++ (templates stuff etc.).
Me too (both)
> If nobody changes that I think the requirements should be updated.
Yes. Maybe someone has an idea.
Jürge
Jürgen Spitzmüller schrieb:
OK, I think it's time to think about another release.
We have already fixed several issues and we are almost ready, AFAICS.
Hello Jürgen,
I don't know if it's a several issue...
Some time ago I tried to build LyX on SLES9 with the system compiler
[gcc version 3.3.
Vincent van Ravesteijn - TNW wrote:
> * Fix some toc ui glitches:
> http://www.lyx.org/trac/changeset/29477
>
> * Bind M-plus(M-equal) and M-minus to buffer-zoom-in/out.
> http://www.lyx.org/trac/changeset/29208
These two, however, look straightforward enough.
Jürgen
Vincent van Ravesteijn - TNW wrote:
> I've the following issues that I still would like to solve in branch:
>
> * Bug #5131: Remember last file active.
> http://www.lyx.org/trac/changeset/29546
>
> * Revision r29532: Close tabs in reverse order.
> http://www.lyx.org/trac/changeset/29539
> This remo
>Please let me know if you think there are other issues that should be
>considered for 1.6.3.
>
>Jürgen
I've the following issues that I still would like to solve in branch:
* Bug #5131: Remember last file active.
http://www.lyx.org/trac/changeset/29546
* Revision r29532: Close tabs in reverse
>Please let me know if you think there are other issues that should be
>considered for 1.6.3.
>
>Jürgen
I've the following issues that I still would like to solve in branch:
* Bug #5131: Remember last file active.
http://www.lyx.org/trac/changeset/29546
* Revision r29532: Close tabs in reverse
Vincent van Ravesteijn - TNW wrote:
> >this one?
> >
> >http://www.lyx.org/trac/changeset/29498/lyx-devel/trunk
> >
> >working with child documents is a pain here...
> >
> >ed.
>
> It's already in (since yesterday).
And it was on my list of must-fixes.
Jürgen
vincent wrote:
> It's already in (since yesterday).
good news, thanks...
ed.
>jürgen wrote:
>> OK, I think it's time to think about another release.
>> Please let me know if you think there are other issues that should be
>> considered for 1.6.3.
>
>this one?
>
>http://www.lyx.org/trac/changeset/29498/lyx-devel/trunk
>
>working with child documents is a pain here...
>
>e
jürgen wrote:
> OK, I think it's time to think about another release.
> Please let me know if you think there are other issues that should be
> considered for 1.6.3.
this one?
http://www.lyx.org/trac/changeset/29498/lyx-devel/trunk
working with child documents is a pain here...
ed.
OK, I think it's time to think about another release.
We have already fixed several issues and we are almost ready, AFAICS.
Here are the critical issues I'm aware of. Is anybody planning to work on
(some of) these?
#5046 shift select makes lyx assert when cursor follow scrollbar is enabled
#5
89 matches
Mail list logo
