Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Dienstag, den 25.10.2016, 08:55 +1300 schrieb Andrew Parsloe:
> My concern was for the list of modules to be scannable "at a
> glance". 
> Particularly with the theorems modules there is a clump of them,
> some 
> with long names where the distinguishable part of the name is not 
> initially visible. Your second attempt Daniel was along the lines I
> had 
> in mind, but Jürgen's suggestion of wrappable lines in the Available 
> window is another possibility.

You rightly pointed out in your first post that "the modules dialogue
[...] looks as if it has outgrown its current arrangement". I think
this is not only due to overly long names, but also due to the
heterogeneity of contents.

I think the right approach to fix this is to use categories, like we
have in layouts (the interface is already implemented also for
modules). This would make it easier to find the module you are looking
for (without knowing the exact name, which is sometimes quite
arbitrary: did you know that there is a further theorem module sorted
under "N"?). This would probably also save horizontal space.

So instead of:

...
Named Theorems
...
Theorems
Theorems (AMS)
Theorems (AMS, Numbered by Type)
Theorems (AMS-Extended)
Theorems (AMS-Extended, Numbered by Type)
Theorems (Numbered by Chapter)
Theorems (Numbered by Type)
Theorems (Numbered by Type within Chapters)
Theorems (Numbered by Section)
Theorems (Unnumbered)
...

We would display:

...
Theorems
|- AMS
|- AMS, num. by Type
|- AMS, extended
|- AMS, extended, num. by Type
|- Standard
|- Named
|- Num. by Chapter
|- Num. by Type
|- Num. by Type within Chapters
|- Num. by Section
|- Unnumbered
...

A filter bar to filter for categories and names (plus probably
descriptions and/or keywords) would further increase usability.

Jürgen



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


Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 21:51 +0200 schrieb racoon:
Ah, I have not made the settings dialog wide enough. Well anyway, the 

right part does not become wider up to a certain point (see attached 

screenshot). I would call that wasted space. So maybe the list of 

settings should be set to a lower maximal width.

Which becomes difficult if you consider localizations (the strings in
this list are much longer, for instance, in the German localization)

Jürgen

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


License to Publish Work

2016-10-24 Thread Joel Kulesza
LyX Developers:

I hereby grant the right to publish my work for LyX under the license GPL
version 2 or later.

Please contact me with any comments, questions, or concerns.

Thank you,
Joel


[PATCH] Add "Swap & Reverse" to math delimiter dialog

2016-10-24 Thread Joel Kulesza
LyX Developers:

Per Uwe's guidance, please find attached a proposed patch to address
enhancement request Ticket #10457.

