Annoying terminal messages: QXcbClipboard: SelectionRequest too old

[Scott Kostyshak]

Does anyone else often get these annoying messages when running LyX from
a terminal?

QXcbClipboard: SelectionRequest too old

I've been getting them for a while. I wonder if it is something
particular to my system (e.g. because of the clipboard manager I use,
CopyQ).

Scott


signature.asc
Description: PGP signature

Re: Help with patch for "word selection mode" on double click

[Scott Kostyshak]

On Sat, Feb 14, 2015 at 10:11:02AM -0500, Scott Kostyshak wrote:
> On Sat, Feb 14, 2015 at 5:06 AM, Jean-Marc Lasgouttes
>  wrote:
> > I'm not sure what your first chunk is doing. Besides, it is very strange
> > that you need to know the position on the current row. Isn't this a screen
> > update problem ?
> 
> I agree. I just don't know how else to solve the "first word on a line
> problem" (which happens if you take the first chunk out).

I'm just bumping this thread, in case someone takes an interest in
getting this unstuck. I hope my patch (let me know if you want me to
resend, it is on this thread two messages up) provides at least a
starting point if someone is interested.

Scott

> 
> Scott
> 
> >
> > Sorry to be so terse, I'm reading on a phone.
> >
> > JMarc
> >
> > Le 14 février 2015 03:29:21 CET, Scott Kostyshak  a écrit
> > :
> >>
> >> On Sun, Feb 8, 2015 at 4:14 PM, Scott Kostyshak  wrote:
> >>>
> >>>  On Thu, Nov 20, 2014 at 3:28 AM, Scott Kostyshak 
> >>> wrote:
> 
>   On Tue, Oct 28, 2014 at 7:03 AM, Scott Kostyshak 
>  wrote:
> >
> >  I have a patch that enables "word selection mode" on double click. It
> >  seems to work well. The patch is here:
> >
> >
> > http://www.lyx.org/trac/attachment/ticket/7890/0001-Fix-9160-and-7890.patch
> >
> >  The only major issue is that when dragging to the left,
> > you cannot
> >  highlight the first word. Does anyone have an idea for where to fix
> >  this?
> >
> >  The following patch might give a clue as to where the problem is. When
> >  applied, you can select the first word. It is not meant to be taken as
> >  a correct patch:
> >
> >
> > http://www.lyx.org/trac/attachment/ticket/7890/0002-HACK-just-to-show-where-the-problem-is.patch
> 
> 
>   I'm still looking for help on this in case anyone is motivated.
> >>>
> >>>
> >>>  Still looking for help on this (perhaps just a guess on where in the
> >>>  code to look to fix the problem?). It would be nice to put this into
> >>>  2.2.
> >>
> >>
> >> I've made some progress. The attached patch does not suffer from not
> >> being able to select the first word on a line, except if the line
> >> spans several "screen lines" (i.e. the line wraps). In
> >> order to solve
> >> the problem when the line is wrapped, how do I get the position of the
> >> cursor on the visual line? I'm currently conditioning on pos() == 0. I
> >> imagine I need to condition on something defined in frontend/ but I'm
> >> not sure what.
> >>
> >> Scott


signature.asc
Description: PGP signature

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 05/06/2016 12:54, Georg Baum a écrit :

Therefore I would vote to support MSVC 2013 and later, but nothing
earlier.


In light of the lack of support of unicode string literals in MSVC 2013,
the availability of mingw and the fact that a last-minute switch to MSVC
2015 was already necessary for the release of lyx 2.2, I vote for
supporting MSVC >= 2015.




1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove
auto_ptr. This is used by two other patches waiting to be
committed. After the first commit, the option --disable-cxx11 will
fail.


Looks good, I have only one minor comment: Please do not use _MSC_VER
in the sources. This code is better located in config.h


Done. I also removed the compatibility code for MSVC 2012.



Concerning the order of committing, I would first change the
--disable-cxx11 switch to --disable-cxx14, so that we do not loose
the infrastructure, and remove all code that is inside #ifndef
LYX_USE_CXX11. Afterwards, we can gradually introduce more C++11
features like unique_ptr. I can do the configure stuff if you like
btw.


Yes, please do this.



I won't comment on the other items. IMHO, discussing all these in
one message makes things more complicated. I would prefer to go step
by step.


Thanks. Take your time.

Re: expected behavior when pasting multiple cells from one table to another

[Scott Kostyshak]

On Sun, Jun 05, 2016 at 08:20:55PM +0100, Guillaume Munch wrote:
> Le 07/03/2016 04:30, Scott Kostyshak a écrit :
> > On Sun, Mar 06, 2016 at 09:47:05PM +0100, Jean-Marc Lasgouttes wrote:
> > > Le 06/03/16 17:52, Scott Kostyshak a écrit :
> > > > > I do not see why overwriting is a problem. We do it everywhere, there 
> > > > > is
> > > > > nothing special about tables.
> > > > 
> > > > Where else do we overwite when we do not paste into a selection?
> > > > To be clear, this is a screencast:
> > > > https://www.dropbox.com/s/3pogl5dbc11tx4l/screencast-LQ-4844.ogv?dl=0
> > > 
> > > I see what you mean.
> > > 
> > > > And this is my desired behavior:
> > > > https://www.dropbox.com/s/4obp8ozb8uvrhah/screencast-LQ-4844_2.ogv?dl=0
> > > 
> > > Note that spreadsheets may contain invisible data (the formulas), so that
> > > overwriting is more insidious in this case.
> > 
> > Good point.
> > 
> > The program most similar to LyX, Libre Office, does overwrite. And there
> > doesn't seem to be support for changing this behavior so I will not
> > insist more.
> 
> + Add new cells if there is no cell selection
> + Overwrite if there is a selection of cells
> + No dialog asking for confirmation
> 
> > 
> > > > Indeed, this is nice. But sometimes I'm not sure if people understand
> > > > the mistake they made until it is too late (e.g. they saved).
> > > 
> > > Saving does not kill undo, but I see your point.
> > 
> > Ah true. Save as does though.
> > 
> 
> Bug...

