Am Donnerstag, 9. Juni 2016 um 00:58:45, schrieb LyX Ticket Tracker
> #9227: Dialog shortcuts are superseded by main menu shortcuts
> ---+
> Reporter: yokota | Owner: uwestoehr
> Type: defect | Status: closed
> Priority: n
On 06/08/2016 10:35 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit 3f4901de9ce36866b75e56ec6864354e4119e647
>> Author: Pavel Sanda
>> Date: Wed Jun 8 19:33:08 2016 -0700
>>
>> Improve build for FreeBSD.
>>
>> Patch from Shankar Giri Venkita Giri.
>>
>> diff --git a/configure.
On 06/08/2016 03:57 PM, Georg Baum wrote:
> Guillaume Munch wrote:
>
>> Le 07/06/2016 00:00, Richard Heck a écrit :
>>> Our use of git would make it very easy for us to have a branch in which
>>> new features not requiring format changes could also be put.
>>>
>> This solution would be fine by me t
Thanks for all your patience, apologies for my remarks, deeply appreciate
your service to all of us.
Still not working when I copy the two .dll files
msvcp100.dll
msvcr100.dll
to the 2.2 bin file from 2.1.4.
Will stay with 2.1.4 till something develops.
What is odd is that I have a new laptop, an
Pavel Sanda wrote:
> commit 3f4901de9ce36866b75e56ec6864354e4119e647
> Author: Pavel Sanda
> Date: Wed Jun 8 19:33:08 2016 -0700
>
> Improve build for FreeBSD.
>
> Patch from Shankar Giri Venkita Giri.
>
> diff --git a/configure.ac b/configure.ac
> index 5d6fe77..3353df4 100644
>
Scott Kostyshak wrote:
> By the way, I saw your comment just above the definition of the lyxdist
> target, which you introduced in 2010 (d407a15c):
>
>
> #Wait some time for bumping automake 1.11, which can use dist-xz
> #directly without this code, which is to be removed.
> #xz has low c
Getting the error
0xc07b
time and time again, after multiple installations,on two different laptops,
one with windows 8, another with windows 7.
Any ideas what is going wrong?
Paul
On Wed, Jun 8, 2016 at 8:30 PM, LyX Ticket Tracker wrote:
> #10206: Problem installing Lyx 2.2
> --
Am 09.06.2016 um 01:41 schrieb Paul McNelis:
Please help, is this new version a joke? Why cannot it work on windows?
I must admit that I don't like how you write. You are using free
software developed by volunteers spending their spare time to give support.
Describe your problem properly a
The beta version worked well, that is the problem, no reason to give
feedback when it worked.
Please, either the product works or it does not. I will stay with 2.1.4.
I am a professor, I want to give a good product to my students.
On Wed, Jun 8, 2016 at 7:45 PM, LyX Ticket Tracker wrote:
> #102
Thanks Pavel.
I'll try to produce a patch for #1. Then both #1 and #2, after review, can go into master/branch. I play around in FreeBSD frequently, so I can help with build issues/regressions in future as well.
Shankar
Sent: Monday, June 06, 2016 at 12:48 PM
From: "Pavel Sanda"
To: l
Le 09/06/2016 00:41, Paul McNelis a écrit :
Please help, is this new version a joke? Why cannot it work on
windows? Please fix this, or cancel the new version, it is not ready
for distribution. Do not waste our time. Either property beta-test it
or not. We are busy people.
--
Robert Bendhei
Please help, is this new version a joke? Why cannot it work on windows?
Please fix this, or cancel the new version, it is not ready for
distribution. Do not waste our time. Either property beta-test it or not.
We are busy people.
On Wed, Jun 8, 2016 at 6:33 PM, LyX Ticket Tracker wrote:
> #10
On Mon, Jun 06, 2016 at 01:57:11PM -0400, Scott Kostyshak wrote:
> On Mon, May 30, 2016 at 12:21:47PM -0400, Scott Kostyshak wrote:
> > On Mon, May 30, 2016 at 02:43:57PM +0200, Charles de Miramon wrote:
> > > Kornel Benko wrote:
> > >
> > > > Knowing what went wrong, why are you doing it again?
>
On Tue, Jun 7, 2016 at 8:08 PM, Liviu Andronic wrote:
>
> AR liblyxinsets.a
> CXXLD lyx
> liblyxinsets.a(InsetERT.o):(.rodata._ZTVN3lyx8InsetERTE[_ZTVN3lyx8InsetERTE]+0x230):
> undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
> liblyxinsets.a(InsetIndex.o):(.rodata._ZTVN3
On Wed, Jun 8, 2016 at 10:14 PM, Guillaume Munch wrote:
>
> Le 08/06/2016 20:48, Pavel Sanda a écrit :
>>
>> Guillaume Munch wrote:
>>>
>>> Here's what I suggest. Let's do, on a trial basis for the duration of
>>> 2.3dev, a branch that mirrors master but inserts patches to disable the
>>> input an
Le 08/06/2016 21:58, Jean-Marc Lasgouttes a écrit :
Le 08/06/16 à 20:21, Guillaume Munch a écrit :
I'd rather include only the standard headers to obtain unique_ptr, and
then include support/make_unique.h when we explicitly need it.
When you have unique_ptr, you also want to have make_unique
On Wed, Jun 08, 2016 at 06:35:21PM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
>
> > Ah yes that is more important. I'm still wondering if it should go in
> > RELEASE-NOTES as well. In our ANNOUNCE we recommend that packagers read
> > the RELEASE-NOTES file. Don't we want packagers to be awa
Le 08/06/16 à 20:21, Guillaume Munch a écrit :
I'd rather include only the standard headers to obtain unique_ptr, and
then include support/make_unique.h when we explicitly need it.
When you have unique_ptr, you also want to have make_unique without
hassle. The reason is that apart from some co
Le 08/06/16 à 22:14, Guillaume Munch a écrit :
As long as I am allowed to ignore the third branch completely I am
fine with that.
I think this is the idea.
So why not, indeed.
JMarc
Le 08/06/2016 20:57, Georg Baum a écrit :
Guillaume Munch wrote:
Le 07/06/2016 00:00, Richard Heck a écrit :
Our use of git would make it very easy for us to have a branch in which
new features not requiring format changes could also be put.
This solution would be fine by me too, if people
Le 08/06/2016 20:48, Pavel Sanda a écrit :
Guillaume Munch wrote:
Here's what I suggest. Let's do, on a trial basis for the duration of
2.3dev, a branch that mirrors master but inserts patches to disable the
input and output of new file-format features (as well as layout changes,
etc.) after eac
Guillaume Munch wrote:
> Le 07/06/2016 00:00, Richard Heck a écrit :
>>
>> Our use of git would make it very easy for us to have a branch in which
>> new features not requiring format changes could also be put.
>>
>
> This solution would be fine by me too, if people agree to have three
> branches
Guillaume Munch wrote:
> Here's what I suggest. Let's do, on a trial basis for the duration of
> 2.3dev, a branch that mirrors master but inserts patches to disable the
> input and output of new file-format features (as well as layout changes,
> etc.) after each file-format change. We would see if
Le 07/06/2016 16:32, Jean-Marc Lasgouttes a écrit :
Le 07/06/2016 à 17:25, Guillaume Munch a écrit :
Technically, unique_ptr.h is also useful to include . When you
start using unique_ptr, you expect that you might use make_unique at
some point, so you want to just include a generic header.
I'
Le 07/06/2016 00:35, Guillaume Munch a écrit :
Le 07/06/2016 00:00, Richard Heck a écrit :
On 06/06/2016 06:40 PM, Guillaume Munch wrote:
The point of the proposal is to enabling the early testing and release
of *non-file-format* changes. Then for a proper master release only
file-format chang
Scott Kostyshak wrote:
> Ah yes that is more important. I'm still wondering if it should go in
> RELEASE-NOTES as well. In our ANNOUNCE we recommend that packagers read
> the RELEASE-NOTES file. Don't we want packagers to be aware of this
> significant change? Or do we just assume they'll read INS
Am Mittwoch, 8. Juni 2016 um 09:36:05, schrieb Kornel Benko
> commit 8019732b395faa9fafe3b4c644cb72143bdd5dd1
> Author: Kornel Benko
> Date: Wed Jun 8 09:21:48 2016 +0200
>
> Cmake build: Check for QPA_XCB when QT_USES_X11 is known
>
> Since QT_USES_X11 is determined in ConfigureC
27 matches
Mail list logo
