Virtual meeting summary (2021-01-11)

[José Abílio Matos]

Hi,
  we have met virtually on Monday, 2021-01-11.

A short summary of the major points discussed can be found here:

https://wiki.lyx.org/Devel/Meeting2021-01-11


For those who were not able to attend feel free to ask question if the summary 
is too terse.

Personally I think that the meeting was a success and part of it can be seen 
from the activity in this list towards the next stable release.

As Jean-Marc said the face-to-face meetings are more productive, when 
possible, but this has the advantage of bringing people from more places/time 
zones. :-)

I think that we should repeat this meeting (say in 6-8 weeks) in order to 
assess the evolution of the stable release. Anyone interested is welcome to 
participate.

Thanks to Pavel for chairing the meeting and for all the participants for IMHO 
a very productive meeting.

Best regards,
-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

On Monday, January 11, 2021 10:58:48 PM WET Joel Kulesza wrote:
> Regarding semantic versioning: I feel like LyX already (arguably) uses that.
>  The argument I imagine: it's not clear what prompted moving from version
> 1->2,

What is the rationale of the number change?
I have been bugging the mailing list ever since 0.12. :-)

And that worked because we changed to version 1.0 (Feb 1999).


In the case of what prompt the change from version 1 to 2 you can search in 
the mailing list. The changed occurred mostly at this time
https://marc.info/?l=lyx-devel=12651045747=2

FWIW this was January-February 2010.

In particular the 1.5 release where we changed to Unicode/UTF-8 it was in a 
sense a fundamental change.

