subject:"\"Re\\\: Windows installer\""

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

2018-09-01 Thread Andrew Parsloe


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

2018-09-01 Thread Andrew Parsloe


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&m=150739249920974&w=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

2018-08-31 Thread Andrew Parsloe





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-13 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 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-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-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

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-03 Thread Richard Heck


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-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

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 Richard Heck


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 Jean-Marc Lasgouttes


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

2012-07-03 Thread Jean-Marc Lasgouttes


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


Am 02.07.2012 23:15, schrieb Uwe Stöhr:


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.


I cannot reproduce this anymore. This was a bug but seems to be fixed. However, 
before you blame the
installer I thought you gave it another try. I have fixed several bugs since my 
test released. I
hoped all issued reported to me.


Here is the new version where  fixed now some other issues and also one where the file association 
as not correctly set without admin privileges:


https://sourceforge.net/projects/lyxwininstaller/

Please give it a try and report further bugs you find.

thanks and regards
Uwe

Re: Windows installer for LyX 2.0.4


Am 02.07.2012 11:00, schrieb Liviu Andronic:


Random thought: When using the standalone installer, not the bundle
one, does the same issue exist? Will LyX instruct MiKTeX to install
packages, if missing?


Yes, because we require new packages from time to time or replace a package support by another 
package. But in this case MiKTeX is already installed so that only one or 2 packages are installed, 
with some releases even no package is changed.
One could think that in this case the automatic install setting can be skipped, but we cannot know 
in what state the LaTeX engine is. Maybe it was not updated for a long time or the last time LyX was 
installed there was no Internet connection. I had such cases so often and therefore always set the 
automatic installation. This way I can assure that the users will in every case a best as possible 
featured LyX.



And modify it's settings to 'Install on the
fly'? If not, then this entire debate is sterile:
- The complete installer is clearly geared at inexperienced users, so
installs all that LyX needs to function properly.
- The standalone installer can be used by expert users to install LyX
very quickly, while such users can install MiKTeX separately (prior to
installing LyX).


Yes, you can use this installer as such. But an average users don't know what kind of package he 
needs and some users even after years of sage don't know what is going on in the background of 
LyX/MiKTeX. But they know that they already have a LaTeX engine installed, can therefore use the 
standard installer and that's it. I mean LyX's aim is to make LaTeX as simple as possible and we try 
hard to hide the LateX internals from the user. So we cannot expect that the users want to be 
bothered with the internals at installation time.



Thus developers can keep full control of their
installation process, and this can be documented on the wiki/download
page.


I still have the strong opinion that an installer must be designed for average users who does not 
need to know how LaTeX works. I also think that a developer don't need an installer as he can easily 
set it up on his own.



further. For example I will try to implement full support for TeXLive when
the new TeXLive 2012 version is released in July. Maybe then the package
installation is much faster and we can switch to TeXLive for new
installations.


That would be nice, indeed! It would also allow some kind of
standardization between Linux and Windows compilation of LyX
documents.


I hope so. Let's see what the new version brings.

regards Uwe

Re: Windows installer for LyX 2.0.4


Am 28.06.2012 14:08, schrieb Jean-Marc Lasgouttes:


Now I read a bit more the miktexdoc. I suspect that using directly the
PackageInstaller interface
   http://docs.miktex.org/2.8/sdk/interfaceIPackageInstaller.html
would help being much faster than the clunky configure.py-based solution.


It is not. This is the method you are using when using MiKTeX's package manager. It takes the same 
time to install because it also downloads a package, then extracts it then installs it and so on.



The lyx installer should
have a list of packages to install and install them by itself.


We already have it, this is the list in the chkconfig.ltx file. It does not matter if the 
installation is invoked by a python script or an NSIS script, it will use the same mechanism and 
takes long time. But note that this time strongly depends on the Internet connection speed and the 
speed of your hard disk. On my new Win 7 PC installing MiKTeX is quite fast. On my old Windows XP it 
takes about 8 minutes.



If some of the packages are big, we
could even ponder the possibility of making some of them optional (what are the 
biggest? How useful
are they?)


This is not an option. We could not know what a particular user wants to do with LyX. If he has to 
write a scientific article he will need exotic packages, if he is a linguist, he will need TIPA, but 
TIPA is unuseful for a mathematician who needs AMS extensions etc...



 > What about packaging the extra packages together with LyX.


This was often proposed in the past but this also not an options. The packages are updated quite 
often, see http://news.gmane.org/gmane.comp.tex.ctan.announce. We don't have the manpower to keep it 
up to date. Moreover we would then only be able to support MiKTeX. But what about TeXLive. Some 
users prefer that engine. It is the right way we are going to call a LaTeX script to chec for 
packages. Then the engine preferred by the user (or the preinstalled one of a company is used; for 
example at Universities TeXLive is often preinstalled).



