subject:"Re\: Windows installer"





On 1/09/2018 11:49 p.m., Enrico Forestieri wrote:

On Sat, Sep 01, 2018 at 11:09:58AM +0200, Jürgen Spitzmüller wrote:

Am Samstag, den 01.09.2018, 20:27 +1200 schrieb Andrew Parsloe:

OK, this time I inserted a Bib(la)TeX Bibliography via Insert >
List/TOC, using an old BibTeX .bib file I had lying around. Even a
small
trial document is noticeably slower for things like starting a new
paragraph, although the delay is more like quarter to half a second
rather than the 2 to 4 seconds you report. Nonetheless it's still
noticeable.

The crucial info we need is what makes this so slow only on Windows
(and not on any other OS). Can we do profiling on Win?

Just a shot in the dark: If you enable the "Files" debug output in View

Messages, is there any indication that (attempts to) file removal

(aux file and/or bbl file) take your time? I am just guessing that
removeBiblioTempFiles() (involved in the BibinfoCache invalidation)
might be the culprit, since it involves QFile, and this is an obvious
candidate for OS-specific weirdness.

Using the --verbose switch it can be seen that each time a new paragraph
is started LyX runs kpsewhich for each bibtex catalog to be found in the
texmf tree. So, if you have 5 catalogs, kpsewhich is run for 5 times
everytime you hit the Enter key.

This was not the case in 2.3.0.
I see that MiKTeX keeps a kpsewhich.log (which must itself cause a 
performance penalty). It's not just starting a new paragraph, but other 
basic operations also result in calls to kpsewhich. In case it's helpful 
(this is with a single .bib file):


1. Deleting a letter with Del or Backspace: no call to kpsewhich; 
*selecting* the letter then deleting it, 1 call.


2. Inserting a space before another space then clicking elsewhere so 
that LyX automatically removes the extra space: 2 calls.


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Windows Installer for Testing

On 09/01/2018 03:34 PM, Jürgen Spitzmüller wrote:
> Scott Kostyshak mailto:skost...@lyx.org>> schrieb
> am Sa., 1. Sep. 2018, 21:26:
>
> On Sat, Sep 01, 2018 at 01:47:54PM -0400, Richard Kimberly Heck wrote:
>
> > Another option for 2.3.1 would be to revert the commits that
> fixed #9158.
>
> +1 The bug does not seem important enough to risk anything at this
> point.
>
>
> I'd vote for that, too. Let's try to get it right for 2.3.2.

OK, I'll plan to go that way. I'll issue new tarballs tomorrow probably.

I have most of a patch at this point and will try to finish it over the
weekend.

Riki

Re: Windows Installer for Testing

On 09/01/2018 01:36 PM, Richard Kimberly Heck wrote:
> On 09/01/2018 12:58 PM, Richard Kimberly Heck wrote:
>> On 09/01/2018 10:02 AM, Jürgen Spitzmüller wrote:
>>> Am Samstag, den 01.09.2018, 13:49 +0200 schrieb Enrico Forestieri:
 Using the --verbose switch it can be seen that each time a new
 paragraph
 is started LyX runs kpsewhich for each bibtex catalog to be found in
 the
 texmf tree. So, if you have 5 catalogs, kpsewhich is run for 5 times
 everytime you hit the Enter key.
>>> Indeed, that's likely the culprit.
>>>
>>> The call is in InsetBibtex::getBibTeXPath(), which is called by
>>> InsetBibtex::getBibFiles(), which is called by
>>> InsetBibTeX::updateBuffer(), which is called by Buffer::updateBuffer()
>>>
>>> Would it make sense to cache those paths, too? After all, they are
>>> unlikely to change that often.
>> Weird that no-one saw this problem on Linux.
> Here's a simple patch which would need a bit of additional work, but can
> be a kind of proof of concept (and be tested). Comments?

Updated patch.

Riki

commit 995e5ddaa031931bad121fa597a8f84b73371c49
Author: Richard Kimberly Heck 
Date:   Sat Sep 1 15:16:01 2018 -0400

Fix slowness on Windows. See bug #9158.

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 8ca74103a2..bbcbd9c62c 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -143,7 +143,6 @@ typedef map > RefCache;
 // A storehouse for the cloned buffers.
 list cloned_buffers;
 
-
 class Buffer::Impl
 {
 public:
@@ -2438,6 +2437,31 @@ void Buffer::registerBibfiles(FileNamePairList const & 
bf) const
 }
 
 
