Re: [patch] support for \fcolorbox and \colorbox

[Jean-Marc Lasgouttes]

Le 15/05/15 06:16, Uwe Stöhr a écrit :

Dear LyXers,

the attached patch makes it possible to choose a frame color and a
background color for boxes.


I see that this does not replace boxes with shaded background. Do we 
really need to have all these types of boxes now?



OK to go in?


A few comments on the patch follow.

JMarc

@@ -73,6 +76,60 @@ static QStringList boxGuiSpecialLengthNames()
 }


+static QListColorPair colorData()
+{

 Please use anonymous namespace rather than static in this case
 (no, I cannot tell you why; but anways I think it is in our code
 rules).

+   QListColorPair colors;
+   colors  ColorPair(qt_(none), Color_none);
+   colors  ColorPair(qt_(black), Color_black);
+   colors  ColorPair(qt_(white), Color_white);
+   colors  ColorPair(qt_(blue), Color_blue);

Don't we have this information of match between enum and name in 
Color.cpp? What is the point of repeating it here?


+   colors  ColorPair(qt_(brown), Color_brown);
+   colors  ColorPair(qt_(cyan), Color_cyan);
+   colors  ColorPair(qt_(darkgray), Color_darkgray);
+   colors  ColorPair(qt_(gray), Color_gray);

[...]

+templateclass P
+static int findPos2nd(QListP const  vec, QString val)
+{
+   for (int i = 0; i != vec.size(); ++i)
+   if (vec[i].first == val)
+   return i;
+   return 0;
+}

I see that this is from GuiCharacter.cpp. Rather than copying it, why 
not put it in qt_helpers.*?

Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is 
possible with a macro and not with \frac.



But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in 
different branches. But this may not be exactly what you are after.



In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro 
would be possible as long as the parameters of the macros have the same 
structure. But switching from a two parameters macro to a one parameter 
one is trickier.



About toggling, they had this discussion before some years ago:
http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)

Thanks,
JMarc

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 12:04:50, schrieb Stephan Witt st.w...@gmx.net
 Am 14.05.2015 um 22:08 schrieb Stephan Witt st.w...@gmx.net:
 
  Am 14.05.2015 um 20:07 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
  
  Le 13/05/2015 22:52, Stephan Witt a écrit :
  Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
  
  
  Hi there,
  
  The ritual question: what is still needed for 2.2?
  
  The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, 
  named
  0001-svg-hidpi-on-mac.patch is not applied already.
  
  It is needed - but I didn't do it until now because it breaks the 
  rendering of the
  splash image (the BackgroundWidget of GuiView) and I got distracted from 
  solving this.
  
  And then Hidpi is mostly done?
  
  Yes, it looks really good on my display. The problem I have with the splash
  widget is the missing size of the SVG version of the banner.
 
 Ok, I have a working solution now.
 
 There are some remarks:
 1. I didn't find a better solution for the params_.pixel_ratio assignment in 
 GraphicsLoader.cpp yet.
 2. The solution for the banner is to provide a SVG with higher resolution 
 than 400x250.
 This is not part of the patch, I tried it with 800x500 and 1600x1000 and for 
 both the result is ok.
 3. The initial size of 400x250 for the BackgroundWidget constructor is needed 
 to get predictable
 results for different physical screen pixel_ratio values.
 
 I'll try to get it running on Linux to see how it works there. Meanwhile, I'm 
 interested in comments.
 
 Stephan

Compiles fine on linux. Splash screen is OK too here.

Kornel

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

Re: [LyX/master] Shut up compiler warning

[Stephan Witt]

Am 14.05.2015 um 20:22 schrieb Georg Baum georg.b...@post.rwth-aachen.de:

 Stephan Witt wrote:
 
 Please, what's the compiler switch to enable these warnings?
 I don't see them. Neither with the settings of automake nor
 with the settings of cmake builds.
 
 autoconf with --enable-warnings and gcc 4.9 (this enables -Wall -Wextra -
 Wfloat-conversion, I guess the last one is the one you mean). Note that it 
 is inside an #ifdef qt5, so you won't see it if you compile for qt4.

Thanks. I'm using clang and the only way to get this warning is -Wconversion, 
AFAIK.
With these warnings enabled I'm getting tons of warnings for boost and Qt 
headers.
So, I'll let it disabled then.

Stephan 

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/15 13:58, Uwe Stöhr a écrit :

This has nothing to do with the announcement of a soon feature freeze.
As you saw I had now some more time for LyX and used it to work on my
ToAdd list.
Nevertheless I like to have more frequent major releases. So fine with
me if you say feature freeze soon.
So I'm not working on any new feature and concentrate on bug fixing
after my box color feature is in. OK?


I think that it would be nice to do that indeed. But then we will need 
to be serious about release and not spend 8 months like last time.



That would be nice. There are no so many features in 2.2 compared to
2.1. And things like horizontal scrollbar, Qt5 and HiDPI don't require
much documentation change.


Indeed.

JMarc

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/15 12:42, Stephan Witt a écrit :

Thank you. The current splash has a size of 400x250. I'll attach the 1600x1000 
splash banner to test.
It would be great if this is ok too. If not I have to get it right myself.


Why is there a need to set a size for the splash? Since it is 
vector-based, one can just resize it, right?


JMarc

Re: [patch] support for \fcolorbox and \colorbox

[Uwe Stöhr]

Am 15.05.2015 um 06:16 schrieb Uwe Stöhr:
 the attached patch makes it possible to choose a frame color and a

background color for boxes.



Attached is a better patch.

(I forgot to register xcolor and now also take care that a box with a 
frame color  black cannot have no background color)


regards Uwe
 lib/lyx2lyx/LyX.py|   2 +-
 lib/lyx2lyx/lyx_2_2.py|  49 +-
 src/frontends/qt4/GuiBox.cpp  | 108 +
 src/frontends/qt4/GuiBox.h|   7 +-
 src/frontends/qt4/ui/BoxUi.ui | 212 +++---
 src/insets/InsetBox.cpp   |  82 
 src/insets/InsetBox.h |   4 +
 src/tex2lyx/text.cpp  |   2 +
 src/version.h |   4 +-
 9 files changed, 369 insertions(+), 101 deletions(-)

diff --git a/lib/lyx2lyx/LyX.py b/lib/lyx2lyx/LyX.py
index 246ab33..c7815f7 100644
--- a/lib/lyx2lyx/LyX.py
+++ b/lib/lyx2lyx/LyX.py
@@ -85,7 +85,7 @@ format_relation = [(0_06,[200], minor_versions(0.6 , 
4)),
(1_6, list(range(277,346)), minor_versions(1.6 , 10)),
(2_0, list(range(346,414)), minor_versions(2.0 , 8)),
(2_1, list(range(414,475)), minor_versions(2.1 , 0)),
-   (2_2, list(range(475,492)), minor_versions(2.2 , 0))
+   (2_2, list(range(475,493)), minor_versions(2.2 , 0))
   ]
 
 
diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index 087e9c3..ec6213b 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@ -1077,6 +1077,51 @@ def revert_textcolor(document):
 i = i + 1
 
 