> but a Python-based conversion script manages forward/backward
> compatibility in such a way that I regard the "API" as unchanging with the
> various changes that underpin 2.4.0 (maybe I'm mistaken).  I would imagine
> a change from 2->3 if, for example, the .lyx file migrated irreversibly
> from what it is now to XML.  Otherwise, as JMarc noted once I was already
> composing this, the "API" is pretty stable.

We are, and try very hard to be, backwards compatible, but we are in no way 
forward compatible. I have been very clear since the begin of lyx2lyx we 
should be able to read perfectly what previous versions LyX version wrote.
If for some reason that does not happen we have a bug.
The conversion of the lyx file format to previous releases works on a best 
basis level but there are changes that are impossible to replicate in a 
general way. They do work most of the time but it is impossible to have them 
work correctly every time. The second law of thermodynamics and the arrow of 
the time...


FWIW this is the list of API breaks that we had previously is:

...
0.6.0
0.8.0
0.10.0
0.12.0
1.0.0
1.1.0
1.1.5
1.1.6.0
1.1.6.3
1.2.0
1.3.0
1.4.0
1.5.0
1.6.0
2.0.0
2.1.0
2.2.0
2.3.0

The version that I placed is the first release of the cycle.

lyx2lyx appeared after 1.2 and with it we had a way to make a more regular 
changes.

After that such as it was the first number is irrelevant.

BTW, do you know that at some point the file format was a real number, in the 
bank format?

What I am proposing is to change to a saner and more predictable model, either 
the semantic version or the scheme used by several gnu projects, like at least 
gcc and octave.

This is similar to the semantic version with one exception. In order to give 
an example suppose that we decide to follow that scheme an so the next version 
is LyX 3.

The development version, unreleased version is 3.0.0.
As soon as the first test version is released it gets the 3.0.1, the next one 
is 3.0.2 and so on.
When the release candidates stage is over and a stable version is released as 
LyX 3.1.
If a micro release is required then it goes to 3.1.1.
The usual stable releases that we do will be 3.2, 3.3, 3.4...

In short this scheme is similar to the semver scheme with the exception that 
releases where the second number is zero are reserved for development/
stabilizing versions.

What I like in this scheme is that there is no need to place other symbols in 
releases to convey its meaning.

-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: XML stream writer library

[Richard Kimberly Heck]

On 1/12/21 6:19 PM, Thibaut Cuvelier wrote:
> On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini
> mailto:lorenzobertin...@gmail.com>> wrote:
>
> Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:
> > A tour of some C++ libraries for XML:
> > - RapidXML: mostly unmaintained since 2013, no support for
> namespaces
> > (except in forks: https://github.com/dwd/rapidxml
> 
> > >)
> > - Boost Property Tree: no XML parser, which limits further use
> (it can
> > use RapidXML though, see above)
> > - libstudxml: C++ library, designed for speed, no DOM
> > - libxml2: C library, designed for features and not speed (also
> includes
> > XPath and XSLT, DTD and XML Schema, namespaces), "mature" and
> barely not
> > evolving anymore
> > - libxml++: depends on glibmm2
> > - Xerces-C++: C++ library, designed for features and not speed
> (also
> > includes XPath, DTD and XML Schema, namespaces), "mature" and
> barely not
> > evolving anymore; no XSLT (Xalan could be used, but it only
> works with a
> > ancient version of Xerces; XQuilla implemented XPath 2, but is
> no more
> > developed since 2016)
> > - Expat: C library, designed for speed, no DOM by default
> (provided by
> > https://github.com/kolotsey/expat-dom
> 
> >  >), with namespaces
> > - tinyxml2: C++ library, designed for speed only (also includes
> XPath
> > through the unmaintained
> https://github.com/stanthomas/tinyxml2-ex
> 
> >  >, no validation, no
> > namespaces), mature and slowly evolving
> > - pugixml: C++ library, designed for speed with a few features
> (like
> > XPath, no validation, no namespaces), mature and evolving
> > - libroxml: C library, no clear design goal (includes XPath,
> namespaces,
> > no validation), evolving
> > - Saxon-C: C/C++ wrapper of the state-of-the-art Java library,
> largest
> > amount of features (XPath and XSLT 3, DTD and XML Schema
> validation --
> > extension for RelaxNG: http://www.cfoster.net/saxon-jing/
> 
> >  > --, namespaces), very mature,
> > really evolving (both performance and features), but it requires
> a JVM
> > (Excelsior is built-in, even though it's not been maintained for
> quite a
> > long time)
> > - Qt: no, I was joking :). Qt XML is not supported anymore, it's
> > recommended to switch to QXmlStreamReader and QXmlStreamWriter
> (which
> > are only SAX-like). Qt XML Patterns used to have XPath, XSLT,
> and XML
> > Schema, but it's been deprecated a while ago (Qt 5.13 for the last
> > wake-up call, but it hasn't been touched since Qt 4, basically)
> >
> > If LyX is being really serious about XML (i.e. moving as many
> things as
> > possible to XML technologies), Saxon is probably the way to go.
> > Otherwise, it's going to be too heavy to ship Saxon and a JVM
> along with
> > LyX. Instead, pugixml seems to me like a good choice: a few
> features
> > (XPath is the most relevant for LyX, and included in the base
> library,
> > no need for addons), good performance, still maintained (there is a
> > chance to have bugs fixed in a newer version, plus security
> > vulnerabilities taken care of).
> Was this addressed in the virtual meeting? 
>
>
> As far as I know, it wasn't discussed.

We were pretty focused on planning for 2.4.0.

 

> Anyhow, I think that for a start we'd need only the most basic
> features
> (tag insertion, indent), as was the purpose of #12055 in the first
> place
> (I'm sorry to have opened this pandora's box), so maybe no harm will
> come if we start wrapping pugi.
>
> Let me know what you think, and if this is not the time for this, as
> with LyX 2.4 coming out there might be other things that need focus.
>
>
> It looks like the patches cannot get integrated into the master
> development branch before 2.4 is out (or at least branched). However,
> in the meantime, I think I can create a feature branch and push your
> patches there (https://www.lyx.org/trac/browser/features
> ).

Yes, that would be the way to go.

Riki



-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Feature Request from Doug Martin and Tom Philips

