Re: [LyX/2.2.x] Fix monolithic build.
On 10/14/2016 12:48 PM, Scott Kostyshak wrote: > On Mon, Oct 10, 2016 at 04:24:45PM +0200, Richard Heck wrote: >> commit 3fe8c04274b0cbc16577965207b4d98aec58d0cd >> Author: Richard Heck>> Date: Mon Oct 10 10:24:08 2016 -0400 >> >> Fix monolithic build. > Is this needed for master also? Probably, but I didn't check. rh
Re: LyX 2.2.2 Tarballs
On 15.10.2016 00:12, racoon wrote: On 14.10.2016 17:14, racoon wrote: On 13.10.2016 10:46, Guillaume Munch wrote: Le 12/10/2016 à 20:02, racoon a écrit : On 10.10.2016 17:49, Richard Heck wrote: Here: ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/2.2.2/ Please prepare binaries. I am on 2.2.2 now. There is something strange happening when I *replace* stuff from the beginning of a paragraph before a space by pasting some inset, e.g. note, label, citation, etc. It removes the following space. Maybe someone can test it on 2.2.1 whether this is a new or old bug. Details: Steps to reproduce: 1. Start a new paragraph write two (or three or four or ...) words (separated by a space) 2. Select the first (or first two or first three or ...) word(s) and insert a label (or a citation or paste a note or ...) Actual result: - The space between the words vanishes Expected result: - It does not I can reproduce with 2.1.5. I think this is an old bug. It actually affects not only insets but any kind of pasting operation, including text. Quite nasty bug I think. I can try to have a look at it but it probably concerns areas I haven't looked at before. Not sure what exactly it is yet. There is some (unnecessary) cleaning going on when removing a selection. It is probably in the eraseSelectionHelper in CutAndPaste.cpp. It seems to remove the leading space in a paragraph when deleting from the beginning of the paragraph up to a space. I guess the idea was that LyX does not allow for leading spaces that's why they should be automatically removed. But I guess they should not be. They will be cleaned up anyway after the cursor leaves the paragraph. This is also the case at other places. For example, when selecting the first word and replacing it by entering a character the bug does not occur. Also, the leading space is not removed when deleting the first word without selection, i.e. one character after the other. That's why there must be a bug here as well or, what I find more likely, the deletion of the leading space is really unnecessary. Attached is a fix. Ironically the problem was actually a passage that is commented as 'necessary' (commented it out for now). It does not seem necessary to me. Maybe there is some advantage in erasing the leading space but, if at all, it has to be done more careful. Daniel From 967d723b5915e52dfbf5a230b8b9c440af1f01a2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20Ram=C3=B6ller?=Date: Sat, 15 Oct 2016 00:35:17 +0200 Subject: [PATCH] Fixes that cutting selection from beginning of paragrph removes space after selection. --- src/CutAndPaste.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp index 4ec9811..888da0c 100644 --- a/src/CutAndPaste.cpp +++ b/src/CutAndPaste.cpp @@ -888,9 +888,9 @@ void cutSelection(Cursor & cur, bool doclear, bool realcut) cur.pit() = endpit; // sometimes necessary - if (doclear + /*if (doclear && text->paragraphs()[begpit].stripLeadingSpaces(bp.track_changes)) - cur.fixIfBroken(); + cur.fixIfBroken();*/ // need a valid cursor. (Lgb) cur.clearSelection(); -- 2.9.0.windows.1
Re: LyX 2.2.2 Tarballs
On 14.10.2016 17:14, racoon wrote: On 13.10.2016 10:46, Guillaume Munch wrote: Le 12/10/2016 à 20:02, racoon a écrit : On 10.10.2016 17:49, Richard Heck wrote: Here: ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/2.2.2/ Please prepare binaries. I am on 2.2.2 now. There is something strange happening when I *replace* stuff from the beginning of a paragraph before a space by pasting some inset, e.g. note, label, citation, etc. It removes the following space. Maybe someone can test it on 2.2.1 whether this is a new or old bug. Details: Steps to reproduce: 1. Start a new paragraph write two (or three or four or ...) words (separated by a space) 2. Select the first (or first two or first three or ...) word(s) and insert a label (or a citation or paste a note or ...) Actual result: - The space between the words vanishes Expected result: - It does not I can reproduce with 2.1.5. I think this is an old bug. It actually affects not only insets but any kind of pasting operation, including text. Quite nasty bug I think. I can try to have a look at it but it probably concerns areas I haven't looked at before. Not sure what exactly it is yet. There is some (unnecessary) cleaning going on when removing a selection. It is probably in the eraseSelectionHelper in CutAndPaste.cpp. It seems to remove the leading space in a paragraph when deleting from the beginning of the paragraph up to a space. I guess the idea was that LyX does not allow for leading spaces that's why they should be automatically removed. But I guess they should not be. They will be cleaned up anyway after the cursor leaves the paragraph. This is also the case at other places. For example, when selecting the first word and replacing it by entering a character the bug does not occur. Also, the leading space is not removed when deleting the first word without selection, i.e. one character after the other. That's why there must be a bug here as well or, what I find more likely, the deletion of the leading space is really unnecessary. Daniel
Re: LyX docs: cleaning up math options
On 2016-10-14, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > On Fri, Oct 14, 2016 at 03:36:11PM +, Guenter Milde wrote: >> For the end-user the difference is: >> * with "no", there is a safeguard against relying on additional packages >> without real need -> less dependencies when compiling the docs. > Wouldn't this be a LyX bug if we rely on an unneededed depencency? To be > clear, I believe Jean-Pierre and I were on the same page of porposing > that the options be changed to "Load automatically". We are not > proposing "Load always". Not a LyX bug. With "safeguard", I only mean the feadback by the compilation error if the editor/maintainer uses a feature requiring an additional package. If we decide now to allow this, we should set the options to "auto". I agree that this is a (small) benefit for the documentation people with a negligible impact on the average user. I.e. I am in favour of setting the math-package settings to "auto". Günter
Re: LyX docs: cleaning up math options
Am 14.10.2016 um 17:36 schrieb Guenter Milde: For the documentation people, the difference is:... Hi Scott and Günter, convinced, so fine with me to change everything to automatic. Please commit directly if the tests were passed to branch (when it is open again) and master (please keep there the fileformat). Please also take care of the non-English files. many thanks for your help and best regards Uwe
Re: LyX 2.2.2 Tarballs
Am 14.10.2016 um 08:30 schrieb racoon: Could you please give it a try and report if this fixes http://www.lyx.org/trac/ticket/10017 Awesome. Yes, now I can actually open menus with the primary mouse button and open more than one sub menu. Many thanks for testing. So this new installer version will become the one for LyX 2.2.2. regards Uwe
Re: LyX 2.2.2 Tarballs
Am 13.10.2016 um 19:04 schrieb Richard Heck: On 10/12/2016 07:33 PM, Uwe Stöhr wrote: are my final ones ready to be put on ftp.lyx.org. Thanks, I've got them and will plan to do the release tomorrow, probably, or Saturday. Hi Richard, Daniel gave me the feedback that my installer version 2 fixes the Qt bugs we was encountering. Could you therefore please grab installer version 2 from http://ftp.lyx.de/LyX%202.2.2/ and put them on ftp.lyx.org? many thanks and regards Uwe
Re: [patch] Fix color when branch name has a space
On Fri, Oct 14, 2016 at 07:16:36PM +0200, Jean-Marc Lasgouttes wrote: > Le 14/10/2016 à 17:51, Scott Kostyshak a écrit : > > Any thoughts? > > I would propose instead to use the helpers getArg and getLongArg in > FuncRequest. Two possibilities: > > lyx_name = cmd.getArg(0); > x11_name = cmd.getLongArg(1); > > This will do what you want, at the price of a badly defined syntax: it would > make more sense to keep the space as a parameter separator. > > The second solution would be to use > > lyx_name = cmd.getArg(0); > x11_name = cmd.getArg(1); > > In this case, the syntax for set-color would be > set-color foo bar > set-color "foo bar" baz > set-color foo "bar baz" > ... > > I really prefer this second solution. And any of these is better than > relying on split and rtrim. Makes sense. I'll work on a better patch. > Final remark: it seems to me that this LFUN should be named "color-set" > (set-graphics-group has the same problem). I agree. Scott signature.asc Description: PGP signature
Re: [patch] Fix color when branch name has a space
Le 14/10/2016 à 17:51, Scott Kostyshak a écrit : Any thoughts? I would propose instead to use the helpers getArg and getLongArg in FuncRequest. Two possibilities: lyx_name = cmd.getArg(0); x11_name = cmd.getLongArg(1); This will do what you want, at the price of a badly defined syntax: it would make more sense to keep the space as a parameter separator. The second solution would be to use lyx_name = cmd.getArg(0); x11_name = cmd.getArg(1); In this case, the syntax for set-color would be set-color foo bar set-color "foo bar" baz set-color foo "bar baz" ... I really prefer this second solution. And any of these is better than relying on split and rtrim. Final remark: it seems to me that this LFUN should be named "color-set" (set-graphics-group has the same problem). JMarc
Re: [LyX/2.2.x] Fix monolithic build.
On Mon, Oct 10, 2016 at 04:24:45PM +0200, Richard Heck wrote: > commit 3fe8c04274b0cbc16577965207b4d98aec58d0cd > Author: Richard Heck> Date: Mon Oct 10 10:24:08 2016 -0400 > > Fix monolithic build. Is this needed for master also? Scott signature.asc Description: PGP signature
[patch] Fix color when branch name has a space
Any thoughts? Scott From dfd265bbcb4c00d06ddd064fa64da5000ebc5cb2 Mon Sep 17 00:00:00 2001 From: Scott KostyshakDate: Fri, 14 Oct 2016 10:41:11 -0400 Subject: [PATCH] Fix color when branch name has a space The argument to set-color is " ", where in the case of branches is the name of the branch. Since branch names are allowed to contain spaces, instead of splitting on the first space in the argument we now split on the last space. --- src/LyXAction.cpp| 1 + src/frontends/qt4/GuiApplication.cpp | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp index 836f97b..fdf736a 100644 --- a/src/LyXAction.cpp +++ b/src/LyXAction.cpp @@ -3566,6 +3566,7 @@ void LyXAction::init() * \li Action: Set the given LyX color to the color defined by the X11 name given. * \li Notion: A new color entry is created if the color is unknown. Color names can be stored as a part of user settings. + Color names may contain spaces. * \li Syntax: set-color * \li Origin: SLior, 11 Jun 2000 * \endvar diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp index 81d5373..6b30ed7 100644 --- a/src/frontends/qt4/GuiApplication.cpp +++ b/src/frontends/qt4/GuiApplication.cpp @@ -1736,7 +1736,8 @@ void GuiApplication::dispatch(FuncRequest const & cmd, DispatchResult & dr) case LFUN_SET_COLOR: { string lyx_name; - string const x11_name = split(to_utf8(cmd.argument()), lyx_name, ' '); + // *r*split because lyx_name (e.g. branch name) might have spaces + string const x11_name = rsplit(to_utf8(cmd.argument()), lyx_name, ' '); if (lyx_name.empty() || x11_name.empty()) { if (current_view_) current_view_->message( -- 2.7.4 signature.asc Description: PGP signature
Re: LyX docs: cleaning up math options
On Fri, Oct 14, 2016 at 03:36:11PM +, Guenter Milde wrote: > For the end-user the difference is: > > * with "no", there is a safeguard against relying on additional packages > without real need -> less dependencies when compiling the docs. Wouldn't this be a LyX bug if we rely on an unneededed depencency? To be clear, I believe Jean-Pierre and I were on the same page of porposing that the options be changed to "Load automatically". We are not proposing "Load always". Scott signature.asc Description: PGP signature
Re: Git command for fetching the current master
On 10/14/2016 10:01 AM, racoon wrote: > On 14.10.2016 15:50, Scott Kostyshak wrote: >> On Fri, Oct 14, 2016 at 02:10:18PM +0200, racoon wrote: >>> Thanks. Unfortunately, the final step "git pull" gives me this: >>> >>> There is no tracking information for the current branch. >>> Please specify which branch you want to merge with. >>> See git-pull(1) for details. >>> >>> git pull >>> >>> If you wish to set tracking information for this branch you can do >>> so with: >>> >>> git branch --set-upstream-to=origin/ master >> >> Try the following command: >> >> git branch --set-upstream-to=origin/master master >> >> The command says that your local master branch should be linked to the >> remote's master branch. That way when you do a git pull it will update. > > Thanks. That worked. I recommend pulling with git pull --rebase This will avoid stupid merge commits by rebasing your current work on top of whatever is getting pulled in from upstream. Richard
Re: LyX docs: cleaning up math options
On 2016-10-13, Uwe Stöhr wrote: > Am 07.10.2016 um 19:01 schrieb Scott Kostyshak: Dear Uwe, >> My proposal is to change everything in all .lyx files to "Automatic". >> Then run the ctests to see which exports start failing and revert the >> changes to those corresponding documents. > OK, if all test are passed, we don't risk anything. the question is > however, if this is really necessary. Setting a package to no or to > automatic does not change anything since if it works when setting to no, > it will also not be used wit automatic. So what is the benefit for the > user, what for LyX and what for us documentation people? For the documentation people, the difference is: * with "no", inserting any character from a package that is (currently) blocked will lead to a compilation error. It is up to the editor or maintainer to decide whether to go without this character or change the package-loading setting. * with "automatic", you can use characters requiring any of the supported packages without further discussion or decision. For the end-user the difference is: * with "no", there is a safeguard against relying on additional packages without real need -> less dependencies when compiling the docs. It is up to you to decide which is the more important. Günter
Re: LyX 2.2.2 Tarballs
On 13.10.2016 10:46, Guillaume Munch wrote: Le 12/10/2016 à 20:02, racoon a écrit : On 10.10.2016 17:49, Richard Heck wrote: Here: ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/2.2.2/ Please prepare binaries. I am on 2.2.2 now. There is something strange happening when I *replace* stuff from the beginning of a paragraph before a space by pasting some inset, e.g. note, label, citation, etc. It removes the following space. Maybe someone can test it on 2.2.1 whether this is a new or old bug. Details: Steps to reproduce: 1. Start a new paragraph write two (or three or four or ...) words (separated by a space) 2. Select the first (or first two or first three or ...) word(s) and insert a label (or a citation or paste a note or ...) Actual result: - The space between the words vanishes Expected result: - It does not I can reproduce with 2.1.5. I think this is an old bug. It actually affects not only insets but any kind of pasting operation, including text. Quite nasty bug I think. I can try to have a look at it but it probably concerns areas I haven't looked at before. Daniel
Re: modules multiple columns not support arabic
On Fri, Oct 14, 2016 at 03:20:07AM +0200, Uwe Stöhr wrote: > Am 14.10.2016 um 00:43 schrieb Scott Kostyshak: > > > Does the attached .lyx file work for you? > > This fixes one of the 3 bugs we are facing here. But how did you manage to > get rid of \beginL? I deleted the number "4", then created an ERT and put "4" in the ERT, then I dissolved the ERT inset. > The point is that as user you just insert the number of columns but LyX does > not take the number as verbatim. > > I guess I only forgot to protect the inset as plain/verbatim in the modules > file. I will hae a look. OK. I didn't know it would be that simple. That's good news. Scott signature.asc Description: PGP signature
Re: LyX docs: cleaning up math options
On Fri, Oct 14, 2016 at 01:21:17AM +0200, Uwe Stöhr wrote: > Am 07.10.2016 um 19:01 schrieb Scott Kostyshak: > > OK, if all test are passed, we don't risk anything. the question is however, > if this is really necessary. Setting a package to no or to automatic does > not change anything since if it works when setting to no, it will also not > be used wit automatic. It is not a necessary change and I don't think the benefits would be enormous. I do think that the small benefits would outweigh the very small risks. > So what is the benefit for the user Users often use our examples and templates as the base of a new file. If they do this and then try to use a feature of a package that we have disabled, they will have problems and might not understand why. > what for LyX and what for us documentation people? For example, see the thread reported by Jean-Pierre here that was solved by fixing the math options: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196026.html Scott signature.asc Description: PGP signature
Re: [PATCH] Re: Return + Return in nested environments
On Fri, Oct 14, 2016 at 03:22:09PM +0200, Jean-Marc Lasgouttes wrote: > Le 07/10/2016 à 03:48, Scott Kostyshak a écrit : > > > I don't know much about layout nesting, but my first reaction is that I > > > agree with you regarding the expected behavior. > > > > Did we figure out what the correct behavior for this is? > > Please try that and tell me whether it works for you. Tested and I think there is a minor issue. In the attached .lyx file, put the cursor at the end of "hello". Press return three times. The first two times show that the issue initially reported is fixed (because it is itemize instead of ennumerate), but the third return is unexpected for me. I expected it to go out of itemize, but instead it created an item with a separator. Can you reproduce the above with your patch? Scott #LyX 2.2 created this file. For more info see http://www.lyx.org/ \lyxformat 508 \begin_document \begin_header \save_transient_properties true \origin unavailable \textclass article \use_default_options true \maintain_unincluded_children false \language english \language_package default \inputencoding auto \fontencoding global \font_roman "default" "default" \font_sans "default" "default" \font_typewriter "default" "default" \font_math "auto" "auto" \font_default_family default \use_non_tex_fonts false \font_sc false \font_osf false \font_sf_scale 100 100 \font_tt_scale 100 100 \graphics default \default_output_format default \output_sync 0 \bibtex_command default \index_command default \paperfontsize default \use_hyperref false \papersize default \use_geometry false \use_package amsmath 1 \use_package amssymb 1 \use_package cancel 1 \use_package esint 1 \use_package mathdots 1 \use_package mathtools 1 \use_package mhchem 1 \use_package stackrel 1 \use_package stmaryrd 1 \use_package undertilde 1 \cite_engine basic \cite_engine_type default \biblio_style plain \use_bibtopic false \use_indices false \paperorientation portrait \suppress_date false \justification true \use_refstyle 1 \index Index \shortcut idx \color #008000 \end_index \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \paragraph_indentation default \quotes_language english \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes false \output_changes false \html_math_output 0 \html_css_as_file 0 \html_be_strict false \end_header \begin_body \begin_layout Itemize one \end_layout \begin_deeper \begin_layout Enumerate hello \end_layout \end_deeper \end_body \end_document signature.asc Description: PGP signature
Re: LyXVC::registrer ???
On Fri, Oct 14, 2016 at 04:37:21PM +0200, Jean-Marc Lasgouttes wrote: > Le 14/10/2016 à 15:57, Scott Kostyshak a écrit : > > On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote: > > > Am I right that it should be "register" instead? > > > > Yes. > > Amusingly, `register' is a reserved word in C++ (even though it is > deprecated). > > Any idea of what I could use instead? Or I can just keep registrer (which > is not worse than `collapsable', after all). Here are a few ideas: - track - index ('man git add' makes me think we could use the word "index" as a verb meaning to add the file to the VC index) - record - enter (into the VC index) - catalog Scott signature.asc Description: PGP signature
Re: LyXVC::registrer ???
Le 14/10/2016 à 15:57, Scott Kostyshak a écrit : On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote: Am I right that it should be "register" instead? Yes. Amusingly, `register' is a reserved word in C++ (even though it is deprecated). Any idea of what I could use instead? Or I can just keep registrer (which is not worse than `collapsable', after all). JMarc
Re: LyXVC::registrer ???
Le 14/10/2016 à 15:57, Scott Kostyshak a écrit : On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote: Am I right that it should be "register" instead? Yes. Note here and in the future though that I only have knowledge of English (USA). Google tends to think that this is Norwegian (ar least booking.com tends to think so). JMarc
Re: Git command for fetching the current master
On 14.10.2016 15:50, Scott Kostyshak wrote: On Fri, Oct 14, 2016 at 02:10:18PM +0200, racoon wrote: Thanks. Unfortunately, the final step "git pull" gives me this: There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/ master Try the following command: git branch --set-upstream-to=origin/master master The command says that your local master branch should be linked to the remote's master branch. That way when you do a git pull it will update. Thanks. That worked. Daniel
Re: LyXVC::registrer ???
On Fri, Oct 14, 2016 at 03:15:29PM +0200, Jean-Marc Lasgouttes wrote: > Am I right that it should be "register" instead? Yes. Note here and in the future though that I only have knowledge of English (USA). Scott signature.asc Description: PGP signature
Re: Git command for fetching the current master
On Fri, Oct 14, 2016 at 02:10:18PM +0200, racoon wrote: > Thanks. Unfortunately, the final step "git pull" gives me this: > > There is no tracking information for the current branch. > Please specify which branch you want to merge with. > See git-pull(1) for details. > > git pull > > If you wish to set tracking information for this branch you can do so with: > > git branch --set-upstream-to=origin/ master Try the following command: git branch --set-upstream-to=origin/master master The command says that your local master branch should be linked to the remote's master branch. That way when you do a git pull it will update. Scott signature.asc Description: PGP signature
[PATCH] Re: Return + Return in nested environments
Le 07/10/2016 à 03:48, Scott Kostyshak a écrit : I don't know much about layout nesting, but my first reaction is that I agree with you regarding the expected behavior. Did we figure out what the correct behavior for this is? Please try that and tell me whether it works for you. JMarc >From 43658068801ad9772728973103414e81373e5a75 Mon Sep 17 00:00:00 2001 From: Jean-Marc LasgouttesDate: Thu, 13 Oct 2016 20:33:57 +0200 Subject: [PATCH] When breaking an empty paragraph reduces depth, set layout too --- src/Text.cpp | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/Text.cpp b/src/Text.cpp index 007271d..16bf899 100644 --- a/src/Text.cpp +++ b/src/Text.cpp @@ -738,9 +738,13 @@ void Text::breakParagraph(Cursor & cur, bool inverse_logic) Layout const & layout = cpar.layout(); if (cur.lastpos() == 0 && !cpar.allowEmpty()) { - if (changeDepthAllowed(cur, DEC_DEPTH)) + if (changeDepthAllowed(cur, DEC_DEPTH)) { changeDepth(cur, DEC_DEPTH); - else { + pit_type const prev = depthHook(cpit, cpar.getDepth()); + docstring const & lay = pars_[prev].layout().name(); + if (lay != layout.name()) +setLayout(cur, lay); + } else { docstring const & lay = cur.paragraph().usePlainLayout() ? tclass.plainLayoutName() : tclass.defaultLayoutName(); if (lay != layout.name()) -- 2.7.4
LyXVC::registrer ???
Am I right that it should be "register" instead? JMarc
Re: Git command for fetching the current master
Thanks. Unfortunately, the final step "git pull" gives me this: There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/ master Daniel On 14.10.2016 14:05, Joel Kulesza wrote: I'm not part of the development team; however, my thoughts: Command-line wise from the LyX directory, check your settings to make sure they are to the right place with with git remote -v Once satisfied (and with any of your changes stashed or committed), try git checkout master git fetch git merge -or- git checkout master git pull - Joel On Fri, Oct 14, 2016 at 3:47 AM, racoon> wrote: Hi, How do I update my local copy to the current master? In git gui I tried Fetch from > origin But this seems not to work. I can now type any git command line commands using Repository > Git Bash So I am even happy about command line commands on how to update to the current master. Daniel
Re: Git command for fetching the current master
I'm not part of the development team; however, my thoughts: Command-line wise from the LyX directory, check your settings to make sure they are to the right place with with git remote -v Once satisfied (and with any of your changes stashed or committed), try git checkout master git fetch git merge -or- git checkout master git pull - Joel On Fri, Oct 14, 2016 at 3:47 AM, racoonwrote: > Hi, > > How do I update my local copy to the current master? > > In git gui I tried > > Fetch from > origin > > But this seems not to work. I can now type any git command line commands > using > > Repository > Git Bash > > So I am even happy about command line commands on how to update to the > current master. > > Daniel > >
Git command for fetching the current master
Hi, How do I update my local copy to the current master? In git gui I tried Fetch from > origin But this seems not to work. I can now type any git command line commands using Repository > Git Bash So I am even happy about command line commands on how to update to the current master. Daniel
Re: Creating new files
On 13.10.2016 22:28, Kornel Benko wrote: Am Donnerstag, 13. Oktober 2016 um 15:22:30, schrieb Richard HeckOn 10/13/2016 03:17 PM, racoon wrote: On 13.10.2016 21:13, Richard Heck wrote: On 10/13/2016 02:31 PM, racoon wrote: Hi, I think I could solve http://www.lyx.org/trac/ticket/10239 http://www.lyx.org/trac/ticket/9982 The idea is to create a new statistics dialog. I think I can just take over the code from the About dialog, i.e. create .cpp, .h, and .ui files accordingly. However, I have never created new files in the LyX project - only changed existing files. Can someone tell me how to go about? I tried to just copy existing files and then renamed them. But Visual Studio does not find those files in the Project Explorer. Or creating new files actually quite tricky and as a beginner I'd rather keep my hands off of this? You'll have to update src/frontends/qt4/Makefile.am to add the new files. I assume cmake then knows about them, too, but someone else will know better. Thanks. So after updating these files I will have to run cmake then again, right? Not after 'updating'. But after creating, yes. We (in cmake build) still use globbing in configure stage to create makefiles (or project files). For me as a beginner it sounds pretty much like: better keep your hands off. (I have not even understood what globbing is.) All right there are other things to do I guess. Daniel
reducing file size of images shipped within LyX
These are really low hanging fruit: Image files are suboptimally compressed. Using both (just examples, there may be better ways or programs) imgopt https://github.com/kormoc/imgopt for raster images and SVG-Cleaner https://sourceforge.net/projects/svgcleaner/ for the vector images I get the following results: Raster: processed 269 files saving 277087 bytes ( 24% ) in about a minute Vector: processed 1435 files saving 2.2 MB ( 56% ) in about 20 seconds Results from a fresh download of 2.2.2 mac. If someone could just once recompress those files in the devel-tree the benefits should propagate from there. greetings Mike
Re: LyX 2.2.2 Tarballs
On 14.10.2016 00:43, Uwe Stöhr wrote: Am 11.10.2016 um 00:50 schrieb racoon: Which Qt version will be used for LyX 2.2.2? Qt 5.6.2 is around the corner (possibly next week). Any chance on a binary with that version? I am so annoyed by the menus (http://www.lyx.org/trac/ticket/10017). And the fix for it is in 5.6.2. I just uploaded a new installer version for 2.2. that uses - Qt 5.6.2 - Perl 5.22.2 - latest updates of MSVC 2015 http://ftp.lyx.de/LyX%202.2.2/LyX-222-Installer-2.exe Could you please give it a try and report if this fixes http://www.lyx.org/trac/ticket/10017 Awesome. Yes, now I can actually open menus with the primary mouse button and open more than one sub menu. Thanks a lot Uwe! Daniel