I assumed it was intended. Note however that one recent user reported
similar confusion:
https://www.mail-archive.com/search?l=mid=A17317DA-D3B1-4DAE-AEE9-3D2E360510E3%40mac.com

Scott


signature.asc
Description: PGP signature

Re: expected behavior when pasting multiple cells from one table to another

[Guillaume Munch]

Le 07/03/2016 04:30, Scott Kostyshak a écrit :

On Sun, Mar 06, 2016 at 09:47:05PM +0100, Jean-Marc Lasgouttes wrote:

Le 06/03/16 17:52, Scott Kostyshak a écrit :

I do not see why overwriting is a problem. We do it everywhere, there is
nothing special about tables.


Where else do we overwite when we do not paste into a selection?
To be clear, this is a screencast:
https://www.dropbox.com/s/3pogl5dbc11tx4l/screencast-LQ-4844.ogv?dl=0


I see what you mean.


And this is my desired behavior:
https://www.dropbox.com/s/4obp8ozb8uvrhah/screencast-LQ-4844_2.ogv?dl=0


Note that spreadsheets may contain invisible data (the formulas), so that
overwriting is more insidious in this case.


Good point.

The program most similar to LyX, Libre Office, does overwrite. And there
doesn't seem to be support for changing this behavior so I will not
insist more.


+ Add new cells if there is no cell selection
+ Overwrite if there is a selection of cells
+ No dialog asking for confirmation




Indeed, this is nice. But sometimes I'm not sure if people understand
the mistake they made until it is too late (e.g. they saved).


Saving does not kill undo, but I see your point.


Ah true. Save as does though.



Bug...

Re: Visible carriage return

[Guillaume Munch]

Le 03/06/2016 16:11, Richard Heck a écrit :

On 06/03/2016 11:05 AM, Guillaume Munch wrote:

Le 03/06/2016 08:18, Richard Heck a écrit :

On 06/02/2016 08:04 PM, Giorgio Zavarise wrote:

Hi,

I have a question concerning the space around centered equation. When
you type text and then add centered equations you may get a different
results if you add an empty line; e.g. the following text will produce
more spaces in the second case:

Test 1
\[
A_{1}=\frac{h}{2}
\]
End Test 1

Test 2

\[
A_{1}=\frac{h}{2}
\]

End Test 2



When using LyX, the fact that you have generated or not a blank line
is basically hidden. As far as I know, the only way to detect it is
looking at the LateX Source panel.
Hence my question is: Is there a workaround to know where I placed a
blank line?
Is it possible that Lyx shows a special character, or something
similar, to let you know where you put a blank line (I mean something
like the carriage return in WORD, that can be visible or it can be
hidden)?


Tools> Preferences> Document Handling> Mark End of Paragraphs

rh



Which should be the default setting IMO.


You can raise that on devel, but I think we had that discussion once.




I remember a discussion. I remember somebody arguing that this is 
already denoted by an increased vertical spacing that matches the one in 
LaTeX. However, I cannot reproduce this (even in 2.1.4). If that was 
fixed, maybe this would be an alternative to what I asked above. However 
please note that the spacing would need to be bigger than the one in 
LaTeX to counterbalance the fact that mathed itself is inconsistent in 
terms of spacing. Let me know your thought about how this should be 
implemented.

Re: Tarballs for LyX 2.2.0 are on FTP

[Guillaume Munch]

Le 03/06/2016 13:02, Jean-Marc Lasgouttes a écrit :

Le 31/05/2016 à 22:26, Georg Baum a écrit :

In addition I would suggest the following: (Officially) allow new
features that do not require a file format change into minor
releases.

The main reason is again that this allows testing more
regularly. For instance, in my case, I can use a development
version in my work, but only if the file format is the same.


Unfortunately it also means we force all users to test these new
features.


Yes, I think that having nightlies would be more efficient than
that.


Still, the problem with nightlies is that the stable version only has a
subset of the new features, and one cannot use the master version
because it changes the files one is working on. This is asking people,
"please test the nightly version, however, once you get in you are
locked, unless you manually convert all your files back".

Yet, most of the file format changes are very simple. I wonder whether
one could introduce a single compilation variable to disable them,
and ask developers to enclose file-format-specific code between the
corresponding #ifdefs. (For instance in my last file format change all
that was needed to be enclosed was the parsing code.) This would allow
the release of "master versions without file format changes", either as
nightlies or as official "x.5" versions as Pavel suggested by Pavel in
another message (without having to maintain three branches in parallel).

- More work for developpers
+ Less pressure on the stable maintainer to accept new features,
  and less work to backport features.
+ Testable nightlies
+ Possibility for "master-without-FF" releases without a third branch to
  maintain.
+ There is a program called unifdef that can get rid at each major
  release of the #ifdefs from the previous version automatically.



- Have a build server that does automatic builds on a regular
basis for all three platforms (Linux, OS X, windows) and makes
binary packages and build logs available.


Do you have a particular service in mind? I agree that this would be
nifty.


- Run tests automatically, using the binaries from the build
server, make test results available.


Sure. Not difficult once we have the nightlies.



Jean-Marc, have you looked into ci.inria.fr?