[Richard Kimberly Heck]

On 1/12/21 6:04 PM, Doug Martin wrote:
> Tom and I are using various R packages for the book Portfolio
> Construction and Risk Management that we are writing
> using LYX.  A LYX feature that would help us in that effort a lot
> would be the ability to import R data framesm and data.table
> objects created using the excellent data.table package. Given the
> thousands of R packages, and the popularity of the
> data.table package, we guess that this import feature for LYX would
> benefit a lot of people who use both R and LYX.

Hi, Doug,

Other people how use R (as I do not) will probably have more helpful
things to say. But I suspect that this can be done using 'external
templates'. Have a look at section 6 of the Customization manual and,
more helpfully, the templates that already exist, which you will find in
the xtemplates/ directory of you LyX system library directory (whose
location is given in the About LyX dialog). If it looks like this might
work, then there will be people here willing to help you write the template.

Riki

PS Glad you have found LyX so useful!


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: XML stream writer library

[Thibaut Cuvelier]

On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini 
wrote:

> Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:
> > A tour of some C++ libraries for XML:
> > - RapidXML: mostly unmaintained since 2013, no support for namespaces
> > (except in forks: https://github.com/dwd/rapidxml
> > )
> > - Boost Property Tree: no XML parser, which limits further use (it can
> > use RapidXML though, see above)
> > - libstudxml: C++ library, designed for speed, no DOM
> > - libxml2: C library, designed for features and not speed (also includes
> > XPath and XSLT, DTD and XML Schema, namespaces), "mature" and barely not
> > evolving anymore
> > - libxml++: depends on glibmm2
> > - Xerces-C++: C++ library, designed for features and not speed (also
> > includes XPath, DTD and XML Schema, namespaces), "mature" and barely not
> > evolving anymore; no XSLT (Xalan could be used, but it only works with a
> > ancient version of Xerces; XQuilla implemented XPath 2, but is no more
> > developed since 2016)
> > - Expat: C library, designed for speed, no DOM by default (provided by
> > https://github.com/kolotsey/expat-dom
> > ), with namespaces
> > - tinyxml2: C++ library, designed for speed only (also includes XPath
> > through the unmaintained https://github.com/stanthomas/tinyxml2-ex
> > , no validation, no
> > namespaces), mature and slowly evolving
> > - pugixml: C++ library, designed for speed with a few features (like
> > XPath, no validation, no namespaces), mature and evolving
> > - libroxml: C library, no clear design goal (includes XPath, namespaces,
> > no validation), evolving
> > - Saxon-C: C/C++ wrapper of the state-of-the-art Java library, largest
> > amount of features (XPath and XSLT 3, DTD and XML Schema validation --
> > extension for RelaxNG: http://www.cfoster.net/saxon-jing/
> >  --, namespaces), very mature,
> > really evolving (both performance and features), but it requires a JVM
> > (Excelsior is built-in, even though it's not been maintained for quite a
> > long time)
> > - Qt: no, I was joking :). Qt XML is not supported anymore, it's
> > recommended to switch to QXmlStreamReader and QXmlStreamWriter (which
> > are only SAX-like). Qt XML Patterns used to have XPath, XSLT, and XML
> > Schema, but it's been deprecated a while ago (Qt 5.13 for the last
> > wake-up call, but it hasn't been touched since Qt 4, basically)
> >
> > If LyX is being really serious about XML (i.e. moving as many things as
> > possible to XML technologies), Saxon is probably the way to go.
> > Otherwise, it's going to be too heavy to ship Saxon and a JVM along with
> > LyX. Instead, pugixml seems to me like a good choice: a few features
> > (XPath is the most relevant for LyX, and included in the base library,
> > no need for addons), good performance, still maintained (there is a
> > chance to have bugs fixed in a newer version, plus security
> > vulnerabilities taken care of).
> Was this addressed in the virtual meeting?


As far as I know, it wasn't discussed.