+static map bibfileCache;
+
+
+bool Buffer::bibCacheHasFile(docstring const & bibid)
+{
+   map::const_iterator it =
+   bibfileCache.find(bibid);
+   return it != bibfileCache.end();
+}
+
+
+void Buffer::updateBibCacheFileName(docstring const & bibid, 
+   support::FileName const & fn)
+{
+   bibfileCache[bibid] = fn;
+}
+
+
+FileName Buffer::getBibCacheFileName(docstring const & bibid)
+{
+   LASSERT(bibCacheHasFile(bibid), return FileName());
+   return bibfileCache[bibid];
+}
+
+
 void Buffer::checkIfBibInfoCacheIsValid() const
 {
// use the master's cache
diff --git a/src/Buffer.h b/src/Buffer.h
index 50d086f287..2f287a2c57 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -766,6 +766,13 @@ public:
void updateChangesPresent() const;
///
void registerBibfiles(support::FileNamePairList const & bf) const;
+   ///
+   static bool bibCacheHasFile(docstring const & bibid);
+   /// will add or update as required
+   static void updateBibCacheFileName(docstring const & bibid, 
+   support::FileName const & fn);
+   ///
+   static support::FileName getBibCacheFileName(docstring const & bibid);
 
 private:
friend class MarkAsExporting;
diff --git a/src/insets/InsetBibtex.cpp b/src/insets/InsetBibtex.cpp
index d2e7284052..03cd44c8a5 100644
--- a/src/insets/InsetBibtex.cpp
+++ b/src/insets/InsetBibtex.cpp
@@ -397,7 +397,13 @@ FileNamePairList InsetBibtex::getBibFiles() const
vector::const_iterator it = bibfilelist.begin();
vector::const_iterator en = bibfilelist.end();
for (; it != en; ++it) {
-   FileName const file = getBibTeXPath(*it, buffer());
+   FileName file;
+   if (buffer().bibCacheHasFile(*it)) {
+   file = buffer().getBibCacheFileName(*it);   

+   } else {
+   file = getBibTeXPath(*it, buffer());
+   buffer().updateBibCacheFileName(*it, file);
+   }
 
if (!file.empty())
vec.push_back(make_pair(*it, file));

Re: Windows Installer for Testing

Scott Kostyshak  schrieb am Sa., 1. Sep. 2018, 21:26:

> On Sat, Sep 01, 2018 at 01:47:54PM -0400, Richard Kimberly Heck wrote:
>
> > Another option for 2.3.1 would be to revert the commits that fixed #9158.
>
> +1 The bug does not seem important enough to risk anything at this
> point.
>

I'd vote for that, too. Let's try to get it right for 2.3.2.

Jürgen


> Scott
>

Re: Windows Installer for Testing

2018-09-01 Thread Scott Kostyshak

On Sat, Sep 01, 2018 at 01:47:54PM -0400, Richard Kimberly Heck wrote:

> Another option for 2.3.1 would be to revert the commits that fixed #9158.

+1 The bug does not seem important enough to risk anything at this
point.

Scott


signature.asc
Description: PGP signature

Re: Windows Installer for Testing

On 09/01/2018 01:36 PM, Richard Kimberly Heck wrote:
> On 09/01/2018 12:58 PM, Richard Kimberly Heck wrote:
>> On 09/01/2018 10:02 AM, Jürgen Spitzmüller wrote:
>>> Am Samstag, den 01.09.2018, 13:49 +0200 schrieb Enrico Forestieri:
 Using the --verbose switch it can be seen that each time a new
 paragraph
 is started LyX runs kpsewhich for each bibtex catalog to be found in
 the
 texmf tree. So, if you have 5 catalogs, kpsewhich is run for 5 times
 everytime you hit the Enter key.
>>> Indeed, that's likely the culprit.
>>>
>>> The call is in InsetBibtex::getBibTeXPath(), which is called by
>>> InsetBibtex::getBibFiles(), which is called by
>>> InsetBibTeX::updateBuffer(), which is called by Buffer::updateBuffer()
>>>
>>> Would it make sense to cache those paths, too? After all, they are
>>> unlikely to change that often.
>> Weird that no-one saw this problem on Linux.
> Here's a simple patch which would need a bit of additional work, but can
> be a kind of proof of concept (and be tested). Comments?
>
> The only danger of using this as is in 2.3.1 is that, if paths changed,
> we would never know. But that is unlikely to happen.

Another option for 2.3.1 would be to revert the commits that fixed #9158.

Riki

Re: Windows Installer for Testing

On 09/01/2018 12:58 PM, Richard Kimberly Heck wrote:
> On 09/01/2018 10:02 AM, Jürgen Spitzmüller wrote:
>> Am Samstag, den 01.09.2018, 13:49 +0200 schrieb Enrico Forestieri:
>>> Using the --verbose switch it can be seen that each time a new
>>> paragraph
>>> is started LyX runs kpsewhich for each bibtex catalog to be found in
>>> the
>>> texmf tree. So, if you have 5 catalogs, kpsewhich is run for 5 times
>>> everytime you hit the Enter key.
>> Indeed, that's likely the culprit.
>>
>> The call is in InsetBibtex::getBibTeXPath(), which is called by
>> InsetBibtex::getBibFiles(), which is called by
>> InsetBibTeX::updateBuffer(), which is called by Buffer::updateBuffer()
>>
>> Would it make sense to cache those paths, too? After all, they are
>> unlikely to change that often.
> Weird that no-one saw this problem on Linux.

Here's a simple patch which would need a bit of additional work, but can
be a kind
of proof of concept (and be tested). Comments?

The only danger of using this as is in 2.3.1 is that, if paths changed,
we would never
know. But that is unlikely to happen.

Riki

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 8ca74103a2..58dd878b5e 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -142,6 +142,7 @@ typedef map > RefCache;
 
 // A storehouse for the cloned buffers.
 list cloned_buffers;
+FileNamePairList Buffer::bibfileCache;
 
 
 class Buffer::Impl
diff --git a/src/Buffer.h b/src/Buffer.h
index 50d086f287..9d34f9c1c3 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -766,6 +766,8 @@ public:
void updateChangesPresent() const;
///
void registerBibfiles(support::FileNamePairList const & bf) const;
+   ///
+   static support::FileNamePairList bibfileCache;
 
 private:
friend class MarkAsExporting;
diff --git a/src/insets/InsetBibtex.cpp b/src/insets/InsetBibtex.cpp
index d2e7284052..4b6760c62b 100644
--- a/src/insets/InsetBibtex.cpp
+++ b/src/insets/InsetBibtex.cpp
@@ -397,7 +397,20 @@ FileNamePairList InsetBibtex::getBibFiles() const
vector::const_iterator it = bibfilelist.begin();
vector::const_iterator en = bibfilelist.end();
for (; it != en; ++it) {
-   FileName const file = getBibTeXPath(*it, buffer());
+   FileNamePairList & cache = buffer().bibfileCache;
+   FileName file;
+   bool found = false;
+   for (auto const & p : cache) {
+   if (p.first == *it) {
+   file = p.second;
+   found = true;
+   break;
+   }
+   }
+   if (!found) {
+   file = getBibTeXPath(*it, buffer());
+   cache.push_back(make_pair(*it, file));
+   }
 
if (!file.empty())
vec.push_back(make_pair(*it, file));

Re: Windows Installer for Testing

On 09/01/2018 10:02 AM, Jürgen Spitzmüller wrote:
> Am Samstag, den 01.09.2018, 13:49 +0200 schrieb Enrico Forestieri:
>> Using the --verbose switch it can be seen that each time a new
>> paragraph
>> is started LyX runs kpsewhich for each bibtex catalog to be found in
>> the
>> texmf tree. So, if you have 5 catalogs, kpsewhich is run for 5 times
>> everytime you hit the Enter key.
> Indeed, that's likely the culprit.
>
> The call is in InsetBibtex::getBibTeXPath(), which is called by
> InsetBibtex::getBibFiles(), which is called by
> InsetBibTeX::updateBuffer(), which is called by Buffer::updateBuffer()
>
> Would it make sense to cache those paths, too? After all, they are
> unlikely to change that often.

Weird that no-one saw this problem on Linux.

Here's a possibility: Cache the paths, as you suggest, and then, if
there's no file at
that location (when we look for it), re-run findtexfile to try to find
it. So we'd need
to find all the places the path is used. I note
Buffer::checkIfBibInfoCacheIsValid
(checking timestamps) and InsetBibtex::parseBibTeXFiles (which calls
getBibfiles
again) and Buffer::prepareBibFilePaths (which is passed the list).

I'm not entirely sure where it's best to put the cache. InsetBibtex is
an option, but
we really only need a single global one. So maybe a static std::map there?

Actually, if we do this, then we probably don't even need the
FileNamePairList
any more. We can just store the name as entered and use the cache to
find the
full path. But maybe we don't want to do anything so dramatic right now?

Riki

Re: Windows Installer for Testing

2018-09-01 Thread Daniel


On 01/09/2018 01:11, Richard Kimberly Heck wrote:

On 08/31/2018 05:58 PM, Daniel wrote:

On 2018-08-31 22:51, Richard Kimberly Heck wrote:

On 08/31/2018 01:31 PM, Daniel wrote:

On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:


It might be the same problem as plagued the 2.3.0 version at first.
Once I have a bibliography included the delay is there (and the more
bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were involved in
its solution.


Yes, I thought we had sorted that out, but perhaps not. Can you give a
few more details?

Riki


Not fully sure what details you are asking for. I still cannot find
the post I was referring to. And lag kick in one a bibliography is
inserted into a document. Writing characters is fine but, for example,
deleting a passage or creating a new paragraph lags.


I have verified that most of the fix that's in master is also in 2.3.x
(and so in 2.3.1). So it's a bit of mystery why this has changed in
2.3.1. That said, there were some other changes that were supposed to
help further.

Do these documents use master-child stuff?

Riki


I noticed it first in a document with master-child stuff. But I could
reproduce it by just adding a bibliography to a newly created
document. It was less of a delay, maybe due to its lesser complexity
(and less bibliographies), but the delay was there none the less.


Are you able to compile these days? If so, can you try the attached
patch with "-dbg files" and let me know what you see?

Riki


Still haven't set up LyX to compile on my new system...

Daniel

Re: Windows Installer for Testing

Am Samstag, den 01.09.2018, 13:49 +0200 schrieb Enrico Forestieri:
> Using the --verbose switch it can be seen that each time a new
> paragraph
> is started LyX runs kpsewhich for each bibtex catalog to be found in
> the
> texmf tree. So, if you have 5 catalogs, kpsewhich is run for 5 times
> everytime you hit the Enter key.

Indeed, that's likely the culprit.

The call is in InsetBibtex::getBibTeXPath(), which is called by
InsetBibtex::getBibFiles(), which is called by
InsetBibTeX::updateBuffer(), which is called by Buffer::updateBuffer()

Would it make sense to cache those paths, too? After all, they are
unlikely to change that often.

Jürgen

> This was not the case in 2.3.0.
> 


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

Re: Windows Installer for Testing

2018-09-01 Thread Enrico Forestieri

On Sat, Sep 01, 2018 at 11:09:58AM +0200, Jürgen Spitzmüller wrote:
> Am Samstag, den 01.09.2018, 20:27 +1200 schrieb Andrew Parsloe:
> > OK, this time I inserted a Bib(la)TeX Bibliography via Insert > 
> > List/TOC, using an old BibTeX .bib file I had lying around. Even a
> > small 
> > trial document is noticeably slower for things like starting a new 
> > paragraph, although the delay is more like quarter to half a second 
> > rather than the 2 to 4 seconds you report. Nonetheless it's still 
> > noticeable.
> 
> The crucial info we need is what makes this so slow only on Windows
> (and not on any other OS). Can we do profiling on Win?
> 
> Just a shot in the dark: If you enable the "Files" debug output in View
> > Messages, is there any indication that (attempts to) file removal
> (aux file and/or bbl file) take your time? I am just guessing that
> removeBiblioTempFiles() (involved in the BibinfoCache invalidation)
> might be the culprit, since it involves QFile, and this is an obvious
> candidate for OS-specific weirdness.

Using the --verbose switch it can be seen that each time a new paragraph
is started LyX runs kpsewhich for each bibtex catalog to be found in the
texmf tree. So, if you have 5 catalogs, kpsewhich is run for 5 times
everytime you hit the Enter key.

This was not the case in 2.3.0.

-- 
Enrico

Re: Windows Installer for Testing

Am Samstag, den 01.09.2018, 12:40 +0200 schrieb Jean-Marc Lasgouttes:
> Le 01/09/2018 à 11:09, Jürgen Spitzmüller a écrit :
> > The crucial info we need is what makes this so slow only on Windows
> > (and not on any other OS). Can we do profiling on Win?
> 
> Could we have a document that exhibits the problem?

I understand that you just need a document with a fairly big BibTeX
database.

Jürgen

> 
> JMarc
> 


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

Re: Windows Installer for Testing

2018-09-01 Thread Jean-Marc Lasgouttes


Le 01/09/2018 à 11:09, Jürgen Spitzmüller a écrit :

The crucial info we need is what makes this so slow only on Windows
(and not on any other OS). Can we do profiling on Win?


Could we have a document that exhibits the problem?

JMarc

Re: Windows Installer for Testing

Am Samstag, den 01.09.2018, 20:27 +1200 schrieb Andrew Parsloe:
> OK, this time I inserted a Bib(la)TeX Bibliography via Insert > 
> List/TOC, using an old BibTeX .bib file I had lying around. Even a
> small 
> trial document is noticeably slower for things like starting a new 
> paragraph, although the delay is more like quarter to half a second 
> rather than the 2 to 4 seconds you report. Nonetheless it's still 
> noticeable.

The crucial info we need is what makes this so slow only on Windows
(and not on any other OS). Can we do profiling on Win?

Just a shot in the dark: If you enable the "Files" debug output in View
> Messages, is there any indication that (attempts to) file removal
(aux file and/or bbl file) take your time? I am just guessing that
removeBiblioTempFiles() (involved in the BibinfoCache invalidation)
might be the culprit, since it involves QFile, and this is an obvious
candidate for OS-specific weirdness.

Jürgen

> 
> Andrew


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

Re: Windows Installer for Testing


On 1/09/2018 7:13 p.m., Daniel wrote:

On 2018-09-01 08:57, Andrew Parsloe wrote:



On 1/09/2018 11:11 a.m., Richard Kimberly Heck wrote:

On 08/31/2018 05:58 PM, Daniel wrote:

On 2018-08-31 22:51, Richard Kimberly Heck wrote:

On 08/31/2018 01:31 PM, Daniel wrote:

On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:
It might be the same problem as plagued the 2.3.0 version at 
first.
Once I have a bibliography included the delay is there (and the 
more

bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were 
involved in

its solution.
Yes, I thought we had sorted that out, but perhaps not. Can you 
give a

few more details?

Riki

Not fully sure what details you are asking for. I still cannot find
the post I was referring to. And lag kick in one a bibliography is
inserted into a document. Writing characters is fine but, for 
example,

deleting a passage or creating a new paragraph lags.
I have verified that most of the fix that's in master is also in 
2.3.x

(and so in 2.3.1). So it's a bit of mystery why this has changed in
2.3.1. That said, there were some other changes that were supposed to
help further.

Do these documents use master-child stuff?

Riki

I noticed it first in a document with master-child stuff. But I could
reproduce it by just adding a bibliography to a newly created
document. It was less of a delay, maybe due to its lesser complexity
(and less bibliographies), but the delay was there none the less.

Are you able to compile these days? If so, can you try the attached
patch with "-dbg files" and let me know what you see?

Riki

To provide another data point for this discussion, 2.3.1 installed 
without problems on my windows 7 system and is not showing any delay 
for the kinds of operations Daniel mentioned. This is with a 
master-child document. The bibliography has 19 entries but is 
'built-in' rather than using an external bib database.


Andrew


By 'built-in' you mean not using the bibliography inset? If so, can 
you try with one?


Daniel

OK, this time I inserted a Bib(la)TeX Bibliography via Insert > 
List/TOC, using an old BibTeX .bib file I had lying around. Even a small 
trial document is noticeably slower for things like starting a new 
paragraph, although the delay is more like quarter to half a second 
rather than the 2 to 4 seconds you report. Nonetheless it's still 
noticeable.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Windows Installer for Testing


On 1/09/2018 7:13 p.m., Daniel wrote:

On 2018-09-01 08:57, Andrew Parsloe wrote:



On 1/09/2018 11:11 a.m., Richard Kimberly Heck wrote:

On 08/31/2018 05:58 PM, Daniel wrote:

On 2018-08-31 22:51, Richard Kimberly Heck wrote:

On 08/31/2018 01:31 PM, Daniel wrote:

On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:
It might be the same problem as plagued the 2.3.0 version at 
first.
Once I have a bibliography included the delay is there (and the 
more

bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were 
involved in

its solution.
Yes, I thought we had sorted that out, but perhaps not. Can you 
give a

few more details?

Riki

Not fully sure what details you are asking for. I still cannot find
the post I was referring to. And lag kick in one a bibliography is
inserted into a document. Writing characters is fine but, for 
example,

deleting a passage or creating a new paragraph lags.
I have verified that most of the fix that's in master is also in 
2.3.x

(and so in 2.3.1). So it's a bit of mystery why this has changed in
2.3.1. That said, there were some other changes that were supposed to
help further.

Do these documents use master-child stuff?

Riki

I noticed it first in a document with master-child stuff. But I could
reproduce it by just adding a bibliography to a newly created
document. It was less of a delay, maybe due to its lesser complexity
(and less bibliographies), but the delay was there none the less.

Are you able to compile these days? If so, can you try the attached
patch with "-dbg files" and let me know what you see?

Riki

To provide another data point for this discussion, 2.3.1 installed 
without problems on my windows 7 system and is not showing any delay 
for the kinds of operations Daniel mentioned. This is with a 
master-child document. The bibliography has 19 entries but is 
'built-in' rather than using an external bib database.


Andrew


By 'built-in' you mean not using the bibliography inset? If so, can 
you try with one?


Daniel

I meant that I went to the layout drop-down box and clicked on 
Bibliography, which inserted a heading "Bibliography". I presume this is 
the "bibliography inset"? Pressing Enter below the heading gives me a 
key-1[]  prompt. I type in  bibliographic details beside that, so that 
the entry is part of the document ('built-in') rather than being stored 
in an external file.


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Windows Installer for Testing

Am Freitag, den 31.08.2018, 23:56 +0200 schrieb Daniel:
> > The thread with "Beta1 is slow on undo“ perhaps?
> > 
> > Stephan
> > 
> 
> Probably, I seem not to be able to access them from here.

https://marc.info/?l=lyx-devel=150739249920974=2

The respective ticket is

https://www.lyx.org/trac/ticket/9158

Jürgen

> 
> Daniel
> 
> 


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

Re: Windows Installer for Testing

2018-09-01 Thread Daniel


On 2018-09-01 08:57, Andrew Parsloe wrote:



On 1/09/2018 11:11 a.m., Richard Kimberly Heck wrote:

On 08/31/2018 05:58 PM, Daniel wrote:

On 2018-08-31 22:51, Richard Kimberly Heck wrote:

On 08/31/2018 01:31 PM, Daniel wrote:

On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:

It might be the same problem as plagued the 2.3.0 version at first.
Once I have a bibliography included the delay is there (and the more
bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were involved in
its solution.
Yes, I thought we had sorted that out, but perhaps not. Can you 
give a

few more details?

Riki

Not fully sure what details you are asking for. I still cannot find
the post I was referring to. And lag kick in one a bibliography is
inserted into a document. Writing characters is fine but, for example,
deleting a passage or creating a new paragraph lags.

I have verified that most of the fix that's in master is also in 2.3.x
(and so in 2.3.1). So it's a bit of mystery why this has changed in
2.3.1. That said, there were some other changes that were supposed to
help further.

Do these documents use master-child stuff?

Riki

I noticed it first in a document with master-child stuff. But I could
reproduce it by just adding a bibliography to a newly created
document. It was less of a delay, maybe due to its lesser complexity
(and less bibliographies), but the delay was there none the less.

Are you able to compile these days? If so, can you try the attached
patch with "-dbg files" and let me know what you see?

Riki

To provide another data point for this discussion, 2.3.1 installed 
without problems on my windows 7 system and is not showing any delay for 
the kinds of operations Daniel mentioned. This is with a master-child 
document. The bibliography has 19 entries but is 'built-in' rather than 
using an external bib database.


Andrew


By 'built-in' you mean not using the bibliography inset? If so, can you 
try with one?


Daniel

Re: Windows Installer for Testing





On 1/09/2018 11:11 a.m., Richard Kimberly Heck wrote:

On 08/31/2018 05:58 PM, Daniel wrote:

On 2018-08-31 22:51, Richard Kimberly Heck wrote:

On 08/31/2018 01:31 PM, Daniel wrote:

On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:

It might be the same problem as plagued the 2.3.0 version at first.
Once I have a bibliography included the delay is there (and the more
bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were involved in
its solution.

Yes, I thought we had sorted that out, but perhaps not. Can you give a
few more details?

Riki

Not fully sure what details you are asking for. I still cannot find
the post I was referring to. And lag kick in one a bibliography is
inserted into a document. Writing characters is fine but, for example,
deleting a passage or creating a new paragraph lags.

I have verified that most of the fix that's in master is also in 2.3.x
(and so in 2.3.1). So it's a bit of mystery why this has changed in
2.3.1. That said, there were some other changes that were supposed to
help further.

Do these documents use master-child stuff?

Riki

I noticed it first in a document with master-child stuff. But I could
reproduce it by just adding a bibliography to a newly created
document. It was less of a delay, maybe due to its lesser complexity
(and less bibliographies), but the delay was there none the less.

Are you able to compile these days? If so, can you try the attached
patch with "-dbg files" and let me know what you see?

Riki

To provide another data point for this discussion, 2.3.1 installed 
without problems on my windows 7 system and is not showing any delay for 
the kinds of operations Daniel mentioned. This is with a master-child 
document. The bibliography has 19 entries but is 'built-in' rather than 
using an external bib database.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Windows Installer for Testing

2018-08-31 Thread Scott Kostyshak

On Fri, Aug 31, 2018 at 01:23:19PM -0400, Richard Kimberly Heck wrote:
> On 08/31/2018 10:44 AM, Daniel wrote:
> >> First, here is the information:
> >>
> >> LyX Version 2.3.1
> >> (30 August 2018)
> >> Built from git commit hash 65bc3149
> >> Library directory: C:\Program Files (x86)\LyX 2.3\Resources\
> >> User directory: ~\AppData\Roaming\LyX2.3\
> >> Qt Version (run-time): 5.10.1
> >> Qt Version (compile-time): 5.10.1
> >
> > Of course your question concerned the comparison:
> >
> > LyX Version 2.3.0
> > (06 July 2018)
> > Built from git commit hash 2a8c7061
> > Library directory: C:\Program Files (x86)\LyX 2.3\Resources\
> > User directory: ~\AppData\Roaming\LyX2.3\
> > Qt Version (run-time): 5.10.1
> > Qt Version (compile-time): 5.10.1
> 
> FYI, the ONLY difference between the 2.3.1 and 2.3.0 packages is the LyX
> binary. I did not make any other updates to the installer.

Good to know. So not a Qt issue then.

Scott


signature.asc
Description: PGP signature

Re: Windows Installer for Testing

On 08/31/2018 05:58 PM, Daniel wrote:
> On 2018-08-31 22:51, Richard Kimberly Heck wrote:
>> On 08/31/2018 01:31 PM, Daniel wrote:
>>> On 2018-08-31 19:23, Richard Kimberly Heck wrote:
 On 08/31/2018 10:33 AM, Daniel wrote:
>
> It might be the same problem as plagued the 2.3.0 version at first.
> Once I have a bibliography included the delay is there (and the more
> bibliographies the worse). I can't find the posting from the last
> version but I seem to remember that Jürgen and Riki were involved in
> its solution.

 Yes, I thought we had sorted that out, but perhaps not. Can you give a
 few more details?

 Riki
>>>
>>> Not fully sure what details you are asking for. I still cannot find
>>> the post I was referring to. And lag kick in one a bibliography is
>>> inserted into a document. Writing characters is fine but, for example,
>>> deleting a passage or creating a new paragraph lags.
>>
>> I have verified that most of the fix that's in master is also in 2.3.x
>> (and so in 2.3.1). So it's a bit of mystery why this has changed in
>> 2.3.1. That said, there were some other changes that were supposed to
>> help further.
>>
>> Do these documents use master-child stuff?
>>
>> Riki
>
> I noticed it first in a document with master-child stuff. But I could
> reproduce it by just adding a bibliography to a newly created
> document. It was less of a delay, maybe due to its lesser complexity
> (and less bibliographies), but the delay was there none the less.

Are you able to compile these days? If so, can you try the attached
patch with "-dbg files" and let me know what you see?

Riki

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index da3db82fa5..a8b6115678 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2416,6 +2416,7 @@ void Buffer::reloadBibInfoCache() const
if (d->bibinfo_cache_valid_)
return;
 
+   LYXERR(Debug::FILES, "Reloading bibinfo cache!");
d->bibinfo_.clear();
FileNameList checkedFiles;
collectBibKeys(checkedFiles);

Re: Windows Installer for Testing


On 2018-08-31 22:51, Richard Kimberly Heck wrote:

On 08/31/2018 01:31 PM, Daniel wrote:

On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:


It might be the same problem as plagued the 2.3.0 version at first.
Once I have a bibliography included the delay is there (and the more
bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were involved in
its solution.


Yes, I thought we had sorted that out, but perhaps not. Can you give a
few more details?

Riki


Not fully sure what details you are asking for. I still cannot find
the post I was referring to. And lag kick in one a bibliography is
inserted into a document. Writing characters is fine but, for example,
deleting a passage or creating a new paragraph lags.


I have verified that most of the fix that's in master is also in 2.3.x
(and so in 2.3.1). So it's a bit of mystery why this has changed in
2.3.1. That said, there were some other changes that were supposed to
help further.

Do these documents use master-child stuff?

Riki


I noticed it first in a document with master-child stuff. But I could 
reproduce it by just adding a bibliography to a newly created document. 
It was less of a delay, maybe due to its lesser complexity (and less 
bibliographies), but the delay was there none the less.


Daniel

Re: Windows Installer for Testing


On 2018-08-31 22:15, Stephan Witt wrote:

Am 31.08.2018 um 19:31 schrieb Daniel :


On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:


It might be the same problem as plagued the 2.3.0 version at first.
Once I have a bibliography included the delay is there (and the more
bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were involved in
its solution.

Yes, I thought we had sorted that out, but perhaps not. Can you give a
few more details?
Riki


Not fully sure what details you are asking for. I still cannot find the post I 
was referring to. And lag kick in one a bibliography is inserted into a 
document. Writing characters is fine but, for example, deleting a passage or 
creating a new paragraph lags.

Daniel


The thread with "Beta1 is slow on undo“ perhaps?

Stephan



Probably, I seem not to be able to access them from here.

Daniel

Re: Windows Installer for Testing

On 08/31/2018 01:31 PM, Daniel wrote:
> On 2018-08-31 19:23, Richard Kimberly Heck wrote:
>> On 08/31/2018 10:33 AM, Daniel wrote:
>>>
>>> It might be the same problem as plagued the 2.3.0 version at first.
>>> Once I have a bibliography included the delay is there (and the more
>>> bibliographies the worse). I can't find the posting from the last
>>> version but I seem to remember that Jürgen and Riki were involved in
>>> its solution.
>>
>> Yes, I thought we had sorted that out, but perhaps not. Can you give a
>> few more details?
>>
>> Riki
>
> Not fully sure what details you are asking for. I still cannot find
> the post I was referring to. And lag kick in one a bibliography is
> inserted into a document. Writing characters is fine but, for example,
> deleting a passage or creating a new paragraph lags.

I have verified that most of the fix that's in master is also in 2.3.x
(and so in 2.3.1). So it's a bit of mystery why this has changed in
2.3.1. That said, there were some other changes that were supposed to
help further.

Do these documents use master-child stuff?

Riki

Re: Windows Installer for Testing

2018-08-31 Thread Stephan Witt

Am 31.08.2018 um 19:31 schrieb Daniel :
> 
> On 2018-08-31 19:23, Richard Kimberly Heck wrote:
>> On 08/31/2018 10:33 AM, Daniel wrote:
>>> 
>>> It might be the same problem as plagued the 2.3.0 version at first.
>>> Once I have a bibliography included the delay is there (and the more
>>> bibliographies the worse). I can't find the posting from the last
>>> version but I seem to remember that Jürgen and Riki were involved in
>>> its solution.
>> Yes, I thought we had sorted that out, but perhaps not. Can you give a
>> few more details?
>> Riki
> 
> Not fully sure what details you are asking for. I still cannot find the post 
> I was referring to. And lag kick in one a bibliography is inserted into a 
> document. Writing characters is fine but, for example, deleting a passage or 
> creating a new paragraph lags.
> 
> Daniel

The thread with "Beta1 is slow on undo“ perhaps?

Stephan

Re: Windows Installer for Testing


On 2018-08-31 19:23, Richard Kimberly Heck wrote:

On 08/31/2018 10:33 AM, Daniel wrote:


It might be the same problem as plagued the 2.3.0 version at first.
Once I have a bibliography included the delay is there (and the more
bibliographies the worse). I can't find the posting from the last
version but I seem to remember that Jürgen and Riki were involved in
its solution.


Yes, I thought we had sorted that out, but perhaps not. Can you give a
few more details?

Riki


Not fully sure what details you are asking for. I still cannot find the 
post I was referring to. And lag kick in one a bibliography is inserted 
into a document. Writing characters is fine but, for example, deleting a 
passage or creating a new paragraph lags.


Daniel

Re: Windows Installer for Testing

On 08/31/2018 10:33 AM, Daniel wrote:
>
> It might be the same problem as plagued the 2.3.0 version at first.
> Once I have a bibliography included the delay is there (and the more
> bibliographies the worse). I can't find the posting from the last
> version but I seem to remember that Jürgen and Riki were involved in
> its solution.

Yes, I thought we had sorted that out, but perhaps not. Can you give a
few more details?

Riki

Re: Windows Installer for Testing

On 08/31/2018 10:44 AM, Daniel wrote:
> On 31/08/2018 16:33, Daniel wrote:
>> On 31/08/2018 16:09, Scott Kostyshak wrote:
>>> On Fri, Aug 31, 2018 at 03:59:34PM +0200, Daniel wrote:
 On 31/08/2018 15:18, Jean-Marc Lasgouttes wrote:
> Le 31/08/2018 à 13:27, Daniel a écrit :
>> Unfortunately, LyX 2.3.1 is not usable for me. Many simple things
>> take a couple of seconds, like when I press enter for a new
>> paragraph, delete something, click on another paragraph, etc.
>
> That is very very weird. I have to give it a go. A couple of
> seconds is
> a lot.
>
> JMarc

 Yes it is (something between 2 to 4 second - but I guess any really
 noticeable delay renders it unusable). I am now back to 2.3.0. No
 problems
 there.
>>>
>>> Thanks for testing, Daniel. When you go to Help > About, is the
>>> information the same except for "2.3.1" instead of "2.3.0" ? (don't
>>> re-install LyX 2.3.1 just to answer this question. I only ask in the
>>> case that you have them installed side-by-side)
>>>
>>> Scott
>>
>> First, here is the information:
>>
>> LyX Version 2.3.1
>> (30 August 2018)
>> Built from git commit hash 65bc3149
>> Library directory: C:\Program Files (x86)\LyX 2.3\Resources\
>> User directory: ~\AppData\Roaming\LyX2.3\
>> Qt Version (run-time): 5.10.1
>> Qt Version (compile-time): 5.10.1
>
> Of course your question concerned the comparison:
>
> LyX Version 2.3.0
> (06 July 2018)
> Built from git commit hash 2a8c7061
> Library directory: C:\Program Files (x86)\LyX 2.3\Resources\
> User directory: ~\AppData\Roaming\LyX2.3\
> Qt Version (run-time): 5.10.1
> Qt Version (compile-time): 5.10.1

FYI, the ONLY difference between the 2.3.1 and 2.3.0 packages is the LyX
binary. I did not make any other updates to the installer.

Riki

Re: Windows Installer for Testing


On 31/08/2018 16:33, Daniel wrote:

On 31/08/2018 16:09, Scott Kostyshak wrote:

On Fri, Aug 31, 2018 at 03:59:34PM +0200, Daniel wrote:

On 31/08/2018 15:18, Jean-Marc Lasgouttes wrote:

Le 31/08/2018 à 13:27, Daniel a écrit :

Unfortunately, LyX 2.3.1 is not usable for me. Many simple things
take a couple of seconds, like when I press enter for a new
paragraph, delete something, click on another paragraph, etc.


That is very very weird. I have to give it a go. A couple of seconds is
a lot.

JMarc


Yes it is (something between 2 to 4 second - but I guess any really
noticeable delay renders it unusable). I am now back to 2.3.0. No 
problems

there.


Thanks for testing, Daniel. When you go to Help > About, is the
information the same except for "2.3.1" instead of "2.3.0" ? (don't
re-install LyX 2.3.1 just to answer this question. I only ask in the
case that you have them installed side-by-side)

Scott


First, here is the information:

LyX Version 2.3.1
(30 August 2018)
Built from git commit hash 65bc3149
Library directory: C:\Program Files (x86)\LyX 2.3\Resources\
User directory: ~\AppData\Roaming\LyX2.3\
Qt Version (run-time): 5.10.1
Qt Version (compile-time): 5.10.1


Of course your question concerned the comparison:

LyX Version 2.3.0
(06 July 2018)
Built from git commit hash 2a8c7061
Library directory: C:\Program Files (x86)\LyX 2.3\Resources\
User directory: ~\AppData\Roaming\LyX2.3\
Qt Version (run-time): 5.10.1
Qt Version (compile-time): 5.10.1

Re: Windows Installer for Testing


On 31/08/2018 16:09, Scott Kostyshak wrote:

On Fri, Aug 31, 2018 at 03:59:34PM +0200, Daniel wrote:

On 31/08/2018 15:18, Jean-Marc Lasgouttes wrote:

Le 31/08/2018 à 13:27, Daniel a écrit :

Unfortunately, LyX 2.3.1 is not usable for me. Many simple things
take a couple of seconds, like when I press enter for a new
paragraph, delete something, click on another paragraph, etc.


That is very very weird. I have to give it a go. A couple of seconds is
a lot.

JMarc


Yes it is (something between 2 to 4 second - but I guess any really
noticeable delay renders it unusable). I am now back to 2.3.0. No problems
there.


Thanks for testing, Daniel. When you go to Help > About, is the
information the same except for "2.3.1" instead of "2.3.0" ? (don't
re-install LyX 2.3.1 just to answer this question. I only ask in the
case that you have them installed side-by-side)

Scott


I actually re-installed it now to do some more testing for which I had 
no time before.


First, here is the information:

LyX Version 2.3.1
(30 August 2018)
Built from git commit hash 65bc3149
Library directory: C:\Program Files (x86)\LyX 2.3\Resources\
User directory: ~\AppData\Roaming\LyX2.3\
Qt Version (run-time): 5.10.1
Qt Version (compile-time): 5.10.1

Now to the testing:

It might be the same problem as plagued the 2.3.0 version at first. Once 
I have a bibliography included the delay is there (and the more 
bibliographies the worse). I can't find the posting from the last 
version but I seem to remember that Jürgen and Riki were involved in its 
solution.


Daniel

Re: Windows Installer for Testing

2018-08-31 Thread Scott Kostyshak

On Fri, Aug 31, 2018 at 03:59:34PM +0200, Daniel wrote:
> On 31/08/2018 15:18, Jean-Marc Lasgouttes wrote:
> > Le 31/08/2018 à 13:27, Daniel a écrit :
> > > Unfortunately, LyX 2.3.1 is not usable for me. Many simple things
> > > take a couple of seconds, like when I press enter for a new
> > > paragraph, delete something, click on another paragraph, etc.
> > 
> > That is very very weird. I have to give it a go. A couple of seconds is
> > a lot.
> > 
> > JMarc
> 
> Yes it is (something between 2 to 4 second - but I guess any really
> noticeable delay renders it unusable). I am now back to 2.3.0. No problems
> there.

Thanks for testing, Daniel. When you go to Help > About, is the
information the same except for "2.3.1" instead of "2.3.0" ? (don't
re-install LyX 2.3.1 just to answer this question. I only ask in the
case that you have them installed side-by-side)

Scott


signature.asc
Description: PGP signature

Re: Windows Installer for Testing


On 31/08/2018 15:18, Jean-Marc Lasgouttes wrote:

Le 31/08/2018 à 13:27, Daniel a écrit :
Unfortunately, LyX 2.3.1 is not usable for me. Many simple things take 
a couple of seconds, like when I press enter for a new paragraph, 
delete something, click on another paragraph, etc.


That is very very weird. I have to give it a go. A couple of seconds is 
a lot.


JMarc


Yes it is (something between 2 to 4 second - but I guess any really 
noticeable delay renders it unusable). I am now back to 2.3.0. No 
problems there.


Daniel

Re: Windows Installer for Testing

2018-08-31 Thread Jean-Marc Lasgouttes


Le 31/08/2018 à 13:27, Daniel a écrit :
Unfortunately, LyX 2.3.1 is not usable for me. Many simple things take a 
couple of seconds, like when I press enter for a new paragraph, delete 
something, click on another paragraph, etc.


That is very very weird. I have to give it a go. A couple of seconds is 
a lot.


JMarc

Re: Windows Installer for Testing


On 31/08/2018 00:52, Richard Kimberly Heck wrote:

Windows installers for 2.3.1 are at
http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. Please let me know if you
have any problems. But I know there are some weird issues with MiKTeX
right now, and I've seen signs of that in my own testing.

Riki


Unfortunately, LyX 2.3.1 is not usable for me. Many simple things take a 
couple of seconds, like when I press enter for a new paragraph, delete 
something, click on another paragraph, etc.


I used the non-bundle installer on Windows 10.

Reverting back to 2.3.0...

Daniel

Re: Windows Installer for Testing


On 31/08/2018 00:52, Richard Kimberly Heck wrote:

Windows installers for 2.3.1 are at
http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. Please let me know if you
have any problems. But I know there are some weird issues with MiKTeX
right now, and I've seen signs of that in my own testing.

Riki


Here are a couple of warnings from the log while installing ("for 
everyone on the computer"). But they have been there in the last 
versions, I think.


[...]
Configuring LyX (MiKTeX may download missing packages, this can take 
some time) ...

Operating on the shared (system-wide) MiKTeX setup
downloading 
https://ftp.acc.umu.se/mirror/CTAN/systems/win32/miktex/tm/packages/miktex-zzdb2-2.9.tar.lzma...

1026237 bytes, 2438.41 KB/Sec
updating package definition directory ("C:\Program Files\MiKTeX 
2.9\tpm\packages")...

installed 3048 package definition files
visiting repository 
https://ftp.acc.umu.se/mirror/CTAN/systems/win32/miktex/tm/packages/...

repository type: remote package repository
loading lightweight database...
downloading 
https://ftp.acc.umu.se/mirror/CTAN/systems/win32/miktex/tm/packages/miktex-zzdb1-2.9.tar.lzma...

180468 bytes, 2517.69 KB/Sec
Operating on the shared (system-wide) MiKTeX setup

Sorry, but "MiKTeX Package Manager" did not succeed.

The log file hopefully contains the information to get MiKTeX going again:

  C:/ProgramData/MiKTeX/2.9/miktex/log/mpmcli_admin.log

You may want to visit the MiKTeX project page, if you need help.
Configuring LyX (MiKTeX may download missing packages, this can take 
some time) ...

checking for DVI to DTL converter...
+checking for "dv2dt"...  no
checking for a Latex2e program...
+checking for "latex"...  yes
checking for a DVI postprocessing program...
+checking for "pplatex"...  no
checking for pLaTeX, the Japanese LaTeX...
+checking for "platex"...  no
latex: warning: running with administrator privileges
initexmf: warning: Option --admin should be specified when running this 
program with administrative privileges
initexmf: warning: Option --admin should be specified when running this 
program with administrative privileges

Re: Windows Installer for Testing


On 31/08/2018 00:52, Richard Kimberly Heck wrote:

Windows installers for 2.3.1 are at
http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. Please let me know if you
have any problems. But I know there are some weird issues with MiKTeX
right now, and I've seen signs of that in my own testing.

Riki


Just got the message attached again. One has to click on "More info" and 
"Run anyway". Maybe it is worth explaining this somewhere - just in 
case. Sorry, if I have missed that it is already. I should have taken a 
screenshot of the second screen as well. Next time.


Daniel

Re: Windows installer: extra discussion on dialog

2018-04-01 Thread Scott Kostyshak

On Sat, Mar 31, 2018 at 05:38:17PM +, Scott Kostyshak wrote:

> In addition to the actual wording of the dialog, there are a few other
> issues to discuss:

I think another question is:

4. What message should we display if the users chooses "Cancel" ?

I think there was some concern that a confused user would choose cancel
when that is not really what they wanted to choose. I think that we can
come up with a clear enough original message that this will not happen
often. But even if it does happen, we have a second chance to clear up
any confusion.

For example, we could put something like

  You have chosen to cancel the LyX installation. Please note that LyX
  2.3.0 cannot work without upgrading your MiKTeX installation to
  version 2.9. You can restart the LyX installation by just re-running
  the installer.

The above is not technically correct. As has been pointed out, if the
user just wants to use LyX to edit and not to compile, they can still do
that. But I think it's better to avoid that situation for the purpose of
clarity.

Scott

signature.asc
Description: PGP signature

Re: Windows Installer: Future Issues

2018-03-18 Thread Jürgen Spitzmüller

Am Samstag, den 17.03.2018, 21:32 -0400 schrieb Scott Kostyshak:
> I agree that the current text is confusing. I wonder if we can
> improve
> on the confusion by just saying something like
> 
> Unfortunately, official LyX 2.3.0 Windows binaries are not
> available
> at this time. The most recent LyX release that has official
> Windows
> binaries is 2.2.3. There are 2 Windows installer variants:
> 
> I will make that change.
> 
> If you think that it is still too confusing, and other developers
> also
> agree that we should hide that text, I can be convinced.

I am fine with that, but probably you should change the text below to

"For Cygwin, however, there is a binary for 2.3.0. It can be downloaded
here: lyx-2.3.0-cygwin.tar.gz."

Jürgen

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

Re: Windows Installer: Future Issues

2018-03-17 Thread Scott Kostyshak

On Sat, Mar 17, 2018 at 06:15:20PM +, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 15.03.2018, 15:08 -0400 schrieb Scott Kostyshak:
> > > Leaving 2.2.3 as it is?
> > 
> > Yes I think so. 
> 
> I suggest to hide the text mentioning the two installer variants (and
> pointing to 2.2.3). It probably irritates more than it helps, see
> http://www.lyx.org/trac/ticket/11079

I agree that the current text is confusing. I wonder if we can improve
on the confusion by just saying something like

Unfortunately, official LyX 2.3.0 Windows binaries are not available
at this time. The most recent LyX release that has official Windows
binaries is 2.2.3. There are 2 Windows installer variants:

I will make that change.

If you think that it is still too confusing, and other developers also
agree that we should hide that text, I can be convinced.

> The 2.2.3 binaries are still reachable, after all, via "Previous
> versions".

But that requires a few extra clicks.

> I'd also keep the link to the LyX for Windows wiki page, where Uwe or
> somebody else might add information should there be "inofficial"
> binaries we do not want to officially list on the website.

Agreed.

Scott

signature.asc
Description: PGP signature

Re: Windows Installer: Future Issues

2018-03-17 Thread Jürgen Spitzmüller

Am Donnerstag, den 15.03.2018, 15:08 -0400 schrieb Scott Kostyshak:
> > Leaving 2.2.3 as it is?
> 
> Yes I think so. 

I suggest to hide the text mentioning the two installer variants (and
pointing to 2.2.3). It probably irritates more than it helps, see
http://www.lyx.org/trac/ticket/11079

The 2.2.3 binaries are still reachable, after all, via "Previous
versions".

I'd also keep the link to the LyX for Windows wiki page, where Uwe or
somebody else might add information should there be "inofficial"
binaries we do not want to officially list on the website.

Jürgen


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

Re: Windows Installer: Future Issues

2018-03-16 Thread Scott Kostyshak

On Fri, Mar 16, 2018 at 07:53:56AM +, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > Yes I think so. After the text "There are 2 Windows installer
> > variants:", I think we could add the similar (adding just the version
> > info) text as in the announcement:
> > 
> >   Unfortunately, official LyX 2.3.0 Windows binaries are not available
> >   at this time.
> > 
> > Should we attempt to clarify the text in order to account for the
> > availability of Cygwin binaries? i.e. one might consider Cygwin binaries
> > to be "Windows binaries", and Cygwin binaries for 2.3.0 are available.
> > My current opinion is to not worry about that, but I'm open.
> 
> I wouldn't worry about that now either. Just make the release, the windows
> situation will need more time to be resolved. The statement above seems
> just fine.

Sounds good.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: Windows Installer: Future Issues

2018-03-16 Thread Pavel Sanda

Scott Kostyshak wrote:
> Yes I think so. After the text "There are 2 Windows installer
> variants:", I think we could add the similar (adding just the version
> info) text as in the announcement:
> 
>   Unfortunately, official LyX 2.3.0 Windows binaries are not available
>   at this time.
> 
> Should we attempt to clarify the text in order to account for the
> availability of Cygwin binaries? i.e. one might consider Cygwin binaries
> to be "Windows binaries", and Cygwin binaries for 2.3.0 are available.
> My current opinion is to not worry about that, but I'm open.

I wouldn't worry about that now either. Just make the release, the windows
situation will need more time to be resolved. The statement above seems
just fine.

Pavel

Re: Windows Installer: Future Issues

2018-03-15 Thread Scott Kostyshak

On Thu, Mar 15, 2018 at 08:28:44AM +, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > > I agree. I will remove the Windows binaries from the FTP, and announce
> > > 2.3.0 on Friday.
> > 
> > For the announce email I'm currently planning to put something like the
> > following:
> > 
> >   Unfortunately, official Windows binaries are not available at this
> >   time.
> 
> What you plan to do with Windows section in Download page?
> Leaving 2.2.3 as it is?

Yes I think so. After the text "There are 2 Windows installer
variants:", I think we could add the similar (adding just the version
info) text as in the announcement:

  Unfortunately, official LyX 2.3.0 Windows binaries are not available
  at this time.

Should we attempt to clarify the text in order to account for the
availability of Cygwin binaries? i.e. one might consider Cygwin binaries
to be "Windows binaries", and Cygwin binaries for 2.3.0 are available.
My current opinion is to not worry about that, but I'm open.

Any other suggestions?

Scott

signature.asc
Description: PGP signature

Re: Windows Installer: Future Issues

2018-03-15 Thread Pavel Sanda

Scott Kostyshak wrote:
> > I agree. I will remove the Windows binaries from the FTP, and announce
> > 2.3.0 on Friday.
> 
> For the announce email I'm currently planning to put something like the
> following:
> 
>   Unfortunately, official Windows binaries are not available at this
>   time.

What you plan to do with Windows section in Download page?
Leaving 2.2.3 as it is?

Pavel

Re: Windows Installer: Future Issues

2018-03-15 Thread Jürgen Spitzmüller

Am 15.03.2018 4:12 vorm. schrieb "Scott


I still have the hope that we can upload the Windows binaries soon.


I certainly hope so, too!

Jürgen


Scott

Re: Windows Installer: Future Issues

2018-03-14 Thread Scott Kostyshak

On Thu, Mar 15, 2018 at 03:12:26AM +, Scott Kostyshak wrote:
> On Wed, Mar 14, 2018 at 06:23:31AM +, Jürgen Spitzmüller wrote:
> 
> > I think (and I actually propose herewith) that we should release LyX 2.3.0
> > now, without the Windows installer.
> 
> I agree. I will remove the Windows binaries from the FTP, and announce
> 2.3.0 on Friday.

For the announce email I'm currently planning to put something like the
following:

  Unfortunately, official Windows binaries are not available at this
  time.

This hints at the following:

  1. unofficial Windows binaries might be available if users want them.
  2. "at this time" reflects my hope that we will be able to upload them
 at a later time.

Scott

signature.asc
Description: PGP signature

Re: Windows Installer: Future Issues

2018-03-14 Thread Scott Kostyshak

On Wed, Mar 14, 2018 at 06:23:31AM +, Jürgen Spitzmüller wrote:

> I think (and I actually propose herewith) that we should release LyX 2.3.0
> now, without the Windows installer.

I agree. I will remove the Windows binaries from the FTP, and announce
2.3.0 on Friday.

I still have the hope that we can upload the Windows binaries soon. I
will continue the lyx-users thread. Maybe if we come up with a dialog
that users on lyx-users agree would not be confusing, Uwe will be
interested in including the dialog.

Scott

signature.asc
Description: PGP signature

Re: Windows Installer: Future Issues

2018-03-14 Thread Jean-Marc Lasgouttes


Le 14/03/2018 à 12:52, Pavel Sanda a écrit :

Abdelrazak Younes wrote:

AFAIU, it is too late already.


2 weeks already...



Too bad!


It's actually exactly two weeks. LyX 2.3.0 already hit testing branch of Debian.
Maybe if we filed a request at ubuntu bugzilla we might still have chance, don't
know how strict they are with the march 1 deadline, but my guess is they are ;)
JMarc, you were active on their tracker no?


I am active fo things I understand (LyX bug). But Ubuntu policies is not 
part of what I understand.



Hmm, we are getting slower than conservative folks in debian... :)


Indeed.

JMarc

Re: Windows Installer: Future Issues

On Wed, Mar 14, 2018 at 12:23 PM, Pavel Sanda  wrote:

> Abdelrazak Younes wrote:
> > Thanks, I sometime read the devel list just for fun :-)
>
> That's a bizarre form of masochism :)
> Where do you live now, there were some rumors we might try to organize
> development meeting after the years...
>

Living close to Lausanne in Switzerland, well I guess we could organize one
here, I can book a nice meeting room for the week-end.

Abdel

Re: Windows Installer: Future Issues

2018-03-14 Thread Pavel Sanda

Abdelrazak Younes wrote:
> > > AFAIU, it is too late already.
> >
> > 2 weeks already...
> >
> 
> Too bad!

It's actually exactly two weeks. LyX 2.3.0 already hit testing branch of Debian.
Maybe if we filed a request at ubuntu bugzilla we might still have chance, don't
know how strict they are with the march 1 deadline, but my guess is they are ;)
JMarc, you were active on their tracker no?

Hmm, we are getting slower than conservative folks in debian... :)

Pavel

Re: Windows Installer: Future Issues

2018-03-14 Thread Pavel Sanda

Abdelrazak Younes wrote:
> Thanks, I sometime read the devel list just for fun :-)

That's a bizarre form of masochism :)
Where do you live now, there were some rumors we might try to organize
development meeting after the years...

Pavel

Re: Windows Installer: Future Issues

On Wed, Mar 14, 2018 at 11:14 AM, Pavel Sanda  wrote:

> Jean-Marc Lasgouttes wrote:
> > Le 14/03/2018 ?? 11:10, Abdelrazak Younes a écrit :
> >> By the way, you should definitely release now in order to get into next
> >> Ubuntu LTS release...
> >
> > AFAIU, it is too late already.
>
> 2 weeks already...
>

Too bad!


> Hi Abdel, nice to hear you again!! :)
>


Thanks, I sometime read the devel list just for fun :-)

You guys are still doing a great job, congratz for this release!

Abdel

Re: Windows Installer: Future Issues

2018-03-14 Thread Jean-Pierre Chrétien


Le 14/03/2018 à 02:43, Uwe Stöhr a écrit :

[...]



So the average user does not know how LaTeX works, what a package is and how it 
is installed or uninstalled.


Sure he does know if he installed LyX himself. as I pointed out in the other 
thread. I tried to be an average Window user (a bit difficult, as I am neither 
for LyX as I am experienced nor for Windows 10 as I know very little about it) 
and ran the last bundle installer.
The reference to MiKTeX is present throughout the installation process, 
particularly of course during the MiKTeX install itself, but also when MiKTeX 
installs missing LaTeX packages.


As I wrote, most of my students and colleagues at the University uses LyX for 
large documents without knowing anything about LaTeX.


Did they install themselves, or did some experienced guy did it for them?

Why don't you trust my experience in helping LyX users? Why should I lie to you 
with my experience?


I am convinced that none of us deny your experience and think that you are lying 
in any manner.


Therefore our main userbase are just users. The task of the installer is to 
provide a working LyX for them.
Users with more knowledge know what to do and how LaTeX works. Therefore I won't 
bother the majority of users with a decision they cannot make because lack of 
knowledge. I explained now a dozen times why I cannot allow these users to deny 
an update because then their LaTeX can be broken and they are lost.
The experienced users have already all possibilities to handle LaTeX differently 
as I wrote.


The current shortened version of the new dialog which could be inserted at the 
very beginning of the installation process is clearly addressed to people 
knowing something about MiKTeX.



The LyX installer requires to update MiKTeX to the newest 2.9 version.
If you use MiKTeX with other applications and do not want to update now,
cancel the LyX installation.
  Cancel Continue


Plain users are thus urged to continue without further hesitation, as you do in 
the bundle installer when it comes to the MiKTeX install:



${LangFileString} LatexInfo 'Now the installer of the LaTeX-distribution 
$\"MiKTeX$\" will be launched.$\r$\n\
57	To install the program press the 
$\"Next$\"-button in the installer windows until the installation begins.$\r$\n\

58  $\r$\n\
59	!!! Please use all default options of the 
MiKTeX-installer !!!'



[...]



I do not know how we should resolve this matter now. But, longer term,
we need someone to create a Windows installer that JUST installs LyX,
much the way the OSX installer does. As JMarc said, users on OSX seem to
manage to install a LaTeX distribution, etc, independently. Surely
Windows users can manage to do the same.


I cannot accept that you are telling me what is good for Windows users. I 
explained my decision but you are not understanding. Why don't you try it out 
yourself to see what can happen?


Nobody here wants to tell you what is good for Windows users, the question 
raised is about what is good for the future of LyX. The present situation shows 
clearly that the packaging approach has attained some limits.
I understand that you may be exhausted to explain again and again to Linux users 
(accustomed to global OS packaging e.g. with experimental, unstable, testing and 
stable releases) that Windows is such a weird OS with lots of software 
instabilities that proposing a  LyX packaging is the only way to make LyX work. 
But the debate must take place in a non passionate manner, later on.


The urgent action is the 2.3.0 release.

--
Jean-Pierre

Re: Windows Installer: Future Issues

2018-03-14 Thread Pavel Sanda

Jean-Marc Lasgouttes wrote:
> Le 14/03/2018 ?? 11:10, Abdelrazak Younes a écrit :
>> By the way, you should definitely release now in order to get into next 
>> Ubuntu LTS release...
>
> AFAIU, it is too late already.

2 weeks already...

Hi Abdel, nice to hear you again!! :)