+def convert_colorbox(document):
+ adds color settings for boxes 
+
+i = 0
+while True:
+i = find_token(document.body, height_special, i)
+if i == -1:
+return
+document.body.insert(i + 2, 'framecolor black\nbackgroundcolor 
white')
+i = i + 2
+
+
+def revert_colorbox(document):
+ outputs color settings for boxes as TeX code 
+
+i = 0
+defaultframecolor = black
+defaultbackcolor = white
+while True:
+i = find_token(document.body, framecolor, i)
+if i == -1:
+return
+# read out the values
+beg = document.body[i].find('');
+end = document.body[i].rfind('');
+framecolor = document.body[i][beg+1:end];
+beg = document.body[i+1].find('');
+end = document.body[i+1].rfind('');
+backcolor = document.body[i+1][beg+1:end];
+# delete the specification
+del document.body[i:i+2]
+# output TeX code
+# first output the closing brace
+if framecolor != defaultframecolor or backcolor != defaultbackcolor:
+document.body[i + 9 : i + 9] = put_cmd_in_ert(})
+# now output the box commands
+if framecolor != defaultframecolor or backcolor != defaultbackcolor:
+document.body[i - 14 : i - 14] = put_cmd_in_ert({)
+if framecolor != defaultframecolor:
+document.body[i - 9 : i - 8] = [\\backslash fboxcolor{ + 
framecolor + }{ + backcolor + }{]
+if backcolor != defaultbackcolor and framecolor == defaultframecolor:
+document.body[i - 9 : i - 8] = [\\backslash colorbox{ + 
backcolor + }{]
+i = i + 11
+
+
 ##
 # Conversion hub
 #
@@ -1102,10 +1147,12 @@ convert = [
[488, [convert_newgloss]],
[489, [convert_BoxFeatures]],
[490, [convert_origin]],
-   [491, []]
+   [491, []],
+   [492, [convert_colorbox]]
   ]
 
 revert =  [
+   [491, [revert_colorbox]],
[490, [revert_textcolor]],
[489, [revert_origin]],
[488, [revert_BoxFeatures]],
diff --git a/src/frontends/qt4/GuiBox.cpp b/src/frontends/qt4/GuiBox.cpp
index 2da6947..2deb45f 100644
--- a/src/frontends/qt4/GuiBox.cpp
+++ b/src/frontends/qt4/GuiBox.cpp
@@ -15,6 +15,8 @@
 
 #include GuiBox.h
 
+#include GuiApplication.h
+#include ColorCache.h
 #include LengthCombo.h
 #include Length.h
 #include qt_helpers.h
@@ -26,6 +28,7 @@
 #include support/foreach.h
 #include support/lstrings.h
 
+#include QComboBox
 #include QLineEdit
 #include QPushButton
 
@@ -73,6 +76,60 @@ static QStringList boxGuiSpecialLengthNames()
 }
 
 
+static QListColorPair colorData()
+{
+   QListColorPair colors;
+   colors  ColorPair(qt_(none), Color_none);
+   colors  ColorPair(qt_(black), Color_black);
+   colors  ColorPair(qt_(white), Color_white);
+   colors  ColorPair(qt_(blue), Color_blue);
+   colors  ColorPair(qt_(brown), Color_brown);
+   colors  ColorPair(qt_(cyan), Color_cyan);
+   colors  ColorPair(qt_(darkgray), Color_darkgray);
+   colors  ColorPair(qt_(gray), Color_gray);
+   colors  ColorPair(qt_(green), Color_green);
+   colors  ColorPair(qt_(lightgray), Color_lightgray);
+   colors  

Re: [patch] support for \fcolorbox and \colorbox

[Uwe Stöhr]

Am 15.05.2015 um 10:50 schrieb Jean-Marc Lasgouttes:

 A few comments on the patch follow.

Many thanks JMarc,


+static QListColorPair colorData()
+{

 Please use anonymous namespace rather than static in this case
 (no, I cannot tell you why; but anways I think it is in our code
 rules).


I can do so but why is static used in GuiCharacter.cpp for QListColorPair?


+QListColorPair colors;
+colors  ColorPair(qt_(none), Color_none);
+colors  ColorPair(qt_(black), Color_black);
+colors  ColorPair(qt_(white), Color_white);
+colors  ColorPair(qt_(blue), Color_blue);

Don't we have this information of match between enum and name in
Color.cpp? What is the point of repeating it here?


I stole the list idea from GuiCharacter.cpp. The reason is that one 
needs a defined list to fill the combo box. The list in GuiCharacter.cpp 
is different from the list in GuiBox.cpp.
If I would use the list in Color.cpp for GuiBox.cpp, I would have to 
hardcode a subset of it (that only the first 20 items are used for 
filling). This seems to be error-prone because if anybody adds a color 
in Color.cpp there will be wrong colors in the box dialog causing LaTeX 
errors.



+templateclass P
+static int findPos2nd(QListP const  vec, QString val)
+{
+for (int i = 0; i != vec.size(); ++i)
+if (vec[i].first == val)
+return i;
+return 0;
+}

I see that this is from GuiCharacter.cpp. Rather than copying it, why
not put it in qt_helpers.*?


Because it is different from the one of GuiCharacter.cpp. So each 
version of findPos2nd is only used in one class. I you nevertheless like 
I can add both variants of findPos2nd to helpers.


thanks and regards
Uwe

Re: 2.2

[Stephan Witt]

Am 14.05.2015 um 22:08 schrieb Stephan Witt st.w...@gmx.net:

 Am 14.05.2015 um 20:07 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
 Le 13/05/2015 22:52, Stephan Witt a écrit :
 Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
 
 Hi there,
 
 The ritual question: what is still needed for 2.2?
 
 The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, named
 0001-svg-hidpi-on-mac.patch is not applied already.
 
 It is needed - but I didn't do it until now because it breaks the rendering 
 of the
 splash image (the BackgroundWidget of GuiView) and I got distracted from 
 solving this.
 
 And then Hidpi is mostly done?
 
 Yes, it looks really good on my display. The problem I have with the splash
 widget is the missing size of the SVG version of the banner.

Ok, I have a working solution now.

There are some remarks:
1. I didn't find a better solution for the params_.pixel_ratio assignment in 
GraphicsLoader.cpp yet.
2. The solution for the banner is to provide a SVG with higher resolution than 
400x250.
This is not part of the patch, I tried it with 800x500 and 1600x1000 and for 
both the result is ok.
3. The initial size of 400x250 for the BackgroundWidget constructor is needed 
to get predictable
results for different physical screen pixel_ratio values.

I'll try to get it running on Linux to see how it works there. Meanwhile, I'm 
interested in comments.

Stephan



0002-svg-hidpi-on-mac.patch
Description: Binary data

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 12:42:01, schrieb Stephan Witt st.w...@gmx.net
 Am 15.05.2015 um 12:33 schrieb Kornel Benko kor...@lyx.org:

  Am Freitag, 15. Mai 2015 um 12:04:50, schrieb Stephan Witt st.w...@gmx.net
  Am 14.05.2015 um 22:08 schrieb Stephan Witt st.w...@gmx.net:
 
  Am 14.05.2015 um 20:07 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
  Le 13/05/2015 22:52, Stephan Witt a écrit :
  Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes 
  lasgout...@lyx.org:
 
 
  Hi there,
 
  The ritual question: what is still needed for 2.2?
 
  The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, 
  named
  0001-svg-hidpi-on-mac.patch is not applied already.
 
  It is needed - but I didn't do it until now because it breaks the 
  rendering of the
  splash image (the BackgroundWidget of GuiView) and I got distracted 
  from solving this.
 
  And then Hidpi is mostly done?
 
  Yes, it looks really good on my display. The problem I have with the 
  splash
  widget is the missing size of the SVG version of the banner.
 
  Ok, I have a working solution now.
 
  There are some remarks:
  1. I didn't find a better solution for the params_.pixel_ratio assignment 
  in GraphicsLoader.cpp yet.
  2. The solution for the banner is to provide a SVG with higher resolution 
  than 400x250.
  This is not part of the patch, I tried it with 800x500 and 1600x1000 and 
  for both the result is ok.
  3. The initial size of 400x250 for the BackgroundWidget constructor is 
  needed to get predictable
  results for different physical screen pixel_ratio values.
 
  I'll try to get it running on Linux to see how it works there. Meanwhile, 
  I'm interested in comments.
 
  Stephan
 
  Compiles fine on linux. Splash screen is OK too here.

 Thank you. The current splash has a size of 400x250. I'll attach the 
 1600x1000 splash banner to test.
 It would be great if this is ok too. If not I have to get it right myself.

 Stephan

The border lines (around LYX) are too thin, the text looks not good.

Kornel

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

Re: 2.2

[Uwe Stöhr]

Am 14.05.2015 um 20:10 schrieb Jean-Marc Lasgouttes:


Since a long time I have some time for LyX and ant to use is to enrich
it with some more features if possible. So if it is not urgent I would
be happy not to start the feature freeze before June.


I am not sure that the point when we discuss feature freeze is the right
moment for adding as many features as necessary. Nothing is never
urgent, but I think we have to draw the line as soon as possible and
just work towards an actual release.


This has nothing to do with the announcement of a soon feature freeze. 
As you saw I had now some more time for LyX and used it to work on my 
ToAdd list.
Nevertheless I like to have more frequent major releases. So fine with 
me if you say feature freeze soon.
So I'm not working on any new feature and concentrate on bug fixing 
after my box color feature is in. OK?



PS: also I guess a lot of documentation work will be needed; I remember
that for 2.1 is was a bit hurried, we will probably want to plan this time.


That would be nice. There are no so many features in 2.2 compared to 
2.1. And things like horizontal scrollbar, Qt5 and HiDPI don't require 
much documentation change.


regards Uwe

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 14:32 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 Le 15/05/15 12:42, Stephan Witt a écrit :
 Thank you. The current splash has a size of 400x250. I'll attach the 
 1600x1000 splash banner to test.
 It would be great if this is ok too. If not I have to get it right myself.
 
 Why is there a need to set a size for the splash? Since it is vector-based, 
 one can just resize it, right?

There is no handle to resize the splash image.
One can resize the window containing the splash but the image size should be 
constant, IMHO.

Stephan

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
 
 Thank you. The current splash has a size of 400x250. I'll attach the
 1600x1000 splash banner to test.
 It would be great if this is ok too. If not I have to get it right myself.

Why is this (compressed) svg image so big? Are you sure there is no
embedded bitmap? That would defeat the purpose of using the svg format.

-- 
Enrico

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 15:14 schrieb Enrico Forestieri for...@lyx.org:

 On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
 On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
 
 Thank you. The current splash has a size of 400x250. I'll attach the
 1600x1000 splash banner to test.
 It would be great if this is ok too. If not I have to get it right myself.
 
 Why is this (compressed) svg image so big? Are you sure there is no
 embedded bitmap? That would defeat the purpose of using the svg format.
 
 Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
 That's bad.

Yes, Jürgen said it would be great to find someone who is able to do it better.
This one was made to have some SVG banner.

Stephan

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
 
 I'll try to get it running on Linux to see how it works there. Meanwhile,
 I'm interested in comments.

Please, don't pass back and forth QPixmap objects on the stack. These
are big objects, potentially. Instead, use

bool getPixmap(QString const  path, QPixmap  pm)
{
// deal with QPixmap

return !pm.isNull();
}

 
 diff --git a/src/frontends/qt4/GuiApplication.cpp 
 b/src/frontends/qt4/GuiApplication.cpp
 index eaf33c4..de4569a 100644
 --- a/src/frontends/qt4/GuiApplication.cpp
 +++ b/src/frontends/qt4/GuiApplication.cpp
 @@ -569,22 +569,39 @@ QString iconName(FuncRequest const  f, bool unknown)
   return QString();
  }
  
 -QPixmap getPixmap(QString const  path, QString const  name, QString const 
  ext)
 +QPixmap getPixmap(QString const  path)
  {
   QPixmap pixmap;
 + if (pixmap.load(path)) {
 + if (path.endsWith(.svgz) || path.endsWith(.svg) ) {
 + GuiApplication const * guiApp = theGuiApp();
 + if (guiApp != 0) {
 + 
 pixmap.setDevicePixelRatio(guiApp-pixelRatio());
 + }
 + }
 + return pixmap;
 + }
 + return QPixmap();
 +}
 +
 +QPixmap getPixmap(QString const  path, QString const  name, QString const 
  ext)
 +{
   QString imagedir = path;
   FileName fname = imageLibFileSearch(imagedir, name, ext, 
 theGuiApp()-imageSearchMode());
   QString fpath = toqstr(fname.absFileName());
 + QPixmap pixmap = getPixmap(fpath);
  
 - if (pixmap.load(fpath)) {
 + if (!pixmap.isNull()) {
   return pixmap;
 - } else {
 - QStringList exts = ext.split(,);
 - fpath = :/ + path + name + .;
 - for (int i = 0; i  exts.size(); ++i) {
 - if (pixmap.load(fpath + exts.at(i)))
 + }
 + 
 + QStringList exts = ext.split(,);
 + fpath = :/ + path + name + .;
 + for (int i = 0; i  exts.size(); ++i) {
 + pixmap = getPixmap(fpath + exts.at(i));
 + if (!pixmap.isNull()) {
   return pixmap;
 - }
 + }
   }
  
   bool const list = ext.contains(,);
 @@ -613,13 +630,13 @@ QIcon getIcon(FuncRequest const  f, bool unknown)
   return QIcon();
  
   //LYXERR(Debug::GUI, Found icon:   icon);
 - QPixmap pm;
 - if (!pm.load(icon)) {
 + QPixmap pixmap = getPixmap(icon);
 + if (pixmap.isNull()) {
   LYXERR0(Cannot load icon   icon   please verify resource 
 system!);
   return QIcon();
   }
  
 - return QIcon(pm);
 + return QIcon(pixmap);
  }
  
  

-- 
Enrico

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 14:49 schrieb Enrico Forestieri for...@lyx.org:

 On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
 
 I'll try to get it running on Linux to see how it works there. Meanwhile,
 I'm interested in comments.
 
 Please, don't pass back and forth QPixmap objects on the stack. These
 are big objects, potentially. Instead, use
 
 bool getPixmap(QString const  path, QPixmap  pm)
 {
   // deal with QPixmap
 
   return !pm.isNull();
 }

Ok, thank you. I'll change it.

Stephan

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/2015 16:58, Stephan Witt a écrit :

Yes, I think that it is better passing big objects by reference rather
than by value.


But this is not a good property of C++ compilers than.
1. It's not a constant fact if an object is big.
2. The compiler should generate fast code for this scenario too.
3. This results in hard to read code eventually.


C++ rvalue references fix this problem, and they re implemented in Qt5 
(and partly in Qt4.8 AFAICS).


JMarc

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 16:53:51, schrieb Stephan Witt st.w...@gmx.net
  
  Compile error with this patch.
 
 That's no surprise. The method I've changed is used in conditionally compiled 
 code. 
 Attached is an updated patch.
 

Still problems ...
[ 30%] Building CXX object 
src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiView.cpp.o
cd /usr/BUILD/BuildLyxGitQt5/src/frontends/qt4  /usr/bin/c++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DLYX_BUILD_QT_FRONTEND 
-DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR -DQT_GUI_LIB 
-DQT_WIDGETS_LIB -Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing  
-Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG 
-fPIC -I/usr/BUILD/BuildLyxGitQt5 -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/frontends -I/usr/src/lyx/lyx-git/src/frontends/qt4 
-I/usr/BUILD/BuildLyxGitQt5/src/frontends/qt4 -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtCore -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/mkspecs/linux-g++ -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtGui -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtWidgets -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtConcurrent
-DBOOST_USER_CONFIG=config.h -o CMakeFiles/frontend_qt.dir/GuiView.cpp.o -c 
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp: In constructor 
‘lyx::frontend::GuiView::GuiView(int)’:
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:536:51: error: expected 
primary-expression before ‘)’ token
  if (getPixmap(pmLyX,images/, lyx, svg,png))) {
   ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:536:51: error: expected ‘;’ 
before ‘)’ token
make[2]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiView.cpp.o] Chyba 
1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'
make[1]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'

(One ')' too much).

With this corrected, it compiles.

Kornel

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

Re: about our lyx2lyx reversion policy

[Uwe Stöhr]

Am 14.05.2015 um 14:34 schrieb Jürgen Spitzmüller:


I disagree with this proposal and opt for going with our current policy.


But why? What are your arguments? What are your experiences with 
collaborations?


regards Uwe

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 03:45:28PM +0200, Stephan Witt wrote:

 Am 15.05.2015 um 15:14 schrieb Enrico Forestieri for...@lyx.org:
 
  On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
  On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
  
  Thank you. The current splash has a size of 400x250. I'll attach the
  1600x1000 splash banner to test.
  It would be great if this is ok too. If not I have to get it right myself.
  
  Why is this (compressed) svg image so big? Are you sure there is no
  embedded bitmap? That would defeat the purpose of using the svg format.
  
  Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
  That's bad.
 
 Yes, Jürgen said it would be great to find someone who is able to do it 
 better.
 This one was made to have some SVG banner.

Sorry, I did not realize it was that same banner. But why did you attach it, 
then?

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:58:24PM +0200, Stephan Witt wrote:

 Am 15.05.2015 um 16:48 schrieb Enrico Forestieri for...@lyx.org:
 
  On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
  
  This results in the following patch - if you had something like that in
  mind I'll split it in two patches. The other getPixmap method with
  QPixmap result was already there.
  
  Yes, I think that it is better passing big objects by reference rather
  than by value.
 
 But this is not a good property of C++ compilers than.
 1. It's not a constant fact if an object is big.
 2. The compiler should generate fast code for this scenario too.
 3. This results in hard to read code eventually.

You are probably right and it seems people prefer the simpler approach by
relying on the return value optimization performed by modern compilers.
http://stackoverflow.com/questions/753312/returning-large-objects-in-functions
http://stackoverflow.com/questions/4809120/creating-and-returning-a-big-object-from-a-function
http://stackoverflow.com/questions/24685054/how-do-c-functions-return-a-big-object-or-a-structure

What triggered my comment was seeing that call in a loop, so you could simply
limit the change to that one function and leave the rest as is. Or you could
also disregard that comment ;-)

-- 
Enrico

Re: [LyX/master] tex2lyx testfiles: update to latest fileformat

[Uwe Stöhr]

Am 15.05.2015 um 21:41 schrieb Georg Baum:


1) It is impossible to manually verify in this huge diff whether the new
references are really correct.


I wondered about that too.

Thanks for taking care and adding the note. However, the huge diff shows 
that tex2lyx is not yet producing the same as LyX. Can#t we do anything 
or shouldn't we do anything here?



I added a corresponding note to lib/doc/Development.lyx.


Thanks

regards Uwe

Re: 2.2

[Jürgen Spitzmüller]

2015-05-15 15:14 GMT+02:00 Enrico Forestieri:

 Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the
 svg.
 That's bad.


I just hacked this svg splash together quite quickly for testing pruposes.
It is _not_ intended to be published.
I agree, of course, that the final splash should be pure vector.

Jürgen



 --
 Enrico

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 16:48 schrieb Enrico Forestieri for...@lyx.org:

 On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
 
 This results in the following patch - if you had something like that in
 mind I'll split it in two patches. The other getPixmap method with
 QPixmap result was already there.
 
 Yes, I think that it is better passing big objects by reference rather
 than by value.

But this is not a good property of C++ compilers than.
1. It's not a constant fact if an object is big.
2. The compiler should generate fast code for this scenario too.
3. This results in hard to read code eventually.

Stephan

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 15:46 schrieb Stephan Witt st.w...@gmx.net:

 Am 15.05.2015 um 14:49 schrieb Enrico Forestieri for...@lyx.org:
 
 On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
 
 I'll try to get it running on Linux to see how it works there. Meanwhile,
 I'm interested in comments.
 
 Please, don't pass back and forth QPixmap objects on the stack. These
 are big objects, potentially. Instead, use
 
 bool getPixmap(QString const  path, QPixmap  pm)
 {
  // deal with QPixmap
 
  return !pm.isNull();
 }
 
 Ok, thank you. I'll change it.

This results in the following patch - if you had something like that in mind 
I'll
split it in two patches. The other getPixmap method with QPixmap result was 
already there.

Stephan



0003-svg-hidpi-on-mac.patch
Description: Binary data

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
 
 This results in the following patch - if you had something like that in
 mind I'll split it in two patches. The other getPixmap method with
 QPixmap result was already there.

Yes, I think that it is better passing big objects by reference rather
than by value.

-- 
Enrico

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 16:31:05, schrieb Stephan Witt st.w...@gmx.net
 Am 15.05.2015 um 15:46 schrieb Stephan Witt st.w...@gmx.net:
 
  Am 15.05.2015 um 14:49 schrieb Enrico Forestieri for...@lyx.org:
  
  On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
  
  I'll try to get it running on Linux to see how it works there. Meanwhile,
  I'm interested in comments.
  
  Please, don't pass back and forth QPixmap objects on the stack. These
  are big objects, potentially. Instead, use
  
  bool getPixmap(QString const  path, QPixmap  pm)
  {
 // deal with QPixmap
  
 return !pm.isNull();
  }
  
  Ok, thank you. I'll change it.
 
 This results in the following patch - if you had something like that in mind 
 I'll
 split it in two patches. The other getPixmap method with QPixmap result was 
 already there.
 
 Stephan

Compile error with this patch.

cd /usr/BUILD/BuildLyxGitQt5/src/frontends/qt4  /usr/bin/c++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DLYX_BUILD_QT_FRONTEND 
-DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR -DQT_GUI_LIB 
-DQT_WIDGETS_LIB -Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing  
-Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG 
-fPIC -I/usr/BUILD/BuildLyxGitQt5 -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/frontends -I/usr/src/lyx/lyx-git/src/frontends/qt4 
-I/usr/BUILD/BuildLyxGitQt5/src/frontends/qt4 -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtCore -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/mkspecs/linux-g++ -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtGui -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtWidgets -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtConcurrent
-DBOOST_USER_CONFIG=config.h -o CMakeFiles/frontend_qt.dir/GuiView.cpp.o -c 
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp: In constructor 
‘lyx::frontend::GuiView::GuiView(int)’:
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:539:77: error: no matching 
function for call to ‘getPixmap(const char [8], const char [4], const char [8])’
  setWindowIcon(QIcon::fromTheme(lyx, getPixmap(images/, lyx, 
svg,png)));
 ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:539:77: note: candidates are:
In file included from /usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:22:0:
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:251:6: note: bool 
lyx::frontend::getPixmap(QPixmap, const QString, const QString, const 
QString)
 bool getPixmap(QPixmap  pixmap, QString const  path, QString const  name, 
QString const  ext);
  ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:251:6: note:   
candidate expects 4 arguments, 3 provided
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:252:6: note: bool 
lyx::frontend::getPixmap(QPixmap, const QString)
 bool getPixmap(QPixmap  pixmap, QString const  path);
  ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:252:6: note:   
candidate expects 2 arguments, 3 provided
make[2]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiView.cpp.o] Chyba 
1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'
make[1]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'