> Also, since Xerces-C was the
> most feature full and mature after Saxon-C, I was curious as to why you
> didn't mention it.
>

Actually, Xerces-C and Xerces-C++ are just the same thing (the official
name being Xerces-C++ and the name of the packages Xerces-C, if I got it
correctly).


> Anyhow, I think that for a start we'd need only the most basic features
> (tag insertion, indent), as was the purpose of #12055 in the first place
> (I'm sorry to have opened this pandora's box), so maybe no harm will
> come if we start wrapping pugi.
>
> Let me know what you think, and if this is not the time for this, as
> with LyX 2.4 coming out there might be other things that need focus.
>

It looks like the patches cannot get integrated into the master development
branch before 2.4 is out (or at least branched). However, in the meantime,
I think I can create a feature branch and push your patches there (
https://www.lyx.org/trac/browser/features).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: #11453: App icons are not retina-ready, missing resolutions

[mn]

On 12.01.21 22:46, LyX Ticket Tracker wrote:

#11453: App icons are not retina-ready, missing resolutions
-+---
  Reporter:  Mike |   Owner:  stwitt
  Type:  enhancement  |  Status:  assigned
  Priority:  normal   |   Milestone:
Component:  general  | Version:  2.3.2
  Severity:  normal   |  Resolution:
  Keywords:  os=macosx|
-+---

Comment (by stwitt):

  This is the situation on my system:
  - Dock icon: [[Image(Bildschirmfoto 2021-01-12 um 22.19.12.png)]]
  - Finder list:  [[Image(Bildschirmfoto LyX in Finder.png)]]
  - Finder property tab:  [[Image(Bildschirmfoto 2021-01-12 um
  22.36.07.png,412px)]]

  IMO we should stay with Lydia!

  I didn't get the message from Mike. What should be done exactly? I can do
  something (e.g. search for a recipe in internet) but this is beyond my
  knowledge currently.



Sorry. Currently my access to trac seems somehow broken, thus replying here:

On all systems, including the old non-retina ones, the screen realestate
afforded to the icons is suboptimal.
The resolution is simply too low for retina displays and the very
quality of the icon itself is a bit lacking.

The higher retina resolution is just one of nice desiderata. But when
tackling that, one might as well clean up the icon construction and
increase usability!

When I switch apps via Dock or Tab-switcher, with many applications
open, it gets ever harder to distinguish different apps by there icon,
and the current default gets too tiny to be easily recognisable.

Thus, aesthetics are low in high resolution and usability could be
improved in all, but especially in lower resolution/display sizes.

Going into the direction Apple indicates and pushes for Big Sur is
therefore a no-go, imo. There is too low contrast and too many things
just look the same.

The github alternative I uploaded some time ago is a first idea into the
compromises of keeping Lydia, cleanup the svg/icns, maximise
icon-space-realestate, increase usability. Stronger contrast, colours.
My result may not satisfy all or everyone in the current iteration, but
shows most points just raised here as 'improved'. A full rework/update
might of course still be better than this idea…

On my local installation I always replace shipped icns with my own and
while the files are still in need for more polish, they already help me
a lot when switching between applications… Stefan: try them out and hit
cmd-tab while a few apps are open.


I am also for keeping Lydia, but wouldn't mind a whole new approach
either, as long as the usability gets increased (again: a no-no to
'BigSur-stylishness').


greetings
mn
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Feature Request from Doug Martin and Tom Philips

[Doug Martin]

Tom and I are using various R packages for the book Portfolio Construction
and Risk Management that we are writing
using LYX.  A LYX feature that would help us in that effort a lot would be
the ability to import R data framesm and data.table
objects created using the excellent data.table package. Given the thousands
of R packages, and the popularity of the
data.table package, we guess that this import feature for LYX would benefit
a lot of people who use both R and LYX.

Thanks in advance for considering this request.

Doug

-- 
R. Douglas Martin
Professor Emeritus in Applied Mathematics and Statistics
Founder and Former Director of MS-CFRM Program
depts.washington.edu/compfin/
University of Washington
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

A Very Happy Pair of LYX Users

[Doug Martin]

 I noticed the following at https://www.lyx.org/MailingLists#toc3

" Also, if you are a LyX user and have enjoyed using LyX for some purpose,
it would be nice of you to email the developers to let us know.",

and I am responding accordingly.

I started using LYX in 2004 because one of my PhD students was using it,
and he wanted me to use it in writing a paper with him.
He was a LaTeX whiz, as were many of my colleagues and students, but I was
not.  It was interesting to see his motivation to
move to LYX: He said that with LYX he could spend more time thinking about
what he was writing, rather than hassling with large equation
layouts, etc.  Since then I have insisted that students and colleagues,
that I am collaborating with, use LYX, and by now have a number of
published papers that we wrote using LYX. One motivation, among others,
was that I got tired of providing my edits in pdf files,
when I can do them in LYX in track changes mode.  Also, I didn't like
Scientific Word that much (had used it to write a book).

Now, I have been writing a book for over two years now with my colleague
Tom Philips at NYU, using LYX, and we do have an LYX feature
request that I will send in the next email.

Meanwhile, I wanted to say that I am very impressed seeing all the
development activity by many people on this list.

Many thanks for a great product.

Best regards,
Doug

-- 
R. Douglas Martin
Professor Emeritus in Applied Mathematics and Statistics
Founder and Former Director of MS-CFRM Program
depts.washington.edu/compfin/
University of Washington
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.3.6.1 Tarballs and Binaries

[Liviu Andronic]

On 12/29/20, Richard Kimberly Heck  wrote:
> The fix for bug #12056, which prevented inclusion of TeX files, warrants
> a quick re-release. I've also included the fix for #11746, which caused
> problems on Gnome Wayland on Fedora.
>
> Tarballs here:
>
> http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/
>
> Please prepare binaries.
>

Ubuntu packages now uploaded to the PPA.

Liviu


> Riki
>
>
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4 Status Update

[Richard Kimberly Heck]

On 1/12/21 11:35 AM, Yu Jin wrote:
> Am Mo., 11. Jan. 2021 um 19:40 Uhr schrieb Richard Kimberly Heck
> mailto:rikih...@lyx.org>>:
>
> On 1/11/21 1:38 PM, Yu Jin wrote:
>> Am Mo., 11. Jan. 2021 um 18:36 Uhr schrieb Richard Kimberly Heck
>> mailto:rikih...@lyx.org>>:
>>
>> I've just uploaded Eugene's Windows binaries to the ftp
>> server and will
>> wait 24 hours for the mirrors to sync before doing the alpha
>> 1 release.
>> Once that's done, we should start getting more feedback. But,
>> as was
>> said in our developer's meeting today, the master branch is
>> pretty
>> stable, so we hope to be able to move forward pretty quickly
>> towards beta.
>>
>> Toward that end, efforts now should be focused on fixing bugs
>> and
>> polishing the new features in 2.4. That said: Are there any
>> new features
>> people would still like to get into 2.4 that require format
>> changes? If
>> so, then those will be considered. Features that do not
>> require format
>> changes can also be considered but are less pressing, since
>> they could
>> be added during the 2.4 cycle. Once we have some sense for
>> the work that
>> needs doing, we can set a target date for feature freeze.
>>
>> Please note that bugs targeted to 2.3.x and 2.4.0 are listed
>> on the bug
>> tracker home page
>> > >.
>> Obviously, not all of these will get fixed, and many of them
>> are quite
>> minor. But if you're looking for something to do
>>
>>
>> Would it make sense to remove the old wininstaller folder and do
>> the related stuff to the tarballs build process (how you call
>> that), so that it includes all the necessary files for the new
>> installer, before the new stable 2.4.x branch is created (save
>> some work)? I could do the installer part, it shouldn't take
>> long, just waiting for the green light.
>
> Yes, any work you want to do on the installer stuff, you should
> probably do as soon as possible. That will give us plenty of time
> to get it all tested with the alpha and beta releases.
>
> Done.

Great, thank you.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4 Status Update

[Yu Jin]

Am Mo., 11. Jan. 2021 um 19:40 Uhr schrieb Richard Kimberly Heck <
rikih...@lyx.org>:

> On 1/11/21 1:38 PM, Yu Jin wrote:
>
> Am Mo., 11. Jan. 2021 um 18:36 Uhr schrieb Richard Kimberly Heck <
> rikih...@lyx.org>:
>
>> I've just uploaded Eugene's Windows binaries to the ftp server and will
>> wait 24 hours for the mirrors to sync before doing the alpha 1 release.
>> Once that's done, we should start getting more feedback. But, as was
>> said in our developer's meeting today, the master branch is pretty
>> stable, so we hope to be able to move forward pretty quickly towards beta.
>>
>> Toward that end, efforts now should be focused on fixing bugs and
>> polishing the new features in 2.4. That said: Are there any new features
>> people would still like to get into 2.4 that require format changes? If
>> so, then those will be considered. Features that do not require format
>> changes can also be considered but are less pressing, since they could
>> be added during the 2.4 cycle. Once we have some sense for the work that
>> needs doing, we can set a target date for feature freeze.
>>
>> Please note that bugs targeted to 2.3.x and 2.4.0 are listed on the bug
>> tracker home page .
>> Obviously, not all of these will get fixed, and many of them are quite
>> minor. But if you're looking for something to do
>>
>
> Would it make sense to remove the old wininstaller folder and do the
> related stuff to the tarballs build process (how you call that), so that it
> includes all the necessary files for the new installer, before the new
> stable 2.4.x branch is created (save some work)? I could do the installer
> part, it shouldn't take long, just waiting for the green light.
>
> Yes, any work you want to do on the installer stuff, you should probably
> do as soon as possible. That will give us plenty of time to get it all
> tested with the alpha and beta releases.
>
Done.
-- 
Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: XML stream writer library

[Lorenzo Bertini]

Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:

A tour of some C++ libraries for XML:
- RapidXML: mostly unmaintained since 2013, no support for namespaces 
(except in forks: https://github.com/dwd/rapidxml 
)
- Boost Property Tree: no XML parser, which limits further use (it can 
use RapidXML though, see above)

- libstudxml: C++ library, designed for speed, no DOM
- libxml2: C library, designed for features and not speed (also includes 
XPath and XSLT, DTD and XML Schema, namespaces), "mature" and barely not 
evolving anymore

- libxml++: depends on glibmm2
- Xerces-C++: C++ library, designed for features and not speed (also 
includes XPath, DTD and XML Schema, namespaces), "mature" and barely not 
evolving anymore; no XSLT (Xalan could be used, but it only works with a 
ancient version of Xerces; XQuilla implemented XPath 2, but is no more 
developed since 2016)
- Expat: C library, designed for speed, no DOM by default (provided by 
https://github.com/kolotsey/expat-dom 
), with namespaces
- tinyxml2: C++ library, designed for speed only (also includes XPath 
through the unmaintained https://github.com/stanthomas/tinyxml2-ex 
, no validation, no 
namespaces), mature and slowly evolving
- pugixml: C++ library, designed for speed with a few features (like 
XPath, no validation, no namespaces), mature and evolving
- libroxml: C library, no clear design goal (includes XPath, namespaces, 
no validation), evolving
- Saxon-C: C/C++ wrapper of the state-of-the-art Java library, largest 
amount of features (XPath and XSLT 3, DTD and XML Schema validation -- 
extension for RelaxNG: http://www.cfoster.net/saxon-jing/ 
 --, namespaces), very mature, 
really evolving (both performance and features), but it requires a JVM 
(Excelsior is built-in, even though it's not been maintained for quite a 
long time)
- Qt: no, I was joking :). Qt XML is not supported anymore, it's 
recommended to switch to QXmlStreamReader and QXmlStreamWriter (which 
are only SAX-like). Qt XML Patterns used to have XPath, XSLT, and XML 
Schema, but it's been deprecated a while ago (Qt 5.13 for the last 
wake-up call, but it hasn't been touched since Qt 4, basically)