Pavel

Re: Windows Installer: Future Issues

2018-03-14 Thread Jean-Marc Lasgouttes


Le 14/03/2018 à 11:10, Abdelrazak Younes a écrit :
By the way, you should definitely release now in order to get into next 
Ubuntu LTS release...


AFAIU, it is too late already.

JMarc

PS: Hi Abdel!

Re: Windows Installer: Future Issues

By the way, you should definitely release now in order to get into next
Ubuntu LTS release...


On Wed, Mar 14, 2018 at 11:05 AM, Abdelrazak Younes  wrote:

> Hi Guys,
>
> In the old days we had the Friday rule for fight... you should restore the
> tradition :-)
>
> Cheers,
> Abdel
>
>
> On Wed, Mar 14, 2018 at 7:23 AM, Jürgen Spitzmüller  wrote:
>
>> Dear all,
>>
>> I have kept calm in this debate until now, but since this is getting more
>> and more ridiculous, here is my position.
>>
>> I think (and I actually propose herewith) that we should release LyX
>> 2.3.0 now, without the Windows installer.
>>
>> It is unacceptable that one single developer holds up a major release
>> while refusing to accept (1) the majority position (actually, the position
>> of _any_ other developer besides himself) and (2) even the release
>> manager's decision.
>>
>> It seems clear that Uwe holds the view that he is the only person who
>> knows what Windows users want and need, and how the installer has to look
>> like. I am sure he has reasons to believe this, but under this condition, I
>> do not consider the Windows installer a part of this community project,
>> since a community project requires that developers accept (1) and (2)
>> above. Since this is an open source (and GPLed) software, Uwe is free to
>> release "his" installer somewhere else, in the shape and form he consider
>> "right", and he does not need to bother with our "unqualified" arguments.
>>
>> With all due respect to Uwe as a person and as a developer. But we cannot
>> proceed like this.
>>
>> Jürgen
>>
>
>

