Re: [LyX/master] Fix cursor movement for large logos (#9628)

[Scott Kostyshak]

On Sun, Oct 11, 2015 at 02:26:16PM +0200, Georg Baum wrote:
> commit 359aef92f87169ce2683e287bb24bc3d5f46a190
> Author: Georg Baum 
> Date:   Sun Oct 11 14:21:45 2015 +0200
> 
> Fix cursor movement for large logos (#9628)
> 
> Previously, if one clicked onto a large non-editable inset like the new 
> LyX
> logo inset, the cursor was always positioned in front of the inset, even 
> if
> the click was almost at the back edge. Now the cursor is positioned at the
> correct edge. I tested this also with RTL contents, where from means right
> and back means left, but the inset anchor position anchor point is still
> at the left, and the right edge is dim.wid pixels to the right of it.

I think this caused the following change in behavior for me: it is
possible for me to get the context menu when right-clicking on a newline
inset but to have the options greyed out. I think this happens more
often when I right-click on the far right of the red, newline inset
symbol. Here is a screencast:

https://www.dropbox.com/s/szcgty1qxk5fayw/disabled_options.ogv?dl=0

Similarly, once I trigger this behavior, if right-click a little to the
left, I again get a greyed-out context menu. I can continue this going
all the way to the left edge of the newline inset. I find this strange
because if my first right-click is on the left side of the newline
inset, then I (usually) get a context menu with options enabled. I did
not show this in the screencast but let me know if you want me to make
another one.

(note also that commit b70f2eff is related to this commit)

Can you reproduce?

Scott


signature.asc
Description: PGP signature

Re: Beamer separators in 2.2b2

[Guillaume Munch]

Le 11/03/2016 18:01, José Matos a écrit :

On Friday, March 11, 2016 05:52:46 PM Guillaume Munch wrote:

What about drawing this inset differently when it is alone in its paragraph?


I would be happy. :-)



Or adapt lyx2lyx to convert the old separator into the plain separator 
followed by the parbreak separator on the same paragraph?

Re: Beamer separators in 2.2b2

[José Matos]

On Friday, March 11, 2016 05:52:46 PM Guillaume Munch wrote:
> What about drawing this inset differently when it is alone in its paragraph?

I would be happy. :-)
-- 
José Abílio

Re: Beamer separators in 2.2b2

[Guillaume Munch]

Le 11/03/2016 17:28, José Matos a écrit :

On Thursday, March 10, 2016 10:48:58 PM Enrico Forestieri wrote:

In a nutshell, the old separator layout has gone and now a separator
inset is used in its place. Given that the old separator layout was
introducing a blank line in the latex output, in order to not change
the output, all converted documents use the parbreak separator (denoted
by the unfamiliar character). However, if that blank line is not essential,
you can get the familiar line back by right clicking the unfamiliar
character and changing it to the plain version.


I understand what you say but what is confusing is the representation. I
suspect that you know that. :-)

When I insert a separator between layouts, be it a Frame or an Theorem, what I
want is to have two distinct Frames or two distinct Theorems and not the same
Frame or Theorem with another standard paragraph.

The separator sign (a line at all length) conveyed that, the new sign does
not. That is what is confusing.

That the old separator added an extra line is an (unfortunate) implementation
detail.
That in one form or another I complained since last century (technically my
problem was with the way we worked implicitly with the standard paragraph).



What about drawing this inset differently when it is alone in its paragraph?

Re: Beamer separators in 2.2b2

[José Matos]

On Thursday, March 10, 2016 10:48:58 PM Enrico Forestieri wrote:
> In a nutshell, the old separator layout has gone and now a separator
> inset is used in its place. Given that the old separator layout was
> introducing a blank line in the latex output, in order to not change
> the output, all converted documents use the parbreak separator (denoted
> by the unfamiliar character). However, if that blank line is not essential,
> you can get the familiar line back by right clicking the unfamiliar
> character and changing it to the plain version.

I understand what you say but what is confusing is the representation. I 
suspect that you know that. :-)

When I insert a separator between layouts, be it a Frame or an Theorem, what I 
want is to have two distinct Frames or two distinct Theorems and not the same 
Frame or Theorem with another standard paragraph.

The separator sign (a line at all length) conveyed that, the new sign does 
not. That is what is confusing.

That the old separator added an extra line is an (unfortunate) implementation 
detail.
That in one form or another I complained since last century (technically my 
problem was with the way we worked implicitly with the standard paragraph).

BTW the plain version representation only covers a small percentage of the 
line and not most of the line has it happened before where the separation 
meaning was obvious then.

Regards,
-- 
José Abílio

Re: Cursor position regression (?) in master