Kornel

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

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 16:40 schrieb Kornel Benko kor...@lyx.org:

 Am Freitag, 15. Mai 2015 um 16:31:05, schrieb Stephan Witt st.w...@gmx.net
 Am 15.05.2015 um 15:46 schrieb Stephan Witt st.w...@gmx.net:
 
 Am 15.05.2015 um 14:49 schrieb Enrico Forestieri for...@lyx.org:
 
 On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
 
 I'll try to get it running on Linux to see how it works there. Meanwhile,
 I'm interested in comments.
 
 Please, don't pass back and forth QPixmap objects on the stack. These
 are big objects, potentially. Instead, use
 
 bool getPixmap(QString const  path, QPixmap  pm)
 {
// deal with QPixmap
 
return !pm.isNull();
 }
 
 Ok, thank you. I'll change it.
 
 This results in the following patch - if you had something like that in mind 
 I'll
 split it in two patches. The other getPixmap method with QPixmap result was 
 already there.
 
 Stephan
 
 Compile error with this patch.

That's no surprise. The method I've changed is used in conditionally compiled 
code. 
Attached is an updated patch.

Stephan



0004-svg-hidpi-on-mac.patch
Description: Binary data

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/15/15 10:04, Jean-Marc Lasgouttes wrote:

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is
possible with a macro and not with \frac.


I agree.




But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in
different branches. But this may not be exactly what you are after.


No indeed, I am speaking of something else. For instance we can use 
copy/paste on one equation because only a few details have to be 
changed. Or simply we can change our mind during the typesetting of a 
proof: writing an article does not go in a straight line.





In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro
would be possible as long as the parameters of the macros have the same
structure. But switching from a two parameters macro to a one parameter
one is trickier.


About toggling, they had this discussion before some years ago:
http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)


For these implementation details I agree---but if the question is how 
do we change the name of a macro in a way that has the same features 
(e.g. completion) as inserting the macro in the first place, then the 
idea of unfolding is quite natural.


Sorry for not being familiar enough with the source code to make more 
constructive suggestions.



Guillaume

Re: [patch] support for \fcolorbox and \colorbox

[Uwe Stöhr]

Am 15.05.2015 um 18:34 schrieb Jean-Marc Lasgouttes:


Actually I see now that static is still used more often than anonymous
namespaces in current code. So you can probably leave it as it is.


OK.
I have put the patch in with static.

regards Uwe

Re: [LyX/master] support for all default colors of the package xcolor

[Uwe Stöhr]

Am 15.05.2015 um 05:14 schrieb Scott Kostyshak:


Is there a reason why White is the only one that is not
alphabetized? Note that it was like this before your patch but this
just seems a convenient place to bring this up.


You are right, there is no reason to treat white differently. I am aware 
that the sorting will be lost with different locales but therefore we 
have not the color icons in the combo box.


regards Uwe

Re: 2.2

[Stephan Witt]

Am 16.05.2015 um 00:48 schrieb Enrico Forestieri for...@lyx.org:

 On Fri, May 15, 2015 at 03:45:28PM +0200, Stephan Witt wrote:
 
 Am 15.05.2015 um 15:14 schrieb Enrico Forestieri for...@lyx.org:
 
 On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
 On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
 
 Thank you. The current splash has a size of 400x250. I'll attach the
 1600x1000 splash banner to test.
 It would be great if this is ok too. If not I have to get it right myself.
 
 Why is this (compressed) svg image so big? Are you sure there is no
 embedded bitmap? That would defeat the purpose of using the svg format.
 
 Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
 That's bad.
 
 Yes, Jürgen said it would be great to find someone who is able to do it 
 better.
 This one was made to have some SVG banner.
 
 Sorry, I did not realize it was that same banner. But why did you attach it, 
 then?

The SVG banner with design size 400x250 results in an pixmap of the same size.
This is not enough for HiDPI. So, I've made a bigger one to get a crisp 
banner.

Stephan 

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Fri, May 15, 2015 at 09:06:34PM +0200, Georg Baum wrote:
 
 Can you try again pelase? c_str() was not instantiated explicitly (because 
 on linux it is automatically instantiated).

Yes, it now compiles on both solaris and cygwin. However, on solaris,
a spurious warning is printed after each tested layout. The output
looks like this:

Testing ../../src/../lib/layouts/AEA.layout...
../../src/tests/test_layout: !: not found
Testing ../../src/../lib/layouts/IEEEtran-CompSoc.layout...
../../src/tests/test_layout: !: not found

I have not investigated, but I think this is due to some script assuming
that /bin/sh is really /bin/bash, and this is not true on solaris.
Incidentally, for this same reason I cannot simply run ./autogen.sh
but have to run bash autogen.sh. This is really minor, though, as


Testing ../../src/../lib/layouts/tufte-handout.layout...
../../src/tests/test_layout: !: not found

layout tests passed.


-- 
Enrico

Re: [LyX/master] tex2lyx testfiles: update to latest fileformat

[Georg Baum]

Am 14.05.2015 um 23:13 schrieb Uwe Stöhr:

commit afdfc3cf43501a0728cef79385b31afe6f4cf877
Author: Uwe Stöhr uwesto...@lyx.org
Date:   Thu May 14 23:13:14 2015 +0200

 tex2lyx testfiles: update to latest fileformat


Uwe, I appreciate your effort to update the tests, but unfortunately it 
does not work like that, for two reasons:


1) It is impossible to manually verify in this huge diff whether the new 
references are really correct.
2) The test machinery uses a textual diff to compare the actual results 
against the reference, so this would still fail.


I added a corresponding note to lib/doc/Development.lyx.

Kornel, could you please describe there how to update the tests with 
cmake? This information is currently missing.



Georg

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Georg Baum]

Kornel Benko wrote:

 Am Donnerstag, 14. Mai 2015 um 21:05:23, schrieb Georg Baum
 georg.b...@post.rwth-aachen.de
 Kornel Benko wrote:
 
  This does not cover all tex2lyx tests used under cmake.
 
 IMHO calling these tests tex2lyx tests is confusing. They test nothing in
 tex2lyx which the standard tex2lyx tests do not test, but they do test
 lyx2lyx in addition.
 
 
 Georg
 
 I am open to any naming.

Maybe combined lyx2lyx and tex2lyx tests?


Georg

Re: [LyX/master] tex2lyx testfiles: update to latest fileformat

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 21:41:37, schrieb Georg Baum 
georg.b...@post.rwth-aachen.de
 Am 14.05.2015 um 23:13 schrieb Uwe Stöhr:
  commit afdfc3cf43501a0728cef79385b31afe6f4cf877
  Author: Uwe Stöhr uwesto...@lyx.org
  Date:   Thu May 14 23:13:14 2015 +0200
 
   tex2lyx testfiles: update to latest fileformat
 
 Uwe, I appreciate your effort to update the tests, but unfortunately it 
 does not work like that, for two reasons:
 
 1) It is impossible to manually verify in this huge diff whether the new 
 references are really correct.
 2) The test machinery uses a textual diff to compare the actual results 
 against the reference, so this would still fail.
 
 I added a corresponding note to lib/doc/Development.lyx.
 
 Kornel, could you please describe there how to update the tests with 
 cmake? This information is currently missing.
 

I am aware of this. And it is not ATM implemented in cmake.

This is, what I wrote to Scott privately (sorry)
 The usage of such a target I rather do not recommend. It hides too easily
 eventual errors.
 I think the goal here is to have easy conversion of test files.
 
 In error case (in cmake) we would anyway check each test and eventually copy
 the compared build-test-file to the appropriate src-test-file.
 Do we then really need such a target?

Running a test in cmake we log the results in
$builddir/Testing/Temporary/LastTest.log
There one can see, what went wrong.

Here the manual toolchain for roundtrip tex2lyx test of test.ltx
# cd $builddir
# ctest -R tex2lyx/roundtrip/test.ltx
-- Start 6: tex2lyx/roundtrip/test.ltx
-- 1/1 Test #6: tex2lyx/roundtrip/test.ltx ...***Failed2.16 sec

Now look into Testing/Temporary/LastTest.log
...
--- /usr/src/lyx/lyx-git/src/tex2lyx/test/test.lyx.lyx  Fri May 15 
22:22:48 2015
+++ /usr/BUILD/BuildLyxGitQt5/src/tex2lyx/test/test.lyx Fri May 15 
22:22:54 2015
@@ -1,5 +1,5 @@
 #LyX file created by tex2lyx 2.2
-\lyxformat 490
+\lyxformat 491
 \begin_document
 \begin_header
 \origin roundtrip
...

What has to be done for update would be
# copy  /usr/BUILD/BuildLyxGitQt5/src/tex2lyx/test/test.lyx 
/usr/src/lyx/lyx-git/src/tex2lyx/test/test.lyx.lyx
but one has really check each file and has to know what he/she is doing.

I really, really dislike to make it automatic.

 Georg

Kornel

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

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

 Le 14/05/15 22:31, Guillaume M-M a écrit :
 My typical use case is to change the macro while keeping the same
 arguments. In the absolute, it is easy to see that this can be useful
 occasionally at least. Indeed, in the absence of macro-unfolding, the
 alternative is to copy and paste the arguments one by one from the old
 macro to the new macro. With unfolding, one just edits the name of the
 macro, benefiting from name completion, etc.
 
 I see it better now. It does not make much sense though that this is
 possible with a macro and not with \frac.

I agree.

 In fact, I do not care so much about macro unfolding itself than the
 possibility of changing the macro in-place (with name completion). Am I
 missing anything?
 
 I do not think you are missing something. Obviously, changing macro
 would be possible as long as the parameters of the macros have the same
 structure. But switching from a two parameters macro to a one parameter
 one is trickier.

Not too difficult. We already have the machinery to (re-)interpret TeX 
snippets (this is used on copying into math).

 About toggling, they had this discussion before some years ago:
 http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I
 don't use repeated unfolding so much. In addition, I do not use macro
 folding because the macros folds itself automatically once the name is
 changed. (But if other power users of unfolding and folding are reading
 this they will surely speak up, right?)

 I hope this clarifies.
 
 Well it indeed clarifies that macro-unfold is a very weird concept :)

Indeed. If the main reason to unfold a macro is to be able to edit its name 
I think we can have this in a much more robust and general way (which would 
work not only for macros but for any command, e.g. \frac):

On unfolding, convert the macro or command including all arguments to a new 
type of inset. This inset would behave like InsetMathUnknown before it is 
finalized (this is the editable ERT that you get when you start typing a 
new command). The difference to InsetMathUnknown would be that the new inset 
would still have the cells of the inset it was converted from attached. When 
editing of the new inset is finished, it would be finalized automatically, 
i.e. converted again into a macro (or built-in command). At that time the 
cells would be re-attached to the final inset, and if it takes less 
arguments then the left over ones would be placed as independent insets 
after the converted one.

This is however a long-term solution. For the short term I will simply try 
to get rid of the ArgumentProxy insets in detachMacroParameters() and re-
interpret each cell. This might result in less good looking detached macro 
parameters, but I believe that this is acceptable.


Georg

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

 Le 14/05/2015 21:00, Georg Baum a écrit :
 Jean-Marc Lasgouttes wrote:

 It is a dummy inset that can be used like a MathInset from outside, but
 forwards every work to the math macro cell that it represents. This
 allows to store the expanded cells in a standard MathData, and it also
 allows to manage the cells like any other math inset if they are detached
 from the macro (well it would allow that if the bug we are currently
 discussing would not exist).
 
 Is there one per macro use or one per argument?

One per argument.

 Would it make sense for the macro inset to hold a copy of the argument
 proxy instead of a pointer? And then this copy would be somehow updated
 as needed.

 It is the other way round: The proxy holds a pointer to the math macro.
 
 Could we make a copy of the macro, then?

I think so, but where to put it? This would need to be an invisible copy.

Anyway, see my other mail, the idea described there could work.


Georg

Re: [LyX/master] Shut up compiler warning

[Georg Baum]

Stephan Witt wrote:

 Thanks. I'm using clang and the only way to get this warning is
 -Wconversion, AFAIK. With these warnings enabled I'm getting tons of
 warnings for boost and Qt headers. So, I'll let it disabled then.

With -Wfloat-conversion you'll also get some in qt and boost, but not as 
much as with clang, so it is a trade-off.


Georg

Re: layout tests are failing

[Georg Baum]

Enrico Forestieri wrote:

 Sorry, I cannot run the tests so I could not see this but I know why it
 happens. Now addLocalLayout() returns a full path if a local layout file
 is found. Hence, it has to be stripped before being used as an index.
 Should be fixed now.

Thanks, works fine now.


Georg

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Georg Baum]

Enrico Forestieri wrote:

 Sure. This is on Solaris:
 
 g++ -fPIC -O2-L/usr/local/lib -Wl,-R/usr/local/lib -L/opt/lib
 -Wl,-R/opt/lib -L/usr/X11/lib -Wl,-R/usr/X11/lib  -o check_trivstring
 check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv
 ../../boost/liblyxboost.a -L/opt/qt5/lib -lQt5Core-laspell  -liconv
 -lz -lmagic
 Undefined   first referenced
  symbol in file
 _ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
 _ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
 ld: fatal: Symbol referencing errors. No output written to
 check_trivstring make[5]: *** [check_trivstring] Error 1

c++filt tells me that the missing symbols are

lyx::trivial_stringchar::c_str() const
lyx::trivial_stringwchar_t::c_str() const

 but it is more clear on Cygwin:
 
 g++ -O2-L/usr/local/lib -shared-libgcc -o check_trivstring.exe
 check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv
 ../../boost/liblyxboost.a -L/usr/local/qt5/lib -L/usr/lib/w32api
 -L/usr/local/lib -lQt5Core -lole32 -luuid -ladvapi32 -lshell32 -luser32
 -lkernel32 -liconv -lspawn -lz -licui18n -licuuc -licudata -lpcre16 -lm 
 -lshlwapi -laspell -lgdi32  -liconv -lz -lmagic
 check_trivstring.o:check_trivstring.cpp:(.text+0xef): undefined reference
 to `lyx::trivial_stringchar::c_str() const'
 check_trivstring.o:check_trivstring.cpp:(.text+0x1a47): undefined
 reference to `lyx::trivial_stringunsigned int::c_str() const' collect2:
 error: ld returned 1 exit status Makefile:570: recipe for target
 'check_trivstring.exe' failed make[5]: *** [check_trivstring.exe] Error 1

Under the assumption that sizeof(unsigned int) == 4 this is exactly the same 
problem as on solaris.

Can you try again pelase? c_str() was not instantiated explicitly (because 
on linux it is automatically instantiated).


Georg

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 17:51 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 Le 15/05/2015 16:58, Stephan Witt a écrit :
 Yes, I think that it is better passing big objects by reference rather
 than by value.
 
 But this is not a good property of C++ compilers than.
 1. It's not a constant fact if an object is big.
 2. The compiler should generate fast code for this scenario too.
 3. This results in hard to read code eventually.
 
 C++ rvalue references fix this problem, and they re implemented in Qt5 (and 
 partly in Qt4.8 AFAICS).

Can you give an example, please? And what's with return value optimization?
I'm not sure I understood it completely, but it sounds like returning objects
by value isn't a problem with modern compilers anymore. Especially I'm not
sure if this is true for nested function calls and passing the result more
than one call up.

Stephan

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/2015 18:47, Stephan Witt a écrit :

C++ rvalue references fix this problem, and they re implemented in Qt5 (and 
partly in Qt4.8 AFAICS).


Can you give an example, please? And what's with return value optimization?
I'm not sure I understood it completely, but it sounds like returning objects
by value isn't a problem with modern compilers anymore. Especially I'm not
sure if this is true for nested function calls and passing the result more
than one call up.


Basically, when returning a temp variable (say a vector) a move 
constructor will steal the contents of the temporary before deleting it, 
instead of doing a copy. A simple description is here:


http://stackoverflow.com/questions/5481539/what-does-t-double-ampersand-mean-in-c11

As far as qt4.8 is concerned, you can read here:

http://blog.qt.io/blog/2011/05/26/cpp0x-in-qt/

JMarc

Re: [patch] support for \fcolorbox and \colorbox

[Jean-Marc Lasgouttes]

Le 15/05/2015 13:48, Uwe Stöhr a écrit :

Am 15.05.2015 um 10:50 schrieb Jean-Marc Lasgouttes:

  A few comments on the patch follow.

Many thanks JMarc,


+static QListColorPair colorData()
+{

 Please use anonymous namespace rather than static in this case
 (no, I cannot tell you why; but anways I think it is in our code
 rules).


I can do so but why is static used in GuiCharacter.cpp for
QListColorPair?


Actually I see now that static is still used more often than anonymous 
namespaces in current code. So you can probably leave it as it is.


JMarc

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 21:45:51, schrieb Georg Baum 
georg.b...@post.rwth-aachen.de
 Kornel Benko wrote:
 
  Am Donnerstag, 14. Mai 2015 um 21:05:23, schrieb Georg Baum
  georg.b...@post.rwth-aachen.de
  Kornel Benko wrote:
  
   This does not cover all tex2lyx tests used under cmake.
  
  IMHO calling these tests tex2lyx tests is confusing. They test nothing in
  tex2lyx which the standard tex2lyx tests do not test, but they do test
  lyx2lyx in addition.
  
  
  Georg
  
  I am open to any naming.
 
 Maybe combined lyx2lyx and tex2lyx tests?
 

In cmake we also distinguish between the two.
The command
# ctest -R test.ltx
displays all test names containing the string test.ltx, in this case the output 
is:
  Test #6: tex2lyx/roundtrip/test.ltx
  Test #7: tex2lyx/cmplyx/test.ltx

It is the second test, which uses 'lyx -E' (not lyx2lyx directly) to compare
the output of tex2lyx and provided test.lyx.lyx.

The first one (roundtrip) does exactly the same as in automake case.

 Georg

Kornel

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

Re: [patch] support for \fcolorbox and \colorbox

[Jean-Marc Lasgouttes]

Le 15/05/15 06:16, Uwe Stöhr a écrit :

Dear LyXers,

the attached patch makes it possible to choose a frame color and a
background color for boxes.


I see that this does not replace boxes with shaded background. Do we 
really need to have all these types of boxes now?



OK to go in?


A few comments on the patch follow.

JMarc

@@ -73,6 +76,60 @@ static QStringList boxGuiSpecialLengthNames()
 }


+static QList colorData()
+{

 Please use anonymous namespace rather than static in this case
 (no, I cannot tell you why; but anways I think it is in our code
 rules).

+   QList colors;
+   colors << ColorPair(qt_("none"), Color_none);
+   colors << ColorPair(qt_("black"), Color_black);
+   colors << ColorPair(qt_("white"), Color_white);
+   colors << ColorPair(qt_("blue"), Color_blue);

Don't we have this information of match between enum and name in 
Color.cpp? What is the point of repeating it here?


+   colors << ColorPair(qt_("brown"), Color_brown);
+   colors << ColorPair(qt_("cyan"), Color_cyan);
+   colors << ColorPair(qt_("darkgray"), Color_darkgray);
+   colors << ColorPair(qt_("gray"), Color_gray);

[...]

+template
+static int findPos2nd(QList const & vec, QString val)
+{
+   for (int i = 0; i != vec.size(); ++i)
+   if (vec[i].first == val)
+   return i;
+   return 0;
+}

I see that this is from GuiCharacter.cpp. Rather than copying it, why 
not put it in qt_helpers.*?

Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is 
possible with a macro and not with \frac.



But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in 
different branches. But this may not be exactly what you are after.



In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro 
would be possible as long as the parameters of the macros have the same 
structure. But switching from a two parameters macro to a one parameter 
one is trickier.



About toggling, they had this discussion before some years ago:
. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)

Thanks,
JMarc

Re: 2.2

[Stephan Witt]

Am 14.05.2015 um 22:08 schrieb Stephan Witt :

> Am 14.05.2015 um 20:07 schrieb Jean-Marc Lasgouttes :
> 
>> Le 13/05/2015 22:52, Stephan Witt a écrit :
>>> Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes :
>>> 
 
 Hi there,
 
 The ritual question: what is still needed for 2.2?
>>> 
>>> The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, named
>>> 0001-svg-hidpi-on-mac.patch is not applied already.
>>> 
>>> It is needed - but I didn't do it until now because it breaks the rendering 
>>> of the
>>> splash image (the BackgroundWidget of GuiView) and I got distracted from 
>>> solving this.
>> 
>> And then Hidpi is mostly done?
> 
> Yes, it looks really good on my display. The problem I have with the splash
> widget is the missing size of the SVG version of the banner.

Ok, I have a working solution now.

There are some remarks:
1. I didn't find a better solution for the params_.pixel_ratio assignment in 
GraphicsLoader.cpp yet.
2. The solution for the banner is to provide a SVG with higher resolution than 
400x250.
This is not part of the patch, I tried it with 800x500 and 1600x1000 and for 
both the result is ok.
3. The initial size of 400x250 for the BackgroundWidget constructor is needed 
to get predictable
results for different physical screen pixel_ratio values.

I'll try to get it running on Linux to see how it works there. Meanwhile, I'm 
interested in comments.

Stephan



0002-svg-hidpi-on-mac.patch
Description: Binary data

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 12:04:50, schrieb Stephan Witt 
> Am 14.05.2015 um 22:08 schrieb Stephan Witt :
> 
> > Am 14.05.2015 um 20:07 schrieb Jean-Marc Lasgouttes :
> > 
> >> Le 13/05/2015 22:52, Stephan Witt a écrit :
> >>> Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes :
> >>> 
>  
>  Hi there,
>  
>  The ritual question: what is still needed for 2.2?
> >>> 
> >>> The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, 
> >>> named
> >>> 0001-svg-hidpi-on-mac.patch is not applied already.
> >>> 
> >>> It is needed - but I didn't do it until now because it breaks the 
> >>> rendering of the
> >>> splash image (the BackgroundWidget of GuiView) and I got distracted from 
> >>> solving this.
> >> 
> >> And then Hidpi is mostly done?
> > 
> > Yes, it looks really good on my display. The problem I have with the splash
> > widget is the missing size of the SVG version of the banner.
> 
> Ok, I have a working solution now.
> 
> There are some remarks:
> 1. I didn't find a better solution for the params_.pixel_ratio assignment in 
> GraphicsLoader.cpp yet.
> 2. The solution for the banner is to provide a SVG with higher resolution 
> than 400x250.
> This is not part of the patch, I tried it with 800x500 and 1600x1000 and for 
> both the result is ok.
> 3. The initial size of 400x250 for the BackgroundWidget constructor is needed 
> to get predictable
> results for different physical screen pixel_ratio values.
> 
> I'll try to get it running on Linux to see how it works there. Meanwhile, I'm 
> interested in comments.
> 
> Stephan

Compiles fine on linux. Splash screen is OK too here.

Kornel

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

Re: [LyX/master] Shut up compiler warning

[Stephan Witt]

Am 14.05.2015 um 20:22 schrieb Georg Baum :

> Stephan Witt wrote:
> 
>> Please, what's the compiler switch to enable these warnings?
>> I don't see them. Neither with the settings of automake nor
>> with the settings of cmake builds.
> 
> autoconf with --enable-warnings and gcc 4.9 (this enables -Wall -Wextra -
> Wfloat-conversion, I guess the last one is the one you mean). Note that it 
> is inside an #ifdef qt5, so you won't see it if you compile for qt4.

Thanks. I'm using clang and the only way to get this warning is -Wconversion, 
AFAIK.
With these warnings enabled I'm getting tons of warnings for boost and Qt 
headers.
So, I'll let it disabled then.

Stephan 

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 12:42:01, schrieb Stephan Witt 
> Am 15.05.2015 um 12:33 schrieb Kornel Benko :
>
> > Am Freitag, 15. Mai 2015 um 12:04:50, schrieb Stephan Witt 
> >> Am 14.05.2015 um 22:08 schrieb Stephan Witt :
> >>
> >>> Am 14.05.2015 um 20:07 schrieb Jean-Marc Lasgouttes :
> >>>
>  Le 13/05/2015 22:52, Stephan Witt a écrit :
> > Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes 
> > :
> >
> >>
> >> Hi there,
> >>
> >> The ritual question: what is still needed for 2.2?
> >
> > The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, 
> > named
> > 0001-svg-hidpi-on-mac.patch is not applied already.
> >
> > It is needed - but I didn't do it until now because it breaks the 
> > rendering of the
> > splash image (the BackgroundWidget of GuiView) and I got distracted 
> > from solving this.
> 
>  And then Hidpi is mostly done?
> >>>
> >>> Yes, it looks really good on my display. The problem I have with the 
> >>> splash
> >>> widget is the missing size of the SVG version of the banner.
> >>
> >> Ok, I have a working solution now.
> >>
> >> There are some remarks:
> >> 1. I didn't find a better solution for the params_.pixel_ratio assignment 
> >> in GraphicsLoader.cpp yet.
> >> 2. The solution for the banner is to provide a SVG with higher resolution 
> >> than 400x250.
> >> This is not part of the patch, I tried it with 800x500 and 1600x1000 and 
> >> for both the result is ok.
> >> 3. The initial size of 400x250 for the BackgroundWidget constructor is 
> >> needed to get predictable
> >> results for different physical screen pixel_ratio values.
> >>
> >> I'll try to get it running on Linux to see how it works there. Meanwhile, 
> >> I'm interested in comments.
> >>
> >> Stephan
> >
> > Compiles fine on linux. Splash screen is OK too here.
>
> Thank you. The current splash has a size of 400x250. I'll attach the 
> 1600x1000 splash banner to test.
> It would be great if this is ok too. If not I have to get it right myself.
>
> Stephan

The border lines (around LYX) are too thin, the text looks not good.

Kornel

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

Re: [patch] support for \fcolorbox and \colorbox

[Uwe Stöhr]

Am 15.05.2015 um 06:16 schrieb Uwe Stöhr:
> the attached patch makes it possible to choose a frame color and a

background color for boxes.



Attached is a better patch.

(I forgot to register xcolor and now also take care that a box with a 
frame color <> black cannot have no background color)


regards Uwe
 lib/lyx2lyx/LyX.py|   2 +-
 lib/lyx2lyx/lyx_2_2.py|  49 +-
 src/frontends/qt4/GuiBox.cpp  | 108 +
 src/frontends/qt4/GuiBox.h|   7 +-
 src/frontends/qt4/ui/BoxUi.ui | 212 +++---
 src/insets/InsetBox.cpp   |  82 
 src/insets/InsetBox.h |   4 +
 src/tex2lyx/text.cpp  |   2 +
 src/version.h |   4 +-
 9 files changed, 369 insertions(+), 101 deletions(-)

diff --git a/lib/lyx2lyx/LyX.py b/lib/lyx2lyx/LyX.py
index 246ab33..c7815f7 100644
--- a/lib/lyx2lyx/LyX.py
+++ b/lib/lyx2lyx/LyX.py
@@ -85,7 +85,7 @@ format_relation = [("0_06",[200], minor_versions("0.6" , 
4)),
("1_6", list(range(277,346)), minor_versions("1.6" , 10)),
("2_0", list(range(346,414)), minor_versions("2.0" , 8)),
("2_1", list(range(414,475)), minor_versions("2.1" , 0)),
-   ("2_2", list(range(475,492)), minor_versions("2.2" , 0))
+   ("2_2", list(range(475,493)), minor_versions("2.2" , 0))
   ]
 
 
diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index 087e9c3..ec6213b 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@ -1077,6 +1077,51 @@ def revert_textcolor(document):
 i = i + 1
 
 
+def convert_colorbox(document):
+" adds color settings for boxes "
+
+i = 0
+while True:
+i = find_token(document.body, "height_special", i)
+if i == -1:
+return
+document.body.insert(i + 2, 'framecolor "black"\nbackgroundcolor 
"white"')
+i = i + 2
+
+
+def revert_colorbox(document):
+" outputs color settings for boxes as TeX code "
+
+i = 0
+defaultframecolor = "black"
+defaultbackcolor = "white"
+while True:
+i = find_token(document.body, "framecolor", i)
+if i == -1:
+return
+# read out the values
+beg = document.body[i].find('"');
+end = document.body[i].rfind('"');
+framecolor = document.body[i][beg+1:end];
+beg = document.body[i+1].find('"');
+end = document.body[i+1].rfind('"');
+backcolor = document.body[i+1][beg+1:end];
+# delete the specification
+del document.body[i:i+2]
+# output TeX code
+# first output the closing brace
+if framecolor != defaultframecolor or backcolor != defaultbackcolor:
+document.body[i + 9 : i + 9] = put_cmd_in_ert("}")
+# now output the box commands
+if framecolor != defaultframecolor or backcolor != defaultbackcolor:
+document.body[i - 14 : i - 14] = put_cmd_in_ert("{")
+if framecolor != defaultframecolor:
+document.body[i - 9 : i - 8] = ["\\backslash fboxcolor{" + 
framecolor + "}{" + backcolor + "}{"]
+if backcolor != defaultbackcolor and framecolor == defaultframecolor:
+document.body[i - 9 : i - 8] = ["\\backslash colorbox{" + 
backcolor + "}{"]
+i = i + 11
+
+
 ##
 # Conversion hub
 #
@@ -1102,10 +1147,12 @@ convert = [
[488, [convert_newgloss]],
[489, [convert_BoxFeatures]],
[490, [convert_origin]],
-   [491, []]
+   [491, []],
+   [492, [convert_colorbox]]
   ]
 
 revert =  [
+   [491, [revert_colorbox]],
[490, [revert_textcolor]],
[489, [revert_origin]],
[488, [revert_BoxFeatures]],
diff --git a/src/frontends/qt4/GuiBox.cpp b/src/frontends/qt4/GuiBox.cpp
index 2da6947..2deb45f 100644
--- a/src/frontends/qt4/GuiBox.cpp
+++ b/src/frontends/qt4/GuiBox.cpp
@@ -15,6 +15,8 @@
 
 #include "GuiBox.h"
 
+#include "GuiApplication.h"
+#include "ColorCache.h"
 #include "LengthCombo.h"
 #include "Length.h"
 #include "qt_helpers.h"
@@ -26,6 +28,7 @@
 #include "support/foreach.h"
 #include "support/lstrings.h"
 
+#include 
 #include 
 #include 
 
@@ -73,6 +76,60 @@ static QStringList boxGuiSpecialLengthNames()
 }
 
 
+static QList colorData()
+{
+   QList colors;
+   colors << ColorPair(qt_("none"), Color_none);
+   colors << ColorPair(qt_("black"), Color_black);
+   colors << ColorPair(qt_("white"), Color_white);
+   colors << ColorPair(qt_("blue"), Color_blue);
+   colors << ColorPair(qt_("brown"), Color_brown);
+   colors << ColorPair(qt_("cyan"), Color_cyan);
+   colors << ColorPair(qt_("darkgray"), Color_darkgray);
+   colors << ColorPair(qt_("gray"), Color_gray);
+   colors << ColorPair(qt_("green"), Color_green);
+   colors << 

Re: [patch] support for \fcolorbox and \colorbox

[Uwe Stöhr]

Am 15.05.2015 um 10:50 schrieb Jean-Marc Lasgouttes:

> A few comments on the patch follow.

Many thanks JMarc,


+static QList colorData()
+{

 Please use anonymous namespace rather than static in this case
 (no, I cannot tell you why; but anways I think it is in our code
 rules).


I can do so but why is static used in GuiCharacter.cpp for QList?


+QList colors;
+colors << ColorPair(qt_("none"), Color_none);
+colors << ColorPair(qt_("black"), Color_black);
+colors << ColorPair(qt_("white"), Color_white);
+colors << ColorPair(qt_("blue"), Color_blue);

Don't we have this information of match between enum and name in
Color.cpp? What is the point of repeating it here?


I stole the list idea from GuiCharacter.cpp. The reason is that one 
needs a defined list to fill the combo box. The list in GuiCharacter.cpp 
is different from the list in GuiBox.cpp.
If I would use the list in Color.cpp for GuiBox.cpp, I would have to 
hardcode a subset of it (that only the first 20 items are used for 
filling). This seems to be error-prone because if anybody adds a color 
in Color.cpp there will be wrong colors in the box dialog causing LaTeX 
errors.



+template
+static int findPos2nd(QList const & vec, QString val)
+{
+for (int i = 0; i != vec.size(); ++i)
+if (vec[i].first == val)
+return i;
+return 0;
+}

I see that this is from GuiCharacter.cpp. Rather than copying it, why
not put it in qt_helpers.*?


Because it is different from the one of GuiCharacter.cpp. So each 
version of findPos2nd is only used in one class. I you nevertheless like 
I can add both variants of findPos2nd to helpers.


thanks and regards
Uwe

Re: 2.2

[Uwe Stöhr]

Am 14.05.2015 um 20:10 schrieb Jean-Marc Lasgouttes:


Since a long time I have some time for LyX and ant to use is to enrich
it with some more features if possible. So if it is not urgent I would
be happy not to start the feature freeze before June.


I am not sure that the point when we discuss feature freeze is the right
moment for adding as many features as necessary. Nothing is never
urgent, but I think we have to draw the line as soon as possible and
just work towards an actual release.


This has nothing to do with the announcement of a soon feature freeze. 
As you saw I had now some more time for LyX and used it to work on my 
ToAdd list.
Nevertheless I like to have more frequent major releases. So fine with 
me if you say feature freeze soon.
So I'm not working on any new feature and concentrate on bug fixing 
after my box color feature is in. OK?



PS: also I guess a lot of documentation work will be needed; I remember
that for 2.1 is was a bit hurried, we will probably want to plan this time.


That would be nice. There are no so many features in 2.2 compared to 
2.1. And things like horizontal scrollbar, Qt5 and HiDPI don't require 
much documentation change.


regards Uwe

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/15 13:58, Uwe Stöhr a écrit :

This has nothing to do with the announcement of a soon feature freeze.
As you saw I had now some more time for LyX and used it to work on my
ToAdd list.
Nevertheless I like to have more frequent major releases. So fine with
me if you say feature freeze soon.
So I'm not working on any new feature and concentrate on bug fixing
after my box color feature is in. OK?


I think that it would be nice to do that indeed. But then we will need 
to be serious about release and not spend 8 months like last time.



That would be nice. There are no so many features in 2.2 compared to
2.1. And things like horizontal scrollbar, Qt5 and HiDPI don't require
much documentation change.


Indeed.

JMarc

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/15 12:42, Stephan Witt a écrit :

Thank you. The current splash has a size of 400x250. I'll attach the 1600x1000 
splash banner to test.
It would be great if this is ok too. If not I have to get it right myself.


Why is there a need to set a size for the splash? Since it is 
vector-based, one can just resize it, right?


JMarc

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
> 
> I'll try to get it running on Linux to see how it works there. Meanwhile,
> I'm interested in comments.

Please, don't pass back and forth QPixmap objects on the stack. These
are big objects, potentially. Instead, use

bool getPixmap(QString const & path, QPixmap & pm)
{
// deal with QPixmap

return !pm.isNull();
}

> 
> diff --git a/src/frontends/qt4/GuiApplication.cpp 
> b/src/frontends/qt4/GuiApplication.cpp
> index eaf33c4..de4569a 100644
> --- a/src/frontends/qt4/GuiApplication.cpp
> +++ b/src/frontends/qt4/GuiApplication.cpp
> @@ -569,22 +569,39 @@ QString iconName(FuncRequest const & f, bool unknown)
>   return QString();
>  }
>  
> -QPixmap getPixmap(QString const & path, QString const & name, QString const 
> & ext)
> +QPixmap getPixmap(QString const & path)
>  {
>   QPixmap pixmap;
> + if (pixmap.load(path)) {
> + if (path.endsWith(".svgz") || path.endsWith(".svg") ) {
> + GuiApplication const * guiApp = theGuiApp();
> + if (guiApp != 0) {
> + 
> pixmap.setDevicePixelRatio(guiApp->pixelRatio());
> + }
> + }
> + return pixmap;
> + }
> + return QPixmap();
> +}
> +
> +QPixmap getPixmap(QString const & path, QString const & name, QString const 
> & ext)
> +{
>   QString imagedir = path;
>   FileName fname = imageLibFileSearch(imagedir, name, ext, 
> theGuiApp()->imageSearchMode());
>   QString fpath = toqstr(fname.absFileName());
> + QPixmap pixmap = getPixmap(fpath);
>  
> - if (pixmap.load(fpath)) {
> + if (!pixmap.isNull()) {
>   return pixmap;
> - } else {
> - QStringList exts = ext.split(",");
> - fpath = ":/" + path + name + ".";
> - for (int i = 0; i < exts.size(); ++i) {
> - if (pixmap.load(fpath + exts.at(i)))
> + }
> + 
> + QStringList exts = ext.split(",");
> + fpath = ":/" + path + name + ".";
> + for (int i = 0; i < exts.size(); ++i) {
> + pixmap = getPixmap(fpath + exts.at(i));
> + if (!pixmap.isNull()) {
>   return pixmap;
> - }
> + }
>   }
>  
>   bool const list = ext.contains(",");
> @@ -613,13 +630,13 @@ QIcon getIcon(FuncRequest const & f, bool unknown)
>   return QIcon();
>  
>   //LYXERR(Debug::GUI, "Found icon: " << icon);
> - QPixmap pm;
> - if (!pm.load(icon)) {
> + QPixmap pixmap = getPixmap(icon);
> + if (pixmap.isNull()) {
>   LYXERR0("Cannot load icon " << icon << " please verify resource 
> system!");
>   return QIcon();
>   }
>  
> - return QIcon(pm);
> + return QIcon(pixmap);
>  }
>  
>  

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
> 
> Thank you. The current splash has a size of 400x250. I'll attach the
> 1600x1000 splash banner to test.
> It would be great if this is ok too. If not I have to get it right myself.

Why is this (compressed) svg image so big? Are you sure there is no
embedded bitmap? That would defeat the purpose of using the svg format.

-- 
Enrico

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 15:14 schrieb Enrico Forestieri :

> On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
>> On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
>>> 
>>> Thank you. The current splash has a size of 400x250. I'll attach the
>>> 1600x1000 splash banner to test.
>>> It would be great if this is ok too. If not I have to get it right myself.
>> 
>> Why is this (compressed) svg image so big? Are you sure there is no
>> embedded bitmap? That would defeat the purpose of using the svg format.
> 
> Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
> That's bad.

Yes, Jürgen said it would be great to find someone who is able to do it better.
This one was made to have some SVG banner.

Stephan

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 14:49 schrieb Enrico Forestieri :

> On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
>> 
>> I'll try to get it running on Linux to see how it works there. Meanwhile,
>> I'm interested in comments.
> 
> Please, don't pass back and forth QPixmap objects on the stack. These
> are big objects, potentially. Instead, use
> 
> bool getPixmap(QString const & path, QPixmap & pm)
> {
>   // deal with QPixmap
> 
>   return !pm.isNull();
> }

Ok, thank you. I'll change it.

Stephan

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 14:32 schrieb Jean-Marc Lasgouttes :

> Le 15/05/15 12:42, Stephan Witt a écrit :
>> Thank you. The current splash has a size of 400x250. I'll attach the 
>> 1600x1000 splash banner to test.
>> It would be great if this is ok too. If not I have to get it right myself.
> 
> Why is there a need to set a size for the splash? Since it is vector-based, 
> one can just resize it, right?

There is no handle to resize the splash image.
One can resize the window containing the splash but the image size should be 
constant, IMHO.

Stephan

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 15:46 schrieb Stephan Witt :

> Am 15.05.2015 um 14:49 schrieb Enrico Forestieri :
> 
>> On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
>>> 
>>> I'll try to get it running on Linux to see how it works there. Meanwhile,
>>> I'm interested in comments.
>> 
>> Please, don't pass back and forth QPixmap objects on the stack. These
>> are big objects, potentially. Instead, use
>> 
>> bool getPixmap(QString const & path, QPixmap & pm)
>> {
>>  // deal with QPixmap
>> 
>>  return !pm.isNull();
>> }
> 
> Ok, thank you. I'll change it.

This results in the following patch - if you had something like that in mind 
I'll
split it in two patches. The other getPixmap method with QPixmap result was 
already there.

Stephan



0003-svg-hidpi-on-mac.patch
Description: Binary data

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 16:31:05, schrieb Stephan Witt 
> Am 15.05.2015 um 15:46 schrieb Stephan Witt :
> 
> > Am 15.05.2015 um 14:49 schrieb Enrico Forestieri :
> > 
> >> On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
> >>> 
> >>> I'll try to get it running on Linux to see how it works there. Meanwhile,
> >>> I'm interested in comments.
> >> 
> >> Please, don't pass back and forth QPixmap objects on the stack. These
> >> are big objects, potentially. Instead, use
> >> 
> >> bool getPixmap(QString const & path, QPixmap & pm)
> >> {
> >>// deal with QPixmap
> >> 
> >>return !pm.isNull();
> >> }
> > 
> > Ok, thank you. I'll change it.
> 
> This results in the following patch - if you had something like that in mind 
> I'll
> split it in two patches. The other getPixmap method with QPixmap result was 
> already there.
> 
> Stephan

Compile error with this patch.

cd /usr/BUILD/BuildLyxGitQt5/src/frontends/qt4 && /usr/bin/c++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DLYX_BUILD_QT_FRONTEND 
-DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR -DQT_GUI_LIB 
-DQT_WIDGETS_LIB -Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing  
-Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG 
-fPIC -I/usr/BUILD/BuildLyxGitQt5 -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/frontends -I/usr/src/lyx/lyx-git/src/frontends/qt4 
-I/usr/BUILD/BuildLyxGitQt5/src/frontends/qt4 -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtCore -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/mkspecs/linux-g++ -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtGui -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtWidgets -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtConcurrent
-DBOOST_USER_CONFIG="" -o CMakeFiles/frontend_qt.dir/GuiView.cpp.o -c 
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp: In constructor 
‘lyx::frontend::GuiView::GuiView(int)’:
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:539:77: error: no matching 
function for call to ‘getPixmap(const char [8], const char [4], const char [8])’
  setWindowIcon(QIcon::fromTheme("lyx", getPixmap("images/", "lyx", 
"svg,png")));
 ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:539:77: note: candidates are:
In file included from /usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:22:0:
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:251:6: note: bool 
lyx::frontend::getPixmap(QPixmap&, const QString&, const QString&, const 
QString&)
 bool getPixmap(QPixmap & pixmap, QString const & path, QString const & name, 
QString const & ext);
  ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:251:6: note:   
candidate expects 4 arguments, 3 provided
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:252:6: note: bool 
lyx::frontend::getPixmap(QPixmap&, const QString&)
 bool getPixmap(QPixmap & pixmap, QString const & path);
  ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.h:252:6: note:   
candidate expects 2 arguments, 3 provided
make[2]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiView.cpp.o] Chyba 
1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'
make[1]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'

Kornel

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

Re: 2.2

[Jürgen Spitzmüller]

2015-05-15 15:14 GMT+02:00 Enrico Forestieri:

> Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the
> svg.
> That's bad.
>

I just hacked this svg splash together quite quickly for testing pruposes.
It is _not_ intended to be published.
I agree, of course, that the final splash should be pure vector.

Jürgen


>
> --
> Enrico
>

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
> 
> This results in the following patch - if you had something like that in
> mind I'll split it in two patches. The other getPixmap method with
> QPixmap result was already there.

Yes, I think that it is better passing big objects by reference rather
than by value.

-- 
Enrico

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 16:40 schrieb Kornel Benko :

> Am Freitag, 15. Mai 2015 um 16:31:05, schrieb Stephan Witt 
>> Am 15.05.2015 um 15:46 schrieb Stephan Witt :
>> 
>>> Am 15.05.2015 um 14:49 schrieb Enrico Forestieri :
>>> 
 On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
> 
> I'll try to get it running on Linux to see how it works there. Meanwhile,
> I'm interested in comments.
 
 Please, don't pass back and forth QPixmap objects on the stack. These
 are big objects, potentially. Instead, use
 
 bool getPixmap(QString const & path, QPixmap & pm)
 {
// deal with QPixmap
 
return !pm.isNull();
 }
>>> 
>>> Ok, thank you. I'll change it.
>> 
>> This results in the following patch - if you had something like that in mind 
>> I'll
>> split it in two patches. The other getPixmap method with QPixmap result was 
>> already there.
>> 
>> Stephan
> 
> Compile error with this patch.

That's no surprise. The method I've changed is used in conditionally compiled 
code. 
Attached is an updated patch.

Stephan



0004-svg-hidpi-on-mac.patch
Description: Binary data

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 16:48 schrieb Enrico Forestieri :

> On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
>> 
>> This results in the following patch - if you had something like that in
>> mind I'll split it in two patches. The other getPixmap method with
>> QPixmap result was already there.
> 
> Yes, I think that it is better passing big objects by reference rather
> than by value.

But this is not a good property of C++ compilers than.
1. It's not a constant fact if an object is big.
2. The compiler should generate fast code for this scenario too.
3. This results in hard to read code eventually.

Stephan

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/15/15 10:04, Jean-Marc Lasgouttes wrote:

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is
possible with a macro and not with \frac.


I agree.




But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in
different branches. But this may not be exactly what you are after.


No indeed, I am speaking of something else. For instance we can use 
copy/paste on one equation because only a few details have to be 
changed. Or simply we can change our mind during the typesetting of a 
proof: writing an article does not go in a straight line.





In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro
would be possible as long as the parameters of the macros have the same
structure. But switching from a two parameters macro to a one parameter
one is trickier.


About toggling, they had this discussion before some years ago:
. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)


For these implementation details I agree---but if the question is "how 
do we change the name of a macro in a way that has the same features 
(e.g. completion) as inserting the macro in the first place", then the 
idea of unfolding is quite natural.


Sorry for not being familiar enough with the source code to make more 
constructive suggestions.



Guillaume

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/2015 16:58, Stephan Witt a écrit :

Yes, I think that it is better passing big objects by reference rather
than by value.


But this is not a good property of C++ compilers than.
1. It's not a constant fact if an object is big.
2. The compiler should generate fast code for this scenario too.
3. This results in hard to read code eventually.


C++ rvalue references fix this problem, and they re implemented in Qt5 
(and partly in Qt4.8 AFAICS).


JMarc

Re: 2.2

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 16:53:51, schrieb Stephan Witt 
> > 
> > Compile error with this patch.
> 
> That's no surprise. The method I've changed is used in conditionally compiled 
> code. 
> Attached is an updated patch.
> 

Still problems ...
[ 30%] Building CXX object 
src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiView.cpp.o
cd /usr/BUILD/BuildLyxGitQt5/src/frontends/qt4 && /usr/bin/c++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DLYX_BUILD_QT_FRONTEND 
-DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR -DQT_GUI_LIB 
-DQT_WIDGETS_LIB -Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing  
-Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG 
-fPIC -I/usr/BUILD/BuildLyxGitQt5 -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/frontends -I/usr/src/lyx/lyx-git/src/frontends/qt4 
-I/usr/BUILD/BuildLyxGitQt5/src/frontends/qt4 -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtCore -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/mkspecs/linux-g++ -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtGui -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtWidgets -isystem 
/usr/BUILD/BuildQt5/5.4/gcc_64/include/QtConcurrent
-DBOOST_USER_CONFIG="" -o CMakeFiles/frontend_qt.dir/GuiView.cpp.o -c 
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp: In constructor 
‘lyx::frontend::GuiView::GuiView(int)’:
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:536:51: error: expected 
primary-expression before ‘)’ token
  if (getPixmap(pmLyX,"images/", "lyx", "svg,png"))) {
   ^
/usr/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:536:51: error: expected ‘;’ 
before ‘)’ token
make[2]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiView.cpp.o] Chyba 
1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'
make[1]: *** [src/frontends/qt4/CMakeFiles/frontend_qt.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQt5'

(One ')' too much).

With this corrected, it compiles.

Kornel

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

Re: [patch] support for \fcolorbox and \colorbox

[Jean-Marc Lasgouttes]

Le 15/05/2015 13:48, Uwe Stöhr a écrit :

Am 15.05.2015 um 10:50 schrieb Jean-Marc Lasgouttes:

 > A few comments on the patch follow.

Many thanks JMarc,


+static QList colorData()
+{

 Please use anonymous namespace rather than static in this case
 (no, I cannot tell you why; but anways I think it is in our code
 rules).


I can do so but why is static used in GuiCharacter.cpp for
QList?


Actually I see now that "static" is still used more often than anonymous 
namespaces in current code. So you can probably leave it as it is.


JMarc

Re: 2.2

[Stephan Witt]

Am 15.05.2015 um 17:51 schrieb Jean-Marc Lasgouttes :

> Le 15/05/2015 16:58, Stephan Witt a écrit :
>>> Yes, I think that it is better passing big objects by reference rather
>>> than by value.
>> 
>> But this is not a good property of C++ compilers than.
>> 1. It's not a constant fact if an object is big.
>> 2. The compiler should generate fast code for this scenario too.
>> 3. This results in hard to read code eventually.
> 
> C++ rvalue references fix this problem, and they re implemented in Qt5 (and 
> partly in Qt4.8 AFAICS).

Can you give an example, please? And what's with return value optimization?
I'm not sure I understood it completely, but it sounds like returning objects
by value isn't a problem with modern compilers anymore. Especially I'm not
sure if this is true for nested function calls and passing the result more
than one call up.

Stephan

Re: 2.2

[Jean-Marc Lasgouttes]

Le 15/05/2015 18:47, Stephan Witt a écrit :

C++ rvalue references fix this problem, and they re implemented in Qt5 (and 
partly in Qt4.8 AFAICS).


Can you give an example, please? And what's with return value optimization?
I'm not sure I understood it completely, but it sounds like returning objects
by value isn't a problem with modern compilers anymore. Especially I'm not
sure if this is true for nested function calls and passing the result more
than one call up.


Basically, when returning a temp variable (say a vector) a move 
constructor will steal the contents of the temporary before deleting it, 
instead of doing a copy. A simple description is here:


http://stackoverflow.com/questions/5481539/what-does-t-double-ampersand-mean-in-c11

As far as qt4.8 is concerned, you can read here:

http://blog.qt.io/blog/2011/05/26/cpp0x-in-qt/

JMarc

Re: [LyX/master] Shut up compiler warning

[Georg Baum]

Stephan Witt wrote:

> Thanks. I'm using clang and the only way to get this warning is
> -Wconversion, AFAIK. With these warnings enabled I'm getting tons of
> warnings for boost and Qt headers. So, I'll let it disabled then.

With -Wfloat-conversion you'll also get some in qt and boost, but not as 
much as with clang, so it is a trade-off.


Georg

Re: layout tests are failing

[Georg Baum]

Enrico Forestieri wrote:

> Sorry, I cannot run the tests so I could not see this but I know why it
> happens. Now addLocalLayout() returns a full path if a local layout file
> is found. Hence, it has to be stripped before being used as an index.
> Should be fixed now.

Thanks, works fine now.


Georg

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Georg Baum]

Enrico Forestieri wrote:

> Sure. This is on Solaris:
> 
> g++ -fPIC -O2-L/usr/local/lib -Wl,-R/usr/local/lib -L/opt/lib
> -Wl,-R/opt/lib -L/usr/X11/lib -Wl,-R/usr/X11/lib  -o check_trivstring
> check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv
> ../../boost/liblyxboost.a -L/opt/qt5/lib -lQt5Core-laspell  -liconv
> -lz -lmagic
> Undefined   first referenced
>  symbol in file
> _ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
> _ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
> ld: fatal: Symbol referencing errors. No output written to
> check_trivstring make[5]: *** [check_trivstring] Error 1

c++filt tells me that the missing symbols are

lyx::trivial_string::c_str() const
lyx::trivial_string::c_str() const

> but it is more clear on Cygwin:
> 
> g++ -O2-L/usr/local/lib -shared-libgcc -o check_trivstring.exe
> check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv
> ../../boost/liblyxboost.a -L/usr/local/qt5/lib -L/usr/lib/w32api
> -L/usr/local/lib -lQt5Core -lole32 -luuid -ladvapi32 -lshell32 -luser32
> -lkernel32 -liconv -lspawn -lz -licui18n -licuuc -licudata -lpcre16 -lm 
> -lshlwapi -laspell -lgdi32  -liconv -lz -lmagic
> check_trivstring.o:check_trivstring.cpp:(.text+0xef): undefined reference
> to `lyx::trivial_string::c_str() const'
> check_trivstring.o:check_trivstring.cpp:(.text+0x1a47): undefined
> reference to `lyx::trivial_string::c_str() const' collect2:
> error: ld returned 1 exit status Makefile:570: recipe for target
> 'check_trivstring.exe' failed make[5]: *** [check_trivstring.exe] Error 1

Under the assumption that sizeof(unsigned int) == 4 this is exactly the same 
problem as on solaris.

Can you try again pelase? c_str() was not instantiated explicitly (because 
on linux it is automatically instantiated).


Georg

Re: [LyX/master] tex2lyx testfiles: update to latest fileformat

[Georg Baum]

Am 14.05.2015 um 23:13 schrieb Uwe Stöhr:

commit afdfc3cf43501a0728cef79385b31afe6f4cf877
Author: Uwe Stöhr 
Date:   Thu May 14 23:13:14 2015 +0200

 tex2lyx testfiles: update to latest fileformat


Uwe, I appreciate your effort to update the tests, but unfortunately it 
does not work like that, for two reasons:


1) It is impossible to manually verify in this huge diff whether the new 
references are really correct.
2) The test machinery uses a textual diff to compare the actual results 
against the reference, so this would still fail.


I added a corresponding note to lib/doc/Development.lyx.

Kornel, could you please describe there how to update the tests with 
cmake? This information is currently missing.



Georg

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Georg Baum]

Kornel Benko wrote:

> Am Donnerstag, 14. Mai 2015 um 21:05:23, schrieb Georg Baum
> 
>> Kornel Benko wrote:
>> 
>> > This does not cover all tex2lyx tests used under cmake.
>> 
>> IMHO calling these tests tex2lyx tests is confusing. They test nothing in
>> tex2lyx which the standard tex2lyx tests do not test, but they do test
>> lyx2lyx in addition.
>> 
>> 
>> Georg
> 
> I am open to any naming.

Maybe "combined lyx2lyx and tex2lyx tests"?


Georg

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 14/05/15 22:31, Guillaume M-M a écrit :
>> My typical use case is to change the macro while keeping the same
>> arguments. In the absolute, it is easy to see that this can be useful
>> occasionally at least. Indeed, in the absence of macro-unfolding, the
>> alternative is to copy and paste the arguments one by one from the old
>> macro to the new macro. With unfolding, one just edits the name of the
>> macro, benefiting from name completion, etc.
> 
> I see it better now. It does not make much sense though that this is
> possible with a macro and not with \frac.

I agree.

>> In fact, I do not care so much about macro unfolding itself than the
>> possibility of changing the macro in-place (with name completion). Am I
>> missing anything?
> 
> I do not think you are missing something. Obviously, changing macro
> would be possible as long as the parameters of the macros have the same
> structure. But switching from a two parameters macro to a one parameter
> one is trickier.

Not too difficult. We already have the machinery to (re-)interpret TeX 
snippets (this is used on copying into math).

>> About toggling, they had this discussion before some years ago:
>> . I admit that I
>> don't use repeated unfolding so much. In addition, I do not use macro
>> folding because the macros folds itself automatically once the name is
>> changed. (But if other power users of unfolding and folding are reading
>> this they will surely speak up, right?)
>>
>> I hope this clarifies.
> 
> Well it indeed clarifies that macro-unfold is a very weird concept :)

Indeed. If the main reason to unfold a macro is to be able to edit its name 
I think we can have this in a much more robust and general way (which would 
work not only for macros but for any command, e.g. \frac):

On unfolding, convert the macro or command including all arguments to a new 
type of inset. This inset would behave like InsetMathUnknown before it is 
finalized (this is the editable "ERT" that you get when you start typing a 
new command). The difference to InsetMathUnknown would be that the new inset 
would still have the cells of the inset it was converted from attached. When 
editing of the new inset is finished, it would be "finalized" automatically, 
i.e. converted again into a macro (or built-in command). At that time the 
cells would be re-attached to the final inset, and if it takes less 
arguments then the left over ones would be placed as independent insets 
after the converted one.

This is however a long-term solution. For the short term I will simply try 
to get rid of the ArgumentProxy insets in detachMacroParameters() and re-
interpret each cell. This might result in less good looking detached macro 
parameters, but I believe that this is acceptable.


Georg

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 14/05/2015 21:00, Georg Baum a écrit :
>> Jean-Marc Lasgouttes wrote:
>>
>> It is a dummy inset that can be used like a MathInset from outside, but
>> forwards every work to the math macro cell that it represents. This
>> allows to store the expanded cells in a standard MathData, and it also
>> allows to manage the cells like any other math inset if they are detached
>> from the macro (well it would allow that if the bug we are currently
>> discussing would not exist).
> 
> Is there one per macro use or one per argument?

One per argument.

>>> Would it make sense for the macro inset to hold a copy of the argument
>>> proxy instead of a pointer? And then this copy would be somehow updated
>>> as needed.
>>
>> It is the other way round: The proxy holds a pointer to the math macro.
> 
> Could we make a copy of the macro, then?

I think so, but where to put it? This would need to be an invisible copy.

Anyway, see my other mail, the idea described there could work.


Georg

Re: [LyX/master] tex2lyx testfiles: update to latest fileformat

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 21:41:37, schrieb Georg Baum 

> Am 14.05.2015 um 23:13 schrieb Uwe Stöhr:
> > commit afdfc3cf43501a0728cef79385b31afe6f4cf877
> > Author: Uwe Stöhr 
> > Date:   Thu May 14 23:13:14 2015 +0200
> >
> >  tex2lyx testfiles: update to latest fileformat
> 
> Uwe, I appreciate your effort to update the tests, but unfortunately it 
> does not work like that, for two reasons:
> 
> 1) It is impossible to manually verify in this huge diff whether the new 
> references are really correct.
> 2) The test machinery uses a textual diff to compare the actual results 
> against the reference, so this would still fail.
> 
> I added a corresponding note to lib/doc/Development.lyx.
> 
> Kornel, could you please describe there how to update the tests with 
> cmake? This information is currently missing.
> 

I am aware of this. And it is not ATM implemented in cmake.

This is, what I wrote to Scott privately (sorry)
> The usage of such a target I rather do not recommend. It hides too easily
> eventual errors.
> I think the goal here is to have easy conversion of test files.
> 
> In error case (in cmake) we would anyway check each test and eventually copy
> the compared build-test-file to the appropriate src-test-file.
> Do we then really need such a target?

Running a test in cmake we log the results in
$builddir/Testing/Temporary/LastTest.log
There one can see, what went wrong.

Here the manual toolchain for roundtrip tex2lyx test of test.ltx
# cd $builddir
# ctest -R tex2lyx/roundtrip/test.ltx
--> Start 6: tex2lyx/roundtrip/test.ltx
--> 1/1 Test #6: tex2lyx/roundtrip/test.ltx ...***Failed2.16 sec

Now look into Testing/Temporary/LastTest.log
...
--- /usr/src/lyx/lyx-git/src/tex2lyx/test/test.lyx.lyx  Fri May 15 
22:22:48 2015
+++ /usr/BUILD/BuildLyxGitQt5/src/tex2lyx/test/test.lyx Fri May 15 
22:22:54 2015
@@ -1,5 +1,5 @@
 #LyX file created by tex2lyx 2.2
-\lyxformat 490
+\lyxformat 491
 \begin_document
 \begin_header
 \origin roundtrip
...

What has to be done for update would be
# copy  /usr/BUILD/BuildLyxGitQt5/src/tex2lyx/test/test.lyx 
/usr/src/lyx/lyx-git/src/tex2lyx/test/test.lyx.lyx
but one has really check each file and has to know what he/she is doing.

I really, really dislike to make it automatic.

> Georg

Kornel

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

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Kornel Benko]

Am Freitag, 15. Mai 2015 um 21:45:51, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Am Donnerstag, 14. Mai 2015 um 21:05:23, schrieb Georg Baum
> > 
> >> Kornel Benko wrote:
> >> 
> >> > This does not cover all tex2lyx tests used under cmake.
> >> 
> >> IMHO calling these tests tex2lyx tests is confusing. They test nothing in
> >> tex2lyx which the standard tex2lyx tests do not test, but they do test
> >> lyx2lyx in addition.
> >> 
> >> 
> >> Georg
> > 
> > I am open to any naming.
> 
> Maybe "combined lyx2lyx and tex2lyx tests"?
> 

In cmake we also distinguish between the two.
The command
# ctest -R test.ltx
displays all test names containing the string test.ltx, in this case the output 
is:
  Test #6: tex2lyx/roundtrip/test.ltx
  Test #7: tex2lyx/cmplyx/test.ltx

It is the second test, which uses 'lyx -E' (not lyx2lyx directly) to compare
the output of tex2lyx and provided test.lyx.lyx.

The first one (roundtrip) does exactly the same as in automake case.

> Georg

Kornel

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

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:58:24PM +0200, Stephan Witt wrote:

> Am 15.05.2015 um 16:48 schrieb Enrico Forestieri :
> 
> > On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
> >> 
> >> This results in the following patch - if you had something like that in
> >> mind I'll split it in two patches. The other getPixmap method with
> >> QPixmap result was already there.
> > 
> > Yes, I think that it is better passing big objects by reference rather
> > than by value.
> 
> But this is not a good property of C++ compilers than.
> 1. It's not a constant fact if an object is big.
> 2. The compiler should generate fast code for this scenario too.
> 3. This results in hard to read code eventually.

You are probably right and it seems people prefer the simpler approach by
relying on the return value optimization performed by modern compilers.
http://stackoverflow.com/questions/753312/returning-large-objects-in-functions
http://stackoverflow.com/questions/4809120/creating-and-returning-a-big-object-from-a-function
http://stackoverflow.com/questions/24685054/how-do-c-functions-return-a-big-object-or-a-structure

What triggered my comment was seeing that call in a loop, so you could simply
limit the change to that one function and leave the rest as is. Or you could
also disregard that comment ;-)

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 03:45:28PM +0200, Stephan Witt wrote:

> Am 15.05.2015 um 15:14 schrieb Enrico Forestieri :
> 
> > On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
> >> On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
> >>> 
> >>> Thank you. The current splash has a size of 400x250. I'll attach the
> >>> 1600x1000 splash banner to test.
> >>> It would be great if this is ok too. If not I have to get it right myself.
> >> 
> >> Why is this (compressed) svg image so big? Are you sure there is no
> >> embedded bitmap? That would defeat the purpose of using the svg format.
> > 
> > Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
> > That's bad.
> 
> Yes, Jürgen said it would be great to find someone who is able to do it 
> better.
> This one was made to have some SVG banner.

Sorry, I did not realize it was that same banner. But why did you attach it, 
then?

-- 
Enrico

Re: about our lyx2lyx reversion policy

[Uwe Stöhr]

Am 14.05.2015 um 14:34 schrieb Jürgen Spitzmüller:


I disagree with this proposal and opt for going with our current policy.


But why? What are your arguments? What are your experiences with 
collaborations?


regards Uwe

Re: [LyX/master] tex2lyx testfiles: update to latest fileformat

[Uwe Stöhr]

Am 15.05.2015 um 21:41 schrieb Georg Baum:


1) It is impossible to manually verify in this huge diff whether the new
references are really correct.


I wondered about that too.

Thanks for taking care and adding the note. However, the huge diff shows 
that tex2lyx is not yet producing the same as LyX. Can#t we do anything 
or shouldn't we do anything here?



I added a corresponding note to lib/doc/Development.lyx.


Thanks

regards Uwe

Re: [patch] support for \fcolorbox and \colorbox

[Uwe Stöhr]

Am 15.05.2015 um 18:34 schrieb Jean-Marc Lasgouttes:


Actually I see now that "static" is still used more often than anonymous
namespaces in current code. So you can probably leave it as it is.


OK.
I have put the patch in with static.

regards Uwe

Re: [LyX/master] support for all default colors of the package xcolor

[Uwe Stöhr]

Am 15.05.2015 um 05:14 schrieb Scott Kostyshak:


Is there a reason why "White" is the only one that is not
alphabetized? Note that it was like this before your patch but this
just seems a convenient place to bring this up.


You are right, there is no reason to treat white differently. I am aware 
that the sorting will be lost with different locales but therefore we 
have not the color icons in the combo box.


regards Uwe

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Fri, May 15, 2015 at 09:06:34PM +0200, Georg Baum wrote:
> 
> Can you try again pelase? c_str() was not instantiated explicitly (because 
> on linux it is automatically instantiated).

Yes, it now compiles on both solaris and cygwin. However, on solaris,
a spurious warning is printed after each tested layout. The output
looks like this:

Testing ../../src/../lib/layouts/AEA.layout...
../../src/tests/test_layout: !: not found
Testing ../../src/../lib/layouts/IEEEtran-CompSoc.layout...
../../src/tests/test_layout: !: not found

I have not investigated, but I think this is due to some script assuming
that /bin/sh is really /bin/bash, and this is not true on solaris.
Incidentally, for this same reason I cannot simply run ./autogen.sh
but have to run "bash autogen.sh". This is really minor, though, as


Testing ../../src/../lib/layouts/tufte-handout.layout...
../../src/tests/test_layout: !: not found

layout tests passed.


-- 
Enrico

Re: 2.2

[Stephan Witt]

Am 16.05.2015 um 00:48 schrieb Enrico Forestieri :

> On Fri, May 15, 2015 at 03:45:28PM +0200, Stephan Witt wrote:
> 
>> Am 15.05.2015 um 15:14 schrieb Enrico Forestieri :
>> 
>>> On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
 On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
> 
> Thank you. The current splash has a size of 400x250. I'll attach the
> 1600x1000 splash banner to test.
> It would be great if this is ok too. If not I have to get it right myself.
 
 Why is this (compressed) svg image so big? Are you sure there is no
 embedded bitmap? That would defeat the purpose of using the svg format.
>>> 
>>> Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
>>> That's bad.
>> 
>> Yes, Jürgen said it would be great to find someone who is able to do it 
>> better.
>> This one was made to have some SVG banner.
> 
> Sorry, I did not realize it was that same banner. But why did you attach it, 
> then?

The SVG banner with design size 400x250 results in an pixmap of the same size.
This is not enough for HiDPI. So, I've made a "bigger" one to get a crisp 
banner.

Stephan