- (not related to automation) Disentangle unrelated stuff from the
release. For example, the current way of updating the documentation
is inefficient. In agile software development you write the
documentation of a new feature almost at the same time as you
implement the fetaure (this is one of the good aspects of agile
software development). If we do that as well we can get rid of a
noticeable delay at release time.


The problem is that we are not very good at writing documentation
and we let Uwe do all this. If he had a small team of documenters to
 help, life would be much easier.


- (not related to automation) Set bug targets more realistically.
This avoids massive retargeting (with related discussions), and
gives a better picture what needs to be done for the release.


We are not good at bug targets, except when the patch is almost
done. I am not sure that we can improve much on that. We cannot
force people to work on a bug, unfortunately.



It was decided that we would use .x targets instead of .1,2,3 targets,
so this is already better.

Jean-Marc, also could a new Trac version not help automating the
retargeting the release manager has to do every time? Independently,
would it not be now the time to update Trac to a newer version? (I am
assuming you are the one who knows about this.)


Guillaume

Re: One official build system?

[Scott Kostyshak]

On Sun, Jun 05, 2016 at 01:59:53PM +0200, Kornel Benko wrote:
> Am Sonntag, 5. Juni 2016 um 12:13:51, schrieb Georg Baum 
> 
> > Kornel Benko wrote:
> > 
> > > Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum
> > >> 
> > >> However, this is not so important. With autotools we have only very few
> > >> people who understand the macro stuff in m4/, config/ and configure.ac,
> > >> but everybody is able to do his modifications to the various Makefile.am.
> > >> I am pretty sure that cmake can be setup in a similar way, so that we
> > >> have the complicated parts that need expert knowledge and are not changed
> > >> often, and the easy ones that can be changed by everybody.
> > > 
> > > Sort of. The comparable ones are m4 macros and macros in the
> > > development/cmake/modules directory. But I do not see cmake-analogy to
> > > Makefile.am files.
> > 
> > I thought those were the CMakeLists.txt files in the individual 
> > directories? 
> > The purpose of Makefile.am is to define what gets built, packaged and 
> > installed in that directory in a way as simple as possible. I had the 
> > impression that the purpose of CMakeLists.txt is the same. If it is not 
> > possible to set up cmake in a way that the average developer needs to know 
> > as little cmake stuff as he currently needs to know from autotools, then 
> > this would be a big disadvantage.
> 
> Yes, you are right. Sometimes I cannot see the forest. Too many trees.
> 
> > >> I would suggest to make a comparison table of build system features
> > >> in the wiki, and everybody adds the ones he needs. Then we can see which
> > >> build system supports which feature, and how much work it would be to
> > >> implement the mising ones in cmake.
> > > 
> > > +1
> > 
> > I started a quite incomplete table at 
> > http://wiki.lyx.org/Devel/BuildSystems 
> > with some options I used. I would invite everybody to contribute to make it 
> > complete. The only question is whether we should continue it in the wiki or 
> > in Development.lyx. I would prefer the latter, since it is easier to edit 
> > and you get better visual feedback, but of course this would make 
> > contributions from non-developers more hard.
> 
> OK, starting on the list first. I can only comment on the cmake part.
> 
> [A] detection of  external  dependencies
>   cmake does full detection IMHO
> [B] create .rpm
>   cmake creates rpm, deb,
> [E] create window package
>   don't know, we should ask Peter

CC'ing Peter then.

Scott

> [I] Reliability
>   why is scons higher then autotools?
>   cmake not reliable?
> [J] Supported platforms
>   cmake supports all our platforms IMHO
> 
> Commandline arguments for autotools and cmake (arguments for cmake)
> custom archiver  -DCMAKE_AR=
> custom assemble   -DCMAKE_AS=
> custom C compiler  -DCMAKE_CXX_COMPILER=
> C++ runtime library   -DLYX_STDLIB_DEBUG=ON
> included boost   -DLYX_EXTERNAL_BOOST=OFF
> included hunspell  -DLYX_3RDPARTY_BUILD=ON
> included zlib  -DLYX_3RDPARTY_BUILD=ON
> installation prefix  -DCMAKE_INSTALL_PREFIX=
> version suffixin work
> verbose compiler output -DLYX_QUIET=OFF
> 
> 
> > >> One thing I noticed recently is the
> > >> version suffix: Which autotools you can use an arbitrary one, with cmake
> > >> you can only toggle between a predefined one or none at all, which is a
> > >> problem if you want to compare two different builds of the same version
> > >> with separate configurations (e.g. qt4/qt5 or different compiler
> > >> settings).
> > > 
> > > I never had problems with this. Each build with different settings can
> > > have its own build-dir, so the comparison is trivial. I am doing it this
> > > way. So for example my build dir for lyx using gcc5.3 with qt5.6 is
> > > '/usr/BUILD/BuildLyxGitQt5.6main-gcc5.3'
> > > 
> > > We don't need to install first.
> > > 
> > > But it is also easy to change the boolean selecting suffix to be a string.
> > 
> > IMHO it is needed. Sometimes you want to install and cannot use the build 
> > dir only. For example, Liviu would need to rename his .deb packages if we 
> > would switch to cmake right now, and this would be cumbersome for the users.
> > 
> 
> I started the work. But I have to know, what should be affected by the suffix.
> Suffix = xy
> 1.) Installations directory (probably not)
> 2.) Environment variables (like LYX_USERDIR_xy)
> 3.) Package name
> 4.) Program suffixes (lyx2.3.dev)
> 5.) Data directory (for lyx-system-lib-dir)
> 6.) Binary dir
> 
> > Georg
> 
> 
>   Kornel




