Re: Bringing a hidden window to the front on a mac.

[Scott Kostyshak]

On Sat, May 21, 2016 at 06:07:19PM -0400, Scott Kostyshak wrote:
> On Sat, May 21, 2016 at 11:58:36PM +0200, Stephan Witt wrote:
> > Am 21.05.2016 um 23:50 schrieb Scott Kostyshak :
> > > 
> > > On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote:
> > >> If one has 2 documents open in LyX 2.2 in 2 separate windows and one 
> > >> wants
> > >> to bring the one in the back to the front via the menu View/Hidden/... 
> > >> then
> > >> (on a mac, OSX 10.11.4) nothing happens. Although the window has been
> > >> activated, it's not brought to the front. [When switching to e.g. the 
> > >> Finder
> > >> and then back to LyX by clicking on the LyX icon in the Dock, the hidden
> > >> window will now be shown in front.]
> > >> 
> > >> The problem is solved by adding a raise() call to the activateWindow() 
> > >> call
> > >> in GuiView.cpp (see included patch).
> > >> 
> > >> Regards,
> > >> 
> > >> P. De Visschere
> > > 
> > >> diff --git a/src/frontends/qt4/GuiView.cpp 
> > >> b/src/frontends/qt4/GuiView.cpp
> > >> index c2101f3..89bff9a 100644
> > >> --- a/src/frontends/qt4/GuiView.cpp
> > >> +++ b/src/frontends/qt4/GuiView.cpp
> > >> @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, 
> > >> DispatchResult & dr)
> > >>  for (; i != ids.size(); ++i) {
> > >>  GuiView & gv = guiApp->view(ids[i]);
> > >>  if (gv.workArea(*buffer)) {
> > >> +gv.raise();
> > >>  gv.activateWindow();
> > >>  gv.setBuffer(buffer);
> > >>  break;
> > > 
> > > Since this part of the code is contained in "case LFUN_BUFFER_SWITCH"
> > > and is only reached if there are multiple views, I think it could go
> > > in for 2.2.0.
> > > 
> > > Let's see if anyone else has an opinion, otherwise I will test on Linux
> > > and commit it before rc2.
> > 
> > You may consider to cherry-pick change 
> > 5f368aec7b3206c873c94294def906911523dc8e.
> 
> Aha, I thought I saw that somewhere.
> 
> Go ahead with the cherry-pick. I will still test on Linux.

Tested and pushed at 1719fa6c.

Thanks Stephan and pdv.

Scott


signature.asc
Description: PGP signature

Re: Bringing a hidden window to the front on a mac.

[Scott Kostyshak]

On Sat, May 21, 2016 at 11:58:36PM +0200, Stephan Witt wrote:
> Am 21.05.2016 um 23:50 schrieb Scott Kostyshak :
> > 
> > On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote:
> >> If one has 2 documents open in LyX 2.2 in 2 separate windows and one wants
> >> to bring the one in the back to the front via the menu View/Hidden/... then
> >> (on a mac, OSX 10.11.4) nothing happens. Although the window has been
> >> activated, it's not brought to the front. [When switching to e.g. the 
> >> Finder
> >> and then back to LyX by clicking on the LyX icon in the Dock, the hidden
> >> window will now be shown in front.]
> >> 
> >> The problem is solved by adding a raise() call to the activateWindow() call
> >> in GuiView.cpp (see included patch).
> >> 
> >> Regards,
> >> 
> >> P. De Visschere
> > 
> >> diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
> >> index c2101f3..89bff9a 100644
> >> --- a/src/frontends/qt4/GuiView.cpp
> >> +++ b/src/frontends/qt4/GuiView.cpp
> >> @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, 
> >> DispatchResult & dr)
> >>for (; i != ids.size(); ++i) {
> >>GuiView & gv = guiApp->view(ids[i]);
> >>if (gv.workArea(*buffer)) {
> >> +  gv.raise();
> >>gv.activateWindow();
> >>gv.setBuffer(buffer);
> >>break;
> > 
> > Since this part of the code is contained in "case LFUN_BUFFER_SWITCH"
> > and is only reached if there are multiple views, I think it could go
> > in for 2.2.0.
> > 
> > Let's see if anyone else has an opinion, otherwise I will test on Linux
> > and commit it before rc2.
> 
> You may consider to cherry-pick change 
> 5f368aec7b3206c873c94294def906911523dc8e.

Aha, I thought I saw that somewhere.

Go ahead with the cherry-pick. I will still test on Linux.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: Bringing a hidden window to the front on a mac.

[Stephan Witt]

Am 21.05.2016 um 23:50 schrieb Scott Kostyshak :
> 
> On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote:
>> If one has 2 documents open in LyX 2.2 in 2 separate windows and one wants
>> to bring the one in the back to the front via the menu View/Hidden/... then
>> (on a mac, OSX 10.11.4) nothing happens. Although the window has been
>> activated, it's not brought to the front. [When switching to e.g. the Finder
>> and then back to LyX by clicking on the LyX icon in the Dock, the hidden
>> window will now be shown in front.]
>> 
>> The problem is solved by adding a raise() call to the activateWindow() call
>> in GuiView.cpp (see included patch).
>> 
>> Regards,
>> 
>> P. De Visschere
> 
>> diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
>> index c2101f3..89bff9a 100644
>> --- a/src/frontends/qt4/GuiView.cpp
>> +++ b/src/frontends/qt4/GuiView.cpp
>> @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, 
>> DispatchResult & dr)
>>  for (; i != ids.size(); ++i) {
>>  GuiView & gv = guiApp->view(ids[i]);
>>  if (gv.workArea(*buffer)) {
>> +gv.raise();
>>  gv.activateWindow();
>>  gv.setBuffer(buffer);
>>  break;
> 
> Since this part of the code is contained in "case LFUN_BUFFER_SWITCH"
> and is only reached if there are multiple views, I think it could go
> in for 2.2.0.
> 
> Let's see if anyone else has an opinion, otherwise I will test on Linux
> and commit it before rc2.

You may consider to cherry-pick change 5f368aec7b3206c873c94294def906911523dc8e.

Stephan

Fix for using system icons

[Scott Kostyshak]

There is a patch for
http://www.lyx.org/trac/ticket/10052
at
http://www.lyx.org/trac/attachment/ticket/10052/10052_alternative.diff

I'm planning to commit the patch before rc2 unless someone objects. The
patch is simple and has been tested.

Scott


signature.asc
Description: PGP signature

Re: Bringing a hidden window to the front on a mac.

[Scott Kostyshak]

On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote:
> If one has 2 documents open in LyX 2.2 in 2 separate windows and one wants
> to bring the one in the back to the front via the menu View/Hidden/... then
> (on a mac, OSX 10.11.4) nothing happens. Although the window has been
> activated, it's not brought to the front. [When switching to e.g. the Finder
> and then back to LyX by clicking on the LyX icon in the Dock, the hidden
> window will now be shown in front.]
> 
> The problem is solved by adding a raise() call to the activateWindow() call
> in GuiView.cpp (see included patch).
> 
> Regards,
> 
> P. De Visschere

> diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
> index c2101f3..89bff9a 100644
> --- a/src/frontends/qt4/GuiView.cpp
> +++ b/src/frontends/qt4/GuiView.cpp
> @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, 
> DispatchResult & dr)
>   for (; i != ids.size(); ++i) {
>   GuiView & gv = guiApp->view(ids[i]);
>   if (gv.workArea(*buffer)) {
> + gv.raise();
>   gv.activateWindow();
>   gv.setBuffer(buffer);
>   break;

Since this part of the code is contained in "case LFUN_BUFFER_SWITCH"
and is only reached if there are multiple views, I think it could go
in for 2.2.0.

Let's see if anyone else has an opinion, otherwise I will test on Linux
and commit it before rc2.

Scott


signature.asc
Description: PGP signature

Re: We will have to change our output for newest LuaTeX

[Scott Kostyshak]

On Sat, May 21, 2016 at 04:23:24PM +, Guenter Milde wrote:
> On 2016-05-20, Guillaume Munch wrote:
> > Le 20/05/2016 19:26, Scott Kostyshak a écrit :
> >> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote:
> >>> On 2016-05-20, Jean-Marc Lasgouttes wrote:
>  Le 20/05/2016 à 13:17, Guenter Milde a écrit :
> > On 2016-05-20, Scott Kostyshak wrote:
> 
> >> There have been some changes in the luatex engine that will be
> >> shipped with TeX Live 2016 that cause many of our tests to fail
> >> (500 something instead of 100 something on TL 2015). The root
> >> issue is discussed on the LuaTeX mailing list at [1].
> 
> >> There is a transitional package available, luatex85, that should
> >> make our current LuaTeX code work. A reasonable approach for now
> >> would be to use the package if it is available and to not use it
> >> if not, keeping the rest of our LuaTeX export code the same.
> ...
> > We could just add
> ...
>  \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
> ...
> 
> >> Should we do this only when we use code that we think needs it? Or
> >> should we just add it to all of our LuaTeX exports?
> 
> I propose to do this with every LuaTeX export
> 
> +3 simple (no LyX-logic required)
> +1 no risk of LyX getting it wrong
> -1 eventually spurious package loading

I agree.

> > For 2.2 this could be shipped as a module, to be deprecated and updated
> > into an empty module once LyX decides to adopt the new luatex syntax.
> 
> I'd rather keep this simple as well: insert
> 
>  \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
> 
> with every LuaTeX export for the next years to come untill we can be safe
> every user has the new version and can start using the new syntax in our
> export.

Makes sense. And because LuaTeX is still beta, I don't think we should feel
too much pressure an old LuaTeX version for a long time.

What about the attached patch? The most controversial change is putting
something before \documentclass. In BufferParams::writeLaTeX() we have
the following warning:

// Do not try to load any other package before the document class, unless you
// have a thorough understanding of the LATEX internals and know exactly what 
you
// are doing!

I do not have a thorough understanding of the LATEX internals and I very
rarely know exactly what I'm doing. The package documentation of
luatex85 does suggest that it should be the first line of the document.

Any thoughts?

Jürgen, since you've done a lot of work on the LuaTeX code, do you have
an opinion?

Scott
From 7a94d6a64919c791e49f2c3e712770d611bc2b55 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Sat, 21 May 2016 17:04:42 -0400
Subject: [PATCH] Fix LuaTeX export for TL >= 2016

If the transitional package luatex85 is available we use it.
Otherwise, we assume that an older luatex engine is being used. For
more information, see the following lyx-devel thread:
https://www.mail-archive.com/search?l=mid=20160520075810.yi3uspufehev5aln%40cotopaxi

The luatex85 manual suggests to users to load the package "as the
first line of their document".
---
 src/BufferParams.cpp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 9d121cb..1689513 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1426,6 +1426,17 @@ bool BufferParams::writeLaTeX(otexstream & os, 
LaTeXFeatures & features,
// Do not try to load any other package before the document class, 
unless you
// have a thorough understanding of the LATEX internals and know 
exactly what you
// are doing!
+
+   // our LuaTeX export is broken with TL >= 2016. If the transitional
+   // package luatex85 is available we use it. Otherwise, we assume that
+   // an older luatex engine is being used.
+   // 
https://www.mail-archive.com/search?l=mid=20160520075810.yi3uspufehev5aln%40cotopaxi
+   // The luatex85 manual suggests to users to load the package "as the
+   // first line of their document"
+   if (features.runparams().flavor == OutputParams::LUATEX ||
+   features.runparams().flavor == OutputParams::DVILUATEX)
+   os << 
"\\IfFileExists{luatex85.sty}{\\usepackage{luatex85}}{}\n";
+
if (features.mustProvide("fix-cm"))
os << "\\RequirePackage{fix-cm}\n";
// Likewise for fixltx2e. If other packages conflict with this policy,
-- 
2.1.4



signature.asc
Description: PGP signature

Plan to tag and tar 2.2.0rc2 on Monday

[Scott Kostyshak]

Dear all,

Unless something comes up, I'm planning to tag and tar rc2 on Monday. At
that point I'll put the tar balls on the FTP and whenever Mac and Win
binaries are uploaded we will announce the release.

Thank you all for your help,

Scott


signature.asc
Description: PGP signature

Re: LyX does work with ImageMagick 7

[Scott Kostyshak]

On Sat, May 21, 2016 at 11:27:27AM +0200, Georg Baum wrote:
> Hi,
> 
> now I found some time to test and it turned out that some information in
> this thread is wrong. Therefore I removed the warning from release notes
> again.
> 
> 1) Imagemagick 7 does still contain the 'convert' utility. If you install
> from source on unix, it is simply a symlink to 'magick'. If you use the
> binary installer on windows, you need to tick the "Install legacy utilities"
> option in order to install a convert.exe along magick.exe (but for LyX this
> is no longer needed since we prefer 'magick' if it is available).
> 
> 2) LyX works perfectly with Imagemagick 7. I tested that without the convert
> symlink. I could not see any difference to IM 6 (and I made sure I deleted
> the image cache and reconfigured). I guess what might have lead to the
> assumption that IM 7 does not work is the fact that the info inset produces
> text output for .svgz images, but an image link for .png images. This should
> be changed, modern browsers support svg (but may need uncompressing, I don't
> know).

Good to know that 2.2.0 is expected to work with IM 7.

Scott


signature.asc
Description: PGP signature

Re: Python 2 in release notes

[Scott Kostyshak]

On Sat, May 21, 2016 at 10:16:25AM +0200, Georg Baum wrote:
> José Matos wrote:
> 
> > On Monday, May 9, 2016 9:46:01 PM WEST Scott Kostyshak wrote:
> >> Georg or José, please feel free to make changes to the RELEASE-NOTES
> >> regarding Python if you think it would make things more clear.
> >> 
> >> Scott
> > 
> > I think that Georg's formulation is clear and more correct than what we
> > have now.
> 
> Actually it was not correct either, since building LyX works with python 3. 
> I just committed a hopefully better version at 8d4236bd1d95.

Thanks.

Scott


signature.asc
Description: PGP signature

Re: [patch] fix bug 10124 (XHTML export of some symbols)

[Scott Kostyshak]

On Sat, May 21, 2016 at 09:56:07AM -0400, Richard Heck wrote:
> On 05/21/2016 05:11 AM, Georg Baum wrote:
> > While testing imagemagick 7 (more on that later) I stumbled upon bug 10124 
> > as well. It is a simple typo where LyX outputs / instead of . OK 
> > for 2.2.0?
> 
> Scott's call, of course, but it certainly looks safe to me.

Go ahead for master.

Scott


signature.asc
Description: PGP signature

Re: enhancing search: make it find everything; including source

[mn]

On 21.05.16 18:15, Guenter Milde wrote:
> On 2016-05-21, mn wrote:
>> Currently it seems quite difficult to get the search function to really
>> find everything that might be in a lyx-document.
> 
>> One example:
>> Open a new document, language is set to English.
>> Enter a word enclosed in smart quotes.
>> Change document language to German with the corresponding smart quotes.
> 
> (it actually suffices to change the smart quotes)
> 
>> Enter a word enclosed with smart quotes.
>> Enter a third word, this time enclosing it with direct quotes (Opt-^ /
>> Opt-2)
> 
> This is a locale/system specific input. I assume you mean insert the Unicode
> characters „ and “ (here on Linux with locale de-UTF8 it is AltGr-V AltGr-B).
> 
Yes. In any case: this is the direct-input I meant.

>> This results in the following source:
>> ``word'' ,,word`` \quotedblbase word\textquotedblleft{}
> 
> This is not the LyX source, it is the LaTeX source which also depends on
> document settings:
> With Document>Settings>Language>LaTeX encoding Unicode (utf8), this becomes
> 
>   ``word'' ,,word`` „word“ 
> 
> In the source view pane, you can also set the "format" to LyX to see the LyX
> source (or open the file in a text editor).
> 
> Then you realize that this is still inconsistent:
> 
> * smart quotes are converted to LyX insets, e.g. «Wort becomes
> 
>\begin_inset Quotes fld
>\end_inset
> 
>Wort
>   
>   (a relict from pre-Unicode times) while 
>   
> * Unicode quotes are stored as Unicode (fine).
> 
> Also the different export via pseudo-ligatures (`` '') or LICR macros is
> inconsistent.
> 

These inconsistencies are there, working as designed, I assumed, for
reasons I missed. (Historical)
For new documents I strive to have a completely streamlined unicode
toolchain.
[Whistling while waiting for full biblatex-support… ;) ]