Notes:

   - The attached patch was made on the master branch (per
   http://www.lyx.org/HowToUseGIT) and should lie neatly atop recent commit
   a9aaec5.  While this was made on master, I'm of course interested to see it
   get included in the soonest possible/reasonable release.  I leave it to the
   benevolent developer who commits on my behalf to determine when that is.
   - I've added a new button to the Math Delimiter GUI.  I'm not sure how
   to properly connect this to GUI translations.  Your help with this would be
   appreciated.
   - The button is titled "Swap & Reverse".  This is as intuitive as I
   could come up with, but suggestions for different names are welcome.
   - I've tested this by "clicking through" various permutations,
   enabling/disabling matching, etc. but created no additional tests.  I
   encourage you to click through and experiment to see if it breaks.  In
   particular, please exercise "(None)" with itself and other delimiters.
   This is a somewhat special case relative to how the other list item entries
   are handled and is probably the most fragile.
   - Along those lines: I tried to minimize creating new code /
   functionality, so I tried to use as much as is there already in LyX & Qt.
   Please see if you agree with my processing steps.
   - Note that arrows are matched with "like directions," e.g., \uparrow
   and \uparrow.  It is possible there would be confusion because the
   "reverse" of up should be \downarrow.  Thoughts on how to handle this?  Or,
   don't worry about it?

Please contact me with any comments, questions, or concerns.

Thank you,
Joel


0001-Add-Swap-Reverse-to-math-delimiter-dialog.patch
Description: Binary data


Re: Ticket 10457 Code Review Request

2016-10-24 Thread Uwe Stöhr

Am 24.10.2016 um 08:46 schrieb Joel Kulesza:


I've implemented the change (selfishly) requested in
https://www.lyx.org/trac/ticket/10457.


Hello Joel,

many thanks! Everyone and every work welcome.


What is the best way to get the change reviewed / committed / merged?


You should attach your patch as unified diff file to the bug report. 
Additionally send a mail to this list with some explanations and the 
patch attached as unified diff.


If the developers say it is OK, someone will commit it to LyX. You are 
then one of the LyX authors and therefore we need your agreement to 
publish your work under the license GPL version 2 or later. Could you 
therefore please send an additional mail to this list where you write?:


"I hereby grant to publish my work for LyX under the license GPL version 
2 or later."


many thanks and best regards
Uwe


Re: please revert: [LyX/2.2.x] Better title for ViewSource

2016-10-24 Thread Uwe Stöhr

Am 24.10.2016 um 00:38 schrieb Guillaume Munch:


You are not being rude at all, in fact you are quite polite.


OK. I felt I was rude. I thought about it and began to update the docs 
when I realized what an impact these renaming have. Then I searched the 
Wiki and googled around. The source code window is referenced all over 
the place a lot. So changing this produces a lot of work for me, breaks 
the idea that the docs for LyX 2.2.x are valid for all 2.2 releases 
(except bugfixes of course) and finally I didn't see a benefit for the 
renaming at all.


So if you think the changed name is an improvement and the others agree, 
I am fine with this change in master but not for branch.



First, surely you do not mean to revert the entire commit. The main
purpose of the patch is to change the title of GuiViewSource to "LaTeX
(pdflatex) preview", "LyXHTML preview", etc. The default title "Code
Preview" does not appear in practice. I think you are mainly referring
to the change in the menu name.


Exactly. The window title is not the problem, but the menu name should stay.


I think that the best solution instead is to have
"Code Preview Pane|S" as a reminiscence of the former name


I opt to change the accelerator of the name is changed. Otherwise 2 
years later it will be confusing.



I can revert the menu name to "Source Pane" in 2.2.x for the
documentation reasons you gave.


Please do so.


I can also revert it in master if
the majority wants it. But I hope that my explanation reassured
you.


If your experience is that the new name helps users, it is OK, I mean 
many things I do here are also driven from user feedback and are perhaps 
sometimes hard to understand by developers. For me user feedback is very 
important. So +1 from me. I don't know if there was already a vote. if 
not, I suggest to do one because this menu is used quite often and 
better to decide now than later in the RC cycle.


regards Uwe


Re: procmail (was: [PATCH] Re: Return + Return in nested environments)

2016-10-24 Thread Enrico Forestieri
On Mon, Oct 24, 2016 at 11:42:16AM -0700, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Sat, Oct 22, 2016 at 09:55:02PM -0700, Pavel Sanda wrote:
> > 
> > > Enrico Forestieri wrote:
> > > > Yes, of course, because procmail inserted a ">" just in front of the
> > > > "From " line in the attachment (which I do manually).
> > > > 
> > > > Care to share the corresponding config line(s) for procmail?
> > > 
> > > Hmm, nothing special:
> > > 
> > > :0
> > > *List-Post: 
> > > .lyx.devel
> > 
> > Ok, thanks anyway.
> 
> Does it mean that this line does not work for you? P

Actually, there is no need for any configuration. Procmail does it
automatically. Now I have configured mutt such that 'G' calls fetchmail,
which, in turn, calls procmail for local delivery.
A bit convoluted, but it works.

I have also checked that mutt adds a '>' in front of a "From " occurring
at the beginning of a line in a text attachment when choosing "7bit" as
transfer encoding (unlike some antique MUAs used by some people here ;-)

-- 
Enrico


Re: Modules dialogue

2016-10-24 Thread Andrew Parsloe

On 25/10/2016 5:53 a.m., Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 13:15 +0200 schrieb racoon:

Sorry, probably the attached is better.


I would prefer a layout where we can maintain the horizontal order
(which we use in all other similar dialogs). Maybe we can wrap the
descriptions to multiple lines.

Jürgen



Daniel


My concern was for the list of modules to be scannable "at a glance". 
Particularly with the theorems modules there is a clump of them, some 
with long names where the distinguishable part of the name is not 
initially visible. Your second attempt Daniel was along the lines I had 
in mind, but Jürgen's suggestion of wrappable lines in the Available 
window is another possibility.


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 20:33, Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 20:21 +0200 schrieb racoon:

Another idea would be to make not the list of document settings
expand
when one expands the settings dialog. All the settings names already
fit
well into the list. So it would make more sense to expand the
individual
settings area of the dialog.


This I don't understand. What do you mean by "expand"?


Ah, I have not made the settings dialog wide enough. Well anyway, the 
right part does not become wider up to a certain point (see attached 
screenshot). I would call that wasted space. So maybe the list of 
settings should be set to a lower maximal width.


Daniel


Re: procmail (was: [PATCH] Re: Return + Return in nested environments)

2016-10-24 Thread Pavel Sanda
Enrico Forestieri wrote:
> On Sat, Oct 22, 2016 at 09:55:02PM -0700, Pavel Sanda wrote:
> 
> > Enrico Forestieri wrote:
> > > Yes, of course, because procmail inserted a ">" just in front of the
> > > "From " line in the attachment (which I do manually).
> > > 
> > > Care to share the corresponding config line(s) for procmail?
> > 
> > Hmm, nothing special:
> > 
> > :0
> > *List-Post: 
> > .lyx.devel
> 
> Ok, thanks anyway.

Does it mean that this line does not work for you? P


Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 20:21 +0200 schrieb racoon:
> Another idea would be to make not the list of document settings
> expand 
> when one expands the settings dialog. All the settings names already
> fit 
> well into the list. So it would make more sense to expand the
> individual 
> settings area of the dialog.

This I don't understand. What do you mean by "expand"?

Jürgen

> 
> Daniel

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


Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 20:08, Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 19:36 +0200 schrieb racoon:

Can you give an example?


Citation dialog.


Oh, I see. Haven't thought about non-settings/preferences dialogs. But 
since those are in quite different areas of LyX I would not mind to have 
it differently. But I see your point.


Another idea would be to make not the list of document settings expand 
when one expands the settings dialog. All the settings names already fit 
well into the list. So it would make more sense to expand the individual 
settings area of the dialog.


Daniel


Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 19:36 +0200 schrieb racoon:
> Can you give an example?

Citation dialog.

Jürgen


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


Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 18:53, Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 13:15 +0200 schrieb racoon:

Sorry, probably the attached is better.


I would prefer a layout where we can maintain the horizontal order
(which we use in all other similar dialogs). Maybe we can wrap the
descriptions to multiple lines.


I had no such expectancy of a horizontal order and I am also not exactly 
sure what you mean. Can you give an example?


Daniel



Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 13:15 +0200 schrieb racoon:
> Sorry, probably the attached is better.

I would prefer a layout where we can maintain the horizontal order
(which we use in all other similar dialogs). Maybe we can wrap the
descriptions to multiple lines.

Jürgen

> 
> Daniel
> 

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


Re: Supposed to be bolded page number not bolded in index

2016-10-24 Thread Jean-Marc Lasgouttes

Le 23/10/2016 à 11:34, Jürgen Spitzmüller a écrit :

In the long term, I think the ideal solution would be that all of these
special characters are escaped by default (so @, | and ! really output
these glyphs), and that the functions they provide in indexes (sort
key, indexical hierarchy, page number formatting) are natively
implemented via sub-insets. But this requires major UI work and lyx2lyx
 conversion/reversion.

So, for the time being, I would apply the patch.


That makes sense to me.

JMarc


Re: Master is slow

2016-10-24 Thread Jean-Marc Lasgouttes

Le 22/10/2016 à 19:39, Guillaume Munch a écrit :

After improvements by Richard and Jean-Marc, GuiView::getStatus is down
to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating.


Thanks for checking.


New bottlenecks are Buffer::updateMacros (25%, of course depends on
the document) and nothing else looks really out of place. You can
celebrate.


Yes, this one is a sore point, especially for people who do not use macros.

JMarc



Re: LyXRC - %%s/scripts

2016-10-24 Thread Jean-Marc Lasgouttes

Le 24/10/2016 à 16:29, Tommaso Cucinotta a écrit :

On 24/10/2016 15:31, Scott Kostyshak wrote:



Do not hesitate to commit to master once you have tested it. This is our
playground, after all. Only stable is subject to authorization from
Richard.

+1. If it worked for you and the change makes logical sense, I would say
go ahead for master.


done, pushed after ~2 yrs silence :-)...