signature.asc
Description: PGP signature

Re: One official build system?

[Liviu Andronic]

On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
>> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
>> 
>> > Kornel Benko wrote:
>> >
> ...
>> > The remaining directories from the second list would be located as follows:
>> >
>> > bin:$prefix/bin
>> > fonts:  $datarootdir/fonts/truetype/$package
>
> I am not sure about this one. Are there clashes with
> the same files installed by different lyx-version?
> How should latex select the correct data?
>
On Ubuntu for the fonts-lyx packages I simply make them conflict with
each other, meaning that the user can install only one on the same
system (e.g. fonts-lyx or fonts-lyx2.2).




>> > locale: $datarootdir/locale
>> > tex:$datarootdir/texmf/tex/latex/$package
>
> Same here.
>
Not sure what happens in this case, though.


Liviu


> Kornel



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
> 
> > Kornel Benko wrote:
> > 
...
> > The remaining directories from the second list would be located as follows:
> > 
> > bin:$prefix/bin
> > fonts:  $datarootdir/fonts/truetype/$package

I am not sure about this one. Are there clashes with
the same files installed by different lyx-version?
How should latex select the correct data?

> > locale: $datarootdir/locale
> > tex:$datarootdir/texmf/tex/latex/$package

Same here.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > ATM cmake installs almost everything under the installation directory.
> > Exceptions are (defaults for versioned)
> > manuals /usr/local/man, (e.g. /usr/local/man/man1/man1/lyxclient2.3.1)
> > lyx-icon /usr/local/share/icons/hicolor/scalable/apps/lyx2.3.svg
> > desktop /usr/local/share/applications/lyx2.3.desktop
> > 
> > So, under the installation directory we find directories
> > bin, bind, commands, doc, examples, fonts, images, kbd, layouts, locale,
> > lyx2lyx, scripts, templates tex, ui
> 
> Thanks for the explanation, now I understand what is meant. IMHO we should 
> follow the GNU standards (which autotools do): 
> http://www.gnu.org/prep/standards/standards.html#Directory-Variables
> 
> This means we have a prefix (defaults to /usr/local and is set to /usr by 
> distro packagers). Everything is installed below the prefix. The listed 
> exceptions above would fit in this scheme, but the differences are in the 
> second list:
> 
> All LyX specific directories (bind, commands, doc, examples, images, kbd, 
> layouts, lyx2lyx, scripts, templates, ui) should be under $datadir which 
> defaults to $datarootdir/$package, e.g. /usr/local/share/lyx2.3 
> ($datarootdir defaults to $prefix/share).
> 
> The remaining directories from the second list would be located as follows:
> 
> bin:$prefix/bin
> fonts:  $datarootdir/fonts/truetype/$package
> locale: $datarootdir/locale
> tex:$datarootdir/texmf/tex/latex/$package

OK.

> Both the binaries in $bin and the translations in $locale would get a 
> version suffix.

Version suffix for bin and locales is already used as expected.

> For windows the easiest thing would be to set both $prefix and $datarootdir 
> to the same installation directory. The only thing which would be special 
> would be the TeX files.

I think, there is nothing to do for windows yet, because it uses already cmake.

> > Each of them _could_ be installed on different place, one has only to
> > specify where do we want them. The prerequisite (IMHO) is that we should
> > be able to install different versions at the same time. Without conflicts.
> 
> Yes. In addition, there are certain standards that should be followed, so 
> that e.g. translations are found without special configurations.
> 

Yes.

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> ATM cmake installs almost everything under the installation directory.
> Exceptions are (defaults for versioned)
> manuals /usr/local/man, (e.g. /usr/local/man/man1/man1/lyxclient2.3.1)
> lyx-icon /usr/local/share/icons/hicolor/scalable/apps/lyx2.3.svg
> desktop /usr/local/share/applications/lyx2.3.desktop
> 
> So, under the installation directory we find directories
> bin, bind, commands, doc, examples, fonts, images, kbd, layouts, locale,
> lyx2lyx, scripts, templates tex, ui

Thanks for the explanation, now I understand what is meant. IMHO we should 
follow the GNU standards (which autotools do): 
http://www.gnu.org/prep/standards/standards.html#Directory-Variables

This means we have a prefix (defaults to /usr/local and is set to /usr by 
distro packagers). Everything is installed below the prefix. The listed 
exceptions above would fit in this scheme, but the differences are in the 
second list:

All LyX specific directories (bind, commands, doc, examples, images, kbd, 
layouts, lyx2lyx, scripts, templates, ui) should be under $datadir which 
defaults to $datarootdir/$package, e.g. /usr/local/share/lyx2.3 
($datarootdir defaults to $prefix/share).

The remaining directories from the second list would be located as follows:

bin:$prefix/bin
fonts:  $datarootdir/fonts/truetype/$package
locale: $datarootdir/locale
tex:$datarootdir/texmf/tex/latex/$package

Both the binaries in $bin and the translations in $locale would get a 
version suffix.

For windows the easiest thing would be to set both $prefix and $datarootdir 
to the same installation directory. The only thing which would be special 
would be the TeX files.

> Each of them _could_ be installed on different place, one has only to
> specify where do we want them. The prerequisite (IMHO) is that we should
> be able to install different versions at the same time. Without conflicts.

Yes. In addition, there are certain standards that should be followed, so 
that e.g. translations are found without special configurations.


Georg

Re: One official build system?

[Liviu Andronic]

On Sun, Jun 5, 2016 at 4:20 PM, Georg Baum
 wrote:
> Kornel Benko wrote:
>
>> OK, starting on the list first. I can only comment on the cmake part.
>>
>> [A] detection of  external  dependencies
>> cmake does full detection IMHO
>> [B] create .rpm
>> cmake creates rpm, deb,
>> [E] create window package
>> don't know, we should ask Peter
>> [I] Reliability
>> why is scons higher then autotools?
>> cmake not reliable?
>> [J] Supported platforms
>> cmake supports all our platforms IMHO
>
> This is an old table, I did not look at it (I re-used an existing page with
> a suitable name).
>
>> Commandline arguments for autotools and cmake (arguments for cmake)
>> custom archiver  -DCMAKE_AR=
>> custom assemble   -DCMAKE_AS=
>> custom C compiler  -DCMAKE_CXX_COMPILER=
>> C++ runtime library   -DLYX_STDLIB_DEBUG=ON
>> included boost   -DLYX_EXTERNAL_BOOST=OFF
>> included hunspell  -DLYX_3RDPARTY_BUILD=ON
>> included zlib  -DLYX_3RDPARTY_BUILD=ON
>> installation prefix  -DCMAKE_INSTALL_PREFIX=
>> version suffixin work
>> verbose compiler output -DLYX_QUIET=OFF
>
> Thanks.
>
>> I started the work. But I have to know, what should be affected by the
>> suffix. Suffix = xy
>> 1.) Installations directory (probably not)
>> 2.) Environment variables (like LYX_USERDIR_xy)
>> 3.) Package name
>> 4.) Program suffixes (lyx2.3.dev)
>> 5.) Data directory (for lyx-system-lib-dir)
>> 6.) Binary dir
>
> The same what is affected by autotools --with-version-suffix ;-)
>
+1

At least on Ubuntu the package name is controlled by Debian packaging,
so this isn't something we should worry about. What is important in my
limited experience is to have binaries with appropriate suffix, the
various data dirs with appropriate suffix (including the ~./lyx2.3.dev
dir).

Liviu


> 2.) to 4.) definitely yes. What is the difference between 1 and 6)? My guess
> would be that this should not be affected.
>
>
> Georg
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 16:20:49, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > OK, starting on the list first. I can only comment on the cmake part.
> > 
> > [A] detection of  external  dependencies
> > cmake does full detection IMHO
> > [B] create .rpm
> > cmake creates rpm, deb,
> > [E] create window package
> > don't know, we should ask Peter
> > [I] Reliability
> > why is scons higher then autotools?
> > cmake not reliable?
> > [J] Supported platforms
> > cmake supports all our platforms IMHO
> 
> This is an old table, I did not look at it (I re-used an existing page with 
> a suitable name).
> 
> > Commandline arguments for autotools and cmake (arguments for cmake)
> > custom archiver  -DCMAKE_AR=
> > custom assemble   -DCMAKE_AS=
> > custom C compiler  -DCMAKE_CXX_COMPILER=
> > C++ runtime library   -DLYX_STDLIB_DEBUG=ON
> > included boost   -DLYX_EXTERNAL_BOOST=OFF
> > included hunspell  -DLYX_3RDPARTY_BUILD=ON
> > included zlib  -DLYX_3RDPARTY_BUILD=ON
> > installation prefix  -DCMAKE_INSTALL_PREFIX=
> > version suffixin work
> > verbose compiler output -DLYX_QUIET=OFF
> 
> Thanks.
> 
> > I started the work. But I have to know, what should be affected by the
> > suffix. Suffix = xy
> > 1.) Installations directory (probably not)
> > 2.) Environment variables (like LYX_USERDIR_xy)
> > 3.) Package name
> > 4.) Program suffixes (lyx2.3.dev)
> > 5.) Data directory (for lyx-system-lib-dir)
> > 6.) Binary dir
> 
> The same what is affected by autotools --with-version-suffix ;-)
> 
> 2.) to 4.) definitely yes. What is the difference between 1 and 6)? My guess 
> would be that this should not be affected.
> 

ATM cmake installs almost everything under the installation directory.
Exceptions are (defaults for versioned)
manuals /usr/local/man, (e.g. /usr/local/man/man1/man1/lyxclient2.3.1)
lyx-icon /usr/local/share/icons/hicolor/scalable/apps/lyx2.3.svg
desktop /usr/local/share/applications/lyx2.3.desktop

So, under the installation directory we find directories
bin, bind, commands, doc, examples, fonts, images, kbd, layouts, locale, 
lyx2lyx, scripts, templates tex, ui

Each of them _could_ be installed on different place, one has only to specify 
where do we want them.
The prerequisite (IMHO) is that we should be able to install different versions 
at the same time. Without conflicts.

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> OK, starting on the list first. I can only comment on the cmake part.
> 
> [A] detection of  external  dependencies
> cmake does full detection IMHO
> [B] create .rpm
> cmake creates rpm, deb,
> [E] create window package
> don't know, we should ask Peter
> [I] Reliability
> why is scons higher then autotools?
> cmake not reliable?
> [J] Supported platforms
> cmake supports all our platforms IMHO

This is an old table, I did not look at it (I re-used an existing page with 
a suitable name).

> Commandline arguments for autotools and cmake (arguments for cmake)
> custom archiver  -DCMAKE_AR=
> custom assemble   -DCMAKE_AS=
> custom C compiler  -DCMAKE_CXX_COMPILER=
> C++ runtime library   -DLYX_STDLIB_DEBUG=ON
> included boost   -DLYX_EXTERNAL_BOOST=OFF
> included hunspell  -DLYX_3RDPARTY_BUILD=ON
> included zlib  -DLYX_3RDPARTY_BUILD=ON
> installation prefix  -DCMAKE_INSTALL_PREFIX=
> version suffixin work
> verbose compiler output -DLYX_QUIET=OFF

