Re: checkbox to filter font list by document language

[Guillaume Munch]

Le 02/06/2016 20:27, Jean-Marc Lasgouttes a écrit :

Le 02/06/16 à 20:41, Scott Kostyshak a écrit :

You are right, LyX deserves a better font selection dialog. I had a
quick look: there is the QFontDialog widget which has a writing system
selection menu. See https://doc.qt.io/qt-5/qfontdialog.html and
qtbase/examples/widgets/dialogs/standarddialogs/.


I am not sure I understand. It seems that the dialog is useful for
selecting font, style and size. This is not exactly what we need.


That's more than we need. But it also filters the fonts (Scott gave an 
example), and also select fonts not available in the usual widgets (I 
gave an example).




Usually what is used is a combox that shows the font. Is it
possible/easy with qt?

JMarc



Not sure that I understand your question, but Google might be able to 
tell you as much as me ;) There are certainly several ways to do it, but 
unless somebody steps in and is ready to spend enough time on it, the 
simplest is to use the dialog.

Re: Require C++11 for 2.3?

[Guillaume Munch]

Le 03/06/2016 06:24, Scott Kostyshak a écrit :

Dear all,

Are we going to require C++11 starting with LyX 2.3.0? From what I
understand, this will make several things easier.

Scott



Apart from Boost features and smart pointers from the other message, two
areas come to mind:

* char32_t and Unicode literals, i.e. being able to directly type
docstrings with the syntax U"..." directly in UTF-8 in the source. This
is a prerequisite for having non-ASCII-only translation strings, which
came up again on the list recently. Unfortunately, this requires
dropping MSVC < 2015.

* Better support for threads. But this is not an area of lyx that I can
speak about.

Re: One official build system?

[Kornel Benko]

Am Samstag, 4. Juni 2016 um 15:36:37, schrieb Scott Kostyshak 
> On Fri, Jun 03, 2016 at 03:40:59PM -0700, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> > > I'm still not sure what the implications of moving to CMake as our
> > > official build system are (I should have made this more clear in my
> > 
> > To start with: If you make tarball with autotools and cmake is there
> > difference between those two, do we get the same files/and their contets?
> 
> Good question. I don't know. There is no 'lyxdist' target for CMake and
> no 'dist' target so I stopped there.

# make package_source
--> LyX-2.3.tar.xz
or
# make git_archive
--> LyX-2.3.0-47674git-Linux.tgz

> 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 compression by default, but can be affected via
> #export XZ_OPT=-9ev put somewhere in the makefile.
> lyxdist: dist
>   bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
>   xz -9 $(PACKAGE)-$(VERSION).tar
>   ls -hl $(PACKAGE)-$(VERSION).tar.*
> 
> 
> Should we use dist-xz directly now?
> 
> Scott

Kornel

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

Re: One official build system?

[Scott Kostyshak]

On Fri, Jun 03, 2016 at 03:40:59PM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > I'm still not sure what the implications of moving to CMake as our
> > official build system are (I should have made this more clear in my
> 
> To start with: If you make tarball with autotools and cmake is there
> difference between those two, do we get the same files/and their contets?

Good question. I don't know. There is no 'lyxdist' target for CMake and
no 'dist' target so I stopped there.

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 compression by default, but can be affected via
#export XZ_OPT=-9ev put somewhere in the makefile.
lyxdist: dist
bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
xz -9 $(PACKAGE)-$(VERSION).tar
ls -hl $(PACKAGE)-$(VERSION).tar.*


Should we use dist-xz directly now?

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Scott Kostyshak]

On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
> 
> > Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
> > 
> > On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
> >  wrote:
> >> 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).
> >> 
> > 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.

> 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.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Get rid of pseudo diffs when remerging strings

[Richard Heck]

On 06/04/2016 01:28 PM, Georg Baum wrote:
> Richard Heck wrote:
>
>> OK, please commit to 2.2.x. (Safe enough, yes?)
> Done. Yes, it is safe. And even if something went wrong you would now see it 
> in the diffs when sommitting .po files: The only visible diffs should now be 
> changed line numbers in source files, and of course added, changed or 
> deleted translations.

Great. Thanks for fixing this.

rh

Re: One official build system?

[Stephan Witt]

> Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
> 
> On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
>  wrote:
>> 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).
>> 
> 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 tried to build a Mac application with cmake and failed.
It looks like a lot of work or to learn to make this working.

Stephan

Re: [LyX/master] Get rid of pseudo diffs when remerging strings

[Georg Baum]

Georg Baum wrote:

> commit 960bcc71c18b21e0444cfce3d9a5e7c10cb3172a
> Author: Georg Baum 
> Date:   Sat Jun 4 17:33:19 2016 +0200
> 
> Get rid of pseudo diffs when remerging strings
> 
> cmake sorts the input files for lyx_pot.py internally, but autotools
> use a shell pattern like *.ui on the command line, so the order may be
> different on different machines. It is more robust not to require any
> sorting from the caller, so lyx_pot.py sorts now internally.
> 

Richard, this might be interesting for the 2.2.x branch as well, depending 
on how you want to organize string remerging. It fixes the sorting problem 
we have had for years, which produces huge pseudo diffs if one remerges with 
autotools after a remerge was done with cmake or vice versa.

Together with 9df45c383ad this should now fix all pseudo-diff problems we 
had with .po file generation.


Georg

Re: [LyX/master] Get rid of pseudo diffs when remerging strings

[Georg Baum]

Richard Heck wrote:

> OK, please commit to 2.2.x. (Safe enough, yes?)

Done. Yes, it is safe. And even if something went wrong you would now see it 
in the diffs when sommitting .po files: The only visible diffs should now be 
changed line numbers in source files, and of course added, changed or 
deleted translations.


Georg

Re: [LyX/master] Get rid of pseudo diffs when remerging strings

[Pavel Sanda]

Georg Baum wrote:
> Together with 9df45c383ad this should now fix all pseudo-diff problems we 
> had with .po file generation.

Nice! P

Re: [LyX/master] Get rid of pseudo diffs when remerging strings

[Richard Heck]

On 06/04/2016 11:54 AM, Georg Baum wrote:
> Georg Baum wrote:
>
>> commit 960bcc71c18b21e0444cfce3d9a5e7c10cb3172a
>> Author: Georg Baum 
>> Date:   Sat Jun 4 17:33:19 2016 +0200
>>
>> Get rid of pseudo diffs when remerging strings
>> 
>> cmake sorts the input files for lyx_pot.py internally, but autotools
>> use a shell pattern like *.ui on the command line, so the order may be
>> different on different machines. It is more robust not to require any
>> sorting from the caller, so lyx_pot.py sorts now internally.
>>
> Richard, this might be interesting for the 2.2.x branch as well, depending 
> on how you want to organize string remerging. It fixes the sorting problem 
> we have had for years, which produces huge pseudo diffs if one remerges with 
> autotools after a remerge was done with cmake or vice versa.
>
> Together with 9df45c383ad this should now fix all pseudo-diff problems we 
> had with .po file generation.

OK, please commit to 2.2.x. (Safe enough, yes?)

rh

Re: One official build system?

[Abdelrazak Younes]

On 04/06/2016 10:18, Georg Baum wrote:

Abdelrazak Younes wrote:


Hi Guys,

Funny to discover that the same discussion is coming back every couple
of years :-)

I am not surprised at all, maintaining two build systems with such a small
amount of developers is simply stupid.


I agree.


The main disadvantage of GLOB is that it can mess up your build if you
let in the source tree some files that was renamed for debugging or
development purpose. Personally I never do that because git branching
and stashing are so good that it is much simpler to use git instead of
manual renaming; but I can fully understand that you are not comfortable
with that.
For renaming files or adding new files I would prefer to handle that
completely in git as well. However, it does not work. If I add a new file
and then stash the changed away, git adds the new file to the stash, but
does not delete the one in the local working tree, so when I pop from the
stash again I get a conflict. Therefore, I do not add new files to the
stash, and then I can easily move around.


In this case branching is the solution, not stashing indeed.




1) Switch to CMake now
2) Take advantage of GLOB to do the much needed file hierarchy cleanups
now (both folder hierarchy and file/class names)
3) Switch file listing mode without GLOB.

Switching to cmake first and some time later from GLOB to explicit file
listing would create a huge amount of work, since you would need to recreate
all file lists from scratch.


Creating a list with all files in the tree is very simple... You can 
even automate that with CMake I think.


Anyway, those are details I think, the important thing to decide is to 
switch or not.


Thanks,
Abdel.

Re: One official build system?

[Kornel Benko]

Am Samstag, 4. Juni 2016 um 10:15:03, schrieb Liviu Andronic 

> On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
>  wrote:
> > 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).
> >
> If moving to cmake definitively would imply losing version suffix
> functionality, this would be a big issue for my packaging arrangements
> for Ubuntu builds.
> 
> Right now I keep master and branch daily builds (as well as
> pre-releases) completely independent from stable LyX packages, which
> allows people to blissfully install both stable and bleeding edge
> versions on the same system, without worrying of corrupting their
> production environment. Losing this will probably imply that we can
> install only one build at a time on a given system, which will reduce
> the testing opportunities for bleeding edge code