If LyX is being really serious about XML (i.e. moving as many things as 
possible to XML technologies), Saxon is probably the way to go. 
Otherwise, it's going to be too heavy to ship Saxon and a JVM along with 
LyX. Instead, pugixml seems to me like a good choice: a few features 
(XPath is the most relevant for LyX, and included in the base library, 
no need for addons), good performance, still maintained (there is a 
chance to have bugs fixed in a newer version, plus security 
vulnerabilities taken care of).
Was this addressed in the virtual meeting? Also, since Xerces-C was the 
most feature full and mature after Saxon-C, I was curious as to why you 
didn't mention it.


Anyhow, I think that for a start we'd need only the most basic features 
(tag insertion, indent), as was the purpose of #12055 in the first place 
(I'm sorry to have opened this pandora's box), so maybe no harm will 
come if we start wrapping pugi.


Let me know what you think, and if this is not the time for this, as 
with LyX 2.4 coming out there might be other things that need focus.

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4 Status Update

[Pavel Sanda]

On Mon, Jan 11, 2021 at 01:25:34PM -0500, Richard Kimberly Heck wrote:
> On 1/11/21 1:22 PM, Pavel Sanda wrote:
> >On Mon, Jan 11, 2021 at 12:36:01PM -0500, Richard Kimberly Heck wrote:
> >>That said: Are there any new features people would
> >>still like to get into 2.4 that require format changes?
> >I still hope to find some time to fix hyperref settings as discussed in
> >https://www.mail-archive.com/lyx-users@lists.lyx.org/msg110459.html
> >
> >Not a new feature, but file format change for sure.
> 
> Can you file a bug for that then, target 2.4.0, keyword fileformat?