Re: Windows Installer: Future Issues

Hi Guys,

In the old days we had the Friday rule for fight... you should restore the
tradition :-)

Cheers,
Abdel


On Wed, Mar 14, 2018 at 7:23 AM, Jürgen Spitzmüller  wrote:

> Dear all,
>
> I have kept calm in this debate until now, but since this is getting more
> and more ridiculous, here is my position.
>
> I think (and I actually propose herewith) that we should release LyX 2.3.0
> now, without the Windows installer.
>
> It is unacceptable that one single developer holds up a major release
> while refusing to accept (1) the majority position (actually, the position
> of _any_ other developer besides himself) and (2) even the release
> manager's decision.
>
> It seems clear that Uwe holds the view that he is the only person who
> knows what Windows users want and need, and how the installer has to look
> like. I am sure he has reasons to believe this, but under this condition, I
> do not consider the Windows installer a part of this community project,
> since a community project requires that developers accept (1) and (2)
> above. Since this is an open source (and GPLed) software, Uwe is free to
> release "his" installer somewhere else, in the shape and form he consider
> "right", and he does not need to bother with our "unqualified" arguments.
>
> With all due respect to Uwe as a person and as a developer. But we cannot
> proceed like this.
>
> Jürgen
>

Re: Windows Installer: Future Issues