Thanks.

> I started the work. But I have to know, what should be affected by the
> suffix. Suffix = xy
> 1.) Installations directory (probably not)
> 2.) Environment variables (like LYX_USERDIR_xy)
> 3.) Package name
> 4.) Program suffixes (lyx2.3.dev)
> 5.) Data directory (for lyx-system-lib-dir)
> 6.) Binary dir

The same what is affected by autotools --with-version-suffix ;-)

2.) to 4.) definitely yes. What is the difference between 1 and 6)? My guess 
would be that this should not be affected.


Georg

Re: [LyX/master] Implement gcc version check for cmake

[Georg Baum]

Kornel Benko wrote:

> Am Sonntag, 5. Juni 2016 um 15:54:43, schrieb Georg Baum 
>> commit c2433d8b8f2bd7be363ddc96bcb95116ac5ea8cd
>> Author: Georg Baum 
>> Date:   Sun Jun 5 15:54:29 2016 +0200
>> 
>> Implement gcc version check for cmake
>> 
>> diff --git a/CMakeLists.txt b/CMakeLists.txt
> 
> So you found it.

Yes. Nevertheless, there was no general version check that prevented too old 
versions, now we have it.


Georg

Re: [LyX/master] Implement gcc version check for cmake

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 15:54:43, schrieb Georg Baum 
> commit c2433d8b8f2bd7be363ddc96bcb95116ac5ea8cd
> Author: Georg Baum 
> Date:   Sun Jun 5 15:54:29 2016 +0200
> 
> Implement gcc version check for cmake
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt

So you found it.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Require at least gcc 4.3

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 15:41:29, schrieb Georg Baum 
> commit ad63374e26f6a314315a06b9e415fafc0366158a
> Author: Georg Baum 
> Date:   Sun Jun 5 15:40:00 2016 +0200
> 
> Require at least gcc 4.3
> 
> This is a prerequisite for mandatory C++11 support.
> I could not find a cmake gcc version check btw.

Top level CMakeLists.txt

...
if(UNIX OR MINGW)
...
message(STATUS "Using GCC version ${GCC_VERSION}")
if(GCC_VERSION VERSION_LESS 4.9)


My line numbers are different, but it should be in the near of line 283.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] glitch in lfundoc

[Jürgen Spitzmüller]

Am Mittwoch, den 01.06.2016, 00:33 -0700 schrieb Pavel Sanda:
> Hi Juergen,
> 
> I don't know whether it was your intention, but it seems that part of
> Hidden
> lfuns is no more generated correctly and some lfuns are missing (most
> probably
> due to the fact they don't have Syntax line).

No, this was not intentional. Thanks for fixing.

Jürgen

> 
> Pavel

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 12:13:51, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum
> >> 
> >> However, this is not so important. With autotools we have only very few
> >> people who understand the macro stuff in m4/, config/ and configure.ac,
> >> but everybody is able to do his modifications to the various Makefile.am.
> >> I am pretty sure that cmake can be setup in a similar way, so that we
> >> have the complicated parts that need expert knowledge and are not changed
> >> often, and the easy ones that can be changed by everybody.
> > 
> > Sort of. The comparable ones are m4 macros and macros in the
> > development/cmake/modules directory. But I do not see cmake-analogy to
> > Makefile.am files.
> 
> I thought those were the CMakeLists.txt files in the individual directories? 
> The purpose of Makefile.am is to define what gets built, packaged and 
> installed in that directory in a way as simple as possible. I had the 
> impression that the purpose of CMakeLists.txt is the same. If it is not 
> possible to set up cmake in a way that the average developer needs to know 
> as little cmake stuff as he currently needs to know from autotools, then 
> this would be a big disadvantage.

Yes, you are right. Sometimes I cannot see the forest. Too many trees.

> >> I would suggest to make a comparison table of build system features
> >> in the wiki, and everybody adds the ones he needs. Then we can see which
> >> build system supports which feature, and how much work it would be to
> >> implement the mising ones in cmake.
> > 
> > +1
> 
> I started a quite incomplete table at http://wiki.lyx.org/Devel/BuildSystems 
> with some options I used. I would invite everybody to contribute to make it 
> complete. The only question is whether we should continue it in the wiki or 
> in Development.lyx. I would prefer the latter, since it is easier to edit 
> and you get better visual feedback, but of course this would make 
> contributions from non-developers more hard.

OK, starting on the list first. I can only comment on the cmake part.

[A] detection of  external  dependencies
cmake does full detection IMHO
[B] create .rpm
cmake creates rpm, deb,
[E] create window package
don't know, we should ask Peter
[I] Reliability
why is scons higher then autotools?
cmake not reliable?
[J] Supported platforms
cmake supports all our platforms IMHO

Commandline arguments for autotools and cmake (arguments for cmake)
custom archiver  -DCMAKE_AR=
custom assemble   -DCMAKE_AS=
custom C compiler  -DCMAKE_CXX_COMPILER=
C++ runtime library   -DLYX_STDLIB_DEBUG=ON
included boost   -DLYX_EXTERNAL_BOOST=OFF
included hunspell  -DLYX_3RDPARTY_BUILD=ON
included zlib  -DLYX_3RDPARTY_BUILD=ON
installation prefix  -DCMAKE_INSTALL_PREFIX=
version suffixin work
verbose compiler output -DLYX_QUIET=OFF


> >> One thing I noticed recently is the
> >> version suffix: Which autotools you can use an arbitrary one, with cmake
> >> you can only toggle between a predefined one or none at all, which is a
> >> problem if you want to compare two different builds of the same version
> >> with separate configurations (e.g. qt4/qt5 or different compiler
> >> settings).
> > 
> > I never had problems with this. Each build with different settings can
> > have its own build-dir, so the comparison is trivial. I am doing it this
> > way. So for example my build dir for lyx using gcc5.3 with qt5.6 is
> > '/usr/BUILD/BuildLyxGitQt5.6main-gcc5.3'
> > 
> > We don't need to install first.
> > 
> > But it is also easy to change the boolean selecting suffix to be a string.
> 
> IMHO it is needed. Sometimes you want to install and cannot use the build 
> dir only. For example, Liviu would need to rename his .deb packages if we 
> would switch to cmake right now, and this would be cumbersome for the users.
> 

I started the work. But I have to know, what should be affected by the suffix.
Suffix = xy
1.) Installations directory (probably not)
2.) Environment variables (like LYX_USERDIR_xy)
3.) Package name
4.) Program suffixes (lyx2.3.dev)
5.) Data directory (for lyx-system-lib-dir)
6.) Binary dir