> This might be worth a bug report.
> 
Thanks, I was looking for exactly this kind of feedback, also to clarify
 thoughts and words for such a report.
Will this be classified as a bug or an enhancement request?

>> When you open the search panel and enter the key-combo used for
>> smart-quotes you will get the "ascii-quote" sign and will not find anything.
>> When entering the direct German closing quote, you will only find
>> \textquotedblleft{}, but not ``.
> 
> Because you find the Unicode character but not the "pseudo-ligature"
> (conversion to typographical quotes is done at the font level).
> 
Precisely.

>> The ‘smart’-quotes are invisible to search?
> 
> I don't know whether they are found via some "inset name".
> 

> I'd like to see a regexp search, then I could search for 
> "some .+word.+ and follwing text".
> 
Given the *nix-background of most of the devs I am puzzled why it wasn’t
included already.

> But this special case would be solved as a nice side effect when the
> "smart quote" feature inserts appropriate Unicode characters instead of
> the legacy insets from pre-Unicode times.
+1

> 
>> But wouldn’t it be a treat to start it by enhancing the source view with
>> a find-in-source facility?
> 
> Which source LyX/LaTeX/HTML/...?

All of them?
I imagined find-in-source as the least intrusive approach and I am still
unsure where this would make the most sense.
It does’t matter to me where this is implemented.
Ultimately, I like to be able to find everything by using a search and
not by close-reading the whole document and the different source-views
when revising a document.
ERT, formatting-instructions, you name it.
Also, basically most of the stuff Insert-menu offers: All hard to find
by themselves. Now, where is that next margin-note again?

