Re: [LyX/master] configure.py: Make 'notepad' last in text editor list

[Guenter Milde]

On 2017-01-14, Paul A. Rubin wrote:

...

> Is there any evidence that xdg-mime/xdg-open will ever be safe?

Not bullet-proof but maybe safe enaugh to be used as default.

+1 in a properly configured system, the system-wide user preference will be
   honoured, no need to configure preferences for both, xdg and lyx.
   
-1 the "xdg-preference" may be worse than what LyX currently uses (at least
   for the moment this is a real problem).

> Right now I see two problems with it, one of which can be avoided. The 
> original show-stopper was that it defaulted to opening files in the web
> browser if no default application was set. We can work around that by 
> using xdg-mime to test whether a default is set in the MIME database.
> If yes, we can make xdg-open the file handler; if not, we can do what
> we currently do.

Or we can use the default returned by xdg-mime as first choice and keep
our list of fallbacks.


> The bigger problem, in my mind, is that xdg-mime sometimes finds a 
> default application, but not the one actually used by the system. I 
> mentioned this in an earlier message, after stumbling on it 
> accidentally. I found xdg-open using a "stale" default from 
> ~/.local/share/applications/mimeapps.list when the correct default was 
> set in ~/.config/mimeapps.list.
...
> In any case, unless my laptop is an outlier, there may be users out
> there for whom xdg-utils would select not the browser but some other
> incorrect (and, in one case on my laptop, not even installed)
> application.

This is one of the things that hopefully will settle over time.
Users/distros removing the stale files, maybe xdg-* excluding or
downgrading the stale files if the correct ones are present, 
applications no longer using obsolete paths and properly cleaning up when
de-installed, ...


> Rather than waiting on xdg-utils to be fixed (if in fact Freedesktop 
> even sees this as a bug -- I have no idea about that), should we look at 
> gvfs-mime/gvfs-open (again with the stipulation that we first check 
> whether a default application is set, and if not revert to our current 
> practice)? It works on both my systems, but they're both running recent 
> (albeit different) versions of Linux Mint. If we move in this direction, 
> I think we should first ask devs with other Linux distributions to test 
> it (which can be done with a simple shell script).

I had the impression that gvfs-mime is (or should be) superseded by
xdg-mime, so I would not propose to invest in this direction.

The MINT problem is now fixed with simpler changes.


> Incidentally, for people ill served by the configuration script, one way 
> to reduce the pain would be to add something in the Tools > 
> Preferences... dialogs that would allow the user, in one step, to set a 
> new default viewer or editor for all file formats of a certain ilk (all 
> PDF formats, all text formats, all image formats). Having to change the 
> viewer for PDF (pdflatex) every time I reconfigure is mildly annoying; 
> having to change it for multiple PDF formats after each reconfiguration 
> is serious annoying.

Indeed, GUI support to change the viewer/editor "file-type wise" would be
a real advantage. The different sub-formats (pdf1...5 etc) are just an
internal way to specify the different export routes.

Thanks for the suggestions,

Günter

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Pavel Sanda]

Christian Ridderström wrote:
> Hi,
> 
> I'd like to announce that we now have a (somewhat) working system for doing
> continuous integration (CI) of the LyX master branch on Linux.
> 
> The system is currently doing this:
> - Polls the LyX repository at git.lyx.org  (every few hours)
> - If branch 'master' has changed, then it builds LyX in two different
> configurations

What you mean by build? "make" or "make distcheck"?
The second one would be more useful, especially if it sends
warning to the list if error was found.

Pavel

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Christian Ridderström]

On 19 January 2017 at 01:45, Pavel Sanda  wrote:

> > The system is currently doing this:
> > - Polls the LyX repository at git.lyx.org  (every few hours)
> > - If branch 'master' has changed, then it builds LyX in two different
> > configurations
>
> What you mean by build? "make" or "make distcheck"?
>
The second one would be more useful,


Currently it's "make" (I didn't know about distcheck), e.g. the CMake
version does this:

cmake -DLYX_USE_QT=QT5 .. && make

Trying with just "make distcheck" instead of "make" produced error about
missing target 'distcheck'.
I can try with "make && make distcheck" instead of "make" and see if I can
get that working.