Welcome back, then !

JMarc



Re: LyXRC - %%s/scripts

2016-10-24 Thread Tommaso Cucinotta

On 24/10/2016 15:31, Scott Kostyshak wrote:



Do not hesitate to commit to master once you have tested it. This is our
playground, after all. Only stable is subject to authorization from Richard.

+1. If it worked for you and the change makes logical sense, I would say
go ahead for master.


done, pushed after ~2 yrs silence :-)...

T.



Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 13:15, racoon wrote:

On 24.10.2016 12:53, racoon wrote:

On 23.10.2016 10:15, Andrew Parsloe wrote:

Few documents have more than a module or five attached to them. Most of
the Selected window is wasted space. I wonder if the two Defaults
buttons in the penultimate row couldn't be shrunk to fit into the gap in
the bottom row. The Selected window could then be moved below the
description window (and expanded horizontally), the Add/Delete buttons
moved to the right in the space now available, and the Up/Down buttons
brought down beside and to the right of the newly sited Selected window.
The space freed by moving the buttons could now be used to expand the
Available window horizontally. That would allow the names of modules
with long ones, like "Theorems (AMS-Extended, Numbered by Type)" to be
read at a glance.

(In fact I want "Theorems (AMS-Extended, Numbered by Type within
Chapters)", an even longer title, but LyX doesn't provide this out of
the box, although it is easy to create using those provided as models.)


I have not yet rearranged the Defaults buttons but moved the other stuff
according to your suggestions (screenshot and patch attached). I hope I
understood it correctly.


Sorry, probably the attached is better.


And maybe the "Add" button should go on the lower end of Available list 
to give a hint that it adds somewhere below.


Daniel




Re: Possible Qt5 bugs (bug 10436)

2016-10-24 Thread Jean-Marc Lasgouttes

Le 24/10/2016 à 02:25, Scott Kostyshak a écrit :

I have had unfortunately avoided making Qt bug reports for the same
reason. Perhaps ask on Qt's dev mailing list?


There was a time were André would magically pop up in moments like this 
and just report problems... Sigh. André, we miss you !



It works well for me in very limited testing.


Thanks, I'll apply to master.


+   lyxerr << "WIDTH[" << s << "]=" << w <

Re: LyXRC - %%s/scripts

2016-10-24 Thread Scott Kostyshak
On Mon, Oct 24, 2016 at 09:42:10AM +0200, Jean-Marc Lasgouttes wrote:
> Le 24/10/2016 à 08:27, Tommaso Cucinotta a écrit :

> > shall I commit to regular master, or would you like to give it a try first?
> 
> Do not hesitate to commit to master once you have tested it. This is our
> playground, after all. Only stable is subject to authorization from Richard.

+1. If it worked for you and the change makes logical sense, I would say
go ahead for master.

Scott


signature.asc
Description: PGP signature


Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 12:53, racoon wrote:

On 23.10.2016 10:15, Andrew Parsloe wrote:

Few documents have more than a module or five attached to them. Most of
the Selected window is wasted space. I wonder if the two Defaults
buttons in the penultimate row couldn't be shrunk to fit into the gap in
the bottom row. The Selected window could then be moved below the
description window (and expanded horizontally), the Add/Delete buttons
moved to the right in the space now available, and the Up/Down buttons
brought down beside and to the right of the newly sited Selected window.
The space freed by moving the buttons could now be used to expand the
Available window horizontally. That would allow the names of modules
with long ones, like "Theorems (AMS-Extended, Numbered by Type)" to be
read at a glance.

(In fact I want "Theorems (AMS-Extended, Numbered by Type within
Chapters)", an even longer title, but LyX doesn't provide this out of
the box, although it is easy to create using those provided as models.)


I have not yet rearranged the Defaults buttons but moved the other stuff
according to your suggestions (screenshot and patch attached). I hope I
understood it correctly.


Sorry, probably the attached is better.

Daniel

From e0053fad3613349102f48dfdba842e33bfc635ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Ram=C3=83=3F=3F=3F=3F=3F=3F=C3=83=3F=3F=3F=3F=3F?=
 =?UTF-8?q?=C3=83=3F=3F=3F=3F=C3=83=3F=3F=3F=C3=83=3F=3F=C3=83=3F=C3=82?=
 =?UTF-8?q?=C2=B6ller?= 
Date: Mon, 17 Oct 2016 01:21:01 +0200
Subject: [PATCH] Rearrangement of ModulesUi to fit long names.

---
 src/frontends/qt4/ui/ModulesUi.ui | 242 +-
 1 file changed, 161 insertions(+), 81 deletions(-)

diff --git a/src/frontends/qt4/ui/ModulesUi.ui 
b/src/frontends/qt4/ui/ModulesUi.ui
index 472a0a2..95f7ef3 100644
--- a/src/frontends/qt4/ui/ModulesUi.ui
+++ b/src/frontends/qt4/ui/ModulesUi.ui
@@ -1,72 +1,84 @@
-
+
+
  ModulesUi
- 
-  
+ 
+  

 0
 0
 407
-340
+332

   
-  
+  

   
-  
-   
+  
+   
 9

-   
+   
+9
+   
+   
+9
+   
+   
+9
+   
+   
 6

-   
-
- 
-  
-   0
-   0
-  
+   
+
+ 
+  6
  
- 
-  
-   16777215
-   120
-  
+ 
+  0
  
-
-   
-   
-
- 
-  6
+ 
+  0
+ 
+ 
+  0
  
- 
+ 
   0
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   QFrame::NoFrame
  
- 
+ 
   Available:
  
- 
+ 
   availableLV
  
 


-
- 
+
+ 
   false
  
 
@@ -74,63 +86,51 @@
   
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


 
- 
+ 
   Qt::Horizontal
  
- 
+ 
+  QSizePolicy::Minimum
+ 
+ 
   
51
20
   
  
- 
-  QSizePolicy::Minimum
- 
 


-
- 
+
+ 
   Add
  
 


-
- 
-  Delete
- 
-
-   
-   
-
- 
-  Up
- 
-
-   
-   
-
- 
-  Down
- 
-
-   
-   
 
- 
+ 
   Qt::Vertical
  
- 
+ 
   
60
16
@@ -140,33 +140,116 @@

   
  
+
+   
+   
+
+ 
+  
+   0
+   0
+  
+ 
+ 
+  
+   16777215
+   120
+  
+ 
+
+   
+   
+
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   Selected:
  
- 
+ 
   selectedLV
  
 


-
- 
+
+ 
   QAbstractItemView::NoEditTriggers
  
 

   
  
+ 
+  
+   
+
+ 
+  Qt::Horizontal
+ 
+ 
+  QSizePolicy::Minimum
+ 
+ 
+  
+   40
+   20
+  
+ 
+
+   
+   
+
+ 
+  Up
+ 
+
+   
+   
+
+ 
+  Down
+ 
+
+   
+   
+
+ 
+ 

Re: Modules dialogue

2016-10-24 Thread racoon

On 23.10.2016 10:15, Andrew Parsloe wrote:

In an earlier email I managed to overlook the Assumption environment,
provided in the Theorems-AMS-Extended module, as Paul indicated. OK,
more of this kind of thing is to be expected as I enter my dotage, but
when I view the modules dialogue it looks as if it has outgrown its
current arrangement. Have a look at the Theorems modules in the
Available window. The window isn't wide enough for many of these
(particularly AMS-Extended) to show the relevant part on the right of
each entry which distinguishes one from another without using the slider.

Few documents have more than a module or five attached to them. Most of
the Selected window is wasted space. I wonder if the two Defaults
buttons in the penultimate row couldn't be shrunk to fit into the gap in
the bottom row. The Selected window could then be moved below the
description window (and expanded horizontally), the Add/Delete buttons
moved to the right in the space now available, and the Up/Down buttons
brought down beside and to the right of the newly sited Selected window.
The space freed by moving the buttons could now be used to expand the
Available window horizontally. That would allow the names of modules
with long ones, like "Theorems (AMS-Extended, Numbered by Type)" to be
read at a glance.