Doesn't
 > miktex allow to create a lyx-extra meta package that we could just put
 > together with the windows installer?


Not that I know.


What about a custom package repository, like described here:
http://docs.miktex.org/packaging/


That would need the same manpower: check every day the CTAN package updates, package them and 
upload. But this is already done by MiKTeX and TeXLive. I don't think it is worth it to do some work 
that is already done.


regards Uwe


Would that help?

JMarc

Re: Windows installer for LyX 2.0.4

Am 02.07.2012 22:59, schrieb Richard Heck:

The installer proposed "LyX 2.0.4" as name but you can of course chose any
other name of your
choice. But the average user justs clicks several time OK in an installer and
then gets the
default/proposed folder.

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.

Having the full LyX Version number in the name seems to be useful for some users as the other
commenters reported and it does not harm. We never had a user complaint about this for years now and
when you don't like the name than choose another one. It furthermore enables to install LyX versions
side by side by default. So not too bad at all to use this.
But anyway, what is the benefit of not using the LyX version number in the name? I'm still don't
understand why Vincent thinks this extra feature is a problem.

Then we do by default what seems to be what most
people would want,

That depends on what people wants. When started the installer years ago I once got some reports
that I should use the LyX version number in the folder name (this time I only used "LyX" as name),
so I did.

but still allow as an option what you are suggesting. Right?

Yes. The question is still what should be the default. We could start a survey at the users list.
I'm curious what the users think/want because the installer is designed for them not for us developers.

regards Uwe

Re: Windows installer for LyX 2.0.4

Am 02.07.2012 20:51, schrieb Vincent van Ravesteijn:

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".

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.

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.

I cannot reproduce this anymore. This was a bug but seems to be fixed. However, before you blame the
installer I thought you gave it another try. I have fixed several bugs since my test released. I
hoped all issued reported to me.

Besides, IIRC the uninstall of preferences is the
default. So, there is a substantial percentage of users that lose their
preferences etc.

I have fixed this now (for the next version). Now it is not enabled by default.

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.

Then I misunderstood your point. I also thought aou refer to the version number. As this is not the
case, what do you then complain about the name?

regards Uwe
<>

Re: Windows installer for LyX 2.0.4

2012-07-02 Thread Richard Heck


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

Am 02.07.2012 22:47, schrieb Richard Heck:

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.


The installer proposed "LyX 2.0.4" as name but you can of course chose 
any other name of your choice. But the average user justs clicks 
several time OK in an installer and then gets the default/proposed 
folder.


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? Then we do by default what seems to be what most people would 
want, but still allow as an option what you are suggesting. Right?


Richard

Re: Windows installer for LyX 2.0.4


Am 02.07.2012 22:47, schrieb Richard Heck:


If everything's just being installed to LyX20 or whatever, isn't this issue 
resolved?


Yes, but then you cannot have two LyX versions of the same major version side by side. So having LyX 
2.0.3 _and_ 2.0.4 is then not possible.



Why should LyX
2.0.4 install ImageMagick with different names than LyX 2.0.1 did?


It does not. The thing is that we have to store the third-party programs in a folder and to follow 
the Windows guidelines, we do this in a subfolder of LyX's installation folder. But OK, I confused 
you because I was not correct in my explanation, see my correction mail.



Why isn't that uninstalled with LyX?


It is and therefore the case I described in my correction  mail can happen.


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.


The installer proposed "LyX 2.0.4" as name but you can of course chose any other name of your 
choice. But the average user justs clicks several time OK in an installer and then gets the 
default/proposed folder.


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

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

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 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 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

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-01 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


Am 28.06.2012 12:30, schrieb Liviu Andronic:


Here's my proposal for a compromise:
- Have the installer default to 'Install on the fly', making it by
default tailored to inexperienced users
- Have an Advanced tab where this can be changed, while each option is
clearly explained, and stern and human-understandable warnings are
dispensed where appropriate:
-- 'Install on the fly': Results in a complete LyX installation. It
takes some time depending on your internet connection. Recommended for
inexperienced users.
-- 'Don't install': Results in an incomplete LyX installation. The
installation procedure is very quick, but use this option only if you
know what you're doing. Strongly discouraged for inexperienced users.
(Or your favourite stern warning.)
-- 'Ask before installing': May result in an incomplete LyX
installation, depending on user choices. The slowest installation
procedure. Not recommended.


I think we could skip the latter. If you are an experienced user you know which packages you need. 
And even if you missed to install a certain package, you can do this later using MiKTeX#s package 
manager.



My feeling is that the implementation above would accommodate both
Uwe's and your objections.


I'll think about this.