Let me know if there's other options or similar that ought to be used.

Here's the build scripts used in the two containers (using only "make"):
-
https://github.com/DrChr/build-lyx-using-ubuntu-latest-qt5-cmake/blob/master/build_lyx.sh
-
https://github.com/DrChr/build-lyx-using-ubuntu-xenial-qt4-autotools/blob/master/build_lyx.sh



> especially if it sends warning to the list if error was found.
>

There seems to be RSS feeds available right now (see bottom right corner of
https://ci.inria.fr/lyx/ ) that I was able to add to my RSS reader (
http://theoldreader.com) . It's probably also possible to get the CI server
to send e-mail notifications to lyx-devel, assuming we want that?

/Christian

-- 
Christian Ridderström, +46-70 687 39 44

Re: Dependencies to build LyX (from Git) on clean Ubuntu 16.04 using Qt5?

[Christian Ridderström]

On 18 January 2017 at 01:21, Scott Kostyshak  wrote:

> On Tue, Jan 17, 2017 at 11:54:02PM +0100, Christian Ridderström wrote:
> > Hi,
> >
> > Does anyone have a list of the build dependencies that need to be
> installed
> > in order to build the latest LyX on a clean Ubuntu 16.04 using Qt5?
> I.e.,
> > I'm looking for the
> >
> >sudo apt-get install build-essential ... XXX
> >
> > and the other steps you need to do in order to be able build LyX with
> Qt5.
>
> I think you can just do
>
>   sudo apt-get build-dep lyx
>
> Does that work?
>

I tried that, but it installed Qt4-libraries. Perhaps it's assuming
dependencies as per LyX using Qt4.

In case it helps someone else, using cmake I could get LyX to build on a
clean Ubuntu 16.04 using:

apt-get update \

&& DEBIAN_FRONTEND=noninteractive apt-get install -y \

build-essential \

qt5-default \

qtbase5-dev \

libqt5svg5-dev \

python \

cmake

followed by these commands from within in a cloned LyX repository:

mkdir -p build
cd build
cmake -DLYX_USE_QT=QT5
make


However, I still want to make it work using autotools, so I'm going to give
that another go.
I'll write again in this thread, either if I can't make work or with the
commands that makes it work.

Regards,
Christian


>
> > I've been searching the web for some build instructions and the best I
> > found so far was this script:
> >https://github.com/scottkosty/lyx-tester/blob/master/CreateQt5
> >
> > I'm hoping not all of the dependencies in that script are needed, and
> that
> > Qt5 can be installed rather than built.
>
> Yes that script is for compiling Qt 5, which I don't think you want.
>
> Scott
>



-- 
Christian Ridderström, +46-70 687 39 44

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Pavel Sanda]

Christian Ridderström wrote:
> On 19 January 2017 at 01:45, Pavel Sanda  wrote:
> 
> > > The system is currently doing this:
> > > - Polls the LyX repository at git.lyx.org  (every few hours)
> > > - If branch 'master' has changed, then it builds LyX in two different
> > > configurations
> >
> > What you mean by build? "make" or "make distcheck"?
> >
> The second one would be more useful,
> 
> 
> Currently it's "make" (I didn't know about distcheck), e.g. the CMake
> version does this:
> 
> cmake -DLYX_USE_QT=QT5 .. && make
> 
> Trying with just "make distcheck" instead of "make" produced error about
> missing target 'distcheck'.

distcheck is autotools not cmake target. Since we (still) build tarballs
via automake it would be worth using this target.

I just tried running make distcheck here and immediately got error,
which is exactly why your machinery could be useful!

Simply running distcheck once a day and send email to lyx-devel in case of 
error.

Otherwise it can take quite some time to find the offender (the error
messages are sometimes convoluted).