This is really no problem at all.
I for one have installed
# dpkg -l | grep lyx
ii  lyx21   2.1.5-45097git  
amd64A WYSIWYM (What You See Is What You Mean) 
document processor
ii  lyx22   2.2.0-47529git  
amd64A WYSIWYM (What You See Is What You Mean) 
document processor
ii  lyx23   2.3.0-47674git  
amd64A WYSIWYM (What You See Is What You Mean) 
document processor

without any conflicts. All of them created by cpack (called automatically by 
cmake).
And changing the suffix handling is not hard, as I wrote in my answer to Georg.

> Liviu
> 
> 
> >
> >
> > Georg
> >

Kornel

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

Re: One official build system?

[Kornel Benko]

Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum 

> Richard Heck wrote:
> 
> > On 06/03/2016 04:28 PM, Scott Kostyshak wrote:
> >> On Fri, Jun 03, 2016 at 09:38:09PM +0200, Kornel Benko wrote:
> >>> Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck
> >>> 
>  I guess maybe there is a question worth discussing here about how many
>  of us understand cmake well enough to modify the build scripts when
>  that needs doing. My sense is that the answer is "one",
> >> I also think this is and important question.
> >>
> >>> In alphabetical order:
> >>> Georg
> >>> Peter
> >>> Scott
> >>> Vincent
> >> I do not know CMake well. I suppose I do know enough to make minor
> >> modifications. I've been learning from Kornel and would put more effort
> >> into it if we did decide to move to CMake for our official builds. But
> >> the point remains that at least in the short-run I think we would depend
> >> a lot on one or two developers that have a lot of CMake experience.
> > 
> > It may be then that things are better than it seemed. But Vincent isn't
> > really active nowadays, and I'd like to hear from Georg. From what I've
> > seen on the list, he hasn't always seemed completely comfortable,
> > either, though it's true he does post some patches to the cmake stuff,
> > and of course he can learn.
> 
> I do not really understand cmake. I am able to do very simple modifications 
> which are basically copy-paste, but I tried several times to understand the 
> cmake language and always failed. Each time I needed a non-trivial change I 
> had to ask Kornel.
> 
> 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.

> We cannot afford having two build systems, this is a waste of time. So for 
> me the question is not about the official build system, but about the only 
> one, and since autotools cannot generate MSVC files the only solution is to 
> use cmake (I know none widely used build wystem that is better than cmake).
> 
> 
> IIRC the known show stoppers for making cmake the default build system are 
> some missing features when building the release packages, and the GLOB 
> stuff.

I use GLOB mainly because it was so easy to get the list of files. Sure they 
can be created manually too.

> 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

> 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.
 
> 
> Georg

Kornel

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

Re: One official build system?

[Georg Baum]

Abdelrazak Younes wrote:

> Hi Guys,
> 
> Funny to discover that the same discussion is coming back every couple
> of years :-)

I am not surprised at all, maintaining two build systems with such a small 
amount of developers is simply stupid.

> I think the only point to discuss is the GLOB functionality. AFAIR Georg
> and you are against it and I can understand why. The advantage of GLOB
> are: 1) You do not have to maintain the list of files
> 2) You can move and rename the files from one folder to the other very
> easily.

GLOB is independent from cmake, you could set up autotools in a similar way. 
It is simply a conincidence that those who like cmake also like GLOB.

> The main disadvantage of GLOB is that it can mess up your build if you
> let in the source tree some files that was renamed for debugging or
> development purpose. Personally I never do that because git branching
> and stashing are so good that it is much simpler to use git instead of
> manual renaming; but I can fully understand that you are not comfortable
> with that.

For renaming files or adding new files I would prefer to handle that 
completely in git as well. However, it does not work. If I add a new file 
and then stash the changed away, git adds the new file to the stash, but 
does not delete the one in the local working tree, so when I pop from the 
stash again I get a conflict. Therefore, I do not add new files to the 
stash, and then I can easily move around.

> 1) Switch to CMake now
> 2) Take advantage of GLOB to do the much needed file hierarchy cleanups
> now (both folder hierarchy and file/class names)
> 3) Switch file listing mode without GLOB.

Switching to cmake first and some time later from GLOB to explicit file 
listing would create a huge amount of work, since you would need to recreate 
all file lists from scratch. IMHO it would be much better to write a small 
script that extracts the file lists from autotools and creates the proper 
cmake files from that. Then some reorganization work can be done 
independently of the switch (and if you move files around with git it is not 
much more effort to adjust the file lists as well).


Georg

Re: One official build system?

[Liviu Andronic]

On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
 wrote:
> 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).
>
If moving to cmake definitively would imply losing version suffix
functionality, this would be a big issue for my packaging arrangements
for Ubuntu builds.

Right now I keep master and branch daily builds (as well as
pre-releases) completely independent from stable LyX packages, which
allows people to blissfully install both stable and bleeding edge
versions on the same system, without worrying of corrupting their
production environment. Losing this will probably imply that we can
install only one build at a time on a given system, which will reduce
the testing opportunities for bleeding edge code

Liviu


>
>
> 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?

[Georg Baum]

Richard Heck wrote:

> On 06/03/2016 04:28 PM, Scott Kostyshak wrote:
>> On Fri, Jun 03, 2016 at 09:38:09PM +0200, Kornel Benko wrote:
>>> Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck
>>> 
 I guess maybe there is a question worth discussing here about how many
 of us understand cmake well enough to modify the build scripts when
 that needs doing. My sense is that the answer is "one",
>> I also think this is and important question.
>>
>>> In alphabetical order:
>>> Georg
>>> Peter
>>> Scott
>>> Vincent
>> I do not know CMake well. I suppose I do know enough to make minor
>> modifications. I've been learning from Kornel and would put more effort
>> into it if we did decide to move to CMake for our official builds. But
>> the point remains that at least in the short-run I think we would depend
>> a lot on one or two developers that have a lot of CMake experience.
> 
> It may be then that things are better than it seemed. But Vincent isn't
> really active nowadays, and I'd like to hear from Georg. From what I've
> seen on the list, he hasn't always seemed completely comfortable,
> either, though it's true he does post some patches to the cmake stuff,
> and of course he can learn.

I do not really understand cmake. I am able to do very simple modifications 
which are basically copy-paste, but I tried several times to understand the 
cmake language and always failed. Each time I needed a non-trivial change I 
had to ask Kornel.

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.

We cannot afford having two build systems, this is a waste of time. So for 
me the question is not about the official build system, but about the only 
one, and since autotools cannot generate MSVC files the only solution is to 
use cmake (I know none widely used build wystem that is better than cmake).


IIRC the known show stoppers for making cmake the default build system are 
some missing features when building the release packages, and the GLOB 
stuff. 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. 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).



Georg

Re: SVG display on LyX appears corrupted on the 2.2RC1 Windows build

[Georg Baum]

Guillaume Munch wrote:

> Do you want to commit?

Thanks for the reminder, it is in now at 6bd5263405340b.


Georg

Re: [LyX/master] Do not duplicate jpg format

[Georg Baum]

Guillaume Munch wrote:

> Why not just using a set instead of a vector if this is important?

I believe that the order matters. We prefer the first format that is 
reachable with a converter. With the current solution, qt can give a 
preference, if we used a set then we would prefer the first in alphabetical 
order.


Georg

Re: One official build system?

[Abdelrazak Younes]

Hi Guys,

Funny to discover that the same discussion is coming back every couple 
of years :-)


On 03/06/2016 22:22, Jean-Marc Lasgouttes wrote:

Le 03/06/16 à 18:42, Richard Heck a écrit :

Same here. I am used to autotools, so I use it.


I have reservations about cmake, but I would have some against 
autotools if I was not used to it already. All I ask from cmake is 
that it does the right think (i.e. what we advise people to do) by 
default (both for release and developer versions)


That's very much up to you guys to tell cmake to do the right thing. I 
believe that Kornel has done a lot of work already to



without having to use variables in capital letters that hurt my fingers.


CMake commands can be used lower or upper case. I personally always use 
lower case.




For the rest, I trust that the problems will vanish with time.


I think the only point to discuss is the GLOB functionality. AFAIR Georg 
and you are against it and I can understand why. The advantage of GLOB are:

1) You do not have to maintain the list of files
2) You can move and rename the files from one folder to the other very 
easily.


The main disadvantage of GLOB is that it can mess up your build if you 
let in the source tree some files that was renamed for debugging or 
development purpose. Personally I never do that because git branching 
and stashing are so good that it is much simpler to use git instead of 
manual renaming; but I can fully understand that you are not comfortable 
with that. Another con against GLOB is that we cannot control what the 
user does and there are some chances that he mess up with his source 
tree; in the best case this would just break compilation; in the worst 
case this would introduce very subtle bugs. IMHO, even this


Here is my humble advice to you guys:

1) Switch to CMake now
2) Take advantage of GLOB to do the much needed file hierarchy cleanups 
now (both folder hierarchy and file/class names)

3) Switch file listing mode without GLOB.

Hope that helps,
Abdel.

PS: for 2) I can dig out a proposal I made quite some years ago if you 
are interested