(In fact I want "Theorems (AMS-Extended, Numbered by Type within
Chapters)", an even longer title, but LyX doesn't provide this out of
the box, although it is easy to create using those provided as models.)


I have not yet rearranged the Defaults buttons but moved the other stuff 
according to your suggestions (screenshot and patch attached). I hope I 
understood it correctly.


Daniel

From c0c1861029a942782144dea5fb40958bc67e6c48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Ram=C3=83=3F=3F=3F=3F=C3=83=3F=3F=3F=C3=83=3F=3F?=
 =?UTF-8?q?=C3=83=3F=C3=82=C2=B6ller?= 
Date: Mon, 17 Oct 2016 01:21:01 +0200
Subject: [PATCH] Rearrangement of ModulesUi to fit long names.

---
 src/frontends/qt4/ui/ModulesUi.ui | 231 +-
 1 file changed, 156 insertions(+), 75 deletions(-)

diff --git a/src/frontends/qt4/ui/ModulesUi.ui 
b/src/frontends/qt4/ui/ModulesUi.ui
index 472a0a2..3c2c8dc 100644
--- a/src/frontends/qt4/ui/ModulesUi.ui
+++ b/src/frontends/qt4/ui/ModulesUi.ui
@@ -1,72 +1,84 @@
-
+
+
  ModulesUi
- 
-  
+ 
+  

 0
 0
 407
-340
+332

   
-  
+  

   
-  
-   
+  
+   
 9

-   
+   
+9
+   
+   
+9
+   
+   
+9
+   
+   
 6

-   
-
- 
-  
-   0
-   0
-  
+   
+
+ 
+  6
  
- 
-  
-   16777215
-   120
-  
+ 
+  0
  
-
-   
-   
-
- 
-  6
+ 
+  0
  
- 
+ 
+  0
+ 
+ 
   0
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   QFrame::NoFrame
  
- 
+ 
   Available:
  
- 
+ 
   availableLV
  
 


-
- 
+
+ 
   false
  
 
@@ -74,63 +86,58 @@
   
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


 
- 
+ 
   Qt::Horizontal
  
- 
+ 
+  QSizePolicy::Minimum
+ 
+ 
   
51
20
   
  
- 
-  QSizePolicy::Minimum
- 
 


-
- 
+
+ 
   Add
  
 


-
- 
+
+ 
   Delete
  
 


-
- 
-  Up
- 
-
-   
-   
-
- 
-  Down
- 
-
-   
-   
 
- 
+ 
   Qt::Vertical
  
- 
+ 
   
60
16
@@ -140,33 +147,109 @@

   
  
+
+   
+   
+
+ 
+  
+   0
+   0
+  
+ 
+ 
+  
+   16777215
+   120
+  
+ 
+
+   
+   
+
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   Selected:
  
- 
+ 
   selectedLV
  
 


-
- 
+
+ 
   QAbstractItemView::NoEditTriggers
  
 
  

Re: LinuxDay @ Pisa - Oct 22nd

2016-10-24 Thread Kornel Benko
Am Sonntag, 23. Oktober 2016 um 17:24:08, schrieb Tommaso Cucinotta 

> commit e85b0d01
> Author: Tommaso Cucinotta 
> Date:   Wed Oct 16 22:55:40 2013 +0100
> 
>  LyX XMPP Chat
> 
>  This patch enables XMPP-based chatting within LyX.
> 

This is from branch "features/chat3"
I was/am trying to adapt cmake, but I have difficulties to compile 
src/support/FileMonitor.cpp with the gcc6.2 compiler.
There are many warnings because of std::auto_ptr declared in our boost source
boost/boost/smart_ptr/shared_ptr.hpp:459:22: warning: ‘template 
class std::auto_ptr’ is deprecated
shared_ptr( std::auto_ptr && r ): px(r.get()), pn()
and also in gcc6.2 include
.../gcc6.2/include/c++/6.2.0/bits/unique_ptr.h:49
template class auto_ptr;