> There seems to be RSS feeds available right now (see bottom right corner of
> https://ci.inria.fr/lyx/ ) that I was able to add to my RSS reader (
> http://theoldreader.com) . It's probably also possible to get the CI server
> to send e-mail notifications to lyx-devel, assuming we want that?

If you don't have SMTP machinery working on that machine I can send you simple
shell script that would do the sending job. You just need port 25 open & SMTP
server accepting us.

Pavel

PS: the current err if it rings bell to someone, I guess just entry in makefile 
is missing:
make[1]: *** No rule to make target `export/ja/wrong_auto_encoding.lyx', needed

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Christian Ridderström]

On 19 January 2017 at 03:17, Pavel Sanda  wrote:

> >
> > Trying with just "make distcheck" instead of "make" produced error about
> > missing target 'distcheck'.
>
> distcheck is autotools not cmake target. Since we (still) build tarballs
> via automake it would be worth using this target.
>

Ok, understood.


> I just tried running make distcheck here and immediately got error,
> which is exactly why your machinery could be useful!
>

I get the same error (output attached below) for doing 'make && make
distcheck'


> Simply running distcheck once a day and send email to lyx-devel in case of
> error.
>
> Otherwise it can take quite some time to find the offender (the error
> messages are sometimes convoluted).
>
> > There seems to be RSS feeds available right now (see bottom right corner
> of
> > https://ci.inria.fr/lyx/ ) that I was able to add to my RSS reader (
> > http://theoldreader.com) . It's probably also possible to get the CI
> server
> > to send e-mail notifications to lyx-devel, assuming we want that?
>
> If you don't have SMTP machinery working on that machine I can send you
> simple
> shell script that would do the sending job. You just need port 25 open &
> SMTP
> server accepting us.
>

The Jenkins SW is capable of sending an e-mail, I just tested to two of my
e-mail addresses.
But to where should e-mails be sent - lyx-devel-list?

I think the sender, ci-...@inria.fr, needs to be added to a list of
approved addresses or something.
/Christian


>
> Pavel
>
> PS: the current err if it rings bell to someone, I guess just entry in
> makefile is missing:
> make[1]: *** No rule to make target `export/ja/wrong_auto_encoding.lyx',
> needed
>

It's the same error I get.
Below's my full log:

# make distcheck

make  dist-bzip2 dist-gzip am__post_remove_distdir='@:'

make[1]: Entering directory '/usr/src/lyx'

if test -d "lyx-2.3.0dev"; then find "lyx-2.3.0dev" -type d ! -perm -200
-exec chmod u+w {} ';' && rm -rf "lyx-2.3.0dev" || { sleep 5 && rm -rf
"lyx-2.3.0dev"; }; else :; fi

test -d "lyx-2.3.0dev" || mkdir "lyx-2.3.0dev"

 (cd 3rdparty && make  top_distdir=../lyx-2.3.0dev
distdir=../lyx-2.3.0dev/3rdparty \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[2]: Entering directory '/usr/src/lyx/3rdparty'

 (cd boost && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/boost \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/boost'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/boost'

 (cd hunspell && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/hunspell \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/hunspell'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/hunspell'

 (cd libiconv && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/libiconv \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/libiconv'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/libiconv'

 (cd zlib && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/zlib \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/zlib'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/zlib'

make[2]: Leaving directory '/usr/src/lyx/3rdparty'

 (cd autotests && make  top_distdir=../lyx-2.3.0dev
distdir=../lyx-2.3.0dev/autotests \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[2]: Entering directory '/usr/src/lyx/autotests'

make[2]: *** No rule to make target 'export/ja/wrong_auto_encoding.lyx',
needed by 'distdir'.  Stop.

make[2]: Leaving directory '/usr/src/lyx/autotests'

Makefile:674: recipe for target 'distdir' failed

make[1]: *** [distdir] Error 1

make[1]: Leaving directory '/usr/src/lyx'

Makefile:772: recipe for target 'dist' failed

make: *** [dist] Error 2




-- 
Christian Ridderström, +46-70 687 39 44

System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Christian Ridderström]

Hi,

I'd like to announce that we now have a (somewhat) working system for doing
continuous integration (CI) of the LyX master branch on Linux.

The system is currently doing this:
- Polls the LyX repository at git.lyx.org  (every few hours)
- If branch 'master' has changed, then it builds LyX in two different
configurations
  - Ubuntu 16.04, Qt4, Autotools
  - Ubuntu 16.04, Qt5, CMake

You can see the status of some CI jobs on this web page:
   https://ci.inria.fr/lyx/job/build-master-head/

The CI platform is provided by Inria, thanks to Jean-Marc and Guillaume.
Joel has also been part of the discussions, and talking with them led to me
setting up this CI system for LyX.
For access to the CI server etc, contact Jean-Marc or Guillaume.

The CI server is a Jenkins instance that distributes jobs to virtual
machines (CI workers), where we today currently use two Linux VMs. The
actual building of LyX is done by Docker containers, one container for each
configuration as per above, so the CI worker doesn't actually have to be
running Linux. Here's a link to one of the Docker images at Docker Hub:

https://hub.docker.com/r/lyxproject/build-lyx-using-ubuntu-latest-qt5-cmake/
The Dockerfile has more details and usage instructions, e.g. in case you'd
like to use a Docker container to perform the same build locally.

Regards,
Christian

PS.
Regarding the part of "somewhat" working:

Currently builds mostly fail because I'm trying out different settings or
the CI worker runs out of disk space..  But someday a build will perhaps
fail due to bad LyX code, in which case we could catch it.  The CI system
should build on more configurations, and probably build more branches than
just 'master'. And it should also be running test cases.

-- 
Christian Ridderström, +46-70 687 39 44

Re: Convertor lyx2.1 -> lyx2.2 does not understand TikZ in math macros

[Richard Heck]

On 01/17/2017 06:06 PM, חיים רוזנר wrote:
> Hi,
> I upgraded lyx 2.1 to lyx 2.2 (Win 10). I have a file with lots of
> tikz environments and some math macros. The convertor took the -- line
> command of tikz in the math macro and converted it to \twohyphens.
> This conversion made me errors.
>
> Attached are a minimal example from LyX 2.1 and its automatic
> conversion to LyX 2.2.
>
> Thanks for all your effort.

I've fixed this for 2.2.3, but it's very easy to fix it for yourself
now. Find the file lyx_2_2.py and open it with a text editor. At line
622, in the convert_dashes routine, you will see:

if len(words) > 1 and words[0] == "\\begin_inset" and \
   words[1] in ["CommandInset", "ERT", "External", "Formula",
"Graphics", "IPA", "listings"]:
# must not replace anything in insets that store LaTeX
contents in .lyx files

This is a list of places not to convert --. Add "FormulaMacro" to the list.

Richard

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Pavel Sanda]

Christian Ridderström wrote:
> The Jenkins SW is capable of sending an e-mail, I just tested to two of my
> e-mail addresses.
> But to where should e-mails be sent - lyx-devel-list?

I would think so, unless other people are not against it.

> I think the sender, ci-...@inria.fr, needs to be added to a list of
> approved addresses or something.

Can you receive mails from ci-...@inria.fr?
If yes then just sent from that address email to 
lyx-devel-subscr...@lists.lyx.org
and reply to the mail you get.
>From that point ci-...@inria.fr mails should be accepted.
(I am not sure whether ci-...@inria.fr has to be used for envelope
are just correct From: header is enough for our list, you have to try :)

> It's the same error I get.

Yes, if you get this machinery working, I will invest some time
to clean up distcheck (again...) so we can start fresh.

P

Re: [CONFIRMED] Display Problem in Stable with \notin, etc.

[Jean-Marc Lasgouttes]

Le 17/01/2017 à 18:01, Enrico Forestieri a écrit :

Hello Enroci,


Hi JMcra :)


:)

I often do this typo, but usually I manage to correct it in time.


Yes, but I would propose to do that in addition. Nonetheless, my feeling
is that this issue is caused by the assumptions of Qt about a given font.
For example, it refuses to draw the glyph of a character whose codepoint
corresponds to a soft hyphen, irrespective of the actual font, and other
such amenities.


I am not completely sure what this styleName thing does. Is it 
mac/windows only? Is it Qt 4.8+ only? Will the bug exist on other 
systems with your patch applied?


But I see that you introduced this thing in f496ec3 and I presume that 
you understand it!


Concerning master, applying your patch breaks \neq, presumably because 
Guillaume worked around the problem manually.


Here is what I came up with. Is it what you had in mind, or should the 
|| in the test become a && ?


You can see that the \kern in the definition of \not is gone, and this 
is definitely a good thing.


JMarc


diff --git a/lib/symbols b/lib/symbols
index 82a6d13..2318d74 100644
--- a/lib/symbols
+++ b/lib/symbols
@@ -314,7 +314,7 @@ spadesuit  cmsy127 170 mathord  
 lyxnot cmsy 54  47 mathrel  /   hiddensymbol
 iffont cmsy
 # kerning is slightly imperfect so that one can see when \not is selected
-\def\not{\lyxnot\mathrel{\kern-11mu}}
+\def\not{\lyxnot}
 else
 \def\not{\kern4mu\lyxnot\kern-19mu}
 endif
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index a0fa699..2f598f4 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -182,17 +182,28 @@ int GuiFontMetrics::width(docstring const & s) const
 	int * pw = strwidth_cache_[s];
 	if (pw)
 		return *pw;
-	// For some reason QMetrics::width returns a wrong value with Qt5
-	// int w = metrics_.width(toqstr(s));
 	PROFILE_CACHE_MISS(width)
 #endif
-	QTextLayout tl;
-	tl.setText(toqstr(s));
-	tl.setFont(font_);
-	tl.beginLayout();
-	QTextLine line = tl.createLine();
-	tl.endLayout();
-	int w = int(line.naturalTextWidth());
+	/* For some reason QMetrics::width returns a wrong value with Qt5
+	 * with some arabic text. OTOH, QTextLayout is broken for single
+	 * characters with null width (like \not in mathed).
+	*/
+	int w = 0;
+	if (s.length() == 1
+#if QT_VERSION >= 0x040800
+	|| font_.styleName() == "LyX"
+#endif
+	)
+		w = metrics_.width(toqstr(s));
+	else {
+		QTextLayout tl;
+		tl.setText(toqstr(s));
+		tl.setFont(font_);
+		tl.beginLayout();
+		QTextLine line = tl.createLine();
+		tl.endLayout();
+		w = int(line.naturalTextWidth());
+	}
 #ifdef CACHE_METRICS_WIDTH
 	strwidth_cache_.insert(s, new int(w), s.size() * sizeof(char_type));
 #endif

Re: [CONFIRMED] Display Problem in Stable with \notin, etc.

[Enrico Forestieri]

On Wed, Jan 18, 2017 at 03:19:31PM +0100, Jean-Marc Lasgouttes wrote:
> 
> I am not completely sure what this styleName thing does. Is it mac/windows
> only?

No, it is platform independent. For example, if you ask for a font with
name cmsy10, Qt would pick the first cmsy10.ttf it stumbles upon. This
would be unfortunate because, due to its idiosyncratic behavior, Qt will
not display many symbols with a certain codepoint. So, we replicated some
glyphs at different positions and tell Qt to display those ones. In order
to be sure of using our fonts, we ask for a font with a given name *and*
style "LyX". This is our own style name, so we can be sure we are using
the right fonts.

> Is it Qt 4.8+ only?

Yes, that method was introduced in Qt 4.8.

> Will the bug exist on other systems with your
> patch applied?

Only if the fonts we use for math are not our owns. But if they are not,
many other symbols would be broken. So, this would be only a minor issue.

> But I see that you introduced this thing in f496ec3 and I presume that you
> understand it!

Actually, I introduced that style name in our fonts using fontforge.

> Concerning master, applying your patch breaks \neq, presumably because
> Guillaume worked around the problem manually.

Possibly. But see below.

> Here is what I came up with. Is it what you had in mind, or should the || in
> the test become a && ?

No, the || is fine. My rationale is the following. Qt has its own idea
of what a font should contain, and in the past we had to workaround its
shortcomings several times. So, when we are sure that a certain code works
with our fonts, we should stick with it to avoid bad surprises. Now we have
a way of telling when we are dealing with our fonts through the styleName
thing.

> You can see that the \kern in the definition of \not is gone, and this is
> definitely a good thing.

I see that your patch is for master. I would advise to apply this patch
only to stable (minus the lib/symbols bit, which is not needed there).
This is because we know what is causing the issue in stable and thus the
patch is fine. However, the issue does not manifest in master, meaning
that someone deployed a corrective action to avoid it. We have to
understand what this action was and then decide. As you can see, the
\kern in the definition of \not is also in stable but it is not a problem
there. My fear is that we put a patch on top of another patch without
an understanding of what is happening, and this can bite later.

-- 
Enrico