It's another variant of #10319. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jean-Marc Lasgouttes]

Le 12/01/2021 à 11:00, Pavel Sanda a écrit :

- I prefer to stay with single digits as long as possible because it's
   easier to remember/communicate them. The moment the version numbers
   go beyond 10, you tend to lose track of versions (experience with
   firefox-like scheme).


Firefox changes its major number on a 6 weeks (maybe 4 weeks now) 
schedule. We change ours every 110 weeks historically. If we go to 3 
now, we will be at 10 in 14 years.


It is more like LibreOffice than Firefox.

But I am not going to argue more than that.
I guess I have to shelve my proposal to rename ourselves to "LyX Office 
Studio", then.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

On Mon, Jan 11, 2021 at 03:58:48PM -0700, Joel Kulesza wrote:
> So, this is effectively how things operate now except collapsing the fourth
> entry into the third.  Once a breaking change occurs, then the jump would
> be made from 2->3.

I agree. If the 4th number is too disturbing collapsing it into +1 of third
digit looks ok.

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

On Mon, Jan 11, 2021 at 08:59:55PM +, José Abílio Matos wrote:
> Since we our release schedule is every two years this will keep us in low 
> numbers for a long time.
> 
> What do you think?

Not surprisingly, I'd propose to stay where we are.

The reasons are two:

- I prefer to stay with single digits as long as possible because it's
  easier to remember/communicate them. The moment the version numbers
  go beyond 10, you tend to lose track of versions (experience with
  firefox-like scheme). 
  
- People are already used to certain numbering scheme x.y.z where staying
  with y means fileformat is fixed. I don't see that we are really solving
  any problem with new proposal while forcing people to adopt new policies.


Major bump 2.x->3.x is fine either when we reach high x number or when
something unusual happens (e.g. XML transition, switch from Qt back to
xforms, 30 years of LyX etc. :))

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: #11532: inputencoding desynchronisation

[Guenter Milde]

On  4.01.21, LyX Ticket Tracker wrote:
> #11532: inputencoding desynchronisation
> --+-
>  Reporter:  milde |   Owner:  lasgouttes
>  Type:  defect|  Status:  new
>  Priority:  low   |   Milestone:
> Component:  latex export  | Version:  2.4.0dev
>  Severity:  normal|  Resolution:
>  Keywords:|
> --+-

> Comment (by rikiheck):

>  Do you think this is one we'll ever actually fix? If not, maybe close as
>  WONTFIX.

Unless Jürgen wants to fix this, I am fine with closing as WONTFIX or
lowest possible priority. Just keep somewhere on record that this is a known
problem with the legacy input encoding scheme.