The real trouble starts with
src/support/strfwd.h:55:9: error: reference to ‘basic_string’ is 
ambiguous
typedef basic_string 
string;
src/support/strfwd.h:54:64: note: candidates are: template class std::basic_string
template class 
basic_string;

Kornel

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


Re: LyXRC - %%s/scripts

2016-10-24 Thread Jean-Marc Lasgouttes

Le 24/10/2016 à 08:27, Tommaso Cucinotta a écrit :

On 24/10/2016 03:32, Scott Kostyshak wrote:

On Sun, Oct 23, 2016 at 09:47:10PM +0200, Tommaso Cucinotta wrote:


For me, this [1] fixes the issue: commit d5495caa in tommaso/master

Thanks for coming up with a fix


shall I commit to regular master, or would you like to give it a try first?


Do not hesitate to commit to master once you have tested it. This is our 
playground, after all. Only stable is subject to authorization from Richard.


JMarc



Re: [LyX/master] Fix Ticket #9741 misleading name for font-encoding setting "default".

2016-10-24 Thread Guenter Milde
On 2016-10-23, Jürgen Spitzmüller wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> Am Sonntag, den 23.10.2016, 08:45 +0200 schrieb Jürgen Spitzmüller:
>> In the meantime, could you please revert your original change? I
>> think
>> it is clear that we will change the strings, but differently.

> Since you didn't do it, I did.

Thank you.

Günter



Re: [LyX/master] unicodesymbols fixes.

2016-10-24 Thread Guenter Milde
Dear Guillaume, dear developers,

On 2016-10-23, Guillaume Munch wrote:
> Le 23/10/2016 à 13:18, Guillaume Munch a écrit :

>> 1942c1942
...
resulted in a change in Math.lyx
...
>> < \textrm{created with \textbf{\textbackslash frac}} &  &
>> \textrm{created with \textbf{\textbackslash cfrac}}\\
>> ---
>>> \textrm{created with \textbf{⧵frac}} &  & \textrm{created with
>> \textbf{⧵cfrac}}\\
...
making it uncompilable.

> As I understand, Günter fixed this at 6ff89c4b9 (I missed it before,
> sorry). I am still curious for the questions below, if anybody knows.

In this case, it was an incomplete change to lib/unicodesymbols (more
details below).  

The intermediate state was not "requiring a fileformat change" but
"buggy".

>> Also, and more importantly, this shows that some changes to
>> lib/[unicode]symbols are in fact file format changes. Is it expected in
>> this case? Is it easy to see which kind of changes to these files are
>> file-format-changing and which ones are not?

>From development.lyx:

  Rule of thumb: 

Whenever there is the danger that a previous version of LyX cannot
open a file using the new feature, a file format update is needed.

  The file format change allows lyx2lyx rules to implement backwards
  compatibility.
  
-> A changed (improved or even buggy) lib/unicodesymbols does not
require a file format change:
  
* lib/unicodesymbols is used on latex export and for relyxing,
  changes will not prevent opening of LyX files.
  
* There is no safe way to backport improvements/changes via lyx2lyx.
  (Converting a literal Unicode character to the correct LICR replacement
  is ugly and has side effects (e.g. prevents the correct XHTML export.)
  
Improvements (additions, simple corrections) just let a literal Unicode
character work that previously did not work properly with 8-bit LaTeX.

For a new lyx version, this is normal and expected: not all improvements
can be backported.

I don't know whether this would be safe for stable, as some documents
that do work with the new revision fail with the old revision.

Günter







Ticket 10457 Code Review Request

2016-10-24 Thread Joel Kulesza
LyX Developers:

I've implemented the change (selfishly) requested in
https://www.lyx.org/trac/ticket/10457.

What is the best way to get the change reviewed / committed / merged?

Thanks,
Joel


Re: LyXRC - %%s/scripts

2016-10-24 Thread Tommaso Cucinotta

On 24/10/2016 03:32, Scott Kostyshak wrote:

On Sun, Oct 23, 2016 at 09:47:10PM +0200, Tommaso Cucinotta wrote:


For me, this [1] fixes the issue: commit d5495caa in tommaso/master

Thanks for coming up with a fix


shall I commit to regular master, or would you like to give it a try first?

thx,

T.