Re: Reverse search: automatically focus LyX window?
On Sat, Jul 30, 2016 at 05:21:31PM -0400, Scott Kostyshak wrote: > I am just starting to use forward/reverse search. Things are working > well and I enjoy the feature. > > One thing that surprised me is that in Okular when I do a shift+click it > correctly sets the location in LyX but it does not take me to the LyX > window. My first reaction was that it is up to Okular whether this > should be done, but then I realized only lyxclient has the information > to decide this. > > Is this the same behavior for others? > Is there a way to have lyxclient focus the LyX window? Guillaume pointed me towards http://www.lyx.org/trac/ticket/10196 I am interested in working on the ticket if we agree on what should happen. I think it is understandable that lyxclient does not by default raise the LyX window. But I think it should be easy to configure it to do so when desired: - Should this be done with a new option to lyxclient? - Should it be the default for lyxclient -g? - Should we implement an LFUN and thus can call with lyxclient -c? Scott signature.asc Description: PGP signature
Ubuntu PPA: need to remove the default repo package first?
An edit was made to the LyXOnUbuntu page: http://wiki.lyx.org/LyX/LyXOnUbuntu?action=diff#diff1469928065 The user "JH" had a problem when using the Ubuntu PPA and changed the wiki page to suggest that users remove the default repo lyx package before using the PPA. Is this indeed the correct advice? I think that should not be necessary, but I've seen a couple of issues regarding upgrading LyX versions on Ubuntu, so I'm not sure. Scott signature.asc Description: PGP signature
External Material Problems
There seem to be some general problems concerning external material and the temporary directory. First, preview of external material does not seem to work. Constructs like: Format DocBook Product "" UpdateFormat eps UpdateResult "$$AbsPath$$Basename.eps" ReferencedFile docbook "$$AbsPath$$Basename.eps" ReferencedFile docbook-xml "$$AbsPath$$Basename.eps" FormatEnd fail on preview, because it is looking for the exported filename, not the mangled one in the temporary directory. Similarly, constructs like Format Ascii Product "$$Contents(\"$$AbsPath$$Basename.asc\")" UpdateFormat asciichess UpdateResult "$$AbsPath$$Basename.asc" FormatEnd fail, for the same reason: They try to include a file in the document directory. Richard
Reverse search: automatically focus LyX window?
I am just starting to use forward/reverse search. Things are working well and I enjoy the feature. One thing that surprised me is that in Okular when I do a shift+click it correctly sets the location in LyX but it does not take me to the LyX window. My first reaction was that it is up to Okular whether this should be done, but then I realized only lyxclient has the information to decide this. Is this the same behavior for others? Is there a way to have lyxclient focus the LyX window? Scott signature.asc Description: PGP signature
Re: [LyX/2.2.x] Start preparations for 2.2.1.
On 07/30/2016 04:10 PM, Guillaume Munch wrote: > Le 27/07/2016 à 17:37, Jean-Pierre Chrétien a écrit : >> >> So what about "LaTeX source"? Replace it by "Source Code"? or simply >> "Code"? >> Or make it follow a change of the selected format? >> > > Sorry I only see now that you are already suggesting "Code". I like > it, e.g. "Code Preview Pane". That is good. rh
Re: [LyX/2.2.x] Start preparations for 2.2.1.
Le 27/07/2016 à 17:37, Jean-Pierre Chrétien a écrit : After reviewing the various uses of Format in the menus and the translations I made, I eventually agree upon this, as I use Format in French in Preferences->File Formats. Ok so for now intend to leave it, and backport it to stable again if no objection. So what about "LaTeX source"? Replace it by "Source Code"? or simply "Code"? Or make it follow a change of the selected format? Sorry I only see now that you are already suggesting "Code". I like it, e.g. "Code Preview Pane".
Re: [LyX/2.2.x] Start preparations for 2.2.1.
Le 26/07/2016 à 09:23, Guenter Milde a écrit : (I have a similar issue with the "source panel": it should really be called "output panel". I cannot follow this argument: the "source panel" shows various output formats (TeX/HTML/LyX) in source form - (as opposed to a user agent (browser) showing HTML in a presentational form or the LyX GUI window showing the source in presentational/interactive form. "Source" depends on the context, and in LyX one would expect that it refers to some source for LyX. What about "Code preview" ? inspired by the current French translation. I still don't like the idea to summarise saving the lyx file and export under "output". Do you have a suggestion? Keeping "Formats"?
Re: [PATCH] fix "scroll here" (#10311)
On Sat, Jul 30, 2016 at 01:54:03AM +0100, Guillaume Munch wrote: > An invariant is that the scrollbar position is always zero. I remember your comment pointing this out. This was helpful when I was debugging. > With your > patch, in rare occasions I noticed that it would become negative (for > instance when scrolling the math manual to the bottom). > > The source of your bug is that SetRange() can change the current value > to force it inside the range. When doing so, it triggers the > valueChanged() signal and therefore a recursive call to scrollTo(). I > think the solution is simply to block signals. Moving setRange after > setPosition(0) ensured that most of the time setRange did not have > to correct the value and therefore did not cause the recursive call, but > of course this is more fragile than blocking signals. Agreed, your patch is better. > (I did not check, > but I think there is only one call to scrollTo instead of two now.) I checked and you are right. Reducing from three to one is a nice improvement. In your commit message, I think you should make it clear that the change improves more than just fixing the symptoms of #10311 (because "scroll here" I suppose is a rarely used feature). Perhaps use the following text if you want: Further, this commit improves efficiency (reduces three calls of scrollTo() to one call) for all scrolling functions of the scroll bar (e.g. clicking on the arrow, dragging, or clicking somewhere on the scrollbar). > I also fixed the range which sometimes excluded zero. This was my > original objection after testing your patch. But in the end I think it > was entirely unrelated to your bug, it just led me to find the cause. Good. Regarding the patch, I have two comments: 1. It seems that it blocks all signals. Is that what we want or do we just want to block the problematic signals? In testing the patch I tried to find broken behavior and could not so perhaps blocking all signals is fine. 2. QSignalBlocker was interoduced in 5.3: http://doc.qt.io/qt-5/qsignalblocker.html But apparently it is just a wrapper around QObject::blockSignals(). Can you use that instead? Scott signature.asc Description: PGP signature