> Georg


Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] unique_ptr and some clean-up

[Georg Baum]

Guillaume Munch wrote:

> Dear List,
> 
> 
> I have recently started using c++11 features, and, one thing leading to
> another, some cleaning of the tree happened. Apparently most of the
> changes below are supported by old compilers (exceptions below), i.e.
> MSVC 2012 and maybe MSVC 2010 (if lucky) since at least one developer
> seemed to care about it.

IMHO it does not make sense to require C++11 and at the same time allow 
MSVC2010. The subset of C++11 that is supported by MSVC2010 is so small that 
this effectively means that we do not require C++11.

MSVC 2010 somehow became a long term support release of MSVC (although it 
was never officially called like that, it just happened), but the lifetime 
of MSVC 2012 is much shorter. For example, the open source qt 5.6 is not 
offered precompiled for MSVC 2012, only for MSVC 2013 and MSVC 2015. 
Therefore I would vote to support MSVC 2013 and later, but nothing earlier.

> 1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove auto_ptr.
> This is used by two other patches waiting to be committed. After the
> first commit, the option --disable-cxx11 will fail.

Looks good, I have only one minor comment: Please do not use _MSC_VER in the 
sources. This code is better located in config.h, like that:

#if (__cplusplus >= 201402L) || (defined(_MSC_VER)&&(_MSC_VER>=1800))
// C++14, MSVC >= 2013
#define HAVE_STD_MAKE_UNIQUE
#endif

This makes it easier to adapt the code to other compilers, and makes it more 
readable as well.

I know that we do already use internal compiler macros like _MSC_VER in a 
few places, but this is IMHO a mistake.


Concerning the order of committing, I would first change the --disable-cxx11 
switch to --disable-cxx14, so that we do not loose the infrastructure, and 
remove all code that is inside #ifndef LYX_USE_CXX11. Afterwards, we can 
gradually introduce more C++11 features like unique_ptr. I can do the 
configure stuff if you like btw.


I won't comment on the other items. IMHO, discussing all these in one 
message makes things more complicated. I would prefer to go step by step.


Georg

Re: [PATCH] microtype

[Jürgen Spitzmüller]

Am Donnerstag, den 02.06.2016, 22:52 -0700 schrieb Pavel Sanda:
> I let it in fonts, but no opposition in case others want to
> push it into layout.

Fine. Text layout would suit better technically, but I think most
people will search it in fonts, indeed.

Jürgen

> 
> Pavel

Re: One official build system?

[Stephan Witt]

Am 05.06.2016 um 11:13 schrieb Georg Baum :
> 
> Scott Kostyshak wrote:
> 
>> On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
>>> 
 Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
 
 If moving to cmake definitively would imply losing version suffix
 functionality, this would be a big issue for my packaging arrangements
 for Ubuntu builds.
>>> 
>>> +1
>>> 
>>> On Mac the version suffix is essential too.
>> 
>> I just want to make sure you saw Kornel's reply to that. I don't know if
>> it addresses your needs or not.
> 
> IMHO it does. Livius builds could be done using their current names if the 
> boolean switch is replaced by a string version, which is easy to do as 
> Kornel wrote.

Yes. I think so.

> 
>>> I just tried to build a Mac application with cmake and failed.
>> 
>> What was the error?
>> 
>>> It looks like a lot of work or to learn to make this working.
>> 
>> This might be a reason to stop this discussion here. You already do a
>> huge favor by taking care of the Mac builds. It would not make sense to
>> make it more difficult. I was hoping that in the long-run it would
>> actually be easier for you, but perhaps the transition would be too
>> frustrating and time-consuming.
> 
> We should not yet stop the discussion. We need more information about the 
> problems.

I didn’t want to put the discussion on hold. I hadn’t the time to write
a mail with enough details at the moment.

I use cmake to create Xcode projects for debugging purpose. So, it’s possible
to create a working binary with cmake. To do the packaging with cmake is another
story and - at least on Mac - not done with LyX yet. No surprise it’s not
working though.

The packaging is done in three steps with autotools + scripts:
1. make install with the appropriate directory structure for Mac
2. adding the 3rd party components required to run LyX
3. create a mountable disk image and put the LyX app and some
decorative stuff there and compress the final result.

To get the first impression how difficult it is with cmake I tried two ways:
1. standard cmake install (the naive way) results in a Linux like directory
structure without an usable application.
2. LYX_DMG=ON cmake install (marked as experimental) is better as it copies
the components of LyX to the appropriate directory structure for Mac.
Therefore the 2nd one should be the default on Mac.