2018-03-14 Thread Jürgen Spitzmüller

Dear all,

I have kept calm in this debate until now, but since this is getting more
and more ridiculous, here is my position.

I think (and I actually propose herewith) that we should release LyX 2.3.0
now, without the Windows installer.

It is unacceptable that one single developer holds up a major release while
refusing to accept (1) the majority position (actually, the position of
_any_ other developer besides himself) and (2) even the release manager's
decision.

It seems clear that Uwe holds the view that he is the only person who knows
what Windows users want and need, and how the installer has to look like. I
am sure he has reasons to believe this, but under this condition, I do not
consider the Windows installer a part of this community project, since a
community project requires that developers accept (1) and (2) above. Since
this is an open source (and GPLed) software, Uwe is free to release "his"
installer somewhere else, in the shape and form he consider "right", and he
does not need to bother with our "unqualified" arguments.

With all due respect to Uwe as a person and as a developer. But we cannot
proceed like this.

Jürgen

Re: Windows Installer: Future Issues

2018-03-13 Thread Richard Heck

On 03/13/2018 09:43 PM, Uwe Stöhr wrote:
> Am 12.03.2018 um 04:32 schrieb Richard Heck:
>
>> That is a serious mistake: to focus on "average users". But it has
>> clearly become pointless to discuss this any longer.
>
> Dear Richard,
>
> I cannot leave this commented because it is too fundamental. I tried
> to calm down, but cannot.

Pardon me if this seems presumptuous, but it does seem to me as if you
are much too invested,
emotionally, in these issues. We are talking about software.

> What is LyX for? It is a frontend for LaTeX. It is designed to hide
> LaTeX from the users. 

That is your opinion, I understand. But I disagree. It is true that LyX
makes it possible to
take advantage of LaTeX's typesetting abilities without knowing anything
about LaTeX
*as long as your needs are very basic*. It is misleading to tell people
anything else, and I do
not myself see why we should cater specially to users whose needs remain
at such a basic
level. To me, what is most valuable about LyX is how it *eases the
learning curve* for
people who are new to LaTeX. Honestly: Look at the kinds of posts we get
on lyx-users.
The great majority of these are actually about LaTeX. I wonder how many
users we LOSE
because of false advertising: users who think LyX will make it possible
for them to do all
kinds of things that you simply can't do without knowing some LaTeX.
E.g., change how
section titles are displayed. It's a very simple thing to want to do,
but it is actually very
hard to do in LyX, as opposed to Word, and for good reason.

There's a real change of mindset involved in moving from Word etc to LyX
and LaTeX
that we understate at our peril.

