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

[Uwe Stöhr]

Am 25.10.2016 um 22:39 schrieb Guillaume Munch:


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


Please do so.


Done.


Many thanks.

regards Uwe

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

[Uwe Stöhr]

Am 25.10.2016 um 09:19 schrieb Jean-Pierre Chrétien:


I can do it when the time comes if you like, if I have the ftp access to
the site.


Many thanks Jean-Pierre.

as I pointed out and as we also agreed is to do these kind of changes 
only for major LyX releases. To if you would do this for LyX 2.3 this 
would be great.


regards Uwe

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

[Guillaume Munch]

Le 24/10/2016 à 23:55, Uwe Stöhr a écrit :

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.


Sorry for all the work. It helps to see it as lifting a lot of small
confusions all over the place. I can also help with the change (maybe it
won't be needed if Jean-Pierre's magical solution works).



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.


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


Please do so.


Done.




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.


Of course what I can only say is that the old name did not help.


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.


Yes, if there are dissenting opinions, now is the time. And then if
rationally it cannot be decided, then it might be needed to resort to a
vote.

Guillaume

Fwd: Re: request to test Urdu support for LyX

[Uwe Stöhr]

Von: Jamil Haider
An: Uwe Stöhr

Hi

Thank you for reaching out to me. I have tested LyX version 2.2.2 on
windows 10. (Previously I was on Ubuntu). Joining behavior is working as
expected. Right To Left is also working fine. Font is also being applied
properly in edit mode as well as in output PDF.

Here is the comparison:


   Editor WindowPDF
Output

[image: Inline image 3][image: Inline image 2]




Regards
Jamil

new warnings in master

[Uwe Stöhr]

Hi JMarc,

these warnings have been introduced today:

  RowPainter.cpp
D:\LyXGit\Master\src\RowPainter.cpp(621): warning C4244: 'initializing': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src\RowPainter.cpp(632): warning C4244: 'argument': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src\RowPainter.cpp(636): warning C4244: 'initializing': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src\RowPainter.cpp(637): warning C4244: 'initializing': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src\RowPainter.cpp(643): warning C4244: '+=': 
conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]


Could you please have a look?

thanks and regards
Uwe

Re: request to test Urdu support for LyX

[Uwe Stöhr]

Am 25.10.2016 um 11:59 schrieb Jamil Haider:


Thank you for reaching out to me. I have tested LyX version 2.2.2 on
windows 10. (Previously I was on Ubuntu). Joining behavior is working as
expected. Right To Left is also working fine. Font is also being applied
properly in edit mode as well as in output PDF.


Hello Jamil,

many thanks for testing. Good news that it now works for you. I will now 
put in the patch so that the next major LyX release will support Urdu.


There are more good news for you: We found a fix for the nasty Arabic 
script display bug

http://www.lyx.org/trac/ticket/10436
that affects also Urdu.
so the next minor LyX release 2.2.3 in a few weeks will be usable again 
for right-to-left languages.


If you encounter other bugs than
http://www.lyx.org/trac/ticket/10436
please report them, no matter if they are related to Urdu.

Another request: could you please create documents where you mix Urdu 
with English text while the LyX document language is Urdu. Is the PDF 
output correct?


best regards
Uwe

Re: Inverted colors for cursor

[racoon]

On 21.10.2016 21:29, racoon wrote:

The cursor is actually hard to see when its color matches the color of
its background. Maybe the idea of setting the cursor color fixed should
be abandoned and inverted colors should be used instead. All writer apps
I know of do so (like Libre and MS). Attached is a quick patch that
seems to achieve this.


I have posted a patch for (optional) inverted cursor color:

http://www.lyx.org/trac/ticket/10462

Daniel

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

[Jean-Pierre Chrétien]

Le 24/10/2016 à 22:55, Uwe Stöhr a écrit :

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.


As the wiki uses flat files (as opposite to sql architecture), you might
 * retrieve the wiki pages through ftp
 * make a global substitution
 * upload the updated stuff (only the modified pages)
 I see one drawback: the changes will not appear in the history, but these are 
"Minor changes".


I can do it when the time comes if you like, if I have the ftp access to the 
site.

--
Jean-Pierre

Re: Modules dialogue

[Andrew Parsloe]

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

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



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"?).


No, I didn't. Thanks for pointing this out.

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


I like this proposal.

Andrew

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

Re: #10436: RTL characters protrude over inset box

