Re: forced screen recenter in GuiApplication::dispatch?

[Scott Kostyshak]

On Sat, Dec 10, 2016 at 12:56:43AM -0500, Scott Kostyshak wrote:
> We currently have the following code in GuiApplication::dispatch:
> 
>   DispatchResult dr;
>   // redraw the screen at the end (first of the two drawing steps).
>   // This is done unless explicitly requested otherwise
>   dr.screenUpdate(Update::FitCursor);
>   dispatch(cmd, dr);
>   updateCurrentView(cmd, dr);
> 
> Regarding the comment "This is done unless explicitly requested", is it
> still possible to request that a redraw not be done and if so how? Or is
> this comment left-over from how things were previously (e.g. a3aad45f)?
> I don't see how the screen flags can be modified after FitCursor is set. 
> 
> I'm looking into how to disable recentering the screen upon a "copy".
> The use case is that I often use ctrl+a, ctrl+a, ctrl+c to copy a large
> inset and then paste it below. Currently, after ctrl+c LyX scrolls up to
> the beginning of the large inset. I'm not confident this is a good
> proposal, but in any case it lead me to this comment that I wasn't sure
> is still valid.

Jürgen, is your comment from a3aad45f still valid? i.e. can I request
for the screen not to be redrawn?

Scott


signature.asc
Description: PGP signature

Re: Gnuplot format & converter script

[Scott Kostyshak]

On Fri, Nov 04, 2016 at 11:51:55AM +0100, Tommaso Cucinotta wrote:
> On 04/11/2016 10:31, Jean-Marc Lasgouttes wrote:
> > > enable the feature. Also, I guess that integration of external materials
> > > suffers of similar security risks.
> > Another big hole is Sweave/knitr.
> 
> so, guess we deserve a TT: https://www.lyx.org/trac/ticket/10481

Hi Tommaso,

Now that the ticket has been mostly addressed, is there any other
barrier for your gnuplot patch?

Scott


signature.asc
Description: PGP signature

Re: [patch] Do not open or close branches after doc settings

[Scott Kostyshak]

On Sat, Jan 21, 2017 at 11:32:27PM -0500, Scott Kostyshak wrote:
> On Mon, Nov 21, 2016 at 09:34:40PM -0500, Scott Kostyshak wrote:
> > On Tue, Nov 22, 2016 at 09:07:35AM +1300, Andrew Parsloe wrote:
> > > On 21/11/2016 6:34 p.m., Scott Kostyshak wrote:
> > 
> > > As an occasional user of branches, when I deactivate a branch I expect the
> > > state of insets in the branch to be left in their current state, some 
> > > open,
> > > some closed, as the case may be. When I reactivate the branch I expect to
> > > recover that previous state. This seems to me the *minimal* assumption for
> > > LyX to make -- there was, presumably, good reason for the insets to be in
> > > that particular configuration. LyX should respect that when the branch is
> > > reactivated.
> > 
> > Thanks for the feedback, Günter and Andrew. I propose two questions for
> > going forward:
> > 
> > (1) Do others agree that LyX should be consistent and treat
> > activating/deactivating branches from right-clicking on a branch inset
> > the same as activating from Document Settings?
> > 
> > (2) Which behavior should be changed?
> > 
> > If the answer to (1) is "it is not inconsistent to treat those
> > situations differently", then we can just leave things as they are and
> > we don't need to change anything. If the answer is that we should change
> > one or the other to be consistent, then we need to debate (2).
> > 
> > For (2), the code for document settings explicitly makes a point to
> > open/close the activated/deactivated branches, and it has been this way
> > for a very long time, from what I see. So the burden would be on us to
> > argue that changing it makes considerably more sense than changing the
> > right-click activate/deactivate. I'm not sure how to proceed in this
> > case. If other developers agree, we could ask on lyx-users to see what
> > they think. I think this is a perfect situation for taking a poll of
> > users.
> 
> I'm still looking for feedback on the above issue.

If no one has feedback, I'll make a decision and commit to master.

Scott


signature.asc
Description: PGP signature

Re: [patch] Fix lyx-2.3dev build failure in FreeBSD

[Scott Kostyshak]

On Wed, Aug 10, 2016 at 04:57:12PM -0400, Scott Kostyshak wrote:
> On Thu, Jun 09, 2016 at 02:30:42AM +0200, Shankar Giri Venkita Giri wrote:
> > Thanks Pavel.
> >  
> > I'll try to produce a patch for #1. Then both #1 and #2, after
> > review, can go into master/branch. I play around in FreeBSD
> > frequently, so I can help with build issues/regressions in future as
> > well.
> 
> Hi Shankar,
> 
> I'm just curious if there's been any progress on this. No worries if
> you're busy.