>> It has become a serious problem the extent to which *MiKTeX* bugs now
>> delay LyX releases,
>
> When did we had the last time a delay because of a bug in MiKTeX?

There have been at least two such occasions since I've been branch
maintainer. I can
look up the emails if you like. And this one has been really painful,
requiring three or
four different installers before we even got to the release.

> We had much, much more problems in the past with ImageMagick. I had to
> create
> many installer builds because of this program.

I know, and I have had to upload them. This is just the same problem.
LyX should not be
integrated with such programs the way it apparently is on Windows. OSX
and Linux users
do not have these issues. We do not need new installers, because the
installation of LyX is
independent of these other programs. They can be upgraded independently,
if users need
new features or bug fixes, or not, if they do not. I do not see why we
cannot do something
similar on Windows.

>> LyX was never meant to be so closely integrated with a particular LaTeX
>> distribution, and it was a mistake to make it so.
>
> Again, please try our LyX under windows by yourself before you continue.
> take a Win users without knowledge of LaTeX and they should use TeXLive. 

I am not saying you should integrate LyX instead with TeXLive. I am
saying that it
would be a lot better for everyone if the Windows installer, just as on
OSX or Linux,
ONLY installed LyX and did not try to manage everything else. To try to
do what you
have been trying to do is to try to do something *impossible*.

Please read what follows carefully.

I do understand why you'd like to manage everything on which LyX
depends: TeX,
ImageMagick, etc, etc, etc. It's a great idea to have a package
management system
that handles all those dependencies. But you are consigning yourself to
misery if you
are going to try create such a thing yourself on Windows just for LyX.
The various
Linux distributions have HUGE TEAMS of people who work on nothing else.
It is
a HUGE project to do this. Linxu distros are incredibly careful about
what updates they
incorporate into various releases; they distinguish 'long term' releases
from 'bleeding
edge' releases; and so forth. Whereas LyX on Windows, by contrast, seems
to be
vulnerable to every update of every piece of software on which it
depends. That
makes LyX, or our users, way too vulnerable to bugs that turn up in
other programs
on which we rely. Ask José about it. He has a lot of experience. And the
problems
we have just had with MiKTeX make this all the more apparent.

Granted, users who decided to install MiKTeX with LyX would still have
those
problems. But then those would be *MiKTeX* problems, not our problems, and
not problems that would delay the release of a MAJOR version for a week
or more.
Can't you see how ridiculous that is?

It's a valiant effort what you are trying to do, but in the end it has
created a huge
problem both for you and for the rest of the LyX community.

Richard

Re: Windows Installer: Future Issues

2018-03-13 Thread Uwe Stöhr


Am 12.03.2018 um 04:32 schrieb Richard Heck:


That is a serious mistake: to focus on "average users". But it has
clearly become pointless to discuss this any longer.


Dear Richard,

I cannot leave this commented because it is too fundamental. I tried to 
calm down, but cannot.


What is LyX for? It is a frontend for LaTeX. It is designed to hide 
LaTeX from the users. Because of this I came once to LyX: "Cool, I don't 
have to learn LaTeX but can use it!". This way I used it for about a 
year for internship protocols at the University. So long after I came to 
LyX I started to learn what is behind it.
As new LyX user you will first learn in sec. 6 of the UserGuide 
something of LaTeX and there also not about package handling.
( Users liking to work with LaTeX directly can and will use other 
editors like TeXWorks.)


So the average user does not know how LaTeX works, what a package is and 
how it is installed or uninstalled.
As I wrote, most of my students and colleagues at the University uses 
LyX for large documents without knowing anything about LaTeX.
Why don't you trust my experience in helping LyX users? Why should I lie 
to you with my experience?


Therefore our main userbase are just users. The task of the installer is 
to provide a working LyX for them.
Users with more knowledge know what to do and how LaTeX works. Therefore 
I won't bother the majority of users with a decision they cannot make 
because lack of knowledge. I explained now a dozen times why I cannot 
allow these users to deny an update because then their LaTeX can be 
broken and they are lost.
The experienced users have already all possibilities to handle LaTeX 
differently as I wrote.


I won't repeat this anymore now. Please add an appropriate sentence to 
the announcement or release notes for the experienced users that then 
will have to set "Never" in miktex for the package handling if they like 
to. But also tell them the risks of this.



I do not know how we should resolve this matter now. But, longer term,
we need someone to create a Windows installer that JUST installs LyX,
much the way the OSX installer does. As JMarc said, users on OSX seem to
manage to install a LaTeX distribution, etc, independently. Surely
Windows users can manage to do the same.


I cannot accept that you are telling me what is good for Windows users. 
I explained my decision but you are not understanding. Why don't you try 
it out yourself to see what can happen?


I would also not start a debate how to handle with LyX under Mac or 
Linux because I don't know these OSes or don't use them. Do you use 
MiKTeX? Do you use LyX under Windows? Do you know LyX Windows users who 
don't know LaTeX? So why do you state what is good for them?



It has become a serious problem the extent to which *MiKTeX* bugs now
delay LyX releases,


When did we had the last time a delay because of a bug in MiKTeX? We had 
much, much more problems in the past with ImageMagick. I had to create 
many installer builds because of this program.



LyX was never meant to be so closely integrated with a particular LaTeX
distribution, and it was a mistake to make it so.


Again, please try our LyX under windows by yourself before you continue. 
take a Win users without knowledge of LaTeX and they should use TeXLive. 
Then you'll see.
It is unacceptable that you tell me what mistakes I made. You know 
nothing about TeXLive and its problem in the past. We had many 
discussions with users and the current installer is the result. For more 
than 10 years I provide it and spent hundreds of ours in supporting 
users. I tried to fix problem, as fast as possible.


I give up now.
Uwe

Re: Windows Installer: Future Issues

2018-03-11 Thread Richard Heck

On 03/12/2018 12:44 AM, Andrew Parsloe wrote:
> On 12/03/2018 4:32 p.m., Richard Heck wrote:
>> On 03/11/2018 04:52 PM, Uwe Stöhr wrote:
>>> Am 11.03.2018 um 18:12 schrieb Scott Kostyshak:
>>>
 I think that's what we're doing. The basic disagreement we have is
 that
 I think adding a dialog will bring more benefit than harm.
>>> And I made clear why I am opposed to this.
>>> In the end it costs my spare time if something does not work. Users
>>> will contact me in this case. Therefore I focus on average users.
>> That is a serious mistake: to focus on "average users". But it has
>> clearly become pointless to discuss this any longer.
>>
>> If users are contacting YOU because of issues with the installer, then
>> that is the problem, as others have already said.
>>
>> I do not know how we should resolve this matter now. But, longer term,
>> we need someone to create a Windows installer that JUST installs LyX,
>> much the way the OSX installer does. As JMarc said, users on OSX seem to
>> manage to install a LaTeX distribution, etc, independently. Surely
>> Windows users can manage to do the same.
>>
>> It has become a serious problem the extent to which *MiKTeX* bugs now
>> delay LyX releases, require updated installers (two or three for every
>> minor version), and the like. And the problems of 'average users', so
>> far as I can see, are almost all due to tight integration with MiKTeX.
>> It is far from clear to me why we actively promote, and almost require,
>> on Windows, the use of a LaTeX distribution that is so unstable that
>> simply reconfiguring LyX can (apparently) break it.
>>
>> LyX was never meant to be so closely integrated with a particular LaTeX
>> distribution, and it was a mistake to make it so. I understand the
>> desire to offer a simpler installation process that gives the user a
>> fully functional LyX installation (though, since no such thing is
>> offered on any other platform, I'm a bit skeptical about how essential
>> this really is). But, at the very least, if we are going to 'integrate'
>> some LaTeX distribution into an offical LyX product, then we should make
>> it one that is stable: the LaTeX equivalent of an Ubuntu LTS release,
>> that cannot so easily be broken.
>>
>> Richard
>>
> Uwe provides two installers at present, one of which does NOT install
> MiKTeX and which could be used, if I understand right, with any LaTeX
> distribution (or at least TeXLive or MiKTeX). This is the one that
> I've always used -- mainly from using dial up until a few years ago. 
> The bundle installer was far too big to download by dial up. I used
> Uwe's installer-1 for 2.3.0 and have used 2.3.0 every day through the
> problem period without issues. Possibly the lack of problems for me is
> because I didn't use the MiKTeX console for updating MiKTeX but the
> older update program (miktex-update_admin.exe). (In fact I wasn't
> aware that there was such a thing as the console until reading about
> it in the present discussion.)

I know there are these two installers, but it was my understanding from
the present discussion that even the basic installer was affected by the
MiKTeX bugs we've been fighting. Perhaps I misunderstood, but Scott
asked a very explicit question along those lines.

If you're right, then perhaps what we need to do is simply offer the
basic installer 'officially' and not the bundle.

Richard

Re: Windows Installer: Future Issues

2018-03-11 Thread Andrew Parsloe


On 12/03/2018 4:32 p.m., Richard Heck wrote:

On 03/11/2018 04:52 PM, Uwe Stöhr wrote:

Am 11.03.2018 um 18:12 schrieb Scott Kostyshak:


I think that's what we're doing. The basic disagreement we have is that
I think adding a dialog will bring more benefit than harm.

And I made clear why I am opposed to this.
In the end it costs my spare time if something does not work. Users
will contact me in this case. Therefore I focus on average users.

That is a serious mistake: to focus on "average users". But it has
clearly become pointless to discuss this any longer.

If users are contacting YOU because of issues with the installer, then
that is the problem, as others have already said.

I do not know how we should resolve this matter now. But, longer term,
we need someone to create a Windows installer that JUST installs LyX,
much the way the OSX installer does. As JMarc said, users on OSX seem to
manage to install a LaTeX distribution, etc, independently. Surely
Windows users can manage to do the same.

It has become a serious problem the extent to which *MiKTeX* bugs now
delay LyX releases, require updated installers (two or three for every
minor version), and the like. And the problems of 'average users', so
far as I can see, are almost all due to tight integration with MiKTeX.
It is far from clear to me why we actively promote, and almost require,
on Windows, the use of a LaTeX distribution that is so unstable that
simply reconfiguring LyX can (apparently) break it.

LyX was never meant to be so closely integrated with a particular LaTeX
distribution, and it was a mistake to make it so. I understand the
desire to offer a simpler installation process that gives the user a
fully functional LyX installation (though, since no such thing is
offered on any other platform, I'm a bit skeptical about how essential
this really is). But, at the very least, if we are going to 'integrate'
some LaTeX distribution into an offical LyX product, then we should make
it one that is stable: the LaTeX equivalent of an Ubuntu LTS release,
that cannot so easily be broken.

Richard

Uwe provides two installers at present, one of which does NOT install 
MiKTeX and which could be used, if I understand right, with any LaTeX 
distribution (or at least TeXLive or MiKTeX). This is the one that I've 
always used -- mainly from using dial up until a few years ago.  The 
bundle installer was far too big to download by dial up. I used Uwe's 
installer-1 for 2.3.0 and have used 2.3.0 every day through the problem 
period without issues. Possibly the lack of problems for me is because I 
didn't use the MiKTeX console for updating MiKTeX but the older update 
program (miktex-update_admin.exe). (In fact I wasn't aware that there 
was such a thing as the console until reading about it in the present 
discussion.)


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Windows Installer could use work: must set miktex packages

2015-03-22 Thread roy canseco

This solution worked for me. Windows 8.1. LyX Version 2.1.3 bundled with 
MikTex.

Thanks!  :)

Re: Windows Installer could use work: must set miktex packages

2015-03-22 Thread roy canseco

This solution worked for me. Windows 8.1. LyX Version 2.1.3 bundled with 
MikTex.

Thanks!  :)

Re: Windows installer for LyX 2.0.4

2012-07-08 Thread Uwe Stöhr


Am 05.07.2012 06:48, schrieb Liviu Andronic:


What about spaces in path names of files? I was quite surprised that
LyX couldn't handle that on Windows,


That is not true. LyX can handle them of course. Spaces in paths even exists in Windows' default 
installation folders. If you find a case where LyX fails, please report it as bug.


regards Uwe

Re: Windows installer for LyX 2.0.4

2012-07-08 Thread Liviu Andronic

On Sun, Jul 8, 2012 at 4:38 PM, Uwe Stöhr uwesto...@web.de wrote:
 What about spaces in path names of files? I was quite surprised that
 LyX couldn't handle that on Windows,

 That is not true. LyX can handle them of course. Spaces in paths even exists
 in Windows' default installation folders. If you find a case where LyX
 fails, please report it as bug.

I will investigate that when I get the chance.

Thanks
Liviu

Re: Windows installer for LyX 2.0.4

2012-07-08 Thread Uwe Stöhr


Am 05.07.2012 06:48, schrieb Liviu Andronic:


What about spaces in path names of files? I was quite surprised that
LyX couldn't handle that on Windows,


That is not true. LyX can handle them of course. Spaces in paths even exists in Windows' default 
installation folders. If you find a case where LyX fails, please report it as bug.


regards Uwe

Re: Windows installer for LyX 2.0.4

2012-07-08 Thread Liviu Andronic