[Stephan Witt]

Am 25.10.2016 um 00:35 schrieb LyX Ticket Tracker :
> 
> #10436: RTL characters protrude over inset box
> ---+
> Reporter:  uwestoehr  |   Owner:  skostysh
> Type:  defect |  Status:  fixedinmaster
> Priority:  normal |   Milestone:  2.2.3
> Component:  frontend-qt5   | Version:  2.2.0
> Severity:  normal |  Resolution:
> Keywords:  regression, patch  |
> ---+
> 
> Comment (by uwestoehr):
> 
>> what do you want me to do for 2.2.x?
> 
> My opinion is that this should go to 2.2.3 to make LyX usable again for
> Farsi and Arabic. As Stephan tested, the patch did not change the behavior
> on Qt 4 or Qt 5 on Mac. From the Windows side I can confirm that it works
> and I played now a lot with Bidi.

One question not related to drawing issues: I’ve noticed the Arrow-Left
key moves to the left (forward in text). But, Fn-Arrow-Left (Home) moves
to the right. Of course „Home“ is the begin of the line but this is not
obvious to me. I’m not sure if the same happens with an Arabic keyboard.

Question: is there something to do with key mapping and/or binding for RTL?

Stephan

Re: [LyX/master] When selecting special logos, set their color correctly

[Richard Heck]

On 10/25/2016 09:15 AM, Jean-Marc Lasgouttes wrote:
> Le 25/10/2016 à 15:14, Jean-Marc Lasgouttes a écrit :
>> commit 860accd01fb8115ec7c6ad80b054f1046e19c62f
>> Author: Jean-Marc Lasgouttes 
>> Date:   Tue Oct 25 15:13:23 2016 +0200
>>
>> When selecting special logos, set their color correctly
>>
>> It is not nice when they are the only thinkg in the text that
>> does not
>> change color.
>
> Richard, this is candidate to branch.

OK.

rh

Re: #10436: RTL characters protrude over inset box

[Jean-Marc Lasgouttes]

Le 25/10/2016 à 10:37, Stephan Witt a écrit :

One question not related to drawing issues: I’ve noticed the Arrow-Left
key moves to the left (forward in text). But, Fn-Arrow-Left (Home) moves
to the right. Of course „Home“ is the begin of the line but this is not
obvious to me. I’m not sure if the same happens with an Arabic keyboard.

Question: is there something to do with key mapping and/or binding for RTL?


I do not know what we can do. On linux/mac Home is Home, no left/right 
arrow. We do have a mechanism that inverts left and right for RtL 
(visual cursor vs logical cursor move), but we do not take this function 
in account.


Currently, we have the 4 functions LFUN_LINE_(BEGIN|END)(_SELECT|). You 
could introduce the new LFUN_LINE_(LEFT|RIGHT)[_SELECT|) to do what you 
mean here.


JMarc

Re: Modules dialogue

[Paul A. Rubin]

On 10/25/2016 12:14 AM, Jürgen Spitzmüller wrote:

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

I have no objection to categories, but I suspect we will end up either 
with a large number of categories containing one or two modules or a 
single large "miscellaneous" category.


With or without categories, I would definitely vote for the filter bar, 
and I think it should include descriptions. With the filter bar, Andrew 
could type in "Assumption" and find all variations of the theorems 
module containing assumptions.


Paul

Re: [LyX/master] When selecting special logos, set their color correctly

[Jean-Marc Lasgouttes]

Le 25/10/2016 à 15:14, Jean-Marc Lasgouttes a écrit :

commit 860accd01fb8115ec7c6ad80b054f1046e19c62f
Author: Jean-Marc Lasgouttes 
Date:   Tue Oct 25 15:13:23 2016 +0200

When selecting special logos, set their color correctly

It is not nice when they are the only thinkg in the text that does not
change color.


Richard, this is candidate to branch.

JMarc


---
 src/insets/InsetSpecialChar.cpp |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/insets/InsetSpecialChar.cpp b/src/insets/InsetSpecialChar.cpp