Nevertheless it doesn’t work ATM because of the type of the dependency on Qt.
This is not easy to explain - but I’ll try it.

The runtime linker knows of the usual LD_LIBRARY_PATH mechanism like Unix.
An more secure and more advanced approach is the modified RPATH mechanism.
For system libraries one uses hard coded library references.

The problem is the RPATH mechanism. Qt frameworks (a collection of header
files, shared libraries and documentation) are build with these. To distribute
these frameworks they have to be placed on a fixed location for system wide use
or inside the LyX application as so called private frameworks. LyX is using
the latter and I cannot see why this should be changed. The cmake build
for LyX needs to be extended to copy the Qt libraries into the LyX application
in or before the „fixup_bundle“ phase of the packaging step. I’m almost sure
this can be done in a reliable and clean way with cmake. That’s why I said
there is something to learn and to spend some time with.

Finally I want to add the concrete error log - it ends with:
===
-- fixup_bundle: preparing…
...
-- warning: gp_resolved_file_type non-absolute file 
'@rpath/QtCore.framework/Versions/5/QtCore' returning type 'other' -- possibly 
incorrect
-- 
warning: cannot resolve item '@rpath/QtCore.framework/Versions/5/QtCore'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

warning: target '@rpath/QtGui.framework/Versions/5/QtGui' is not absolute...
warning: target '@rpath/QtGui.framework/Versions/5/QtGui' does not exist...
CMake Error at /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 
(message):
  
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool
  failed: 1

  error:
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
  can't open file: @rpath/QtGui.framework/Versions/5/QtGui (No such file or
  directory)

Call Stack (most recent call first):
  /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 
(get_prerequisites)
  /opt/local/share/cmake-3.4/Modules/BundleUtilities.cmake:555 
(get_prerequisites)
  /opt/local/share/cmake-3.4/Modules/BundleUtilities.cmake:804 (get_bundle_keys)
  development/cmake/post_install/cmake_install.cmake:52 (fixup_bundle)
  cmake_install.cmake:2703 (include)
  


make: *** [install_buildpart_0] Error 1



I tried to find a log file of the build but didn’t find any.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum
>> 
>> However, this is not so important. With autotools we have only very few
>> people who understand the macro stuff in m4/, config/ and configure.ac,
>> but everybody is able to do his modifications to the various Makefile.am.
>> I am pretty sure that cmake can be setup in a similar way, so that we
>> have the complicated parts that need expert knowledge and are not changed
>> often, and the easy ones that can be changed by everybody.
> 
> Sort of. The comparable ones are m4 macros and macros in the
> development/cmake/modules directory. But I do not see cmake-analogy to
> Makefile.am files.

I thought those were the CMakeLists.txt files in the individual directories? 
The purpose of Makefile.am is to define what gets built, packaged and 
installed in that directory in a way as simple as possible. I had the 
impression that the purpose of CMakeLists.txt is the same. If it is not 
possible to set up cmake in a way that the average developer needs to know 
as little cmake stuff as he currently needs to know from autotools, then 
this would be a big disadvantage.

>> I would suggest to make a comparison table of build system features
>> in the wiki, and everybody adds the ones he needs. Then we can see which
>> build system supports which feature, and how much work it would be to
>> implement the mising ones in cmake.
> 
> +1

I started a quite incomplete table at http://wiki.lyx.org/Devel/BuildSystems 
with some options I used. I would invite everybody to contribute to make it 
complete. The only question is whether we should continue it in the wiki or 
in Development.lyx. I would prefer the latter, since it is easier to edit 
and you get better visual feedback, but of course this would make 
contributions from non-developers more hard.

>> One thing I noticed recently is the
>> version suffix: Which autotools you can use an arbitrary one, with cmake
>> you can only toggle between a predefined one or none at all, which is a
>> problem if you want to compare two different builds of the same version
>> with separate configurations (e.g. qt4/qt5 or different compiler
>> settings).
> 
> I never had problems with this. Each build with different settings can
> have its own build-dir, so the comparison is trivial. I am doing it this
> way. So for example my build dir for lyx using gcc5.3 with qt5.6 is
> '/usr/BUILD/BuildLyxGitQt5.6main-gcc5.3'
> 
> We don't need to install first.
> 
> But it is also easy to change the boolean selecting suffix to be a string.

IMHO it is needed. Sometimes you want to install and cannot use the build 
dir only. For example, Liviu would need to rename his .deb packages if we 
would switch to cmake right now, and this would be cumbersome for the users.


Georg

Re: One official build system?

[Georg Baum]

Scott Kostyshak wrote:

> On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
>> 
>> > Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
>> > 
>> > If moving to cmake definitively would imply losing version suffix
>> > functionality, this would be a big issue for my packaging arrangements
>> > for Ubuntu builds.
>> 
>> +1
>> 
>> On Mac the version suffix is essential too.
> 
> I just want to make sure you saw Kornel's reply to that. I don't know if
> it addresses your needs or not.

IMHO it does. Livius builds could be done using their current names if the 
boolean switch is replaced by a string version, which is easy to do as 
Kornel wrote.

>> I just tried to build a Mac application with cmake and failed.
> 
> What was the error?
> 
>> It looks like a lot of work or to learn to make this working.
> 
> This might be a reason to stop this discussion here. You already do a
> huge favor by taking care of the Mac builds. It would not make sense to
> make it more difficult. I was hoping that in the long-run it would
> actually be easier for you, but perhaps the transition would be too
> frustrating and time-consuming.

We should not yet stop the discussion. We need more information about the 
problems.


Georg