Hi Shankar,

I just want to make sure this is not forgotten. Are there any issues
with the master branch of LyX on FreeBSD now?

Scott


signature.asc
Description: PGP signature

Re: cmake build

[Ian Wilder]

On 2017-02-13 16:21:52 +, Kornel Benko said:

Am Mittwoch, 1. Februar 2017 um 09:58:40, schrieb Ian Wilder 


Hey everyone!

I am attempting to build lyx master using the cmake build, but I can't
seem to get it to work.

My process is

git pull
git clean -fd
git checkout --

cmake . -DLYX_USE_QT=QT5 -DLYX_COCOA=ON
-DLYX_INSTALL_PREFIX=/Users/ian/Applications/LyX-master
-DLYX_REQUIRE_SPELLCHECK=ON -DLYX_RELEASE=ON -DLYX_QUIET=ON


1.) Please do not use source dir as build dir. This messes the source.


fixed.

2.) Do you really want lyx to be installed at 
"/Users/ian/Applications/LyX-master"?


I needed to make this LyX-master.app, but other than this, yes. Does 
this introduce an issue?





make

The error I get is:

[ 37%] Building CXX object
build/src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiBibitem.cpp.o
/Users/ian/src/lyx/src/frontends/qt4/GuiBibitem.cpp:35:10: error: use
of undeclared identifier 'literalCB'
connect(literalCB, SIGNAL(clicked()),
^
/Users/ian/src/lyx/src/frontends/qt4/GuiBibitem.cpp:46:2: error: use of
undeclared identifier 'literalCB'
literalCB->setChecked(params["literal"] == "true");
^
/Users/ian/src/lyx/src/frontends/qt4/GuiBibitem.cpp:55:22: error: use
of undeclared identifier 'literalCB'
params["literal"] = literalCB->isChecked()
^
3 errors generated.
make[2]: ***
[build/src/frontends/qt4/CMakeFiles/frontend_qt.dir/GuiBibitem.cpp.o]
Error 1
make[1]: *** [build/src/frontends/qt4/CMakeFiles/frontend_qt.dir/all] Error 2
make: *** [all] Error 2


It looks like the created ui_*.h (in the source dir) are left from some 
previous run of automake

created by using qt4 executables.


I am not sure why it's trying to build qt4 libs when LYX_USE_QT=QT5 is
on, perhaps this is the issue?


Historical reasons. We should rename the dir from 'qt4' to 'qt' eventually.


Just to note, I am able to build using autogen/configure/make.


Yes, and you use here probably the source dir again.


My platform is

Darwin ares 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21
PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64

Thanks for any help!

Ian Wilder


To compile with cmake:
Get a really clean source tree, say 'xyzzy_src'.
Create a _new_ build tree, say 'xyzzy_build'.

cd xyzzy_build
cmake xyzzy_src -DLYX_USE_QT=QT5 -DLYX_COCOA=ON etc
make


Kornel



I have now been able to do a build with cmake. Thank you very much!

However, the make install target doesn't seem to be runnable. Has 
someone been able to run a cmake built version on macos?


Thanks,
Ian

Re: cmake compilation error

[Guillaume Munch]

Le 12/03/2017 à 16:51, Kornel Benko a écrit :


Should we emit a warning (which probably will be ignored) or better refuse to 
build
with "5.0" <= QT < "5.4" ?


I don't think so, the indication INSTALL file should be enough in that case.



From my POV, if user selects QT5, we should use it.



Agreed. In addition, from my POV, it is better if Qt5 for big enough
values of 5 are selected as default, so that one does not have to select
it explicitly.

Re: cmake compilation error

[Kornel Benko]

Am Samstag, 11. März 2017 um 22:23:22, schrieb Guillaume Munch 
> Le 11/03/2017 à 18:07, Jean-Pierre Chrétien a écrit :
> > Le 11/03/2017 à 17:57, Kornel Benko a écrit :
> >
> >> I see the same with installed QT5.2.1. But no problems with QT5.7.
> >
> > Seems that I've got 5.3.2 here, Debian Jessie (up to date stable).
> 
> Indeed the function is introduced in qt5.4. It is now fixed. Note that
> from what I remember, LyX suffers various bugs with early releases of
> qt5, which is why the release notes strongly advises qt>=5.4. CMake
> should select qt4.8 over qt5.3 when possible.
> 
> Guillaume

Even if user _selects_ QT5? (default is QT4).

Should we emit a warning (which probably will be ignored) or better refuse to 
build
with "5.0" <= QT < "5.4" ?

From my POV, if user selects QT5, we should use it.

Kornel



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