index 3d32f40..b6bcb47 100644
--- a/src/insets/InsetSpecialChar.cpp
+++ b/src/insets/InsetSpecialChar.cpp
@@ -139,8 +139,10 @@ namespace {
 // helper function: draw text and update x.
 void drawChar(PainterInfo & pi, int & x, int const y, char_type ch)
 {
-   pi.pain.text(x, y, ch, pi.base.font);
-   x += theFontMetrics(pi.base.font).width(ch);
+   FontInfo font = pi.base.font;
+   font.setPaintColor(pi.textColor(font.realColor()));
+   pi.pain.text(x, y, ch, font);
+   x += theFontMetrics(font).width(ch);
 }

Re: Modules dialogue

[Jürgen Spitzmüller]

2016-10-25 17:13 GMT+02:00 Richard Heck :

> This assumes (!) that the Assumption style is mentioned in the
> description, which it might be. It would be possible, but a whole lot
> more complicated, to filter on the styles, etc, that are declared in the
> module (if any).
>

Or add some sensible key words.

Jürgen


>
> Richard
>
>

Re: Modules dialogue

[Richard Heck]

On 10/25/2016 09:58 AM, Paul A. Rubin wrote:
> On 10/25/2016 12:14 AM, Jürgen Spitzmüller wrote:
>> 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
>>
> I have no objection to categories, but I suspect we will end up either
> with a large number of categories containing one or two modules or a
> single large "miscellaneous" category.
>
> With or without categories, I would definitely vote for the filter
> bar, and I think it should include descriptions. With the filter bar,
> Andrew could type in "Assumption" and find all variations of the
> theorems module containing assumptions.

This assumes (!) that the Assumption style is mentioned in the
description, which it might be. It would be possible, but a whole lot
more complicated, to filter on the styles, etc, that are declared in the
module (if any).

Richard

Re: [LyX/master] Show on screen font changes for text-in-math

[Enrico Forestieri]

On Tue, Oct 25, 2016 at 04:04:01PM +0200, Enrico Forestieri wrote:
> commit 3cf0cbb3c69e73d72b6cee3723de7b67e69c4c0a
> Author: Enrico Forestieri 
> Date:   Tue Oct 25 16:03:34 2016 +0200
> 
> Show on screen font changes for text-in-math

Richard, please find attached the corresponding patch for stable.
This solves the on-screen representation glitch illustrated in
the also attached example.

-- 
Enrico
diff --git a/src/MetricsInfo.cpp b/src/MetricsInfo.cpp
index 2b954d3..71d7a39 100644
--- a/src/MetricsInfo.cpp
+++ b/src/MetricsInfo.cpp
@@ -244,7 +244,8 @@ FontSetChanger::FontSetChanger(MetricsBase & mb, char const 
* name,
ColorCode oldcolor = save_.font.color();
docstring const oldname = from_ascii(save_.fontname);
mb.fontname = name;
-   mb.font = sane_font;
+   if (isMathFont(from_ascii(name)) || isMathFont(oldname))
+   mb.font = sane_font;
augmentFont(mb.font, from_ascii(name));
mb.font.setSize(oldsize);
if (string(name) != "lyxtex"
@@ -264,7 +265,8 @@ FontSetChanger::FontSetChanger(MetricsBase & mb, docstring 
const & name,
ColorCode oldcolor = save_.font.color();
docstring const oldname = from_ascii(save_.fontname);
mb.fontname = to_utf8(name);
-   mb.font = sane_font;
+   if (isMathFont(name) || isMathFont(oldname))
+   mb.font = sane_font;
augmentFont(mb.font, name);
mb.font.setSize(oldsize);
if (name != "lyxtex"
#LyX 1.4.5.1 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes true
\end_header

\begin_body

\begin_layout Standard
In the following equation, the 
\begin_inset Quotes els
\end_inset

a
\begin_inset Quotes ers
\end_inset

 should be bold, italic and green:
\begin_inset Formula \[
{\color{green}b=\textbf{\textit{a}}}\]

\end_inset


\end_layout

\end_body
\end_document

Re: [LyX/master] Show on screen font changes for text-in-math

[Richard Heck]

On 10/25/2016 01:08 PM, Enrico Forestieri wrote:
> On Tue, Oct 25, 2016 at 04:04:01PM +0200, Enrico Forestieri wrote:
>> commit 3cf0cbb3c69e73d72b6cee3723de7b67e69c4c0a
>> Author: Enrico Forestieri 
>> Date:   Tue Oct 25 16:03:34 2016 +0200
>>
>> Show on screen font changes for text-in-math
> Richard, please find attached the corresponding patch for stable.
> This solves the on-screen representation glitch illustrated in
> the also attached example.

OK, and thanks.

Richard