Re: [LyX/master] Fix 480937a103708a651/lyxgit. See also #9740.
On 2015-11-12, Kornel Benko wrote:
> The actual failed export tests.
> 117 failed, that is 9 less than previously. We are advancing.
> 309:export/doc/EmbeddedObjects_pdf4_systemF
Example of "high bit" chars in listings. Fails with XeTeX due ot
limiation to ASCII (no LICR in listings possible). Gives correct warning.
-> invert or ignore.
> 351:export/doc/LaTeXConfig_dvi3_texF
> 358:export/doc/LaTeXConfig_pdf5_texF
This generated has inputenc = "default" (i.e. language default encoding
without inputenc calls). Fails for non-ASCII character (Komödie) with LuaTeX.
Correct the template to include \usepackage[latin9]{inputenc}.
> 406:export/doc/UserGuide_pdf4_texF
Non-ASCII char in verbatim environment.
Fails with ASCII (and hence also with XeTeX).
-> invert or ignore.
> 550:export/doc/de/Additional_pdf4_texF
> 565:export/doc/de/Customization_pdf5_systemF
> 599:export/doc/de/EmbeddedObjects_pdf4_systemF
> 670:export/doc/de/UserGuide_pdf4_texF
Non-ASCII characters in a comment in the user-preamble.
Warning with inputenc == ASCII or XeTeX
-> change preamble, invert, or ignore.
> 694:export/doc/es/Additional_pdf4_texF
ERT (tabular) with non-ASCII chars, fails with inputenc == ASCII and XeTeX
-> convert ERT to LyX, invert, or ignore.
> 709:export/doc/es/Customization_pdf5_systemF
cannot reproduce
> 737:export/doc/es/EmbeddedObjects_dvi3_texF
> 742:export/doc/es/EmbeddedObjects_pdf4_texF
> 744:export/doc/es/EmbeddedObjects_pdf5_texF
non-ASCII character in user preamble comment
undefined control sequence in listings
> 743:export/doc/es/EmbeddedObjects_pdf4_systemF
\usepackage{lmodern} in preamble.
Enough for today,
Günter
Re: We now include both png and svgz?
On Sun, Nov 15, 2015 at 05:59:38PM +0100, Jean-Marc Lasgouttes wrote: > Le 15/11/2015 17:57, Georg Baum a écrit : > >OK, if it is assumed that qt can show svg images, then it does not make > >sense to ship or own .pngs. If we want to stick with this, we should remove > >the .pngs now and require qtsvg at configure time. > > > >For me personally the svgs work fine both with qt 4.8 and 5.3, so I would > >not have a problem with that. I only thought there might by exotic systems > >where it does not work, and therefore I thought it might be a good idea to > >ship both png and svg for one release, instead of switching from only png > >directly to only svg. > > Or we only ship svg for our beats and see what happens. We could decide to > re-introduce pngs if needed. > > In any case, it is good to have the code for pngs still working. Is the only disadvantage of including the .pngs bloat in the sense that we are increasing the size of our tars and of the repos? Or is there a concern that shipping .pngs could lead to different issues also (because our code could get confused)? Scott signature.asc Description: PGP signature
Re: master branch is open again
On Sun, Nov 15, 2015 at 12:18:28PM -0500, Richard Heck wrote: > On 11/15/2015 12:05 PM, Jean-Marc Lasgouttes wrote: > > Le 14/11/2015 05:13, Scott Kostyshak a écrit : >> I have tagged and tarred > > (and signed) alpha1. I will upload the > tarballs >> soon. >> >> Development is open for post-alpha commits. > > > So can we just commit as we see fit, or would you like stuff to go to > mailing list first? > > I would suggest we move at this point to the rule we've used before. All > non-trivial patches must go to the list and get the approval of at least > one other developer. Once we get a further into the process, we could > switch to the stricter condition that they need Scott's approval in > particular. Thanks for this proposal Richard. Sounds good to me. There will be many patches that I do not understand so I will be confident if they receive a +1 from another developer. > Along those lines: The idea behind your patch looks fine to me. The following is not a critique (so please push because of Richard's positive feedback), but if you have time I am curious about the following: strwidth_cache_(1 << 19) How did you decide on 19? And why the trick of 1 << 19 instead of just the following? strwidth_cache_(19) I'm guessing this is a C++ trick I should know. Scott signature.asc Description: PGP signature
Re: Basic test of alpha1 tar
Scott Kostyshak wrote: > Same Qt version? Yes, 4.8.5. P
Re: Basic test of alpha1 tar
Jean-Marc Lasgouttes wrote: > And how does this compare to a 2.1 build? 2.1 seems to be the same as 2.0. > Could you provide a profile log for 2.2 being slow? Not now, but i will try get to it, it's pretty annoying. BTW my defaults are: xset r rate 300 180 maybe you can see it with this autorepeat rate as well? Pavel
Re: Basic test of alpha1 tar
Jürgen Spitzmüller wrote: > This probably points to > http://www.lyx.org/trac/changeset/7f1d33efc1d0b4302875706ba85d42c2a8f35a67/lyxgit/ > > Please try the attached patch. Yep, this fixes it. Pavel
Re: synchronizing po file of branch and trunk
Am Sonntag, 15. November 2015 um 19:03:01, schrieb Georg Baum > Kornel Benko wrote: > > > Am Freitag, 13. November 2015 um 20:18:46, schrieb Georg Baum > > > >> > >> I am tempted to write our own merge tool in python.. > > > > I have a script ready, though it is perl. > > Nice, but a pity that it is not python;-( Many years ago it was decided that > all scripts should be python, and everything was converted. We do not provide perl scripts, but developer should be free to use. > > It has to be adapted to ones local paths. Also one has to specify which > > languages to are to be handled. > > I did it a bit different. If you put the attached file into > development/tools, and run it (the single argument is the po directory you > want to take the translations from), you'll get this: You do not check changed translations, if I read the script correctly? > Not bad for less than 50 lines of code and less than one hour of work, is't > it? Most po files are up to date, but there a few where merging can save a > lot of work. No, not bad. > Unfortunately the resulting diff is huge because of reformatting. If we > decide to use this script, I'll improve it to keep the existing formatting. > > > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: synchronizing po file of branch and trunk
Kornel Benko wrote:
> Am Freitag, 13. November 2015 um 20:18:46, schrieb Georg Baum
>
>>
>> I am tempted to write our own merge tool in python..
>
> I have a script ready, though it is perl.
Nice, but a pity that it is not python;-( Many years ago it was decided that
all scripts should be python, and everything was converted.
> It has to be adapted to ones local paths. Also one has to specify which
> languages to are to be handled.
I did it a bit different. If you put the attached file into
development/tools, and run it (the single argument is the po directory you
want to take the translations from), you'll get this:
Merging ../lyx-2.1-git/po/pt_PT.po into po/pt_PT.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/ja.po into po/ja.po: Updated 7 translations.
Merging ../lyx-2.1-git/po/sl.po into po/sl.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/bg.po into po/bg.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/fr.po into po/fr.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/id.po into po/id.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/fi.po into po/fi.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/ar.po into po/ar.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/ia.po into po/ia.po: Updated 17 translations.
Merging ../lyx-2.1-git/po/cs.po into po/cs.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/zh_CN.po into po/zh_CN.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/nl.po into po/nl.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/el.po into po/el.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/de.po into po/de.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/en.po into po/en.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/pt_BR.po into po/pt_BR.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/wa.po into po/wa.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/sr.po into po/sr.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/ko.po into po/ko.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/hu.po into po/hu.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/ro.po into po/ro.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/tr.po into po/tr.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/uk.po into po/uk.po: Updated 3 translations.
Merging ../lyx-2.1-git/po/ru.po into po/ru.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/he.po into po/he.po: Updated 115 translations.
Merging ../lyx-2.1-git/po/sk.po into po/sk.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/da.po into po/da.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/nb.po into po/nb.po: Updated 108 translations.
Merging ../lyx-2.1-git/po/es.po into po/es.po: Updated 3 translations.
Merging ../lyx-2.1-git/po/pl.po into po/pl.po: Updated 256 translations.
Merging ../lyx-2.1-git/po/eu.po into po/eu.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/gl.po into po/gl.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/ca.po into po/ca.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/sv.po into po/sv.po: Updated 37 translations.
Merging ../lyx-2.1-git/po/nn.po into po/nn.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/it.po into po/it.po: Updated 0 translations.
Merging ../lyx-2.1-git/po/zh_TW.po into po/zh_TW.po: Updated 0 translations.
Not bad for less than 50 lines of code and less than one hour of work, is't
it? Most po files are up to date, but there a few where merging can save a
lot of work.
Unfortunately the resulting diff is huge because of reformatting. If we
decide to use this script, I'll improve it to keep the existing formatting.
Georg#! /usr/bin/env python
# -*- coding: utf-8 -*-
# file updatelayouts.py
# This file is part of LyX, the document processor.
# Licence details can be found in the file COPYING.
# author Georg Baum
# Full author contact details are available in file CREDITS
# This script takes missing translations from another set of po files and
# merges them into the po files in this source tree.
import os, re, string, sys
import polib
def mergepo(target, source):
if os.path.exists(source):
sys.stderr.write('Merging %s into %s: ' % (source, target))
changed = 0
po1 = polib.pofile(target)
po2 = polib.pofile(source)
for entry in po1.untranslated_entries():
other = po2.find(entry.msgid, include_obsolete_entries=True)
if not other:
continue
if other.translated():
entry.msgstr = other.msgstr
changed = changed + 1
sys.stderr.write('Updated %d translations.\n' % changed)
if changed > 0:
po1.save(target)
else:
sys.stderr.write('Skipping %s since %s does not exist' % (target, source))
def main(argv):
toolsdir = os.path.dirname(argv[0])
podir1 = os.path.normpath(os.path.join(toolsdir, '../../po'))
if len(argv) <= 1:
sys.stderr.write('''Usage: %s where dir is
Re: master branch is open again
On 11/15/2015 12:05 PM, Jean-Marc Lasgouttes wrote: > Le 14/11/2015 05:13, Scott Kostyshak a écrit : >> I have tagged and tarred > (and signed) alpha1. I will upload the tarballs >> soon. >> >> Development is open for post-alpha commits. > > So can we just commit as we see fit, or would you like stuff to go to mailing list first? I would suggest we move at this point to the rule we've used before. All non-trivial patches must go to the list and get the approval of at least one other developer. Once we get a further into the process, we could switch to the stricter condition that they need Scott's approval in particular. Along those lines: The idea behind your patch looks fine to me. Richard
Re: Basic test of alpha1 tar
Works fine here (Debian jessie). Georg
Re: master branch is open again
Le 14/11/2015 05:13, Scott Kostyshak a écrit :
I have tagged and tarred (and signed) alpha1. I will upload the tarballs
soon.
Development is open for post-alpha commits.
So can we just commit as we see fit, or would you like stuff to go to
mailing list first? First example would be the following patch, which
tries to avoid excessive memory use during long editing sessions.
JMarc
>From a5bbce530586b8dd6aa54e4479749cfc0a54f0b1 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Mon, 9 Nov 2015 10:11:57 +0100
Subject: [PATCH] Use a QCache for string metrics
This is better because it implements a LRU cache. Indeed, while editing in particular, width of many different strings has to be computed. This is different from the previous situation where only width of single characters was computed and cached.
---
src/frontends/qt4/GuiFontLoader.cpp | 16
src/frontends/qt4/GuiFontMetrics.cpp | 21 -
src/frontends/qt4/GuiFontMetrics.h | 7 +++
3 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/src/frontends/qt4/GuiFontLoader.cpp b/src/frontends/qt4/GuiFontLoader.cpp
index 69f1ed2..9a662a8 100644
--- a/src/frontends/qt4/GuiFontLoader.cpp
+++ b/src/frontends/qt4/GuiFontLoader.cpp
@@ -259,8 +259,9 @@ FontLoader::~FontLoader()
/
+namespace {
-static QString makeFontName(QString const & family, QString const & foundry)
+QString makeFontName(QString const & family, QString const & foundry)
{
QString res = family;
if (!foundry.isEmpty())
@@ -269,9 +270,9 @@ static QString makeFontName(QString const & family, QString const & foundry)
}
-GuiFontInfo::GuiFontInfo(FontInfo const & f)
- : metrics(QFont())
+QFont makeQFont(FontInfo const & f)
{
+ QFont font;
QString const pat = symbolFamily(f.family());
if (!pat.isEmpty()) {
bool ok;
@@ -347,9 +348,16 @@ GuiFontInfo::GuiFontInfo(FontInfo const & f)
LYXERR(Debug::FONT, "The font has size: " << font.pointSizeF());
- metrics = GuiFontMetrics(font);
+ return font;
}
+} // anon namespace
+
+
+GuiFontInfo::GuiFontInfo(FontInfo const & f)
+ : font(makeQFont(f)), metrics(font)
+{}
+
bool FontLoader::available(FontInfo const & f)
{
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index 2214623..8d0b026 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -53,7 +53,10 @@ inline QChar const ucs4_to_qchar(char_type const ucs4)
} // anon namespace
-GuiFontMetrics::GuiFontMetrics(QFont const & font) : font_(font), metrics_(font, 0)
+// Limit strwidth_cache_ size to 512kB of string data
+GuiFontMetrics::GuiFontMetrics(QFont const & font)
+ : font_(font), metrics_(font, 0),
+ strwidth_cache_(1 << 19)
{
}
@@ -138,14 +141,14 @@ int GuiFontMetrics::rbearing(char_type c) const
int GuiFontMetrics::width(docstring const & s) const
{
- int w = 0;
- map::const_iterator it = strwidth_cache_.find(s);
- if (it != strwidth_cache_.end()) {
- w = it->second;
- } else {
- w = metrics_.width(toqstr(s));
- strwidth_cache_[s] = w;
- }
+ QByteArray qba =
+ QByteArray(reinterpret_cast(s.data()),
+ s.size() * sizeof(docstring::value_type));
+ int * pw = strwidth_cache_[qba];
+ if (pw)
+ return *pw;
+ int w = metrics_.width(toqstr(s));
+ strwidth_cache_.insert(qba, new int(w), qba.size());
return w;
}
diff --git a/src/frontends/qt4/GuiFontMetrics.h b/src/frontends/qt4/GuiFontMetrics.h
index 75507b0..1e813f6 100644
--- a/src/frontends/qt4/GuiFontMetrics.h
+++ b/src/frontends/qt4/GuiFontMetrics.h
@@ -16,8 +16,8 @@
#include "support/docstring.h"
-#include
-
+#include
+#include
#include
#include
#include
@@ -73,8 +73,7 @@ private:
mutable QHash width_cache_;
/// Cache of string widths
- /// FIXME Try to use a QHash (this requires to define qHash(docstring))
- mutable std::map strwidth_cache_;
+ mutable QCache strwidth_cache_;
struct AscendDescend {
int ascent;
--
2.5.0
Re: We now include both png and svgz?
Le 15/11/2015 17:57, Georg Baum a écrit : OK, if it is assumed that qt can show svg images, then it does not make sense to ship or own .pngs. If we want to stick with this, we should remove the .pngs now and require qtsvg at configure time. For me personally the svgs work fine both with qt 4.8 and 5.3, so I would not have a problem with that. I only thought there might by exotic systems where it does not work, and therefore I thought it might be a good idea to ship both png and svg for one release, instead of switching from only png directly to only svg. Or we only ship svg for our beats and see what happens. We could decide to re-introduce pngs if needed. In any case, it is good to have the code for pngs still working. JMarc
Re: We now include both png and svgz?
Enrico Forestieri wrote: > It is not intended to work that way. If the svgz image is there, it is > not expected that Qt is not able to show it. The double entry are there > only to assure that if there is no svgz then the png can be used instead. > In this way, you are able to override the default icons by placing your > own in the ~/.lyx/images directory, even if they are pngs. OK, if it is assumed that qt can show svg images, then it does not make sense to ship or own .pngs. If we want to stick with this, we should remove the .pngs now and require qtsvg at configure time. For me personally the svgs work fine both with qt 4.8 and 5.3, so I would not have a problem with that. I only thought there might by exotic systems where it does not work, and therefore I thought it might be a good idea to ship both png and svg for one release, instead of switching from only png directly to only svg. Georg
Re: Basic test of alpha1 tar
Le 15/11/2015 03:14, Pavel Sanda a écrit : Pavel Sanda wrote: non harmful, but warnings: Apart from that I was able to build and run it on gentoo system. Sadly, moving cursor in paragraph is considerably slower than in my current 2.0 build :( And how does this compare to a 2.1 build? Could you provide a profile log for 2.2 being slow? JMarc
Re: Basic test of alpha1 tar
Am Sonntag 15 November 2015, 16:16:35 schrieb Kornel Benko: > It does, in this case. But as the compilation proceeds, I get lot of errors > and warnings. Is the attached too big for list? That's at least definitely too much for my agenda. Let's see first if we can get monolithic build working again for autotools. I don't know if it ever worked with CMake. Jürgen > > Jürgen > > Kornel
Re: Basic test of alpha1 tar
Am Sonntag 15 November 2015, 14:44:40 schrieb Kornel Benko:
> Cmake build: Using '-DLYX_MERGE_FILES=ON' I get this error:
>
> [ 46%] Building CXX object
> src/support/CMakeFiles/support.dir/_allinone_const.C.o cd
> /usr/BUILD/BuildLyxGitQtlocal/src/support && /usr/bin/c++
> -DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_CORE_LIB -DQT_GUI_LIB
> -I/usr/BUILD/BuildLyxGitQtlocal -I/usr/src/lyx/lyx-git/src
> -I/usr/include/enchant -I/usr/src/lyx/lyx-git/boost
> -I/usr/src/lyx/lyx-git/src/support
> -I/usr/BUILD/BuildLyxGitQtlocal/src/support
> -I/usr/src/lyx/lyx-git/src/support/mythes -isystem /usr/include/qt5
> -isystem /usr/include/qt5/QtCore -isystem
> /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem
> /usr/include/qt5/QtGui -Wall -Wunused-parameter --std=c++11
> -fno-strict-aliasing -Wall -Wunused-parameter --std=c++11
> -fno-strict-aliasing -O0 -g3 -D_DEBUG -fPIC
> -DBOOST_USER_CONFIG="" -o
> CMakeFiles/support.dir/_allinone_const.C.o -c
> /usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C In file
> included from /usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:17:0,
> from /usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:48:
> /usr/src/lyx/lyx-git/src/LyX.h:124:18: error: reference to ‘ErrorItem’ is
> ambiguous void printError(ErrorItem const &);
> ^
> /usr/src/lyx/lyx-git/src/LyX.h:27:7: note: candidates are: class
> lyx::ErrorItem class ErrorItem;
>^
This is completely unrelated to my patch.
Try if the attached patch helps.
Jürgen
diff --git a/src/support/debug.cpp b/src/support/debug.cpp
index f44f7fc..538b487 100644
--- a/src/support/debug.cpp
+++ b/src/support/debug.cpp
@@ -31,14 +31,14 @@ namespace lyx {
namespace {
-struct ErrorItem {
+struct DebugErrorItem {
Debug::Type level;
char const * name;
char const * desc;
};
-ErrorItem errorTags[] = {
+DebugErrorItem errorTags[] = {
{ Debug::NONE, "none", N_("No debugging messages")},
{ Debug::INFO, "info", N_("General information")},
{ Debug::INIT, "init", N_("Program initialisation")},
Re: Basic test of alpha1 tar
Am Sonntag, 15. November 2015 um 14:30:21, schrieb Jürgen Spitzmüller
> Am Samstag 14 November 2015, 21:34:43 schrieb Scott Kostyshak:
> > On Sat, Nov 14, 2015 at 04:31:55PM -0800, Pavel Sanda wrote:
> > > Scott Kostyshak wrote:
> > > > Dear all,
> > > >
> > > > If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > >
> > > > it compiles/installs as expected. It is located here:
> > > Monolithic build seems to be broken:
> > I can reproduce but I'm not sure how to fix it. Should I do a git
> > bisect?
>
> This probably points to
> http://www.lyx.org/trac/changeset/7f1d33efc1d0b4302875706ba85d42c2a8f35a67/lyxgit/
>
> Please try the attached patch.
>
> Jürgen
>
> >
> > Scott
Cmake build: Using '-DLYX_MERGE_FILES=ON' I get this error:
[ 46%] Building CXX object
src/support/CMakeFiles/support.dir/_allinone_const.C.o
cd /usr/BUILD/BuildLyxGitQtlocal/src/support && /usr/bin/c++
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_CORE_LIB -DQT_GUI_LIB
-I/usr/BUILD/BuildLyxGitQtlocal -I/usr/src/lyx/lyx-git/src
-I/usr/include/enchant -I/usr/src/lyx/lyx-git/boost
-I/usr/src/lyx/lyx-git/src/support -I/usr/BUILD/BuildLyxGitQtlocal/src/support
-I/usr/src/lyx/lyx-git/src/support/mythes -isystem /usr/include/qt5 -isystem
/usr/include/qt5/QtCore -isystem
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem
/usr/include/qt5/QtGui -Wall -Wunused-parameter --std=c++11
-fno-strict-aliasing -Wall -Wunused-parameter --std=c++11 -fno-strict-aliasing
-O0 -g3 -D_DEBUG -fPIC -DBOOST_USER_CONFIG="" -o
CMakeFiles/support.dir/_allinone_const.C.o -c
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C
In file included from
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:17:0,
from
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:48:
/usr/src/lyx/lyx-git/src/LyX.h:124:18: error: reference to ‘ErrorItem’ is
ambiguous
void printError(ErrorItem const &);
^
/usr/src/lyx/lyx-git/src/LyX.h:27:7: note: candidates are: class lyx::ErrorItem
class ErrorItem;
^
In file included from
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:43:0:
/usr/src/lyx/lyx-git/src/support/debug.cpp:34:8: note: struct
lyx::{anonymous}::ErrorItem
struct ErrorItem {
^
In file included from
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:17:0,
from
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:48:
/usr/src/lyx/lyx-git/src/LyX.h:124:18: error: ‘ErrorItem’ has not been declared
void printError(ErrorItem const &);
^
make[2]: *** [src/support/CMakeFiles/support.dir/_allinone_const.C.o] Chyba 1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'
make[1]: *** [src/support/CMakeFiles/support.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'
Normally I never use monolithic build, so maybe it was always erroneous.
Looks like disabling it would be a good idea.
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: Basic test of alpha1 tar
Am Samstag 14 November 2015, 21:34:43 schrieb Scott Kostyshak:
> On Sat, Nov 14, 2015 at 04:31:55PM -0800, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> > > Dear all,
> > >
> > > If you have time, please download the LyX 2.2.0alpha1 tar and test that
> >
> > > it compiles/installs as expected. It is located here:
> > Monolithic build seems to be broken:
> I can reproduce but I'm not sure how to fix it. Should I do a git
> bisect?
This probably points to
http://www.lyx.org/trac/changeset/7f1d33efc1d0b4302875706ba85d42c2a8f35a67/lyxgit/
Please try the attached patch.
Jürgen
>
> Scott
diff --git a/src/frontends/qt4/GuiBox.cpp b/src/frontends/qt4/GuiBox.cpp
index 0999039..e4d4256 100644
--- a/src/frontends/qt4/GuiBox.cpp
+++ b/src/frontends/qt4/GuiBox.cpp
@@ -103,16 +103,6 @@ static QList colors()
}
-namespace {
-
-bool ColorSorter(ColorCode lhs, ColorCode rhs)
-{
- return support::compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
-}
-
-} // namespace anon
-
-
GuiBox::GuiBox(QWidget * parent) : InsetParamsWidget(parent)
{
setupUi(this);
diff --git a/src/frontends/qt4/GuiCharacter.cpp b/src/frontends/qt4/GuiCharacter.cpp
index c673d2d..e016876 100644
--- a/src/frontends/qt4/GuiCharacter.cpp
+++ b/src/frontends/qt4/GuiCharacter.cpp
@@ -192,12 +192,6 @@ void fillComboColor(QComboBox * combo, QList const & list)
combo->addItem(qt_("Reset"), "inherit");
}
-
-bool ColorSorter(ColorCode lhs, ColorCode rhs)
-{
- return support::compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
-}
-
} // namespace anon
GuiCharacter::GuiCharacter(GuiView & lv)
diff --git a/src/frontends/qt4/GuiPrefs.cpp b/src/frontends/qt4/GuiPrefs.cpp
index a076402..2c99dee 100644
--- a/src/frontends/qt4/GuiPrefs.cpp
+++ b/src/frontends/qt4/GuiPrefs.cpp
@@ -1115,19 +1115,6 @@ void PrefScreenFonts::selectTypewriter(const QString & name)
/
-namespace {
-
-struct ColorSorter
-{
- bool operator()(ColorCode lhs, ColorCode rhs) const {
- return
- compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
- }
-};
-
-} // namespace anon
-
-
PrefColors::PrefColors(GuiPreferences * form)
: PrefModule(catLookAndFeel, N_("Colors"), form)
{
@@ -1164,7 +1151,7 @@ PrefColors::PrefColors(GuiPreferences * form)
continue;
lcolors_.push_back(lc);
}
- sort(lcolors_.begin(), lcolors_.end(), ColorSorter());
+ qSort(lcolors_.begin(), lcolors_.end(), ColorSorter);
vector::const_iterator cit = lcolors_.begin();
vector::const_iterator const end = lcolors_.end();
for (; cit != end; ++cit) {
diff --git a/src/frontends/qt4/qt_helpers.cpp b/src/frontends/qt4/qt_helpers.cpp
index 4eacaca..c1294e5 100644
--- a/src/frontends/qt4/qt_helpers.cpp
+++ b/src/frontends/qt4/qt_helpers.cpp
@@ -213,6 +213,12 @@ QString formatLocFPNumber(double d)
}
+bool ColorSorter(ColorCode lhs, ColorCode rhs)
+{
+ return compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
+}
+
+
void setValid(QWidget * widget, bool valid)
{
if (valid) {
diff --git a/src/frontends/qt4/qt_helpers.h b/src/frontends/qt4/qt_helpers.h
index fcdcd53..d4afc78 100644
--- a/src/frontends/qt4/qt_helpers.h
+++ b/src/frontends/qt4/qt_helpers.h
@@ -13,6 +13,7 @@
#ifndef QTHELPERS_H
#define QTHELPERS_H
+#include "ColorSet.h"
#include "Length.h"
#include "support/qstring_helpers.h"
#include "support/filetools.h"
@@ -73,6 +74,9 @@ void doubleToWidget(QLineEdit * input, std::string const & value,
*/
QString formatLocFPNumber(double d);
+/// Method to sort colors by GUI name in combo widgets
+bool ColorSorter(ColorCode lhs, ColorCode rhs);
+
/// colors a widget red if invalid
void setValid(QWidget * widget, bool valid);
Re: [patch] RFC: better submenu for tables
Am Sonntag 15 November 2015, 14:10:07 schrieb Kornel Benko: > Am Sonntag, 15. November 2015 um 13:36:50, schrieb Jürgen Spitzmüller > > > Am Freitag 13 November 2015, 13:15:05 schrieb Kornel Benko: > > > What about multipage table? > > > > Yes, why not. > > There are 5 strings which would need new wordings: > 1 "&Use long table" > 2 "Horizontal alignment of the longtable" > 3 "Longtable alignment" > 4 "Breakable Table|g" > 5 "A spreadsheet made with Gnumeric, LibreOffice, OpenOffice or > Excel.\n" > "It imports as a long table, so any length\n" > "is ok. Excessive width could be a problem.\n" > "The gnumeric software is necessary for conversion,\n" > "both for gnumeric and excel files.\n" > > May I adapt them? Fine with me. I think the correct spelling would be "multi-page table". Jürgen > > Jürgen > > Kornel
Re: [patch] RFC: better submenu for tables
Am Sonntag, 15. November 2015 um 13:36:50, schrieb Jürgen Spitzmüller > Am Freitag 13 November 2015, 13:15:05 schrieb Kornel Benko: > > What about multipage table? > > Yes, why not. There are 5 strings which would need new wordings: 1 "&Use long table" 2 "Horizontal alignment of the longtable" 3 "Longtable alignment" 4 "Breakable Table|g" 5 "A spreadsheet made with Gnumeric, LibreOffice, OpenOffice or Excel.\n" "It imports as a long table, so any length\n" "is ok. Excessive width could be a problem.\n" "The gnumeric software is necessary for conversion,\n" "both for gnumeric and excel files.\n" May I adapt them? > Jürgen Kornel signature.asc Description: This is a digitally signed message part.
Re: Basic test of alpha1 tar
Le 15/11/2015 01:18, Pavel Sanda a écrit :
Scott Kostyshak wrote:
Dear all,
If you have time, please download the LyX 2.2.0alpha1 tar and test that
it compiles/installs as expected. It is located here:
non harmful, but warnings:
GuiViewSource.cpp:174:9: warning: 'QString
lyx::frontend::{anonymous}::prependTexRow(const lyx::TexRow&, const QString&)'
defined but not used [-Wunused-function]
QString prependTexRow(TexRow const & texrow, QString const & content)
^
Fixed now.
insets/InsetListingsParams.cpp: In constructor
'lyx::{anonymous}::ParValidator::ParValidator()':
insets/InsetListingsParams.cpp:298:1: note: variable tracking size limit
exceeded with -fvar-tracking-assignments, retrying without
ParValidator::ParValidator()
(gcc 4.9.3)
P
Re: [patch] RFC: better submenu for tables
Am Freitag 13 November 2015, 13:15:05 schrieb Kornel Benko: > What about multipage table? Yes, why not. Jürgen
