Jürgen Spitzmüller wrote:
> This patch needs to go to trunk and branch.
OK for 2.1-staging?
Jürgen
On Mon, Jul 8, 2013 at 2:06 AM, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
>> I would expect it, yes. But there are some discussions about Apply/OK
>> behavior of diverse inset dialogs on trac.
>
> Actually, this one is also reported:
> http://www.lyx.org/trac/ticket/3964
Thanks for d
Jürgen Spitzmüller wrote:
> I would expect it, yes. But there are some discussions about Apply/OK
> behavior of diverse inset dialogs on trac.
Actually, this one is also reported:
http://www.lyx.org/trac/ticket/3964
Jürgen
Scott Kostyshak wrote:
> If you go to Insert Citation, click on an available citation, click on
> add, and then click on apply, it inserts the citation. If you click on
> OK, it again inserts the citation.
>
> Similarly, if you click on "apply" multiple times, it inserts the
> citation each time.
The knowledgeable egreg gives advice about what packages to load when
using Greek and a lot depends on how new the TeX distribution is:
http://tex.stackexchange.com/questions/122992/classic-thesis-lyx-language-problem
Currently, LyX outputs this in the preamble for Greek:
\documentclass[greek]{a
Six advanced find tests are failing for me on master:
findadv-18
findadv-19
findadv-re-01
findadv-re-02
findadv-re-03
findadv-re-05
I remember that sometimes tests would pass for Tommaso but not for me
and Kornel under CMake but I thought we solved this issue.
What do others see?
Scott
On Sun, Jul 7, 2013 at 4:14 PM, Scott Kostyshak wrote:
> I never got this error when I was on Ubuntu 12.04 so perhaps the
> change to 13.04 and the new versions of libraries lead to this? I can
> reproduce this error on a fresh 13.04 install.
I just tested on Ubuntu 12.04 (although not a fresh i
If you go to Insert Citation, click on an available citation, click on
add, and then click on apply, it inserts the citation. If you click on
OK, it again inserts the citation.
Similarly, if you click on "apply" multiple times, it inserts the
citation each time.
Is this the expected behavior? Thi
On Sat, Jul 6, 2013 at 4:11 AM, Jürgen Spitzmüller wrote:
> Scott Kostyshak wrote:
>> I have
>> made three suggestions on the ticket for how to address the situation.
>> Of the three, my two preferred solutions are:
>>
>> (a) move the templates to examples
>> (b) change the relative paths to hard-
Vincent van Ravesteijn wrote:
> -You can download LyX 2.0.0 from http://www.lyx.org/Download/.
> +You can download LyX 2.1.0beta1 from http://www.lyx.org/Download/.
We shouldn't put it immediatelly into main Download page.
Usually it went just somewhere in ftp devel directories.
Pavel
Op 7-7-2013 22:14, Scott Kostyshak schreef:
In Chromium or Firefox, when I go to http://www.lyx.org and right
click on intro.png and go to "copy image" and then go to LyX and
paste, nothing is pasted (although "paste" shows up in LyX's message box).
This is indeed a difference between 2.0 and
On Sun, Jul 7, 2013 at 4:15 PM, Vincent van Ravesteijn wrote:
> Op 7-7-2013 10:04, Kornel Benko schreef:
>
> Am Sonntag, 7. Juli 2013 um 02:47:20, schrieb Scott Kostyshak
>
>
>> On Ubuntu 13.04:
>
>>
>
>> FindQt4.cmake gets confused when I have qt5 libraries installed (even
>
>> if I have qt4 lib
Op 7-7-2013 10:04, Kornel Benko schreef:
Am Sonntag, 7. Juli 2013 um 02:47:20, schrieb Scott Kostyshak
> On Ubuntu 13.04:
>
> FindQt4.cmake gets confused when I have qt5 libraries installed (even
> if I have qt4 libraries installed also).
> for qmake (or maybe I'm wrong).
Ideally qmake
I get the following build error when CMake detects that I have the
required packages to build xvkbd:
/usr/bin/ld: CMakeFiles/xvkbd.dir/findwidget.c.o: undefined reference
to symbol '_XEditResGet16'
/usr/bin/ld: note: '_XEditResGet16' is defined in DSO
/usr/lib/x86_64-linux-gnu/libXmu.so.6 so try a
On Sun, Jul 7, 2013 at 4:32 AM, Georg Baum
wrote:
> Sorry, it is finally summer here, so I had to spend more time outside:-)
Same here, except that 37 C means that some days I spend less time outside :)
> Today I had a look, but could not reproduce your problem. I also changed the
> preference
On Sun, Jul 7, 2013 at 4:04 AM, Kornel Benko wrote:
> FindQt4.cmake is a copy of the cmake-provided module. (Very outdated
> version).
>
> As I understood from the cmake-list, the new module should handle the case
> of
>
> simultaneously installed qt4+qt5.
>
>
>
> I am not sure, if this module ne
Jürgen Spitzmüller wrote:
> Please report those cases. They need to be fixed (the lyx2lyx conversion is
> pretty complex too, so I really rely on testing and feedback, as stated many
> times before).
I'll try to report my problems in more detail as time permits... P
Perhaps you are looking for this
http://comments.gmane.org/gmane.editors.lyx.devel/142638
P
The only answer to my question "Why would anyone want to keep closed
documents in the memory ?" is that if you have a master, you might want
to hide it. But that was already possible.
Is there actually
Richard Heck wrote:
>> Basically, what I did was to add a new parameter to
>> SystemcallPrivate::startProcess() to tell if we should detach. If so, I'm
>> calling QProcess::startDetached instead of QProcess::start().
>
> Who knows this code well enough to comment?
Enrico?
> Richard
>
Vincent van Ravesteijn wrote:
> I'm now editing the release notes, and I stumbled over this feature that I
> didn't notice before.
Perhaps you are looking for this
http://comments.gmane.org/gmane.editors.lyx.devel/142638
P
Can someone explain to me why we have this new feature ? Why would
anyone want to keep closed documents in the memory ?
I'm now editing the release notes, and I stumbled over this feature that
I didn't notice before.
Vincent
Am 07.07.2013 um 15:59 schrieb Georg Ritter :
> On 07/07/13 13:47, Stephan Witt wrote:
>> Am 07.07.2013 um 13:39 schrieb Georg Ritter :
>>
>>> Dear lyx team,
>>>
>>> I just pulled the sources from git an noticed the following:
>>>
>>> If ./configure --with-qt4-dir=/my/qt4dir482/ is specified, t
On 07/07/13 13:47, Stephan Witt wrote:
> Am 07.07.2013 um 13:39 schrieb Georg Ritter :
>
>> Dear lyx team,
>>
>> I just pulled the sources from git an noticed the following:
>>
>> If ./configure --with-qt4-dir=/my/qt4dir482/ is specified, the build
>> system should pickup and use:
>> /my/qt4dir/bi
Am 07.07.2013 um 13:39 schrieb Georg Ritter :
> Dear lyx team,
>
> I just pulled the sources from git an noticed the following:
>
> If ./configure --with-qt4-dir=/my/qt4dir482/ is specified, the build
> system should pickup and use:
> /my/qt4dir/bin/moc
>
> but it did use /usr/bin/moc-qt4 on my
Dear lyx team,
I just pulled the sources from git an noticed the following:
If ./configure --with-qt4-dir=/my/qt4dir482/ is specified, the build
system should pickup and use:
/my/qt4dir/bin/moc
but it did use /usr/bin/moc-qt4 on my system (ubuntu 9.10) and got
confused (as the system one is 4.5.
Scott Kostyshak wrote:
> On Sun, Jun 9, 2013 at 4:48 AM, Georg Baum
> wrote:
>> Scott Kostyshak wrote:
>>
>>> Bisect leads me here:
>>> c14b9e67
>>
>> Thanks, I'll have a look.
>
> Did you have a chance to take a look at this Georg? Should I open a trac
> ticket?
Sorry, it is finally summer her
26 matches
Mail list logo