[Scott Kostyshak]

On Fri, Mar 11, 2016 at 11:51:42AM +0100, Jean-Marc Lasgouttes wrote:
> Le 10/03/2016 21:35, Scott Kostyshak a écrit :
> >On Thu, Mar 10, 2016 at 09:32:36PM +0100, Jean-Marc Lasgouttes wrote:
> >>Thanks. So it's me after all. I'll handle it.
> >
> >It seems like a minor issue (that no one reported in 2 years of testing
> >on master), so if you think it's better to wait, then I think that would
> >be fine. Your call.
> 
> What about this new version?

Fixes the problem for me. If you recommend it for 2.2.0, please put it
in.

I don't think the following is a new observation, but in case it is
relevant I mention it here: if your cursor is just before a paragraph
break, word-forward puts you after that inset. If it is before a newline
inset, it puts you on the next line.

Scott


signature.asc
Description: PGP signature

Re: Plan for 2.2.0rc1

[Guenter Milde]

On 2016-03-11, Scott Kostyshak wrote:
> On Thu, Mar 10, 2016 at 10:49:16PM -0500, Scott Kostyshak wrote:
>> On Thu, Mar 10, 2016 at 12:50:25AM +0100, Uwe Stöhr wrote:

>> > - we still haven't done anything to fix the 2 layouts that will produce
>> > uncompilable files (acmsiggraph and agutex). Please make a decision and I
>> > will apply it that way. It would be embarassing when we include outdated
>> > layouts despite that we are aware of this.

>> OK I will take a look at this.

> My decision is that if someone gives you a +1 on a patch that is posted
> for the two layouts and the lyx2lyx tests pass, then the patch should
> go in.

> Note that Georg stated:
> https://www.mail-archive.com/search?l=mid=n8i0e7%24pr5%241%40ger.gmane.org
> "I would very likely give a +1 to a patch that renames the old layout
> file to a different name, updates the one with the generic name to the
> current version (as you did it), and a lyx2lyx step that simply changes
> the document class to the new name of the old layout file for old
> documents. This would even be less work (no real lyx2lyx code needed)."

Sounds reasonable.

In the case of acmsiggraph, we could also just drop the styles corresponding
to LaTeX commands/environments that are no longer supported by the new
documentclass version. (See the post/patch linked below).

> If I understood correctly, there is support from Kornel and Guenter for
> versioned layouts. It seems to me we just need to figure out some of the
> details. Guenter provided some points for discussion here:
> https://www.mail-archive.com/search?l=mid=n8m1ff%24nnq%241%40ger.gmane.org

> Also, I do not see any response to Guenter's patch posted at
> https://www.mail-archive.com/search?l=mid=n90eas%24gab%241%40ger.gmane.org

Günter

Re: Plan for 2.2.0rc1

[Peter Kümmel]

Am 11.03.2016 um 04:49 schrieb Scott Kostyshak:

On Thu, Mar 10, 2016 at 12:50:25AM +0100, Uwe Stöhr wrote:

Am 09.03.2016 um 04:37 schrieb Scott Kostyshak:


8. What am I missing?


- I need for Qt 5.6 this patch from Peter to be applied:
https://github.com/syntheticpp/lyx/commit/2470fb442cb2b04a69b2030f28f1da60221556a7?diff=unified


Peter, do you proppose this for 2.2.0?


No, not necessary for builds with msvc10.

And I only propose a 2.2.0 release with Qt 5.5.1 and msvc10. We could not 
change compilers and Qt versions like socks.




- bug http://www.lyx.org/trac/ticket/10009


I'm glad you figured out a workaround for that.


- we still haven't done anything to fix the 2 layouts that will produce
uncompilable files (acmsiggraph and agutex). Please make a decision and I
will apply it that way.. It would be embarassing when we include outdated
layouts despite that we are aware of this.


OK I will take a look at this.


Uwe and Stephan, which Qt versions will you be able to release RC1 with?


In my opinion the RC should feature Qt 5.6. For Qt 5.6 I need MSVC 2015
Update 2 (no other MSVC version could be used). Qt 5.6 will be released next
week and I assume MSVC 2015 Update 2 too (there is already an RC out). If
http://www.lyx.org/trac/ticket/10009 cannot be solved I will have to try out
MinGW but there are reports that MinGW misses some things necessary for
Windows 10.


Will you be able to also release an installer using Qt 5.5.1 and Qt
4.8.6? This would be nice so that if we get a bug report that we can't
reproduce, we can ask them to try the 5.5.1 installer and that way we
can see whether the bug is due to LyX or to Qt.

Scott

Re: Cursor position regression (?) in master

[Jean-Marc Lasgouttes]

Le 10/03/2016 21:35, Scott Kostyshak a écrit :

On Thu, Mar 10, 2016 at 09:32:36PM +0100, Jean-Marc Lasgouttes wrote:

Thanks. So it's me after all. I'll handle it.


It seems like a minor issue (that no one reported in 2 years of testing
on master), so if you think it's better to wait, then I think that would
be fine. Your call.


What about this new version?

JMarc



>From 5cab866b48be3699f81347147690c3eb2f90c816 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Sun, 6 Mar 2016 15:29:25 +0100
Subject: [PATCH] Do not set cursor to the right of newline with mouse

When a row is broken by for example a display math inset, it is
possible to put the cursor at the end of the previous line using the
boundary setting of cursor.

For newline insets and separator insets, we want to force the cursor
to be before this inset. Also, in the other cases, do not force
boundary property (effectively reverts part of f29e7803).
---
 src/TextMetrics.cpp |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/TextMetrics.cpp b/src/TextMetrics.cpp
index 05e1c97..e930350 100644
--- a/src/TextMetrics.cpp
+++ b/src/TextMetrics.cpp
@@ -1156,9 +1156,14 @@ pos_type TextMetrics::getPosNearX(Row const & row, int & x,
 	 * row is larger than the end of its last element.
 	 */
 	if (!row.empty() && pos == row.back().endpos
-	&& row.back().endpos == row.endpos())
-		boundary = true;
-
+	&& row.back().endpos == row.endpos()) {
+		Inset const * inset = row.back().inset;
+		if (inset && (inset->lyxCode() == NEWLINE_CODE
+		  || inset->lyxCode() == SEPARATOR_CODE))
+			pos = row.back().pos;
+		else
+			boundary = row.right_boundary();
+	}
 	x += xo;
 	//LYXERR0("getPosNearX ==> pos=" << pos << ", boundary=" << boundary);
 	return pos;
-- 
1.7.9.5

Re: xcolor conflict with beamer article?

[Scott Kostyshak]

On Fri, Mar 11, 2016 at 09:41:05AM +0100, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 10.03.2016, 16:55 -0500 schrieb Scott Kostyshak:
> > Committed to master at 97521c4e.
> > Note that I ran the ctests and nothing changed.
> 
> Thanks. I think you should also delete the "Provides color 0"
> statements in both article layouts.

OK done at d319a9e8.

Scott


signature.asc
Description: PGP signature

Re: Plan for 2.2.0rc1

[Scott Kostyshak]

On Thu, Mar 10, 2016 at 10:49:16PM -0500, Scott Kostyshak wrote:
> On Thu, Mar 10, 2016 at 12:50:25AM +0100, Uwe Stöhr wrote:

> > - we still haven't done anything to fix the 2 layouts that will produce
> > uncompilable files (acmsiggraph and agutex). Please make a decision and I
> > will apply it that way.. It would be embarassing when we include outdated
> > layouts despite that we are aware of this.
> 
> OK I will take a look at this.

My decision is that if someone gives you a +1 on a patch that is posted
for the two layouts and the lyx2lyx tests pass, then the patch should go
in.

Note that Georg stated:
https://www.mail-archive.com/search?l=mid=n8i0e7%24pr5%241%40ger.gmane.org
"I would very likely give a +1 to a patch that renames the old layout
file to a different name, updates the one with the generic name to the
current version (as you did it), and a lyx2lyx step that simply changes
the document class to the new name of the old layout file for old
documents. This would even be less work (no real lyx2lyx code needed)."

If I understood correctly, there is support from Kornel and Guenter for
versioned layouts. It seems to me we just need to figure out some of the
details. Guenter provided some points for discussion here:
https://www.mail-archive.com/search?l=mid=n8m1ff%24nnq%241%40ger.gmane.org

Also, I do not see any response to Guenter's patch posted at
https://www.mail-archive.com/search?l=mid=n90eas%24gab%241%40ger.gmane.org

Scott


signature.asc
Description: PGP signature

Re: xcolor conflict with beamer article?

[Jürgen Spitzmüller]

Am Donnerstag, den 10.03.2016, 16:55 -0500 schrieb Scott Kostyshak:
> Committed to master at 97521c4e.
> Note that I ran the ctests and nothing changed.

Thanks. I think you should also delete the "Provides color 0"
statements in both article layouts.

> I'm guessing you don't have enough time to test whether that's
> correct.

Yes, unfortunately. I am lucky if I can follow the discussions.

> I think I will leave this for now. Let me know if you want me to make
> a
> trac ticket.

Please do. Thanks.

Jürgen

> 
> Scott