Re: Windows Cmake build
Am 24.06.2019 um 09:04 schrieb Jürgen Womser-Schütz: > Am 22.06.2019 um 15:47 schrieb José Abílio Matos: >> On Friday, 21 June 2019 14.41.40 WEST Jürgen Womser-Schütz wrote: >>> For me the Cmake build (Win 10) isn't working anymore: Python3 is not >>> found but is is installed and in the path. >>> >>> After successful compilation und running LyX I get on the LyX-console >>> the message: >>> >>> Looking for python 3.x ... >>> Examining C:/Program Files (x86)/Python37//python3.exe >>> Looking for python 2.x ... >>> Warning: No python v2.x or 3.x binary found. >>> >>> It seems to me that the reason is in the function "python23_call()", >>> module "os.cpp", in which a batch command-line is generated. >>> The command-line is the concatenation of the string "python3" and a >>> string "version_info", yielding: >>> >>> python3 -c 'from __future__ import print_function;import sys; >>> print(sys.version_info[:2], end=\"\")' >>> >>> This command worked in PowerShell (on my system the result was (3,7)), >>> but not for the command console "cmd" (I got a syntax error). >>> For "cmd" I need to substitute the characters ' by the characters ". >>> >>> The problem for me is to change this for Windows and not to destroy LyX >>> for other operation systems >> OK. Let us try to find a solution that works in all environments. :-) >> >> python3 -c "from __future__ import print_function;import sys; >> print(sys.version_info[:2], end=\"\")" >> >> From the original case I have replaced the outer single quotes by double >> quotes. >> >> This works in bash on linux but fails on csh (C shell - actually tc shell). >> >> An equivalente versions is: >> python3 -c "from __future__ import print_function;import sys; >> print(sys.version_info[:2], end='')" >> >> The inner escaped double quotes were transformed in single quotes. This now >> works for bash and csh. >> >> Does this version works for cmd and PowerShell on windows? >> >> Best regards, > You are right! Your version > > python3 -c "from __future__ import print_function;import sys; > print(sys.version_info[:2], end='')" > > works for me. > > Best regards and thanks for the help > Jürgen (JWS) > By the way: file "development/cmake/ConfigureChecks.cmake", line 278 produces a warning in CMake. I would recommend to change it to: set(QT_USES_X11 CACHE "Win32 compiled without X11" STRING 0) Jürgen (JWS)
Re: Windows Cmake build
Am 22.06.2019 um 15:47 schrieb José Abílio Matos: > On Friday, 21 June 2019 14.41.40 WEST Jürgen Womser-Schütz wrote: >> For me the Cmake build (Win 10) isn't working anymore: Python3 is not >> found but is is installed and in the path. >> >> After successful compilation und running LyX I get on the LyX-console >> the message: >> >> Looking for python 3.x ... >> Examining C:/Program Files (x86)/Python37//python3.exe >> Looking for python 2.x ... >> Warning: No python v2.x or 3.x binary found. >> >> It seems to me that the reason is in the function "python23_call()", >> module "os.cpp", in which a batch command-line is generated. >> The command-line is the concatenation of the string "python3" and a >> string "version_info", yielding: >> >> python3 -c 'from __future__ import print_function;import sys; >> print(sys.version_info[:2], end=\"\")' >> >> This command worked in PowerShell (on my system the result was (3,7)), >> but not for the command console "cmd" (I got a syntax error). >> For "cmd" I need to substitute the characters ' by the characters ". >> >> The problem for me is to change this for Windows and not to destroy LyX >> for other operation systems > OK. Let us try to find a solution that works in all environments. :-) > > python3 -c "from __future__ import print_function;import sys; > print(sys.version_info[:2], end=\"\")" > > From the original case I have replaced the outer single quotes by double > quotes. > > This works in bash on linux but fails on csh (C shell - actually tc shell). > > An equivalente versions is: > python3 -c "from __future__ import print_function;import sys; > print(sys.version_info[:2], end='')" > > The inner escaped double quotes were transformed in single quotes. This now > works for bash and csh. > > Does this version works for cmd and PowerShell on windows? > > Best regards, You are right! Your version python3 -c "from __future__ import print_function;import sys; print(sys.version_info[:2], end='')" works for me. Best regards and thanks for the help Jürgen (JWS)
Re: Windows Cmake build
Am 22.06.2019 um 15:47 schrieb José Abílio Matos: > On Friday, 21 June 2019 14.41.40 WEST Jürgen Womser-Schütz wrote: >> For me the Cmake build (Win 10) isn't working anymore: Python3 is not >> found but is is installed and in the path. >> >> After successful compilation und running LyX I get on the LyX-console >> the message: >> >> Looking for python 3.x ... >> Examining C:/Program Files (x86)/Python37//python3.exe >> Looking for python 2.x ... >> Warning: No python v2.x or 3.x binary found. >> >> It seems to me that the reason is in the function "python23_call()", >> module "os.cpp", in which a batch command-line is generated. >> The command-line is the concatenation of the string "python3" and a >> string "version_info", yielding: >> >> python3 -c 'from __future__ import print_function;import sys; >> print(sys.version_info[:2], end=\"\")' >> >> This command worked in PowerShell (on my system the result was (3,7)), >> but not for the command console "cmd" (I got a syntax error). >> For "cmd" I need to substitute the characters ' by the characters ". >> >> The problem for me is to change this for Windows and not to destroy LyX >> for other operation systems > OK. Let us try to find a solution that works in all environments. :-) > > python3 -c "from __future__ import print_function;import sys; > print(sys.version_info[:2], end=\"\")" > > From the original case I have replaced the outer single quotes by double > quotes. > > This works in bash on linux but fails on csh (C shell - actually tc shell). > > An equivalente versions is: > python3 -c "from __future__ import print_function;import sys; > print(sys.version_info[:2], end='')" > > The inner escaped double quotes were transformed in single quotes. This now > works for bash and csh. > > Does this version works for cmd and PowerShell on windows? > > Best regards, I tried this already without success. I am just looking for a solution and will tell if I am successful. Jürgen (JWS)
Windows Cmake build
For me the Cmake build (Win 10) isn't working anymore: Python3 is not found but is is installed and in the path. After successful compilation und running LyX I get on the LyX-console the message: Looking for python 3.x ... Examining C:/Program Files (x86)/Python37//python3.exe Looking for python 2.x ... Warning: No python v2.x or 3.x binary found. It seems to me that the reason is in the function "python23_call()", module "os.cpp", in which a batch command-line is generated. The command-line is the concatenation of the string "python3" and a string "version_info", yielding: python3 -c 'from __future__ import print_function;import sys; print(sys.version_info[:2], end=\"\")' This command worked in PowerShell (on my system the result was (3,7)), but not for the command console "cmd" (I got a syntax error). For "cmd" I need to substitute the characters ' by the characters ". The problem for me is to change this for Windows and not to destroy LyX for other operation systems :-)
Re: Windows Binaries
Am 20.06.2019 um 12:07 schrieb Jürgen Spitzmüller: > Am Donnerstag, den 20.06.2019, 12:03 +0200 schrieb Jürgen Womser- > Schütz: >> I just recognized a vey, very serious problem at least in the Windows >> build :-) :-) :-) >> The credits-entry for me is missing. > The explanation is probably that your contributions are only in the 2.4 > line, not (yet) 2.3.x. > > Jürgen That is right. Sorry. Jürgen (JWS)
Re: Windows Binaries
Am 20.06.2019 um 10:27 schrieb Jean-Marc Lasgouttes: > Le 20/06/2019 à 10:03, Daniel a écrit : >> I did a quick test. Installs and runs on Windows 10 with MiKTeX. Most >> importantly, I noticed no slowdown. However, it reset my toolbar >> stated (e.g. position and movability) which are saved in the >> registry. This problem might have been there in earlier upgrades but >> I am not sure. I tried to reproduce by re-installing but didn't >> succeed. Maybe I would have to first downgrade to 2.3.2 and then >> upgrade to 2.3.3 again? > > Yes, it is a "feature" when some of the layout files have changed. I > think this should be revisited eventually. > > JMarc I just recognized a vey, very serious problem at least in the Windows build :-) :-) :-) The credits-entry for me is missing. Jürgen (JWS)
Re: Windows Binaries
Am 19.06.2019 um 16:41 schrieb Richard Kimberly Heck: > ...are at ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ for testing. Please > let me know if they are OK. I'll be travelling tomorrow, but will do the > release over the weekend. > > Riki > > Works for me. I exported successful the tutorial and the user manual. Jürgen (JWS)
Windows build
I have no idea wether this is a general problem or not, but commit "adb779a692f29f391cf5" did'nt translate for my Windows 10 VS2017. The C alternative tokens "and" and "or", should be a standard part of C++ but VS2017 require to include "" or "iso646.h". Including this header is also fine for the Linux-build process, as I tested. Jürgen (JWS)
Re: Towards 2.4.0: required gcc version
... and for example test the regx-functionality. Jürgen (JWS) Am 07.06.2019 um 15:10 schrieb Jürgen Womser-Schütz: > Maybe I can help a little bit. On my Windows 10 system I can build LyX > with Visual Studio 2017. > > Jürgen (JWS) >
Re: Towards 2.4.0: required gcc version
Maybe I can help a little bit. On my Windows 10 system I can build LyX with Visual Studio 2017. Jürgen (JWS)
Broken preview
Python file "lyxpreview2bitmap.py" isn't correct: it seems for me that near line 381 the statement " import lyxpreview_tools" is missing. Jürgen
Broken build
For me the LyX build is broken:
CXX Cursor.o
Cursor.cpp: In member function ‘bool lyx::Cursor::macroModeClose(bool)’:
Cursor.cpp:1765:53: error: expected ‘)’ before ‘{’ token
if (!selection.empty() && data && data->numargs() {
^
Cursor.cpp:1770:76: warning: suggest braces around empty body in an ‘if’
statement [-Wempty-body]
atomAsMacro->setDisplayMode(InsetMathMacro::DISPLAY_INTERACTIVE_INIT, 0);
Jürgen (JWS)
Re: about the Win installer
Am 03.04.2019 um 16:57 schrieb Daniel: > On 03/04/2019 15:05, Jürgen Womser-Schütz wrote: >> MikTex itself provides a nice description for the installing procedure >> on Windows: https://miktex.org/howto/install-miktex >> LyX-users should take account of only one setting: "Install missing >> packages on-the-fly" should be set to "Always". > > Why is that setting recommended? I am using MiKTeX with the default > Ask me first setting and LyX seems to work fine with it so far. > > Daniel > In the past I made the experience that MikTex works very good with "Always" and you learned that it works fine too with "Ask me first". If we put our observations together we can subsum: "Install missing packages on-the-fly" probable doesn't matter for LyX purpose. All the best. Jürgen
Re: about the Win installer
> Richard Kimberly Heck Tue, 02 Apr 2019 10:02:05 -0700 > >On 4/2/19 11:05 AM, Jean-Marc Lasgouttes wrote: >> Le 02/04/2019 à 16:53, Richard Kimberly Heck a écrit : A solution would be to point people to a nicely crafted page explaining what needs to be installed and what the choices are. >>> >>> You mean like this? >>> >>> https://wiki.lyx.org/Windows/TeXLive >> >> Yes :) I admit I did not know it. Does the installer point to it? >> Could it? > > >We point to it from the download page. I would guess it would also be >done in the installer. > > >> >>> We could have another for MiKTeX. >> >> Or a not too long and intimidating page that explains why one needs >> LaTeX and which distribution to use depending on uses. This page could >> point to two a bit more technical pages describing each installer. >> >> An executive summary (aka TL;DR) at the beginning could be useful for >> users for short attention span concerning computer technicalities. > >You think we can rustle up a volunteer? > >Riki MikTex itself provides a nice description for the installing procedure on Windows: https://miktex.org/howto/install-miktex LyX-users should take account of only one setting: "Install missing packages on-the-fly" should be set to "Always". Regards Jürgen
Re: about the Win installer
I am a newbie in this discussion. But what's about the idea to build a windows installer which gives the user the possibility to choose between MikTex and TexLive? I am not sure to be right, but both seems to be functional (after the MikTex problems are now solved)? Maybe this would be the best for windows LyX users??? Best regards Jürgen
Re: Toward LyX 2.3.3
Am 20.03.2019 um 02:21 schrieb Richard Kimberly Heck: > On 3/19/19 4:32 PM, Jürgen Womser-Schütz wrote: >> Am 19.03.2019 um 20:05 schrieb Scott Kostyshak: >>> On Tue, Mar 19, 2019 at 01:57:03PM -0400, Richard Kimberly Heck wrote: >>>> We're about three months past 2.3.2, so time to start thinking about the >>>> next release. We have collected a decent number of fixes since then >>>> (though it seems a lot of us have been pretty busy). Are there any >>>> must-haves for 2.3.3? >>> Not a must-have (e.g., not a regression), but I wonder if we should >>> consider putting in the patch that you proposed for >>> >>> https://www.lyx.org/trac/ticket/10091 >>> >>> That ticket seems to affect a lot of people. From what I understand, no >>> one has tested the patch. We could include it and make a test Windows >>> installer and ask for testers. I think I remember you saying that you >>> wanted to make a test installer anyways (but this is a very vague memory >>> so perhaps I just made that up). In any case, this would be even more >>> work for you, Riki, so if your plate is full then I'm fine with just >>> skipping this. >>> >>> Scott >> I am using Lyx 2.3.2-2/Win10 but I am not using Dropbox at the moment. >> If it is helpful I could try to reproduce this error with a Dropbox >> Basic account. >> And supposed I am successful with this I could also try a LyX >> test-version with your patch. > Yes, that would be very, very helpful. > > I do have access to a Windows installation and so could test to confirm > if it works, but I don't know enough to be confident doing this on my own. > > Riki I have to beg for apologies :-( By testing LyX on my old Win7 system I found out: it works fine. After uninstalling and reinstalling LyX on my Win10 machine I can say: it works fine too. Also no problems with my Dropbox drive. Sorry. Jürgen
Re: Toward LyX 2.3.3
Am 20.03.2019 um 02:21 schrieb Richard Kimberly Heck:
> On 3/19/19 4:32 PM, Jürgen Womser-Schütz wrote:
>> Am 19.03.2019 um 20:05 schrieb Scott Kostyshak:
>>> On Tue, Mar 19, 2019 at 01:57:03PM -0400, Richard Kimberly Heck wrote:
>>>> We're about three months past 2.3.2, so time to start thinking about the
>>>> next release. We have collected a decent number of fixes since then
>>>> (though it seems a lot of us have been pretty busy). Are there any
>>>> must-haves for 2.3.3?
>>> Not a must-have (e.g., not a regression), but I wonder if we should
>>> consider putting in the patch that you proposed for
>>>
>>> https://www.lyx.org/trac/ticket/10091
>>>
>>> That ticket seems to affect a lot of people. From what I understand, no
>>> one has tested the patch. We could include it and make a test Windows
>>> installer and ask for testers. I think I remember you saying that you
>>> wanted to make a test installer anyways (but this is a very vague memory
>>> so perhaps I just made that up). In any case, this would be even more
>>> work for you, Riki, so if your plate is full then I'm fine with just
>>> skipping this.
>>>
>>> Scott
>> I am using Lyx 2.3.2-2/Win10 but I am not using Dropbox at the moment.
>> If it is helpful I could try to reproduce this error with a Dropbox
>> Basic account.
>> And supposed I am successful with this I could also try a LyX
>> test-version with your patch.
> Yes, that would be very, very helpful.
>
> I do have access to a Windows installation and so could test to confirm
> if it works, but I don't know enough to be confident doing this on my own.
>
> Riki
Hi,
this is the 2. try to send this Mail. The 1. seemed not to be transmitted.
Now I drop the attachements (1.3MB screenshots). May be it is working now.
Jürgen (JWS)
Hi all,
I tried out saving a large LyX-file (UsersGuide.lyx) in my just created
Dropbox folder but I could not reproduce the issues from ticket 10091.
Instead I got 3 different kind of reproduceable issues:
1. A segment violation (see attached LyX-Dropbox-Save-Error-2.JPG).
2. An software assertion "Buffer-error" (see
LyX-Dropbox-Save-Error-3.JPG).
The assertion seems to be thrown in the following function (in
Line 3606):
Inset const & Paragraph::inInset() const
{
LBUFERR(d->inset_owner_); // Line 3606
return *d->inset_owner_;
}
3. Furthermore I got a reproduceable segment violation by saving the
file onto my fixed disk (see LyX-Dropbox-Save-Error-4.JPG).
In this case the temporarily file "UserGuide-x.lyx" was
successful written as you can see in the bottom LyX status line.
As mentioned I use a LyX 2.3.2-2/Win10-64Bit system.
What is the next step for solving the issue(s)above?
I see 2 possibilities:
1. I try to build LyX on my system and hopefully I can debug and fix it.
2. I can try a Test-Installer for Windows with Rikis
"0001-Fix-bug-10091.patch" includet.
Disadvantage for point 1: It would take a very long time because I am
not familiar with the LyX buildsystem (neither Win nor Linux).
Disadvantage for point 2: Someone (Riki?) has to build an Windows
installer and maybe the problem still stayed.
What do you think? I am happy with both possibilities.
Another problem for me is: for testing on my Linux-system I did the
following steps:
checkout 2.3.2
make clean
sh autogen.sh
./configure
But the ./configure-step stopped with
"configure: error: cannot compile a simple Qt executable. Check you
have the right $QTDIR."
Maybe I forgot a step? Do you have any suggestion for me?
Jürgen (JWS)
Re: Toward LyX 2.3.3
Am 19.03.2019 um 20:05 schrieb Scott Kostyshak: > On Tue, Mar 19, 2019 at 01:57:03PM -0400, Richard Kimberly Heck wrote: >> We're about three months past 2.3.2, so time to start thinking about the >> next release. We have collected a decent number of fixes since then >> (though it seems a lot of us have been pretty busy). Are there any >> must-haves for 2.3.3? > Not a must-have (e.g., not a regression), but I wonder if we should > consider putting in the patch that you proposed for > > https://www.lyx.org/trac/ticket/10091 > > That ticket seems to affect a lot of people. From what I understand, no > one has tested the patch. We could include it and make a test Windows > installer and ask for testers. I think I remember you saying that you > wanted to make a test installer anyways (but this is a very vague memory > so perhaps I just made that up). In any case, this would be even more > work for you, Riki, so if your plate is full then I'm fine with just > skipping this. > > Scott I am using Lyx 2.3.2-2/Win10 but I am not using Dropbox at the moment. If it is helpful I could try to reproduce this error with a Dropbox Basic account. And supposed I am successful with this I could also try a LyX test-version with your patch. Jürgen
Re: Bug #11484
Hello Jürgen, I think it is now much better than I could do it without your help. But I am still learning :-) Another thing: In the case of include type "Input" or "Include" only LyX or LaTeX-files are meaningful. I wasn't aware this fact during my tests and so I got conversion errors because I was using a c-file instead of *.lyx/*.tex. I know in Linux istn't a strong binding between content and fileextension usual. But do you think the dialog should give users a hint not to select a unappropriate file? If "Yes" i could try to improve this. Jürgen (JWS) Am 11.03.2019 um 13:11 schrieb Jürgen Spitzmüller: > Am Mo., 11. März 2019 um 08:40 Uhr schrieb Jürgen Spitzmüller > > Some more comments: > > > The attached patch includes my suggestions (incl. the ltrimming of > the file name). > > What do you think, Jürgen? > > Jürgen > (not talking to himself) >
Re: Bug #11484
Hi,
Jürgen's improvements for "GNU Gettext" are now includet.
I looked into the documentation (chapter "Child Documents" in the
"Embedded Objects" helpfile ): a change seems to me not really necessary.
Maybe it is self explanatory enough.
Jürgen
Am 10.03.2019 um 19:17 schrieb Jürgen Spitzmüller:
> Am Sonntag, den 10.03.2019, 19:08 +0100 schrieb Jürgen Womser-Schütz:
>> Ahh, I see: _() is the C++ user defined flag for enabling the
>> translation machinery! I couldn't find the definition :-(
> src/support/getttext.h
>
> Jürgen
diff --git a/src/insets/InsetInclude.cpp b/src/insets/InsetInclude.cpp
old mode 100644
new mode 100755
index 51cc147333..f77dad2b03
--- a/src/insets/InsetInclude.cpp
+++ b/src/insets/InsetInclude.cpp
@@ -55,6 +55,7 @@
#include "support/convert.h"
#include "support/debug.h"
#include "support/docstream.h"
+#include "support/FileName.h"
#include "support/FileNameList.h"
#include "support/filetools.h"
#include "support/gettext.h"
@@ -188,7 +189,7 @@ char_type replaceCommaInBraces(docstring & params)
InsetInclude::InsetInclude(Buffer * buf, InsetCommandParams const & p)
: InsetCommand(buf, p), include_label(uniqueID()),
preview_(make_unique(this)),
failedtoload_(false),
- set_label_(false), label_(0), child_buffer_(0)
+ set_label_(false), label_(0), child_buffer_(0), file_exist_(false)
{
preview_->connect([=](){ fileChanged(); });
@@ -203,7 +204,7 @@ InsetInclude::InsetInclude(Buffer * buf, InsetCommandParams
const & p)
InsetInclude::InsetInclude(InsetInclude const & other)
: InsetCommand(other), include_label(other.include_label),
preview_(make_unique(this)),
failedtoload_(false),
- set_label_(false), label_(0), child_buffer_(0)
+ set_label_(false), label_(0), child_buffer_(0),
file_exist_(other.file_exist_)
{
preview_->connect([=](){ fileChanged(); });
@@ -391,6 +392,8 @@ bool InsetInclude::isChildIncluded() const
docstring InsetInclude::screenLabel() const
{
+ docstring pre = file_exist_ ? docstring() : _("FILE MISSING:");
+
docstring temp;
switch (type(params())) {
@@ -418,13 +421,9 @@ docstring InsetInclude::screenLabel() const
}
temp += ": ";
+ temp += from_utf8(onlyFileName(to_utf8(params()["filename"])));
- if (params()["filename"].empty())
- temp += "???";
- else
- temp += from_utf8(onlyFileName(to_utf8(params()["filename"])));
-
- return temp;
+ return pre.empty() ? temp : pre + from_ascii(" ") + temp;
}
@@ -513,8 +512,8 @@ void InsetInclude::latex(otexstream & os, OutputParams
const & runparams) const
{
string incfile = to_utf8(params()["filename"]);
- // Do nothing if no file name has been specified
- if (incfile.empty())
+ // Do nothing if file doesn't exist
+ if (!listingFileExist())
return;
FileName const included_file = includedFileName(buffer(), params());
@@ -1330,6 +1329,8 @@ void InsetInclude::updateCommand()
void InsetInclude::updateBuffer(ParIterator const & it, UpdateType utype)
{
+ file_exist_ = listingFileExist();
+
button_.update(screenLabel(), true, false);
Buffer const * const childbuffer = getChildBuffer();
@@ -1359,4 +1360,12 @@ void InsetInclude::updateBuffer(ParIterator const & it,
UpdateType utype)
}
+bool InsetInclude::listingFileExist() const
+{
+ // check whether the file of the listing exist
+ string listingFileName = to_utf8(params()["filename"]);
+ FileName fn = support::makeAbsPath(listingFileName,
support::onlyPath(buffer().absFileName()));
+ return fn.exists();
+}
+
} // namespace lyx
diff --git a/src/insets/InsetInclude.h b/src/insets/InsetInclude.h
old mode 100644
new mode 100755
index 9ecaf42e7e..65e2945c92
--- a/src/insets/InsetInclude.h
+++ b/src/insets/InsetInclude.h
@@ -137,6 +137,8 @@ private:
void editIncluded(std::string const & file);
///
bool isChildIncluded() const;
+ /// check whether the file of the listing exist
+ bool listingFileExist() const;
/// \name Private functions inherited from Inset class
//@{
@@ -170,6 +172,7 @@ private:
mutable docstring listings_label_;
InsetLabel * label_;
mutable Buffer * child_buffer_;
+ mutable bool file_exist_;
};
Re: Bug #11484
Am 10.03.2019 um 18:26 schrieb Jürgen Spitzmüller:
> Am Sonntag, den 10.03.2019, 17:38 +0100 schrieb Jürgen Womser-Schütz:
>> PS: If the small change is worth to merge in LyX: what is about the
>> translation of the new introduced string into all supported languages
> Our l7n machinery will catch this string and add it to the po files for
> translation. The translators will handle it.
>
> BTW I would do
>
> docstring pre = file_exist_ ? docstring() : _("FILE MISSING: ");
>
> (not flag the empty string as translatable) and maybe also handle the
> trailing space outside the translatable string, since this is prone to
> be missed by translators. I.e.,
>
> docstring pre = file_exist_ ? docstring() : _("FILE MISSING:");
>
> ...
>
> return pre.empty() ? temp : pre + from_ascii(" ") + temp;
>
>> and whats about the LyX documentation (also all languages)?
Ahh, I see: _() is the C++ user defined flag for enabling the
translation machinery! I couldn't find the definition :-(
> Is there something to document here?
I am not sure. Maybe not. I will have a look.
Jürgen
Re: Bug #11484
Hi,
I have a revised patch for the little problem of an possibly non
existing user-provided listing file in LyX child-document dialog.
Following JMarc's suggestion I am now altering the label-text of the
Include-inset by an additional string "FILE MISSING: " (of course only
if the file is missing!).
So the user sees immediately what is going on instead of getting later
an LaTex-error during conversation (for example in PDF).
Hth
Jürgen
PS: If the small change is worth to merge in LyX: what is about the
translation of the new introduced string into all supported languages
and whats about the LyX documentation (also all languages)?
Am 25.02.2019 um 18:33 schrieb Jean-Marc Lasgouttes:
> Le 22/02/2019 à 21:29, Jürgen Womser-Schütz a écrit :
>> Hi alltogether,
>>
>> I have a revised patch for the little problem of possibly non existing
>> user-provided listing file in LyX child-document dialog.
>> If the listing file don't exist, a warning QMessageBox is displayed:
>> "The listing file " FILENAME " does not exist. You will not be able
>> to export your LyX-file (LaTeX-errors)."
>> The diff-file is attached.
>
> Another possibility would be to change the label of the include inset
> to start with "INVALID" of something like that. This is already what
> we do with broken cross references. This would also appear in the
> outline and the user would see it immediately after clicking OK.
>
>> In my opinion the whole LyX child-document dialog needs a revision.
>> Im am not a user of this dialog at all but if I select instead of
>> "Program Listing" for example "Input" or "Include" I get errors.
>
> This is my problem too. I am a very light user of the dialog.
>
> JMarc
>
diff --git a/src/insets/InsetInclude.cpp b/src/insets/InsetInclude.cpp
old mode 100644
new mode 100755
index 51cc147333..a74a51600b
--- a/src/insets/InsetInclude.cpp
+++ b/src/insets/InsetInclude.cpp
@@ -55,6 +55,7 @@
#include "support/convert.h"
#include "support/debug.h"
#include "support/docstream.h"
+#include "support/FileName.h"
#include "support/FileNameList.h"
#include "support/filetools.h"
#include "support/gettext.h"
@@ -188,7 +189,7 @@ char_type replaceCommaInBraces(docstring & params)
InsetInclude::InsetInclude(Buffer * buf, InsetCommandParams const & p)
: InsetCommand(buf, p), include_label(uniqueID()),
preview_(make_unique(this)),
failedtoload_(false),
- set_label_(false), label_(0), child_buffer_(0)
+ set_label_(false), label_(0), child_buffer_(0), file_exist_(false)
{
preview_->connect([=](){ fileChanged(); });
@@ -203,7 +204,7 @@ InsetInclude::InsetInclude(Buffer * buf, InsetCommandParams
const & p)
InsetInclude::InsetInclude(InsetInclude const & other)
: InsetCommand(other), include_label(other.include_label),
preview_(make_unique(this)),
failedtoload_(false),
- set_label_(false), label_(0), child_buffer_(0)
+ set_label_(false), label_(0), child_buffer_(0),
file_exist_(other.file_exist_)
{
preview_->connect([=](){ fileChanged(); });
@@ -391,6 +392,8 @@ bool InsetInclude::isChildIncluded() const
docstring InsetInclude::screenLabel() const
{
+ docstring pre = file_exist_ ? _("") : _("FILE MISSING: ");
+
docstring temp;
switch (type(params())) {
@@ -418,13 +421,9 @@ docstring InsetInclude::screenLabel() const
}
temp += ": ";
+ temp += from_utf8(onlyFileName(to_utf8(params()["filename"])));
- if (params()["filename"].empty())
- temp += "???";
- else
- temp += from_utf8(onlyFileName(to_utf8(params()["filename"])));
-
- return temp;
+ return pre + temp;
}
@@ -513,8 +512,8 @@ void InsetInclude::latex(otexstream & os, OutputParams
const & runparams) const
{
string incfile = to_utf8(params()["filename"]);
- // Do nothing if no file name has been specified
- if (incfile.empty())
+ // Do nothing if file doesn't exist
+ if (!listingFileExist())
return;
FileName const included_file = includedFileName(buffer(), params());
@@ -1330,6 +1329,8 @@ void InsetInclude::updateCommand()
void InsetInclude::updateBuffer(ParIterator const & it, UpdateType utype)
{
+ file_exist_ = listingFileExist();
+
button_.update(screenLabel(), true, false);
Buffer const * const childbuffer = getChildBuffer();
@@ -1359,4 +1360,12 @@ void InsetInclude::updateBuffer(ParIterator const & it,
UpdateType utype)
}
+bool InsetInclude::listingFileExist() const
+{
+ // check whether the file o
Re: Bug #11484
Am 25.02.2019 um 18:33 schrieb Jean-Marc Lasgouttes: > Le 22/02/2019 à 21:29, Jürgen Womser-Schütz a écrit : >> Hi alltogether, >> >> I have a revised patch for the little problem of possibly non existing >> user-provided listing file in LyX child-document dialog. >> If the listing file don't exist, a warning QMessageBox is displayed: >> "The listing file " FILENAME " does not exist. You will not be able >> to export your LyX-file (LaTeX-errors)." >> The diff-file is attached. > > Another possibility would be to change the label of the include inset > to start with "INVALID" of something like that. This is already what > we do with broken cross references. This would also appear in the > outline and the user would see it immediately after clicking OK. > >> In my opinion the whole LyX child-document dialog needs a revision. >> Im am not a user of this dialog at all but if I select instead of >> "Program Listing" for example "Input" or "Include" I get errors. > > This is my problem too. I am a very light user of the dialog. > > JMarc > OK, "I will do my very best". Jürgen
Re: Bug #11484
Hi alltogether,
I have a revised patch for the little problem of possibly non existing
user-provided listing file in LyX child-document dialog.
If the listing file don't exist, a warning QMessageBox is displayed:
"The listing file " FILENAME " does not exist. You will not be able
to export your LyX-file (LaTeX-errors)."
The diff-file is attached.
In my opinion the whole LyX child-document dialog needs a revision.
Im am not a user of this dialog at all but if I select instead of
"Program Listing" for example "Input" or "Include" I get errors.
HTH Jürgen
Am 06.02.2019 um 16:25 schrieb Jürgen Womser-Schütz:
> Hi,
>
> in the surrounding field of bug #11484 I tried to improve the "user
> experiance" by checking the existence of the user-specified listing file.
> I changed two files:
> src/frontends/qt4/GuiInclude.cpp
> src/frontends/qt4/GuiInclude.h
> The diff-output is attached.
>
> Jürgen
From 6beaa885b113233d741a0f4516515db7f15f4087 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=BCrgen=20Womser-Sch=C3=BCtz?=
Date: Fri, 22 Feb 2019 20:21:12 +0100
Subject: [PATCH] bug11484
---
src/frontends/qt4/GuiDialog.h| 2 +-
src/frontends/qt4/GuiInclude.cpp | 51
src/frontends/qt4/GuiInclude.h | 4 +++
3 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/src/frontends/qt4/GuiDialog.h b/src/frontends/qt4/GuiDialog.h
index d5f4227c08..2ca0a93448 100644
--- a/src/frontends/qt4/GuiDialog.h
+++ b/src/frontends/qt4/GuiDialog.h
@@ -52,7 +52,7 @@ public Q_SLOTS:
// Restore Defaults button clicked
virtual void slotRestoreDefaults() {}
// OK button clicked
- void slotOK();
+ virtual void slotOK();
// Apply button clicked
void slotApply();
// AutoApply checkbox clicked
diff --git a/src/frontends/qt4/GuiInclude.cpp b/src/frontends/qt4/GuiInclude.cpp
index c55d71fa7f..e9b16487e6 100644
--- a/src/frontends/qt4/GuiInclude.cpp
+++ b/src/frontends/qt4/GuiInclude.cpp
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -75,11 +76,17 @@ GuiInclude::GuiInclude(GuiView & lv)
bc().setPolicy(ButtonPolicy::OkApplyCancelReadOnlyPolicy);
bc().setOK(buttonBox->button(QDialogButtonBox::Ok));
bc().setCancel(buttonBox->button(QDialogButtonBox::Cancel));
- bc().addReadOnly(filenameED);
- bc().addReadOnly(browsePB);
- bc().addReadOnly(visiblespaceCB);
- bc().addReadOnly(typeCO);
- bc().addReadOnly(listingsED);
+
+ if(false)
+ {
+ // unnecessary calls (list ButtonController.readOnly_ is used
only
+ // in ButtonController.refreshReadOnly(), but this is not
called anymore):
+ bc().addReadOnly(filenameED);
+ bc().addReadOnly(browsePB);
+ bc().addReadOnly(visiblespaceCB);
+ bc().addReadOnly(typeCO);
+ bc().addReadOnly(listingsED);
+ }
bc().addCheckedLineEdit(filenameED, filenameLA);
}
@@ -288,6 +295,23 @@ void GuiInclude::browse()
}
+void GuiInclude::slotOK()
+{
+ // listing file exists?
+ QString docpath;
+ if( !listingFileExist( docpath ) )
+ {
+ // warning: file doesn't exist
+ QMessageBox::information(this, qt_("LyX Warning"),
+qt_("The listing file \"") + docpath + qt_("\" does not exist.
"
+"You will not be able to export your LyX-file
(LaTeX-errors)."));
+ }
+
+ // call base-class functionality
+ GuiDialog::slotOK();
+}
+
+
void GuiInclude::edit()
{
if (!isValid())
@@ -303,10 +327,25 @@ void GuiInclude::edit()
bool GuiInclude::isValid()
{
- return !filenameED->text().isEmpty() &&
validate_listings_params().empty();
+ return validate_listings_params().empty();
}
+bool GuiInclude::listingFileExist(QString & docpath)
+{
+ // check whether the file of the listing exists
+ QString const listingFileName = filenameED->text();
+ docpath = toqstr(support::onlyPath(buffer().absFileName()));
+ docpath += listingFileName;
+
+ bool listingFileExist = false;
+ if (!listingFileName.isEmpty())
+ listingFileExist = FileName(docpath.toStdString()).exists();
+
+ return listingFileExist;
+ }
+
+
QString GuiInclude::browse(QString const & in_name, Type in_type) const
{
QString const title = qt_("Select document to include");
diff --git a/src/frontends/qt4/GuiInclude.h b/src/frontends/qt4/GuiInclude.h
index 1106c3e02e..9da767352a 100644
--- a/src/frontends/qt4/GuiInclude.h
+++ b/src/frontends/qt4/GuiInclude.h
@@ -72,6 +72,8 @@ private:
void updateLists();
/// validate listings parameters and return an error message, if any
Re: Fwd: [Bug 1815278] [NEW] LyX restores the same cursor position wherever it was placed next time(s)
I can not reproduce this wether in my windows 10 installation 2.3.2-2 nor in ubuntu version 2.4.0dev. Jürgen Am 14.02.2019 um 14:59 schrieb Jean-Marc Lasgouttes: > An interesting bug report from ubuntu bugs. > I did not try confirm the bug. > > JMarc > > > Message transféré > Sujet : [Bug 1815278] [NEW] LyX restores the same cursor position > wherever it was placed next time(s) > Date : Sat, 09 Feb 2019 10:48:49 - > De : Konstantin Boyandin <1815...@bugs.launchpad.net> > Répondre à : Bug 1815278 <1815...@bugs.launchpad.net> > Pour : lasgout...@lyx.org > > Public bug reported: > > LyX version: 2.3.2 , OS: Ubuntu 16.04.5 64-bit > > (I use LyX PPA found here: https://launchpad.net/~lyx- > devel/+archive/ubuntu/release ) > > Problem: In "Preferences > Look & Feel > Document handling" I checked > "Restore cursor positions". > > LyX only saved cursor position once. very next time when I open files (I > keep several files open in the same session), cursor position never > changes, it's restored to the value where it was first saved. > > That means that corresponding strings in > > ~/.lyx/session > > are never updated (I checked that) once written. > > ** Affects: lyx (Ubuntu) > Importance: Undecided > Status: New >
Re: Bug #11484
Hi alltogether, I hereby grant permission to use my work for LyX under the license GPL version 2 or later. Best regards Jürgen Am 06.02.2019 um 16:25 schrieb Jürgen Womser-Schütz: > Hi, > > in the surrounding field of bug #11484 I tried to improve the "user > experiance" by checking the existence of the user-specified listing file. > I changed two files: > src/frontends/qt4/GuiInclude.cpp > src/frontends/qt4/GuiInclude.h > The diff-output is attached. > > Jürgen
Re: Bug #11484
Am 10 Feb 2019 um 09:23:53 schrieb Jean-Marc Lasgouttes: > Dear Jürgen, > > I have a question: is the effect of your patch to disable the OK button when > the file does not exist? If it is the case, I am not sure that it will > considered as an improvement by everyone. I am not a heavy listings user, but > I suspect that some people insert references to documents with placeholder > names that they will update/create later. > > > I think it would be better to warn in a different way. > > What I am trying to do is just start the discussion. It is up to heavy users > of this feature to tell how they use it. > > > JMarc > > PS: welcome anyway, and sorry for the delay in answering :) Hello JMarc, you are right: to get the most minimal change, I intended the same behaviour as in the original version if no filename whatsoever is provided by the user. If you have an result for your discussion: please tell it to me. In the meantime I try to find out the usual LyX-way of handling such a warning. Best regards Jürgen PS: Because of an unknown problem I didn't receive your mail. I found it "accidently" visiting the LyX-mail-archive :-(
Re: Bug #11484
Hi, you are right - maybe I am a bit "over-enthusiastic" :-) Jürgen Am 09.02.2019 um 22:48 schrieb Richard Kimberly Heck: > On 2/8/19 8:53 PM, Scott Kostyshak wrote: >> On Fri, Feb 08, 2019 at 10:40:48PM +0100, Kornel Benko wrote: >>> Am Freitag, 8. Februar 2019 22:14:55 CET schrieb Jürgen Womser-Schütz >>> : >>>> Hi alltogether, as I can see: no volunteers desired. >>>> Best regards Jürgen >>>> >>>> >>>> Am 06.02.2019 um 16:25 schrieb Jürgen Womser-Schütz: >>>>> Hi, >>>>> >>>>> in the surrounding field of bug #11484 I tried to improve the "user >>>>> experiance" by checking the existence of the user-specified listing file. >>>>> I changed two files: >>>>> src/frontends/qt4/GuiInclude.cpp >>>>> src/frontends/qt4/GuiInclude.h >>>>> The diff-output is attached. >>>>> >>>>> Jürgen >>> Don't be disappointed. Sometimes it may take some time until some >>> experienced >>> developer checks your patch. >> +1 > And, just to be clear, traffic on the list has just generally been a bit > light lately. My sense is that a lot of people are very busy right now. > We're *all* volunteers with demanding day-jobs. I am as busy with > classes, etc, right now as I can ever remember being. And now I'm sick. :-( > > Riki > >
Re: Bug #11484
Hi alltogether, as I can see: no volunteers desired. Best regards Jürgen Am 06.02.2019 um 16:25 schrieb Jürgen Womser-Schütz: > Hi, > > in the surrounding field of bug #11484 I tried to improve the "user > experiance" by checking the existence of the user-specified listing file. > I changed two files: > src/frontends/qt4/GuiInclude.cpp > src/frontends/qt4/GuiInclude.h > The diff-output is attached. > > Jürgen
Re: Bug #11484
... and a patch to git-master for convenience.
Jürgen
Am 06.02.2019 um 16:25 schrieb Jürgen Womser-Schütz:
> Hi,
>
> in the surrounding field of bug #11484 I tried to improve the "user
> experiance" by checking the existence of the user-specified listing file.
> I changed two files:
> src/frontends/qt4/GuiInclude.cpp
> src/frontends/qt4/GuiInclude.h
> The diff-output is attached.
>
> Jürgen
From 559a25f02c3f1d35e31b7cd1adcbf5609175c296 Mon Sep 17 00:00:00 2001
From: JWS
Date: Wed, 6 Feb 2019 17:39:35 +0100
Subject: [PATCH] Improve the "user experience" by checking the existence
---
src/frontends/qt4/GuiInclude.cpp | 17 -
src/frontends/qt4/GuiInclude.h | 2 ++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/frontends/qt4/GuiInclude.cpp b/src/frontends/qt4/GuiInclude.cpp
index c55d71fa7f..4d96ac8415 100644
--- a/src/frontends/qt4/GuiInclude.cpp
+++ b/src/frontends/qt4/GuiInclude.cpp
@@ -303,7 +303,22 @@ void GuiInclude::edit()
bool GuiInclude::isValid()
{
- return !filenameED->text().isEmpty() &&
validate_listings_params().empty();
+ return listingFileExist() && validate_listings_params().empty();
+}
+
+
+bool GuiInclude::listingFileExist()
+{
+ // check whether the file of the listing exists
+ QString const listingFileName = filenameED->text();
+ QString docpath = toqstr(support::onlyPath(buffer().absFileName()));
+ docpath += listingFileName;
+
+ bool listingFileExist = false;
+ if (!listingFileName.isEmpty())
+ listingFileExist = FileName(docpath.toStdString()).exists();
+
+ return listingFileExist;
}
diff --git a/src/frontends/qt4/GuiInclude.h b/src/frontends/qt4/GuiInclude.h
index 1106c3e02e..862cdab968 100644
--- a/src/frontends/qt4/GuiInclude.h
+++ b/src/frontends/qt4/GuiInclude.h
@@ -72,6 +72,8 @@ private:
void updateLists();
/// validate listings parameters and return an error message, if any
docstring validate_listings_params();
+ /// exists the file?
+ bool listingFileExist();
///
bool isValid();
/// Apply changes
--
2.20.1
Bug #11484
Hi,
in the surrounding field of bug #11484 I tried to improve the "user
experiance" by checking the existence of the user-specified listing file.
I changed two files:
src/frontends/qt4/GuiInclude.cpp
src/frontends/qt4/GuiInclude.h
The diff-output is attached.
Jürgen
diff --git a/src/frontends/qt4/GuiInclude.cpp b/src/frontends/qt4/GuiInclude.cpp
index c55d71fa7f..4d96ac8415 100644
--- a/src/frontends/qt4/GuiInclude.cpp
+++ b/src/frontends/qt4/GuiInclude.cpp
@@ -303,7 +303,22 @@ void GuiInclude::edit()
bool GuiInclude::isValid()
{
- return !filenameED->text().isEmpty() &&
validate_listings_params().empty();
+ return listingFileExist() && validate_listings_params().empty();
+}
+
+
+bool GuiInclude::listingFileExist()
+{
+ // check whether the file of the listing exists
+ QString const listingFileName = filenameED->text();
+ QString docpath = toqstr(support::onlyPath(buffer().absFileName()));
+ docpath += listingFileName;
+
+ bool listingFileExist = false;
+ if (!listingFileName.isEmpty())
+ listingFileExist = FileName(docpath.toStdString()).exists();
+
+ return listingFileExist;
}
diff --git a/src/frontends/qt4/GuiInclude.h b/src/frontends/qt4/GuiInclude.h
index 1106c3e02e..862cdab968 100644
--- a/src/frontends/qt4/GuiInclude.h
+++ b/src/frontends/qt4/GuiInclude.h
@@ -72,6 +72,8 @@ private:
void updateLists();
/// validate listings parameters and return an error message, if any
docstring validate_listings_params();
+ /// exists the file?
+ bool listingFileExist();
///
bool isValid();
/// Apply changes
Windows build documentation
Hi altogether :-) I am a newbi and I am trying to setup the LyX-build for my Win10/VS2017 machine using "https://wiki.lyx.org/Windows/Compilation";. It seems to me that the referred batch-file "http://ftp.lyx.de/Images/MSVC2015-LyX22.bat"; in chapter "Compilation" is missing. Best wishes and a nice new year 2019 Jürgen