Günter
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: What Localized Manuals Are Maintained?

[Jean-Pierre Chrétien]

Le 11/01/2021 à 18:52, Richard Kimberly Heck a écrit :
Before I send a note asking for help with the copy-paste stuff, what localized 
manuals are currently maintained? I.e., for which languages do we need to copy 
over the new and changed material?




As I said yesterday, manuals other than Intro and Tutorial are localized in 
French, German, Japanese ans Spanish.


There are translations of specific manuals in these languages as well.

I posted a record of the 2.3 translation status in French on lyx-docs :

https://www.mail-archive.com/lyx-docs@lists.lyx.org/msg09668.html

I committed the final version of Customization since. I really would like to 
translate Jürgen's sections about biblatex in the UserGuide before 2.3.7, can 
you give me an idea of the deadline ?

A couple of months maybe ?

As for the other languages, I'm pretty confident that German manuals are up to 
date as Jürgen writes down the German version of the changes first. I can 
contact Ignacio Garcia for Spanish and Koji Yokota for Japanese to ask about the 
status of their translations.


--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jürgen Spitzmüller]

Am Mo., 11. Jan. 2021 um 23:59 Uhr schrieb Joel Kulesza :

> Regarding semantic versioning: I feel like LyX already (arguably) uses
> that.  The argument I imagine: it's not clear what prompted moving from
> version 1->2, but a Python-based conversion script manages forward/backward
> compatibility in such a way that I regard the "API" as unchanging with the
> various changes that underpin 2.4.0 (maybe I'm mistaken).  I would imagine
> a change from 2->3 if, for example, the .lyx file migrated irreversibly
> from what it is now to XML.  Otherwise, as JMarc noted once I was already
> composing this, the "API" is pretty stable.
>
> Taking Jose's semver example, I'd alternatively summarize as:
>
> So I am proposing for the next version to be 2.4.0.
>
> The stable bug fix releases for this series would be 2.4.1, 2.4.2,...
>
> If, for instance, there is a problem in the stable version 2.4.2 then we
> can immediately release version 2.4.3.
>
>
> So, this is effectively how things operate now except collapsing the
> fourth entry into the third.  Once a breaking change occurs, then the jump
> would be made from 2->3.
>
> Regarding how these numbers might matter to someone: I've had experience
> with organizations that approve software for use based on major version
> number.  So, changing major version number can require re-review for use,
> which inhibits adoption/continued use.  This is not insurmountable, and
> it's a very unique and bizarre concern; however, I did want to raise it as
> an issue and why I'm not too enthusiastic about rapid version number
> changes.  That said, my belief is that numbers are straightforward to count
> and arbitrary anyway, so rapid incrementation doesn't bother me personally.
>

Just for the records, I do not really care as long as the version does not
increase to something bizarre (maybe apply Linus' "no more fingers left to
count" rule).

If we apply Joel's approach, it is well possible that we'll never reach
3.0. At least I hope we won't have changes that are incompatible in the
sense that we cannot convert and revert via lyx2lyx. If this doesn't count,
any major release is such an incompatible change.

Jürgen
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel