Re: One official build system?

[Pavel Sanda]

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?

Pavel

Re: One official build system?

[Jessica Hamilton]

> The following email thread (3 years ago) suggests that we would like to
> move to one official build system in the long-run across all platforms,
> but that there were barriers to using CMake:
> http://marc.info/?i=kmrd28$e1k$1%20()%20ger%20!%20gmane%20!%20org
>
> Have those issues been resolved?
>
> Is the opinion among currently active LyX developers also that we would
> like to move to CMake as the official build system?
>
> Is CMake currently used for our official builds on Mac and Win?
>
> I don't know much about build systems and I don't have a strong opinion
> on this. I just start this conversation now because of:
>
> (1) the recent discussion about making the release process easier/faster
> (2) it seems like a conversation that should be had at the beginning of
> a major release cycle
>
> From what I understand, most developers on Linux use autotools. I can't
> tell if this is because that is what most developers have experience
> with or if it is because autotools has other advantages.

If there is a move to CMake, I recommend the use of the GNUInstallDirs
module .
This alleviates a lot of pain on platforms with "non-standard"
installation locations.

Re: One official build system?

[Richard Heck]

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.

That said, it's possible this is actually better than with autotools.

Richard

Re: Horizontal crolling impossible in table in float in LyX 2.2.0

[Jean-Marc Lasgouttes]

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

On 06/01/2016 04:46 PM, Jean-Marc Lasgouttes wrote:

Le 01/06/16 à 18:34, Richard Heck a écrit :

I hope to do the 2.1.5 release in a week or so. Once that's been done,
and if nothing really bad has appeared in the meanwhile, then we let's
merge 2.2.2-staging and move towards a 2.2.1 release.


OK. Shall I cherry-pick c8e1c09236 to stable althouhg it is already in
2.2.2?


Yes, that's fine. It should still merge all right.


Done at 7850e77bd912.

JMarc

Re: Changing trac defaults

[Jean-Marc Lasgouttes]

Le 03/06/16 à 22:30, Scott Kostyshak a écrit :

I have set it to "unspecified". Is it better?


Yes, in my opinion this is better.


I also tried to make the ticket keyword plugin work again, but the only 
thing I managed to obtain is a link to our wiki page about keywords. I 
do not know how to debug trac.


JMarc

Re: Changing trac defaults

[Scott Kostyshak]

On Fri, Jun 03, 2016 at 02:07:35PM +0200, Jean-Marc Lasgouttes wrote:
> Le 02/06/2016 à 06:56, Scott Kostyshak a écrit :
> > Now the default milestone is blank, which is great. Can we also have the
> > version be blank by default? I think this would help, as discussed
> > before, so that we know if there is a version specified the user likely
> > has that version. Currently the default version is 2.2.0 and it's hard
> > to know whether that is the version of the user or if the user just did
> > not go to the trouble of changing it (or just didn't see it).
> 
> I have set it to "unspecified". Is it better?

Yes, in my opinion this is better.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Scott Kostyshak]

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 
> > On 06/03/2016 11:37 AM, José Abílio Matos wrote:
> > > On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
> > >> From what I understand, most developers on Linux use autotools. I can't
> > >> tell if this is because that is what most developers have experience
> > >> with or if it is because autotools has other advantages.
> > >>
> > >> Scott
> > > In my case I use autotools by default because that it is what I am used 
> > > to. I do not have any particular attachment to autotools (or cmake).
> > 
> > Same here. I am used to autotools, so I use it.
> > 
> > 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.

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
initial email). I just wonder if it can help with making the release
process easier.

Scott

> > whereas at least two people (JMarc and Georg, maybe others) can do
> > this for autotools.
> > 
> > Richard
> 
>   Kornel




signature.asc
Description: PGP signature

Re: One official build system?

[Jean-Marc Lasgouttes]

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) without having to use variables in 
capital letters that hurt my fingers.


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

JMarc

Re: One official build system?

[Scott Kostyshak]

On Fri, Jun 03, 2016 at 09:34:15AM -0600, Joel Kulesza wrote:
> On Fri, Jun 3, 2016 at 9:11 AM, Guillaume Munch  wrote:
> 
> >
> > What are the
> > advantages? What are the basic commands? How do you set up
> > out-of-directory builds?
> >
> >
> I am far from an expert; however, a self-contained and somewhat compact
> application of CMake is available here:
> https://github.com/jkulesza/NERS590_Project.
> 
> The basic commands are in the src/CMakeLists.txt file (which are almost
> certainly *not* following best practices, but they and their simplicity
> have served me well).
> 
> A simple script to drive out-of-source builds is shown in build/.
> 
> Advantages I might identify, without attempting to articulate further: it
> automates the Makefile generation process removing much of the manual labor
> (particularly as source files are added/removed).  In principle, it can
> also find compilers/libraries on the system quite readily and can be set up
> to flexibly use them in various combinations.  With various targets, it can
> also be setup to build release, debug, etc. for (straightforward) use with
> continuous-integration testing.
> 
> P.S. I hope you don't mind me chiming in...

Not at all, Joel! Please chime away. Any help is appreciated.

Guillaume, I didn't look in depth at the above, but if you have any
question, please ask. I usually just ask Kornel and he is happy to help.
I'm not sure it is worth your time though, unless we do decide to make
it our official build system. It is not clear yet we want that.

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Kornel Benko]

Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck 
> On 06/03/2016 11:37 AM, José Abílio Matos wrote:
> > On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
> >> From what I understand, most developers on Linux use autotools. I can't
> >> tell if this is because that is what most developers have experience
> >> with or if it is because autotools has other advantages.
> >>
> >> Scott
> > In my case I use autotools by default because that it is what I am used to. 
> > I do not have any particular attachment to autotools (or cmake).
> 
> Same here. I am used to autotools, so I use it.
> 
> 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",

In alphabetical order:
Georg
Peter
Scott
Vincent

> whereas at least two
> people (JMarc and Georg, maybe others) can do this for autotools.
> 
> Richard

Kornel

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

Re: Basic test of alpha1 tar

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 24/05/2016 23:37, Pavel Sanda a écrit :
 I only tried 2.2, so I did not really compare. I do not have 2.0 here. I
 can try to have a look at 2.1 vs 2.2 later.
>>>
>>> Please try, we should see whether the problem is reproducible at all...
>>
>> Since you were asking in different thread, ping :)
>
> When I looked at that, I did not find much. I'll have to return to it.

You mean, you couldn't reproduce the problem, correct? Pavel

Re: [LyX/master] Introduce basic support for microtype.sty.

[Pavel Sanda]

Kornel Benko wrote:
> > --- a/src/frontends/qt4/ui/FontUi.ui
> > +++ b/src/frontends/qt4/ui/FontUi.ui
> ...
> > 
> > +   
> > +
> > + 
> > +  Activate extensions such as character protusion and font 
> > expansion via the microtype package
> > + 
> 
> Do you mean protrusion instead?

Yes, thanks Kornel. Pavel

Re: One official build system?

[Richard Heck]

On 06/03/2016 11:37 AM, José Abílio Matos wrote:
> On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
>> From what I understand, most developers on Linux use autotools. I can't
>> tell if this is because that is what most developers have experience
>> with or if it is because autotools has other advantages.
>>
>> Scott
> In my case I use autotools by default because that it is what I am used to. I 
> do not have any particular attachment to autotools (or cmake).

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

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", whereas at least two
people (JMarc and Georg, maybe others) can do this for autotools.

Richard

Re: Horizontal crolling impossible in table in float in LyX 2.2.0

[Richard Heck]

On 06/01/2016 04:46 PM, Jean-Marc Lasgouttes wrote:
> Le 01/06/16 à 18:34, Richard Heck a écrit :
>> I hope to do the 2.1.5 release in a week or so. Once that's been done,
>> and if nothing really bad has appeared in the meanwhile, then we let's
>> merge 2.2.2-staging and move towards a 2.2.1 release.
>
> OK. Shall I cherry-pick c8e1c09236 to stable althouhg it is already in
> 2.2.2?

Yes, that's fine. It should still merge all right.

Richard

Wishlist for future LyX

[Helge Hafting]

Now that we have 2.2.0, here are some wishes for the future:


Enumeration style document setting

==

GUI for setting the numbering style, similiar to what we already have 
for bullet lists. I.e. the default for the 4 levels are "1.", "(a)", 
"i.", "A."


The gui would change that. Perhaps I want "a)" [not "(a)"] on the first 
level, and uppercase roman numerals on the second level. The LaTeX code 
to achieve this is easy enough. And of course the main window would 
change to reflect this setting too.


This, (and \thispagestyle), is what usually forces me to use LaTeX in 
LyX these days.



Bullet lists displaying correct symbols

==

We already have a GUI for selecting different symbols. It'd be nice if 
the bullet lists in the main window respected this, and showed the 
selected bullet instead of a hardcoded default. (Except when the user 
sets a custom bullet. Well, even that could be attempted rendered via 
the preview mechanism. If this result in latex failure or a blank image, 
fall back on a hardcoded default symbol.)



Case-respecting search/replace



A case-following search/replace. So if I replace “zeppeliner” with 
“balloon”, it will understand that “Zeppeliner” is to be replaced by 
“Balloon”. (And ZEPPELINER->BALLOON)


Some characters (dotless i, double.-dot i, german ss) does not exist in 
both cases. Not replacing those is ok, the common case is good enough here.



Box alignments that works "the way I mean"

==

You align boxes vertically by top, bottom or center. And it doesn't 
necessarily work. What you get, does not line up as specified – 
depending on box content. (table & image side-by-side being a nasty 
common case.)


The manuals tells us how to fix this by putting in protected spaces or 
other latex constructs first/last inside the box. This is due to obscure 
limitations of latex, but I don't see why LyX, as a WYSIWYM tool, should 
reproduce such oddities. If I say the boxes is to be aligned by their 
bottom, then they should - regardless of content.


When LyX exports a box to latex, it could export the necessary 
zero-width/height latex constructs to make the box align as the user 
specified in the dialog – no matter what content the box may have.


This would remove a recurring question/frustration from the user's list. 
A well-written latex construct should not create trouble. A weird user 
who wants a figure & table side by side that does not line up well, can 
go and write his box with TeX code instead of Insert->Frame. (Or if this 
really pains anyone, add a checkbox for “not correcting alignment” in 
the box settings dialog. But I have a hard time imagining a use case for 
this.)



Helge Hafting

Re: Tarballs for LyX 2.2.0 are on FTP

[José Abílio Matos]

On Friday, June 3, 2016 2:02:15 PM WEST Jean-Marc Lasgouttes wrote:
> I prefer the fixed schedule. We never know exactly when starting a 
> release cycle what features will happen or not. But we can enforce when 
> the release will happen.

+1

-- 
José Abílio

Re: One official build system?

[José Abílio Matos]

On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
> From what I understand, most developers on Linux use autotools. I can't
> tell if this is because that is what most developers have experience
> with or if it is because autotools has other advantages.
> 
> Scott

In my case I use autotools by default because that it is what I am used to.
I do not have any particular attachment to autotools (or cmake).

With my Fedora hat on (pun intended) it does not matter which one is used to 
build, both are well supported in Fedora.

Regards,
-- 
José Abílio

Re: One official build system?

[Joel Kulesza]

On Fri, Jun 3, 2016 at 9:11 AM, Guillaume Munch  wrote:

>
> What are the
> advantages? What are the basic commands? How do you set up
> out-of-directory builds?
>
>
I am far from an expert; however, a self-contained and somewhat compact
application of CMake is available here:
https://github.com/jkulesza/NERS590_Project.

The basic commands are in the src/CMakeLists.txt file (which are almost
certainly *not* following best practices, but they and their simplicity
have served me well).

A simple script to drive out-of-source builds is shown in build/.

Advantages I might identify, without attempting to articulate further: it
automates the Makefile generation process removing much of the manual labor
(particularly as source files are added/removed).  In principle, it can
also find compilers/libraries on the system quite readily and can be set up
to flexibly use them in various combinations.  With various targets, it can
also be setup to build release, debug, etc. for (straightforward) use with
continuous-integration testing.

P.S. I hope you don't mind me chiming in...

Re: One official build system?

[Guillaume Munch]

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

Dear all,

The following email thread (3 years ago) suggests that we would like to
move to one official build system in the long-run across all platforms,
but that there were barriers to using CMake:
http://marc.info/?i=kmrd28$e1k$1%20()%20ger%20!%20gmane%20!%20org

Have those issues been resolved?

Is the opinion among currently active LyX developers also that we would
like to move to CMake as the official build system?

Is CMake currently used for our official builds on Mac and Win?

I don't know much about build systems and I don't have a strong opinion
on this. I just start this conversation now because of:

(1) the recent discussion about making the release process easier/faster
(2) it seems like a conversation that should be had at the beginning of
a major release cycle

 From what I understand, most developers on Linux use autotools. I can't
tell if this is because that is what most developers have experience
with or if it is because autotools has other advantages.

Scott



From my perspective it is mostly ignorance about CMake. I would be happy
to give it a try and do not mind if it was default. What are the
advantages? What are the basic commands? How do you set up
out-of-directory builds?

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

[Guillaume Munch]

Le 02/06/2016 21:33, Georg Baum a écrit :

commit 8d255ced2a003b2b8262bf51d1b245ff0dee9dc3
Author: Georg Baum 
Date:   Thu Jun 2 22:31:27 2016 +0200

 Do not duplicate jpg format

 Some qt versions report both "jpeg" and "jpg" as loadable file extensions.
 In this case the jpg format was added twice previously. This does not 
happen
 anymore with the new code, and it works as well if only "jpg" or only 
"jpeg"
 is reported.

diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index b3efd78..1513636 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -227,14 +227,25 @@ vector loadableImageFormats()
if (qt_formats.empty())
LYXERR(Debug::GRAPHICS, "\nQt4 Problem: No Format available!");

+   bool jpeg_found = false;
+   bool jpg_found = false;
for (QList::const_iterator it = qt_formats.begin(); it != 
qt_formats.end(); ++it) {

LYXERR(Debug::GRAPHICS, (const char *) *it << ", ");

string ext = ascii_lowercase((const char *) *it);
// special case
-   if (ext == "jpeg")
+   if (ext == "jpeg") {
+   jpeg_found = true;
+   if (jpg_found)
+   continue;
ext = "jpg";
+   }
+   else if (ext == "jpg") {
+   jpg_found = true;
+   if (jpeg_found)
+   continue;
+   }
fmts.push_back(ext);
}




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

Re: Tarballs for LyX 2.2.0 are on FTP

[Jean-Marc Lasgouttes]

Le 03/06/2016 à 15:03, Liviu Andronic a écrit :

We already have nightly builds for Ubuntu Linux:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

It's been running for couple of years (probably all through the 2.2
development cycle), though I'm not sure it's made much of an impact in
terms of testing and bug reports. (I still have to update the
packaging arrangements for 2.3dev, but it should be up and running
"soon".)


We should advertise it.

JMarc

Re: Tarballs for LyX 2.2.0 are on FTP

[Liviu Andronic]

On Fri, Jun 3, 2016 at 2:02 PM, Jean-Marc Lasgouttes  wrote:
> Le 31/05/2016 à 22:26, Georg Baum a écrit :
>>
>> We need to decide: Either have a fixed schedule, and an unknown feature
>> set
>> of the next release, or a fixed feature set, and an unknown schedule. We
>> do
>> not have enough man power for defining both a fixed feature set and a
>> fixed
>> release schedule.
>
>
> I prefer the fixed schedule. We never know exactly when starting a release
> cycle what features will happen or not. But we can enforce when the release
> will happen.
>
I too would favour a fixed schedule. Have a planned ~1 year release
cycle (instead of the 2-2.5 years we currently have, on average), and
start the release process and discussing tagging alpha some 6-8 months
into the cycle. This will help avoid burn out for devels and dragging
new features in trunk for longer than necessary, and avoid too much
uncertainty on when the release will actually happen. This will also
make it possible to make fileformat changes more often than we now do,
and bring about serious testing of trunk (with alpha and beta
releases) by end users less than a year since major features were
introduced on GIT.



>> - 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.
>
We already have nightly builds for Ubuntu Linux:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

It's been running for couple of years (probably all through the 2.2
development cycle), though I'm not sure it's made much of an impact in
terms of testing and bug reports. (I still have to update the
packaging arrangements for 2.3dev, but it should be up and running
"soon".)


Liviu





-- 
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: Changing trac defaults

[Jean-Marc Lasgouttes]

Le 02/06/2016 à 06:56, Scott Kostyshak a écrit :

Now the default milestone is blank, which is great. Can we also have the
version be blank by default? I think this would help, as discussed
before, so that we know if there is a version specified the user likely
has that version. Currently the default version is 2.2.0 and it's hard
to know whether that is the version of the user or if the user just did
not go to the trouble of changing it (or just didn't see it).


I have set it to "unspecified". Is it better?

JMarc

Re: Tarballs for LyX 2.2.0 are on FTP

[Jean-Marc Lasgouttes]

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

We need to decide: Either have a fixed schedule, and an unknown feature set
of the next release, or a fixed feature set, and an unknown schedule. We do
not have enough man power for defining both a fixed feature set and a fixed
release schedule.


I prefer the fixed schedule. We never know exactly when starting a 
release cycle what features will happen or not. But we can enforce when 
the release will happen.



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.


- Automate windows installer generation. This would probably mean to switch
to mingw, since we can do both a mingw build and run nsis from a linux
machine.


Yes.


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


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


JMarc

Re: Require C++11 for 2.3?

[Jean-Marc Lasgouttes]

Le 03/06/2016 à 07: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.


Hello Scott,

Yes, that's the plan.

JMarc

Re: [LyX/master] Introduce basic support for microtype.sty.

[Kornel Benko]

Am Freitag, 3. Juni 2016 um 07:49:08, schrieb Pavel Sanda 
> commit ba2b86fa5d718c434521a7b9722e6ccd677864ad
> Author: Pavel Sanda 
> Date:   Thu Jun 2 22:40:21 2016 -0700
> 
> Introduce basic support for microtype.sty.
> 
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg192743.html
> 

...

> --- a/src/frontends/qt4/ui/FontUi.ui
> +++ b/src/frontends/qt4/ui/FontUi.ui
...
> 
> +   
> +
> + 
> +  Activate extensions such as character protusion and font 
> expansion via the microtype package
> + 

Do you mean protrusion instead?

Kornel



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