On Sun, Jul 8, 2012 at 4:38 PM, Uwe Stöhr  wrote:
>> What about spaces in path names of files? I was quite surprised that
>> LyX couldn't handle that on Windows,
>
> That is not true. LyX can handle them of course. Spaces in paths even exists
> in Windows' default installation folders. If you find a case where LyX
> fails, please report it as bug.
>
I will investigate that when I get the chance.

Thanks
Liviu

Re: Windows installer for LyX 2.0.4

2012-07-04 Thread Uwe Stöhr


Am 04.07.2012 00:28, schrieb Richard Heck:


You Windows people should decide what makes sense.


As I have shown in my screenshot the other programs use also the scheme Name major.sub, so LyX 
2.0 would be the same.



I'm allergic to spaces in pathnames myself.


They are not a problem. I was using this for years in the old installer and also the other progrmas 
use spaces, see my screenshot.


So this topic is now solved.

regards Uwe

Re: Windows installer for LyX 2.0.4

2012-07-04 Thread Liviu Andronic

On Wed, Jul 4, 2012 at 11:31 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 04.07.2012 00:28, schrieb Richard Heck:
 I'm allergic to spaces in pathnames myself.

 They are not a problem. I was using this for years in the old installer and
 also the other progrmas use spaces, see my screenshot.

 So this topic is now solved.

What about spaces in path names of files? I was quite surprised that
LyX couldn't handle that on Windows, and this could be a psychological
hurdle to Windows users.

Liviu

Re: Windows installer for LyX 2.0.4

2012-07-04 Thread Uwe Stöhr


Am 04.07.2012 00:28, schrieb Richard Heck:


You Windows people should decide what makes sense.


As I have shown in my screenshot the other programs use also the scheme "Name major.sub", so "LyX 
2.0" would be the same.



I'm allergic to spaces in pathnames myself.


They are not a problem. I was using this for years in the old installer and also the other progrmas 
use spaces, see my screenshot.


So this topic is now solved.

regards Uwe

Re: Windows installer for LyX 2.0.4

2012-07-04 Thread Liviu Andronic

On Wed, Jul 4, 2012 at 11:31 PM, Uwe Stöhr  wrote:
> Am 04.07.2012 00:28, schrieb Richard Heck:
>> I'm allergic to spaces in pathnames myself.
>
> They are not a problem. I was using this for years in the old installer and
> also the other progrmas use spaces, see my screenshot.
>
> So this topic is now solved.
>
What about spaces in path names of files? I was quite surprised that
LyX couldn't handle that on Windows, and this could be a psychological
hurdle to Windows users.

Liviu

Re: Windows installer for LyX 2.0.4


Le 03/07/2012 01:57, Uwe Stöhr a écrit :

So how about if we propose LyX20, and then if someone wants to install
various things side-by-side,
can't they do that by choosing some other name?


Yes, but if he is not patient, he just clicks Next and thus installs in
the proposed/default LyX20 folder and overwrites the existing
installation.


So this is the case of a user who has a special need, but is not patient 
enough to check how to satisfy it? Is this our problem?


Are there people who want their updates to MS Word to install in a 
different directory (Program Files\Microsoft\Word 2012.sp3-fix005\)?


JMarc

Re: Windows installer for LyX 2.0.4


Le 02/07/2012 23:15, Uwe Stöhr a écrit :

There is no other software I know where I do this. Besides, there is a
difference between to be
able to install side-by-side and to install side-by-side by default.


Attached is a screen shot of my Start menu. As I have about 120 programs
I have to group them not to loose the overview.
And yes, other programs also do this: Python, CMake, LibreOffice, Qt...
Not all programs but some. I guess that is a matter of tested, but I use
LyX 2.0.4 as proposition because of the side-by side installation
issue we discussed.


Very good example ! Cmake 2.8 is probably cmake 2.8.8. LibreOffice 3.5 
is actually 3.5.4. Python has a minor version number too. Don't you see 
that it just disprove your point?


JMarc

Re: Windows installer for LyX 2.0.4


On 07/03/2012 05:17 AM, Jean-Marc Lasgouttes wrote:

Le 03/07/2012 01:57, Uwe Stöhr a écrit :

So how about if we propose LyX20, and then if someone wants to install
various things side-by-side,
can't they do that by choosing some other name?


Yes, but if he is not patient, he just clicks Next and thus installs in
the proposed/default LyX20 folder and overwrites the existing
installation.


So this is the case of a user who has a special need, but is not 
patient enough to check how to satisfy it? Is this our problem?


That's my thought, too: In the special case where the person *doesn't* 
want to over-write the installation, they will need to take special 
care, and will expect to need to take special care, since every other 
program installs over the old one, by default, when only minor versions 
are changing.


Richard

Re: Windows installer for LyX 2.0.4

2012-07-03 Thread Uwe Stöhr


Am 03.07.2012 11:20, schrieb Jean-Marc Lasgouttes:


Attached is a screen shot of my Start menu. As I have about 120 programs
I have to group them not to loose the overview.
And yes, other programs also do this: Python, CMake, LibreOffice, Qt...
Not all programs but some. I guess that is a matter of tested, but I use
LyX 2.0.4 as proposition because of the side-by side installation
issue we discussed.


Very good example ! Cmake 2.8 is probably cmake 2.8.8. LibreOffice 3.5 is 
actually 3.5.4. Python has
a minor version number too. Don't you see that it just disprove your point?


Convinced. I thought again about yours and also Richard's argument from 
yesterday.
It is only Qt that uses the full version number in the folder name. You both are also right that 
these users who prefer to install LyX side by side still can do this by using another name.

So can we agree to use the name LyX 2.0 as folder name?

regards Uwe

Re: Windows installer for LyX 2.0.4

2012-07-03 Thread Andrew Parsloe


On 4/07/2012 6:28 a.m., Richard Heck wrote:

On 07/03/2012 05:17 AM, Jean-Marc Lasgouttes wrote:

Le 03/07/2012 01:57, Uwe Stöhr a écrit :

So how about if we propose LyX20, and then if someone wants to install
variou things side-by-side,
can't they do that by choosing some other name?


Yes, but if he is not patient, he just clicks Next and thus installs in
the proposed/default LyX20 folder and overwrites the existing
installation.


So this is the case of a user who has a special need, but is not
patient enough to check how to satisfy it? Is this our problem?


That's my thought, too: In the special case where the person *doesn't*
want to over-write the installation, they will need to take special
care, and will expect to need to take special care, since every other
program installs over the old one, by default, when only minor versions
are changing.

Richard

I was in favour of using a LyX 2.0.4 folder but this is a valid point. 
I already change the suggested installation folder (from C:/Program 
files ... to E:/Program files ...). It would be no hardship to make an 
additional change from LyX20 to LyX 2.0.x.


Andrew

Re: Windows installer for LyX 2.0.4


On 07/03/2012 02:49 PM, Uwe Stöhr wrote:

Am 03.07.2012 11:20, schrieb Jean-Marc Lasgouttes:

Attached is a screen shot of my Start menu. As I have about 120 
programs

I have to group them not to loose the overview.
And yes, other programs also do this: Python, CMake, LibreOffice, Qt...
Not all programs but some. I guess that is a matter of tested, but I 
use

LyX 2.0.4 as proposition because of the side-by side installation
issue we discussed.


Very good example ! Cmake 2.8 is probably cmake 2.8.8. LibreOffice 
3.5 is actually 3.5.4. Python has
a minor version number too. Don't you see that it just disprove your 
point?


Convinced. I thought again about yours and also Richard's argument 
from yesterday.
It is only Qt that uses the full version number in the folder name. 
You both are also right that these users who prefer to install LyX 
side by side still can do this by using another name.

So can we agree to use the name LyX 2.0 as folder name?

You Windows people should decide what makes sense. I'm allergic to 
spaces in pathnames myself.


Richard

Re: Windows installer for LyX 2.0.4


Le 03/07/2012 01:57, Uwe Stöhr a écrit :

So how about if we propose LyX20, and then if someone wants to install
various things side-by-side,
can't they do that by choosing some other name?


Yes, but if he is not patient, he just clicks Next and thus installs in
the proposed/default "LyX20" folder and overwrites the existing
installation.


So this is the case of a user who has a special need, but is not patient 
enough to check how to satisfy it? Is this our problem?


Are there people who want their updates to MS Word to install in a 
different directory (Program Files\Microsoft\Word 2012.sp3-fix005\)?


JMarc

Re: Windows installer for LyX 2.0.4


Le 02/07/2012 23:15, Uwe Stöhr a écrit :

There is no other software I know where I do this. Besides, there is a
difference between "to be
able to install side-by-side" and "to install side-by-side by default".


Attached is a screen shot of my Start menu. As I have about 120 programs
I have to group them not to loose the overview.
And yes, other programs also do this: Python, CMake, LibreOffice, Qt...
Not all programs but some. I guess that is a matter of tested, but I use
"LyX 2.0.4" as proposition because of the side-by side installation
issue we discussed.


Very good example ! Cmake 2.8 is probably cmake 2.8.8. LibreOffice 3.5 
is actually 3.5.4. Python has a minor version number too. Don't you see 
that it just disprove your point?


JMarc

Re: Windows installer for LyX 2.0.4


On 07/03/2012 05:17 AM, Jean-Marc Lasgouttes wrote:

Le 03/07/2012 01:57, Uwe Stöhr a écrit :

So how about if we propose LyX20, and then if someone wants to install
various things side-by-side,
can't they do that by choosing some other name?


Yes, but if he is not patient, he just clicks Next and thus installs in
the proposed/default "LyX20" folder and overwrites the existing
installation.


So this is the case of a user who has a special need, but is not 
patient enough to check how to satisfy it? Is this our problem?


That's my thought, too: In the special case where the person *doesn't* 
want to over-write the installation, they will need to take special 
care, and will expect to need to take special care, since every other 
program installs over the old one, by default, when only minor versions 
are changing.


Richard

Re: Windows installer for LyX 2.0.4

2012-07-03 Thread Uwe Stöhr


Am 03.07.2012 11:20, schrieb Jean-Marc Lasgouttes:


Attached is a screen shot of my Start menu. As I have about 120 programs
I have to group them not to loose the overview.
And yes, other programs also do this: Python, CMake, LibreOffice, Qt...
Not all programs but some. I guess that is a matter of tested, but I use
"LyX 2.0.4" as proposition because of the side-by side installation
issue we discussed.


Very good example ! Cmake 2.8 is probably cmake 2.8.8. LibreOffice 3.5 is 
actually 3.5.4. Python has
a minor version number too. Don't you see that it just disprove your point?


Convinced. I thought again about yours and also Richard's argument from 
yesterday.
It is only Qt that uses the full version number in the folder name. You both are also right that 
these users who prefer to install LyX side by side still can do this by using another name.

So can we agree to use the name "LyX 2.0" as folder name?

regards Uwe

Re: Windows installer for LyX 2.0.4

2012-07-03 Thread Andrew Parsloe


On 4/07/2012 6:28 a.m., Richard Heck wrote:

On 07/03/2012 05:17 AM, Jean-Marc Lasgouttes wrote:

Le 03/07/2012 01:57, Uwe Stöhr a écrit :

So how about if we propose LyX20, and then if someone wants to install
variou things side-by-side,
can't they do that by choosing some other name?


Yes, but if he is not patient, he just clicks Next and thus installs in
the proposed/default "LyX20" folder and overwrites the existing
installation.


So this is the case of a user who has a special need, but is not
patient enough to check how to satisfy it? Is this our problem?


That's my thought, too: In the special case where the person *doesn't*
want to over-write the installation, they will need to take special
care, and will expect to need to take special care, since every other
program installs over the old one, by default, when only minor versions
are changing.

Richard

I was in favour of using a "LyX 2.0.4" folder but this is a valid point. 
I already change the suggested installation folder (from C:/Program 
files ... to E:/Program files ...). It would be no hardship to make an 
additional change from "LyX20" to "LyX 2.0.x".


Andrew

Re: Windows installer for LyX 2.0.4


On 07/03/2012 02:49 PM, Uwe Stöhr wrote:

Am 03.07.2012 11:20, schrieb Jean-Marc Lasgouttes:

Attached is a screen shot of my Start menu. As I have about 120 
programs

I have to group them not to loose the overview.
And yes, other programs also do this: Python, CMake, LibreOffice, Qt...
Not all programs but some. I guess that is a matter of tested, but I 
use

"LyX 2.0.4" as proposition because of the side-by side installation
issue we discussed.


Very good example ! Cmake 2.8 is probably cmake 2.8.8. LibreOffice 
3.5 is actually 3.5.4. Python has
a minor version number too. Don't you see that it just disprove your 
point?


Convinced. I thought again about yours and also Richard's argument 
from yesterday.
It is only Qt that uses the full version number in the folder name. 
You both are also right that these users who prefer to install LyX 
side by side still can do this by using another name.

So can we agree to use the name "LyX 2.0" as folder name?

You Windows people should decide what makes sense. I'm allergic to 
spaces in pathnames myself.


Richard

Re: Windows installer for LyX 2.0.4

2012-07-02 Thread Andrew Parsloe

I'm by now an experienced Windows (Vista) user of LyX. Doubtless I'm 
adding fuel to the flames rather than oil on troubled waters, but ...


On 2/07/2012 12:33 p.m., Uwe Stöhr wrote:

Am 28.06.2012 11:23, schrieb Vincent van Ravesteijn:


But then you don't get a full functional LyX. We cannot surpass the
package installations, see me last 2 mails.

Even if we add an option Surpass the LaTeX package installation what
do you expect a new user who has never worked with LaTeX nor know what
LaTeX is will do?


Surpass? A nice combination of bypass and suppress.




The reason why I don't accept this installer now is that:
- the installer installs LyX in a folder called: LyX 2.0.4 instead of
LyX20 as the current official
installer does. I really don't see a single reason to change this
behaviour;


There is also no reason not to change the name of the folder. I already
also explained that we can easily change the name to somewhat else but
need the info about the bugfix release. If is perfectly valid to install
LyX 2.0.4 and leave 2.0.3 as backup and some users do this (e.g. if they
write a large document like a thesis).


I find the LyX 2.0.4 naming useful. For example, when LyX moved from 
2.0.1 to 2.0.2 it brought problems on my system: sticky scrolling, and 
memory leakage which caused a number of crashes, and I needed to revert 
to 2.0.1. I like to be able to install the latest version side by side 
with the previous one until I'm comfortable that it works properly. I've 
just installed 2.0.4 beside 2.0.3.





- this means that you have to manually uninstall the previous version
each time;

  - this also means that you have to manually uninstall the previous
version _before_ installing
  the new version;

No. If this is necessary for you, you find a bug in the installer. It
must be allowed to install LyX 2.0.4 to a system where already LyX 2.0.3
exists.



I've had no problems uninstalling afterwards. Just to check, I've 
uninstalled 2.0.3 *after* installing 2.0.4. No problems (the only thing 
to remember is *not* to uninstall preferences).  I've then reinstalled 
2.0.3 beside 2.0.4, again without problems.



- you still insist on installing the LyX shortcut in a subfolder in
the start menu. Your reply that
this was much easier if you want to manually reorder the start menu,
but this is totally non-sense;


This is not nonsense. On my Win XP PC I have about 120 programs
installed. You would get crazy if you cannot sort them. Only one program
(Inkscape) does not store the link in a subfolder.
But anyway, why is such a nitpick that important for you?



I find it convenient to be able to see the version number of a program 
in the start menu, which the current installation of LyX provides.




regards Uwe



I downloaded not from SourceForge itself, which is a dead loss as far as 
someone on dial-up (like me) is concerned, since the download is almost 
always cut off anywhere between a few hundred KB or 20 MB, but from one 
of the mirrors listed there, which gives a much more reliable download. 
I also ensure that I'm *not* connected to the internet when LyX is being 
installed so that the auto downloading of missing MiKTeX packages can't 
occur. This results in a prompt recommending downloading missing 
packages to which I reply No (just the once), and installation is then 
completed without fuss.


By the way, the Welcome screen of the setup wizard includes the line

}Click Next to continue

including the left brace, which should be deleted.

Andrew

Re: Windows installer for LyX 2.0.4

2012-07-02 Thread Jean-Marc Lasgouttes


Le 02/07/2012 08:30, Andrew Parsloe a écrit :

There is also no reason not to change the name of the folder. I already
also explained that we can easily change the name to somewhat else but
need the info about the bugfix release. If is perfectly valid to install
LyX 2.0.4 and leave 2.0.3 as backup and some users do this (e.g. if they
write a large document like a thesis).


I find the LyX 2.0.4 naming useful. For example, when LyX moved from
2.0.1 to 2.0.2 it brought problems on my system: sticky scrolling, and
memory leakage which caused a number of crashes, and I needed to revert
to 2.0.1. I like to be able to install the latest version side by side
with the previous one until I'm comfortable that it works properly. I've
just installed 2.0.4 beside 2.0.3.


The point is that you can reinstall 2.0.1 if there is a problem and it 
will still work with your local files and preferences. Therefore 
parallel install is more often a problem than a feature IMO. The 
situation is different with a major release of course.


Concerning new bugs in stable releases, this does happen, but very 
rarely, and we actively try to avoid this. I am not sure this happens 
often enough to justify a different packaging.


If you want to be careful, the best is often to wait a few days before 
installing.


JMarc

Re: Windows installer for LyX 2.0.4

2012-07-02 Thread Vincent van Ravesteijn





Even if we add an option Surpass the LaTeX package installation what
do you expect a new user who has never worked with LaTeX nor know what
LaTeX is will do?


Surpass? A nice combination of bypass and suppress.


Yeah.. cool huh.






The reason why I don't accept this installer now is that:
- the installer installs LyX in a folder called: LyX 2.0.4 instead of
LyX20 as the current official
installer does. I really don't see a single reason to change this
behaviour;


There is also no reason not to change the name of the folder. I already
also explained that we can easily change the name to somewhat else but
need the info about the bugfix release. If is perfectly valid to install
LyX 2.0.4 and leave 2.0.3 as backup and some users do this (e.g. if they
write a large document like a thesis).


I find the LyX 2.0.4 naming useful. For example, when LyX moved from 
2.0.1 to 2.0.2 it brought problems on my system: sticky scrolling, 
and memory leakage which caused a number of crashes, and I needed to 
revert to 2.0.1. I like to be able to install the latest version side 
by side with the previous one until I'm comfortable that it works 
properly. I've just installed 2.0.4 beside 2.0.3.




There is no other software I know where I do this. Besides, there is a 
difference between to be able to install side-by-side and to install 
side-by-side by default.





- this means that you have to manually uninstall the previous version
each time;

  - this also means that you have to manually uninstall the previous
version _before_ installing
  the new version;

No. If this is necessary for you, you find a bug in the installer. It
must be allowed to install LyX 2.0.4 to a system where already LyX 2.0.3
exists.



I've had no problems uninstalling afterwards. Just to check, I've 
uninstalled 2.0.3 *after* installing 2.0.4. No problems (the only 
thing to remember is *not* to uninstall preferences).  I've then 
reinstalled 2.0.3 beside 2.0.4, again without problems.


Well, last time I tried, the lyx file format was no longer connected to 
LyX after uninstalling an old LyX version after installing the new one. 
Besides, IIRC the uninstall of preferences is the default. So, there is 
a substantial percentage of users that lose their preferences etc.





- you still insist on installing the LyX shortcut in a subfolder in
the start menu. Your reply that
this was much easier if you want to manually reorder the start menu,
but this is totally non-sense;


This is not nonsense. On my Win XP PC I have about 120 programs
installed. You would get crazy if you cannot sort them. Only one program
(Inkscape) does not store the link in a subfolder.
But anyway, why is such a nitpick that important for you?



I find it convenient to be able to see the version number of a program 
in the start menu, which the current installation of LyX provides.




The above discussion had nothing to do with the version number. Anyway, 
there are hardly any other applications showing the full version numbers 
including the minor and revision version numbers.



Andrew



Vincent

Re: Windows installer for LyX 2.0.4

Am 02.07.2012 10:23, schrieb Jean-Marc Lasgouttes:

I find the LyX 2.0.4 naming useful. For example, when LyX moved from
2.0.1 to 2.0.2 it brought problems on my system: sticky scrolling, and
memory leakage which caused a number of crashes, and I needed to revert
to 2.0.1. I like to be able to install the latest version side by side
with the previous one until I'm comfortable that it works properly. I've
just installed 2.0.4 beside 2.0.3.

The point is that you can reinstall 2.0.1 if there is a problem and it will
still work with your
local files and preferences.

Unfortunately not on Windows. The reason is that we deliver stripped-down versions of ImageMagick,
Ghostscript and Python with LyX. So assume you have uninstalled LyX 2.0.3 and the installed 2.0.4 or
you have installed 2.0.4 over an existing 2.0.3, you can later reinstall an older LyX version, but
the stripped-down programs remain in subfolders of LyX 2.0.4. So you then have to adapt the paths in
the older LyX version manually and to do this you need some background knowledge.

Concerning new bugs in stable releases, this does happen, but very rarely, and
we actively try to
avoid this. I am not sure this happens often enough to justify a different
packaging.

I can understand why people prefer this. When I was at the end of my Ph.D. I also did not remove the
LyX version I found stable. Regressions in branch are rare but they happened and no matter how less
probable they are, if you suffering from one and you are running against a deadline you suffer 100%.
Therefore I would like to continue support for side-by-side installation of LyX bugfix releases.

But OK, if you are voting to drop support for this, I will do so. We then also don't need to rename
the older to LyX 2.0.4 but can keep the name LyX20.

However, I vote for no because of the reason stated above, what do others think?

regards Uwe

Re: Windows installer for LyX 2.0.4

2012-07-02 Thread Richard Heck


On 07/02/2012 04:42 PM, Uwe Stöhr wrote:

Am 02.07.2012 10:23, schrieb Jean-Marc Lasgouttes:


I find the LyX 2.0.4 naming useful. For example, when LyX moved from
2.0.1 to 2.0.2 it brought problems on my system: sticky scrolling, 
and

memory leakage which caused a number of crashes, and I needed to revert
to 2.0.1. I like to be able to install the latest version side by side
with the previous one until I'm comfortable that it works properly. 
I've

just installed 2.0.4 beside 2.0.3.


The point is that you can reinstall 2.0.1 if there is a problem and 
it will still work with your

local files and preferences.


Unfortunately not on Windows. The reason is that we deliver 
stripped-down versions of ImageMagick, Ghostscript and Python with 
LyX. So assume you have uninstalled LyX 2.0.3 and the installed 2.0.4 
or you have installed 2.0.4 over an existing 2.0.3, you can later 
reinstall an older LyX version, but the stripped-down programs remain 
in subfolders of LyX 2.0.4. So you then have to adapt the paths in the 
older LyX version manually and to do this you need some background 
knowledge.


If everything's just being installed to LyX20 or whatever, isn't this 
issue resolved? Why should LyX 2.0.4 install ImageMagick with different 
names than LyX 2.0.1 did? Why isn't that uninstalled with LyX?


I guess my proposal would be not to change the names or paths of what we 
install during a major cycle.


Concerning new bugs in stable releases, this does happen, but very 
rarely, and we actively try to
avoid this. I am not sure this happens often enough to justify a 
different packaging.


I can understand why people prefer this. When I was at the end of my 
Ph.D. I also did not remove the LyX version I found stable. 
Regressions in branch are rare but they happened and no matter how 
less probable they are, if you suffering from one and you are running 
against a deadline you suffer 100%. Therefore I would like to continue 
support for side-by-side installation of LyX bugfix releases.


Isn't it possible for users to choose to install to a different location 
if they wish to do so? I'd have thought the issue here was what we do by 
default.


Richard

Re: Windows installer for LyX 2.0.4

Am 02.07.2012 08:30, schrieb Andrew Parsloe:

I've had no problems uninstalling afterwards. Just to check, I've uninstalled
2.0.3 *after*
installing 2.0.4. No problems (the only thing to remember is *not* to uninstall
preferences). I've
then reinstalled 2.0.3 beside 2.0.4, again without problems.

Thanks for testing and good to hear that it works for you.

I downloaded not from SourceForge itself, which is a dead loss as far as
someone on dial-up (like
me) is concerned, since the download is almost always cut off anywhere between
a few hundred KB or
20 MB,

Hmm, works for me here, but I cannot influence how and if the servers are running. But thanks to
Sourceforge, there is always a mirror online.

but from one of the mirrors listed there, which gives a much more reliable
download. I also
ensure that I'm *not* connected to the internet when LyX is being installed so
that the auto
downloading of missing MiKTeX packages can't occur. This results in a prompt
recommending
downloading missing packages to which I reply No (just the once), and
installation is then
completed without fuss.

Yes, but then you don't have a fully functional LyX. Try e.g. to write an Elsevier document, make a
longtable, rotate floats etc, etc. You will sooner or later get LaTeX errors that a package is missing.

By the way, the Welcome screen of the setup wizard includes the line

}Click Next to continue

including the left brace, which should be deleted.

Thanks for the report, this is now fixed for the next installer version.

regards Uwe

Re: Windows installer for LyX 2.0.4 - correction


Am 02.07.2012 22:42, schrieb Uwe Stöhr:


The point is that you can reinstall 2.0.1 if there is a problem and it will 
still work with your
local files and preferences.


Unfortunately not on Windows. The reason is that we deliver stripped-down 
versions of ImageMagick,
Ghostscript and Python with LyX. So assume you have uninstalled LyX 2.0.3 and 
the installed 2.0.4 or
you have installed 2.0.4 over an existing 2.0.3, you can later reinstall an 
older LyX version, but
the stripped-down programs remain in subfolders of LyX 2.0.4. So you then have 
to adapt the paths in
the older LyX version manually and to do this you need some background 
knowledge.


Sorry, this was not correct. What i described only happens if you install e.g. LyX 2.0.4, than later 
on LyX 2.0.3 as backup. LyX 2.0.3 will then use the programs in the subfolders of LyX 2.0.4. If you 
now uninstall LyX 2.0.4 and only want to keep 2.0.3 then you will get problems. But OK this case is 
only hypothetic one.


regards Uwe

Re: Windows installer for LyX 2.0.4