A side note: When 'Install on the fly' is used the user will
experience UI freezes while MiKTeX downloads and installs packages in
the background. When this happens it is difficult to tell whether the
installer hanged, the internet connection is down or what else. So
would the following two be possible:
-  Instead of freezing up, the Windows installer should keep track


This once worked but there is now a bug in configure.py that the current installed package is no 
output. So currently you don't see a progress in the package installation but noting.

I'll have a look.

regards Uwe

Re: Windows installer for LyX 2.0.4


Am 28.06.2012 11:23, schrieb Vincent van Ravesteijn:


If I remember your only remaining complain was that I set MiKTeX to install 
missing packages
silently. I several times explained in detail why this is necessary. I accept 
that you are an
expert in many fields but the average user is not. We cannot bother average 
users with dialogs
where he has to made about 50 times a decision.


Who is speaking about 50 decisions ? All I asked for was an option to surpass 
this step.


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?



I find it
more distracting that I get a messagebox forcing me to choose whether I want to 
update MikTeX or not
(and after that updating MikTeX failed).


The problem is that the MiKTeX installer is only released each 6 month or so, but as the aim is to 
get a full functional LyX, the user should be able to benefit from the latest package updates. 
Especially users who already use LyX normally don't update MiKTeX by themselves and thus suffer from 
bugs in packages that are already fixed. When had several cases in this regards. Take for example 
one of the bugs in hyperref or caption that made documents uncompilable.
However, in this case it is not important what the users decides. If he choose to update, fine, if 
not, it doesn't harm in terms of LyX's feature completeness.



The installer is the first thing a new user sees and he cannot know anything at 
this state. I
don't get why you will not accept that the average user doesn't know what a 
package is and that he
also don't need to know.
(You know that you can any time later rest the settings you prefer.)


I did never say I do not accept this, because the current installer has the 
same behaviour.


So what is the point why you don't want to accept it?


In my opinion the installer is ready and now also stable to become the official 
one. So let's do
it now.


I think it is not ready yet.


Can you please be more precise. What exactly is missing?


Btw. I have added some new files and would add them t the dependency package. I 
want upload the
new one to our FTP server but don't know who can put it then to the correct 
location.


The dependency package is on sourceforge, not on our FTP.


Who runs it, to whom can I sent the updated package?


I believe you're writing ImageMagick entries in the registry yourself. Why ?


When installing IM, it writes registry values to HKLM. IM needs registry values 
to determine where
to find its modules. Now it is possible to use also HKCU and so it can be used 
also when not
installed with admin privileges.


You can repeat over and over again that IM needs registry values, but that 
doesn't help me.
According to the website of ImageMagick: "Portable Win32 static at 16 
bits-per-pixel. Just copy to
your host and run (no installer, no Windows registry entries)."

This clearly tells me you're wrong that IM needs registry values in either HKLM 
or HKCU.


I also read this and tested this several times. It never worked correct for all cases, especially 
not for delegates likes SVG or PDF images. But as it is now fixed in IM this is no longer an issue.
The new installer currently still writes things to the registry, but this is more a safety thing as 
I don't know if a certain delegate would still fail without them. However, these settings don't harm 
and if you would have installed IM using its own installer, you would get them too.



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).
So when can change it from "LyX 2.0.4" to "LyX204" if you don't like the dots. "LyX20" is not 
sufficient.

(I also explained this several times.)


- 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.



- you forced this upon the user by disallowing to install LyX when a version of 
LyX is already
installed;


This was not planned and is not the case on my 2 test PCs. But I will have 
another look.


- this prevents the user from installing a new version even if it does not have 
right

Re: Windows installer for LyX 2.0.4


Am 28.06.2012 11:04, schrieb Vincent van Ravesteijn:


If such users need to choose
(or actually choose) something other than 'Install packages on the
fly', LyX is effectively broken for them.


I don't get this sentence.


I guess he means that then they don't have all packages needed by LyX. Sooner or later they will use 
a feature that require a certain packages that is not installed in their system. Because of the 
about 50 pop-ups from MiKTeX many users where I could have a look how they act when installing LyX 
clicked at some point "No" to not to be bothered.



Personally I still find the Windows installation of LyX confusing and
complicated, with UI freezes and lots of waiting time. Each time I
have to do it for a friend, it's pretty much an ordeal.


And that's why I just want an option to surpass this installation of exotic 
packages that I will
never use, but which takes me a 'coffee-break' to install.


How will you do that? Form where do you know what the user will need or not. Take for example a 
researcher who needs to write a scientific paper for a journal published by the IOP. He will then 
need very special packages and document classes.
The aim of an installer is that every user gets a full functional LyX, no matter for what purpose he 
will use if.


regards Uwe

Re: Windows installer for LyX 2.0.4