greetings
Mike

Re: We will have to change our output for newest LuaTeX

[Guenter Milde]

On 2016-05-20, Guillaume Munch wrote:
> Le 20/05/2016 19:26, Scott Kostyshak a écrit :
>> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote:
>>> On 2016-05-20, Jean-Marc Lasgouttes wrote:
 Le 20/05/2016 à 13:17, Guenter Milde a écrit :
> On 2016-05-20, Scott Kostyshak wrote:

>> There have been some changes in the luatex engine that will be
>> shipped with TeX Live 2016 that cause many of our tests to fail
>> (500 something instead of 100 something on TL 2015). The root
>> issue is discussed on the LuaTeX mailing list at [1].

>> There is a transitional package available, luatex85, that should
>> make our current LuaTeX code work. A reasonable approach for now
>> would be to use the package if it is available and to not use it
>> if not, keeping the rest of our LuaTeX export code the same.
...
> We could just add
...
 \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
...

>> Should we do this only when we use code that we think needs it? Or
>> should we just add it to all of our LuaTeX exports?

I propose to do this with every LuaTeX export

+3 simple (no LyX-logic required)
+1 no risk of LyX getting it wrong
-1 eventually spurious package loading

> For 2.2 this could be shipped as a module, to be deprecated and updated
> into an empty module once LyX decides to adopt the new luatex syntax.

I'd rather keep this simple as well: insert

 \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}

with every LuaTeX export for the next years to come untill we can be safe
every user has the new version and can start using the new syntax in our
export.

Günter

Re: enhancing search: make it find everything; including source

[Guenter Milde]

On 2016-05-21, mn wrote:
> Currently it seems quite difficult to get the search function to really
> find everything that might be in a lyx-document.

> One example:
> Open a new document, language is set to English.
> Enter a word enclosed in smart quotes.
> Change document language to German with the corresponding smart quotes.

(it actually suffices to change the smart quotes)

> Enter a word enclosed with smart quotes.
> Enter a third word, this time enclosing it with direct quotes (Opt-^ /
> Opt-2)

This is a locale/system specific input. I assume you mean insert the Unicode
characters „ and “ (here on Linux with locale de-UTF8 it is AltGr-V AltGr-B).

> This results in the following source:
> ``word'' ,,word`` \quotedblbase word\textquotedblleft{}

This is not the LyX source, it is the LaTeX source which also depends on
document settings:
With Document>Settings>Language>LaTeX encoding Unicode (utf8), this becomes

  ``word'' ,,word`` „word“ 

In the source view pane, you can also set the "format" to LyX to see the LyX
source (or open the file in a text editor).

Then you realize that this is still inconsistent:

* smart quotes are converted to LyX insets, e.g. «Wort becomes

   \begin_inset Quotes fld
   \end_inset

   Wort
  
  (a relict from pre-Unicode times) while 
  
* Unicode quotes are stored as Unicode (fine).

Also the different export via pseudo-ligatures (`` '') or LICR macros is
inconsistent.

This might be worth a bug report.

> When you open the search panel and enter the key-combo used for
> smart-quotes you will get the "ascii-quote" sign and will not find anything.
> When entering the direct German closing quote, you will only find
> \textquotedblleft{}, but not ``.

Because you find the Unicode character but not the "pseudo-ligature"
(conversion to typographical quotes is done at the font level).

> The ‘smart’-quotes are invisible to search?

I don't know whether they are found via some "inset name".

I'd like to see a regexp search, then I could search for 
"some .+word.+ and follwing text".

But this special case would be solved as a nice side effect when the
"smart quote" feature inserts appropriate Unicode characters instead of
the legacy insets from pre-Unicode times.



> (btw: entering `` into the search panel renders it inoperable?
> This is on OS X: the input obviously waits for a second compose
> character that the acent goes to and doesn’t treat this as a backtick.
> Nevertheless, the search button ist dead and when you switch to the
> document and back to the search panel one of the `’s is gone.
> As a workaround entering space and deleting that right away reactivates
> the button.)

This is a feature of your system keybindings with "dead" keys. Nothing that
can be solved by LyX. Some "dead" keys can be made self-inserting by double
press (`` becomes ` and  becomes ``).

...

> But wouldn’t it be a treat to start it by enhancing the source view with
> a find-in-source facility?

Which source LyX/LaTeX/HTML/...?

Günter

Re: [patch] fix bug 10124 (XHTML export of some symbols)

[Richard Heck]

On 05/21/2016 05:11 AM, Georg Baum wrote:
> While testing imagemagick 7 (more on that later) I stumbled upon bug 10124 as 
> well. It is a simple typo where LyX outputs / instead of . OK for 
> 2.2.0?

Scott's call, of course, but it certainly looks safe to me.

Richard

LyX does work with ImageMagick 7

[Georg Baum]

Hi,

now I found some time to test and it turned out that some information in 
this thread is wrong. Therefore I removed the warning from release notes 
again.


1) Imagemagick 7 does still contain the 'convert' utility. If you 
install from source on unix, it is simply a symlink to 'magick'. If you 
use the binary installer on windows, you need to tick the "Install 
legacy utilities" option in order to install a convert.exe along 
magick.exe (but for LyX this is no longer needed since we prefer 
'magick' if it is available).


2) LyX works perfectly with Imagemagick 7. I tested that without the 
convert symlink. I could not see any difference to IM 6 (and I made sure 
I deleted the image cache and reconfigured). I guess what might have 
lead to the assumption that IM 7 does not work is the fact that the info 
inset produces text output for .svgz images, but an image link for .png 
images. This should be changed, modern browsers support svg (but may 
need uncompressing, I don't know).



Georg

Bringing a hidden window to the front on a mac.

[pdv]

If one has 2 documents open in LyX 2.2 in 2 separate windows and one 
wants to bring the one in the back to the front via the menu 
View/Hidden/... then (on a mac, OSX 10.11.4) nothing happens. Although 
the window has been activated, it's not brought to the front. [When 
switching to e.g. the Finder and then back to LyX by clicking on the LyX 
icon in the Dock, the hidden window will now be shown in front.]


The problem is solved by adding a raise() call to the activateWindow() 
call in GuiView.cpp (see included patch).


Regards,

P. De Visschere
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index c2101f3..89bff9a 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, 
DispatchResult & dr)
for (; i != ids.size(); ++i) {
GuiView & gv = guiApp->view(ids[i]);
if (gv.workArea(*buffer)) {
+   gv.raise();
gv.activateWindow();
gv.setBuffer(buffer);
break;

[patch] fix bug 10124 (XHTML export of some symbols)

[Georg Baum]

While testing imagemagick 7 (more on that later) I stumbled upon bug 10124 
as well. It is a simple typo where LyX outputs / instead of . OK 
for 2.2.0?


Georgdiff --git a/src/mathed/MathMacro.cpp b/src/mathed/MathMacro.cpp
index e01f7c2..9fe6e15 100644
--- a/src/mathed/MathMacro.cpp
+++ b/src/mathed/MathMacro.cpp
@@ -1008,7 +1008,7 @@ void MathMacro::mathmlize(MathStream & os) const
 		docstring const xmlname = d->macro_->xmlname();
 		if (!xmlname.empty()) {
 			char const * type = d->macro_->MathMLtype();
-			os << '<' << type << "> " << xmlname << " /<"
+			os << '<' << type << "> " << xmlname << " ';
 			return;
 		}

enhancing search: make it find everything; including source

[mn]

Currently it seems quite difficult to get the search function to really
find everything that might be in a lyx-document.

One example:
Open a new document, language is set to English.
Enter a word enclosed in smart quotes.
Change document language to German with the corresponding smart quotes.
Enter a word enclosed with smart quotes.
Enter a third word, this time enclosing it with direct quotes (Opt-^ /
Opt-2)

This results in the following source:
``word'' ,,word`` \quotedblbase word\textquotedblleft{}

When you open the search panel and enter the key-combo used for
smart-quotes you will get the "ascii-quote" sign and will not find anything.
When entering the direct German closing quote, you will only find
\textquotedblleft{}, but not ``.
The ‘smart’-quotes are invisible to search?

So while in the editor, one and the same character representation should
be found when searching for it. (Being aware of the diffreent means to
achieve it.)

(btw: entering `` into the search panel renders it inoperable?
This is on OS X: the input obviously waits for a second compose
character that the acent goes to and doesn’t treat this as a backtick.
Nevertheless, the search button ist dead and when you switch to the
document and back to the search panel one of the `’s is gone.
As a workaround entering space and deleting that right away reactivates
the button.)

This is aggravated in old, grown, evolved, revised or collaborated on
documents.

But I think this could be generalized.
It seems to me that it applies to many more use cases, when searching
for anything that is not alphabetical text.

How can I find instances of direct formatting; e.g. LyX’s italics; set
directly so in contrast to defined through ‘logical markup’?
How can I search for ERT? (The text in those can be found, not
necessarily like ‘the next box’)
How can I find graphics, other insets or indeed most of the stuff from
the insert-menu?
How can I find environments that are not represented in the outline view
(i.e.: the navigate-menu could be fuller populated: next language, next
footnote etc.)?

This looks like quite a list, of course.
(Assuming the above documents something more than my ignorance)

But wouldn’t it be a treat to start it by enhancing the source view with
a find-in-source facility?

greetings
Mike

Re: Python 2 in release notes

[Georg Baum]

José Matos wrote:

> On Monday, May 9, 2016 9:46:01 PM WEST Scott Kostyshak wrote:
>> Georg or José, please feel free to make changes to the RELEASE-NOTES
>> regarding Python if you think it would make things more clear.
>> 
>> Scott
> 
> I think that Georg's formulation is clear and more correct than what we
> have now.

Actually it was not correct either, since building LyX works with python 3. 
I just committed a hopefully better version at 8d4236bd1d95.


Georg