Re: thoughts about LyX's future and proposals
Thanks Helge. You made your point and I fully concur. It is as simple as that: Different tasks need different tools. Who wants to deny that fact? Michael Am 30.07.2018 um 16:13 schrieb Helge Hafting: Den 10. juli 2018 00:19, skrev Uwe Stöhr: [...] * compatibility with other file formats: a major task is to collaborate with others. My solution to this is: use LyX when the others writes LyX or LaTeX. Otherwise, use libreoffice. (word is not an option - I don't use the required windows and I don't pay for sw where good free alternatives exists.) I don't think it is a problem to have more than one word processor. Hence, I don't need LyX to do "everything". I use it for writing, which it does very well. Certainly much better than the alternatives I have seen. I can use libreoffice when someone wants comments on their docx. (And others can use LyX, if they want to co-author with me.) The required sw is free either way, and disk space is cheap enough these days. I don't see why LyX would be a no-go just because "it won't open your old word documents." Word users already have word for that. Just make it clear that this is the case, LyX is for writing new documents (and working on old LyX documents, of course.) One-off conversion can usually be done by copy+paste. My impression is that file format converters are very hard, because the underlying file formats are so different. Word positions stuff on a page - LyX collects your sentences, keeps track of what it all is (text, heading, abstract etc) and do page breaking just-in-time when printing. Before a converter can be written (by volunteer or a funded programmer) we need to know what such a conversion should do: * Create a converted document that renders the same way on the other platform? I don't think this is realistic. If we go for the same line/page breaking, then the converted document will be full of positioning commands, and certainly not something that can be edited in a meaningful way. * A "reasonable" conversion in that headings become headings, plain text becomes plain text - and all supportable features survive conversion? The first problem with this, is that people *will* complain when something looks different. Even if still looks good. A subsection might get on another page, making it hard to phone up a co-author "to fix the spelling error on page 13, at the end of the second line". Another problem is that many word documents are created in a very bad way. There are forced line breaks, forced page breaks and similar all over. (A "good" word document is one that looks nice, and where you can change the text size, the page size and the margins - and then it still looks good without you having to change anything. Such a document may not be hard to convert to LyX.) A document that has some manual line breaks, usually breaks badly if you increase the font size or make the lines a little shorter. Such a document will also be hard to convert to LyX in a meaningful way. What to do about a manual page break? Word users uses them to avoid getting a heading at the end of page - as word doesn't always do that automatically. But they also use them mistakenly, where word is capable of breaking automatically. Upon conversion to LyX, the line breaking will be different, and also the page breaking. LyX still support forced breaks, but should we take them all, or none, or some? Third problem: too many features that doesn't exist in both LyX and word, which breaks conversions of any documents using them. I am not opposed to converters, but even specifying one seems hard. If you can solve that problem, then a converter might be possible to write. [...] I could add some more things. But this is not my point. I see that most LyX developers only code for their pleasure not for the things the potential customers need the most. That might have something to do with not having any actual customers. (paying customers, that is.) Volunteers generally do what they want, and rarely care about 'market share'. I want enough 'market share' that LyX keeps being developed - but we are there already. You may want to look into Pavel's idea about funding features for those willing to pay. I don't want to blame anybody but I want to make clear that we all need to improve our sights to the real world. There is a good reason why more than 90 % of PC users use Windows. I am not sure there are any good reasons for those 90%, other than marketing & inertia. It is not as if windows actually have advantages. (Use windows because you always used windows - even if the new version is almost as different from the old as linux is). Incidentally, this inertia also means lots of people won't switch word processor - even if all shortcomings in LyX were fixed. For example I also made my step out of the Windows world to understand how it is under Linux. I found out that it does change the view on t
Re: thoughts about LyX's future and proposals
Den 10. juli 2018 00:19, skrev Uwe Stöhr: [...] * compatibility with other file formats: a major task is to collaborate with others. My solution to this is: use LyX when the others writes LyX or LaTeX. Otherwise, use libreoffice. (word is not an option - I don't use the required windows and I don't pay for sw where good free alternatives exists.) I don't think it is a problem to have more than one word processor. Hence, I don't need LyX to do "everything". I use it for writing, which it does very well. Certainly much better than the alternatives I have seen. I can use libreoffice when someone wants comments on their docx. (And others can use LyX, if they want to co-author with me.) The required sw is free either way, and disk space is cheap enough these days. I don't see why LyX would be a no-go just because "it won't open your old word documents." Word users already have word for that. Just make it clear that this is the case, LyX is for writing new documents (and working on old LyX documents, of course.) One-off conversion can usually be done by copy+paste. My impression is that file format converters are very hard, because the underlying file formats are so different. Word positions stuff on a page - LyX collects your sentences, keeps track of what it all is (text, heading, abstract etc) and do page breaking just-in-time when printing. Before a converter can be written (by volunteer or a funded programmer) we need to know what such a conversion should do: * Create a converted document that renders the same way on the other platform? I don't think this is realistic. If we go for the same line/page breaking, then the converted document will be full of positioning commands, and certainly not something that can be edited in a meaningful way. * A "reasonable" conversion in that headings become headings, plain text becomes plain text - and all supportable features survive conversion? The first problem with this, is that people *will* complain when something looks different. Even if still looks good. A subsection might get on another page, making it hard to phone up a co-author "to fix the spelling error on page 13, at the end of the second line". Another problem is that many word documents are created in a very bad way. There are forced line breaks, forced page breaks and similar all over. (A "good" word document is one that looks nice, and where you can change the text size, the page size and the margins - and then it still looks good without you having to change anything. Such a document may not be hard to convert to LyX.) A document that has some manual line breaks, usually breaks badly if you increase the font size or make the lines a little shorter. Such a document will also be hard to convert to LyX in a meaningful way. What to do about a manual page break? Word users uses them to avoid getting a heading at the end of page - as word doesn't always do that automatically. But they also use them mistakenly, where word is capable of breaking automatically. Upon conversion to LyX, the line breaking will be different, and also the page breaking. LyX still support forced breaks, but should we take them all, or none, or some? Third problem: too many features that doesn't exist in both LyX and word, which breaks conversions of any documents using them. I am not opposed to converters, but even specifying one seems hard. If you can solve that problem, then a converter might be possible to write. [...] I could add some more things. But this is not my point. I see that most LyX developers only code for their pleasure not for the things the potential customers need the most. That might have something to do with not having any actual customers. (paying customers, that is.) Volunteers generally do what they want, and rarely care about 'market share'. I want enough 'market share' that LyX keeps being developed - but we are there already. You may want to look into Pavel's idea about funding features for those willing to pay. I don't want to blame anybody but I want to make clear that we all need to improve our sights to the real world. There is a good reason why more than 90 % of PC users use Windows. I am not sure there are any good reasons for those 90%, other than marketing & inertia. It is not as if windows actually have advantages. (Use windows because you always used windows - even if the new version is almost as different from the old as linux is). Incidentally, this inertia also means lots of people won't switch word processor - even if all shortcomings in LyX were fixed. For example I also made my step out of the Windows world to understand how it is under Linux. I found out that it does change the view on the treatment of third-party programs but the main deficiencies of LyX remain: missing file format conversion and simplicity. Up to now me only developed things some of use needed for their private tasks. J
Re: thoughts about LyX's future and proposals
On 19/07/2018 17:52, Jean-Marc Lasgouttes wrote: There a lot of tickets on trac that either point to issues or propose well designed features that I do not have time to work on. Racoon, for example has written plenty of these and I feel bad about neglecting most f them. As far as I am concerned, I am pretty happy with the process. Thanks a lot for all your efforts! Best, Daniel
Re: thoughts about LyX's future and proposals
Hi Uwe, your message wakes me up from my LyX-idle period... On 10/07/2018 00:19, Uwe Stöhr wrote: - I gave lectures about LyX at my university, tried to introduce LyX to friends and family members. Nevertheless the success was "modest" even under my students. shared feelings here, especially with the "no success with colleagues & students" part, as there's a widespread belief that you need to learn LaTeX to write papers, and after that nobody wants to learn anything else, combine with no journal nor conference accepts a .lyx submission AFAIK ;-P... ... albeit I managed to use LyX myself to write papers, technical reports, even patent applications, to co-edit stuff with others on a git repo where some sections are in .lyx, others in .tex, etc... So what can be done? In my opinion, we should - define the goal of LyX together with our users. isn't that what a users@ list and a Trac tracker already do ? - setup a "board of development" that take care of user feedback and who define the things the next version of LyX should have. Such a board should only be 50% consist of developers. Translators are not treated as developers. The idea is to see what people really need and to organize its development so that several developers develop a certain feature. as from the little I've been observing over the years about how LyX devels work, this looks like proposing a PKI when everyone is familiar and happy with GPG ;-P I share the frustrating feeling that the overall WYSIWYG/M goal looks like a too much idealistic, almost impossible & too far away target, perhaps because the underlying LaTeX is way too complicated, with so/too many extensions & features, but AFAICS, progress has been done on development, along several axes -- just see the "what's new" in every release, and see the git log. If such progress is small w.r.t. the amount of work that should be put in place in order to let the tool attract a much wider users base, then guess that must be the case... because still, when you start from a publisher .tex template, and you want to work with LyX, headaches start coming, or your .lyx starts being filled-up with TeX code blocks As to the side of practical improvements, I've got a feeling that the P&R side of LyX has seen limited efforts over the years, both in terms of attracting users, and devels. I'll conclude reminding how/why I've got involved on the project at the beginning: 1) inability to be a LaTeX expert, frustration that in year 200x we still could: a) use a beautiful WYSIWYG tool that can't even handle styles, nor nested lists nor references nor floats nor maths properly/conveniently; b) compile a document (wth?), and having to deal with a life-cycle that seems more for sw devels rather than for authors, with incomprehensible errors, a missing "}" that gives you a 1-h headache & the likes... 2) the need for sharing docs with plenty of maths with a colleague, where LyX was making the interaction so much faster 3) the identification of a feature that looked like "cool" to add to the tool (the search dialog looked miserable at that time, compared to the LyX on-screen rendering capabilities), that intrigued me, and where there seemed to be an easy prototyping path 4) the satisfaction coming from seeing that cool feature working the first times, that was amazing 5) a bit of frustration after seeing what looked like the impossibility to see that (big & complex) patch-set merged 6) after <1y inactivity, I came back to rebase the patch and retry to get devels interested, thanks to a random meeting with my colleague Enrico at the local cafeteria, who I had no clue was actually the same Enrico on the list ;-P, I happened to show him the old compiled tool, and he gave me back an exceptional motivational push -- thanks to that I made my mind into rebasing and making a YT video, which succeeded a lot more in seeing other devels interested 7) after that, I used to lend a hand with other random features, when I had some time, including chasing a few bugs when approaching new releases... For me, contributing to LyX has been a bit something across tackling some challenges, learning something new, being involved in a relatively complex software project, and having a lot of fun & satisfaction seeing patches ultimately being merged! And still, I use excerpts from LyX sources as practical examples of some design patterns in my university lectures :-)! I'd like to stress on the "<1y" lag time between point 5) and 6) above: personally, I think that the key to getting new devels involved, is to let them contribute more easily, people need to be pulled in with cheerful enthusiasm, whilst a "board of members" sounds something that goes into a different direction, doesn't it ? After all, there's already a min pool of people controlling permissions on the repo, and putting the great effort into every release cycle (thx for that!) & the likes, no? My2c
Re: thoughts about LyX's future and proposals
Le 19/07/2018 à 15:28, mn a écrit : What would be some middle ground here? Of course the right attitude is somewhere in the middle. My message came ou harsher than it should have. I certainly do not want to impose my will on a dev, do not want to be a member of a committee. But a lot of features I'd like to see implemented or bugs fixed (even readymade solutions I proposed) just do not materialize, certainly not in a timeframe that gets me excited. The problem I see is that, as a developer, I need some incentive to work on a feature. If I look back on stuff that I implemented, the categories are: * a feature that I happen to need (extended literate programming support, little annoyances I have when using LyX) * something that interests me and that I presume to be generally desirable (speed, better rendering...) * something that nobody asks for but that needs to be done if we want to go forward (unicode support for tex2lyx, large code cleanup to get rid of accumulated cruft) * something I began because I though it was easy but that proves to be very complicated (math formulae display). After starting, it is too late to stop :) * small things that people requested and I know how to do while reading the bug report. In conclusion, it is a match between a need and someone able/willing to provide a solution. I do not think that we will be able to go very far from this equilibrium point. What is not in these categories for example is conversion to/from MS Word: * I do not use Word if I can avoid to * converters are pretty difficult and the result is often mediocre; tex2lyx is already very difficult to get right, and LyX is supposed to be close to LaTeX. Therefore I do not see any compelling reason to embark in this endeavour. There is just not enough *systematic* user feedback. Error reports, user-ml private feedback are certainly not showing the devs a complete and accurate or representative picture. It is indeed in this "negociation" phase that we can make progress to find good matches. Things are not easy though. There a lot of tickets on trac that either point to issues or propose well designed features that I do not have time to work on. Racoon, for example has written plenty of these and I feel bad about neglecting most f them. I do have almost 10 years old bug reports taunting me in my mail box :) As can be seen in the email exchange above: Devs have quite distinct impressions and personal opinions on the situation. Do we ? ;) I think a compromise might involve a more quantified user feedback, maybe for the ticket tracker? Currently only the devs assign priority to a ticket. How about adding a running counter on which users might then vote? I see these voting things on some bug trackers but I am not sure that they help. Having a feature highly voted on does not guarantee that it is fixable or that somebody has the time/urging/capacity to implement it. This can even create frustration from users. As Pavel mentioned, there is the Features page that serves a similar purpose. We should maybe move the ones that have been implemented somewhere else, so that the green highlight does not catch the eye so much. In any case I think Uwe's idea should be reconcilable with JMarc's stance on that. I see a benefit for everyone involved if that could be implemented. Devs still choose what to do next, what seems to them the most taxing problem or the nicest thing to add, but with an awareness of a more objective quality of what others think about that. We definitely need to find ways forward. But the number of active developers is not that big. Of course, we will try to be supportive of users who want to try a toe in the cold water of development ! Best regards, JMarc
Re: thoughts about LyX's future and proposals
mn wrote: > I think a compromise might involve a more quantified user feedback, > maybe for the ticket tracker? > > Currently only the devs assign priority to a ticket. How about adding a > running counter on which users might then vote? We have smt like this for features (not bugs) on our wiki, you can put your name in https://wiki.lyx.org/LyX/FeaturePoll1 for features and as far as I remember there was reflection on this list, eg continuous spell check via donation started thanks to this. Pavel
Re: thoughts about LyX's future and proposals
On 17.07.18 16:26, Jean-Marc Lasgouttes wrote: > Le 17/07/2018 à 02:17, Uwe Stöhr a écrit : >>> So what can be done? In my opinion, we should - define the goal >>> of LyX together with our users. Maybe the result is to hide >>> background stuff, maybe it is the opposite. Whatever it might be, >>> that should be the base for future development. - setup a "board >>> of development" that take care of user feedback and who define >>> the things the next version of LyX should have. Such a board >>> should only be 50% consist of developers. Translators are not >>> treated as developers. The idea is to see what people really need >>> and to organize its development so that several developers >>> develop a certain feature. >> >> I only made these 2 proposals and thought they are worth to be considered. >> It is OK not to agree, but what about other ideas or do you think >> we should just continue as we did the last months? I mean criticism >> should be constructive. So I would her your ideas for future >> development. > > OK, here are my _final_ words on the subject then. Considering the > number of active developers, we do not have that much free goodwill > to spend on design by committee. I already have a day job, thanks. I > am not looking for a new boss telling me what I should be doing > during my free time. > > Despite your insistence that we do not love our users, I do my best. > If it is not good enough for you, so be it. > > I hope this is a clear enough answer, it is as constructive as I can > be. > > JMarc > > PS: remember that LyX is a platypus: something so weirdly designed > that everybody is surprised that it even exists. I understand you > would better have something useful like a cow or a duck. However, > these are boring animals and everybody loves platypuses :) What would be some middle ground here? I certainly do not want to impose my will on a dev, do not want to be a member of a committee. But a lot of features I'd like to see implemented or bugs fixed (even readymade solutions I proposed) just do not materialize, certainly not in a timeframe that gets me excited. There is just not enough *systematic* user feedback. Error reports, user-ml private feedback are certainly not showing the devs a complete and accurate or representative picture. As can be seen in the email exchange above: Devs have quite distinct impressions and personal opinions on the situation. I do not suggest to conduct surveys or the like. --- Just an example: But the discussion about the win-Installer has demonstrated quite a bit that there is apparently no objective basis to come to a solution. We never knew how many people use actually use Lyx-Win_MikTex compared to the less problematic (for that "issue") Lyx-Win-TexLive. --- end of example I think a compromise might involve a more quantified user feedback, maybe for the ticket tracker? Currently only the devs assign priority to a ticket. How about adding a running counter on which users might then vote? In any case I think Uwe's idea should be reconcilable with JMarc's stance on that. I see a benefit for everyone involved if that could be implemented. Devs still choose what to do next, what seems to them the most taxing problem or the nicest thing to add, but with an awareness of a more objective quality of what others think about that. greetings mn
Re: thoughts about LyX's future and proposals
On 07/18/2018 02:01 PM, Jean-Pierre Chrétien wrote: > Le 18/07/2018 à 15:01, Neal Becker a écrit : > >> >> You got me curious, so I just tried exporting a ieee journal article >> to odt >> (pandoc). The result was pretty useless. I might as well have just >> converted to plain txt. >> >> > > Before I retired (and thus before pandoc), the only converter which > gave me usable results was latex2rtf, and I used it quite a lot. For simple documents, that works reasonably well, in my experience. Indeed, for simple documents, lots of things work well. I've used LyX's own XHTML output and imported that into LibreOffice, for example. But for documents that are at all complex, nothing works very well. Especially if there are many formulas. That's really the issue, it seems to me. Very many people who use LaTeX do so because of how good it is with formulas. If converters can't handle that, then they won't be very useful to very many people. And then the problem is that formula support in ODT and DOCX is very primitive compared to what LaTeX can do, even without pstricks and tikz and the like. > From Document to latex, the result depends completely upon the > structure of the document. For relatively simple documents, LibreOffice's writer2latex works quite well, if you set it to use "Clean" or "Ultra-clean" mode. Riki
Re: thoughts about LyX's future and proposals
Le 18/07/2018 à 15:01, Neal Becker a écrit : You got me curious, so I just tried exporting a ieee journal article to odt (pandoc). The result was pretty useless. I might as well have just converted to plain txt. Before I retired (and thus before pandoc), the only converter which gave me usable results was latex2rtf, and I used it quite a lot. From Document to latex, the result depends completely upon the structure of the document. I remember a shared doc having 95 styles, each author rewriting his own styles in turn. -- Jean-Pierre
Re: thoughts about LyX's future and proposals
Richard Kimberly Heck wrote: > On 07/17/2018 09:29 AM, William Adams wrote: >> I've asked before, and I'd really like to see direct support for >> pandoc in File | Open/Save or (Import/Export) whatever makes sense --- >> just install pandoc if it's not available and allow one to directly >> convert stuff into and out of LyX. > > We already configure pandoc as a converter between LaTeX and ODT or > DOCX, both ways. If you have it installed, you should see both these > options on the export menu. If not, try reconfiguring. > > Riki You got me curious, so I just tried exporting a ieee journal article to odt (pandoc). The result was pretty useless. I might as well have just converted to plain txt.
Re: thoughts about LyX's future and proposals
On 07/16/2018 08:17 PM, Uwe Stöhr wrote: > Am 10.07.2018 um 00:19 schrieb Uwe Stöhr: > >> As result I wrote this lengthy mail and hope you read it till the end >> where I make some proposals: > > Obviously nobody has any comments on my thoughts about LyX's future. > That is sad because I only got few private mails as replies stating > that indeed the missing fileformat conversion capabilities are a real > problem in real life. > >> So what can be done? In my opinion, we should >> - define the goal of LyX together with our users. Maybe the result is >> to hide background stuff, maybe it is the opposite. Whatever it might >> be, that should be the base for future development. >> - setup a "board of development" that take care of user feedback and >> who define the things the next version of LyX should have. Such a >> board should only be 50% consist of developers. Translators are not >> treated as developers. The idea is to see what people really need and >> to organize its development so that several developers develop a >> certain feature. > > I only made these 2 proposals and thought they are worth to be > considered. > It is OK not to agree, but what about other ideas or do you think we > should just continue as we did the last months? I mean criticism > should be constructive. So I would her your ideas for future development. It's a perfectly fine idea to find out what users would like, though they do frequently tell us, via bug reports, emails, and the like. But as JMarc and Pavel have both pointed out, we are all doing this in our spare time. We work on what gives us pleasure and satisfaction, or what seems challenging and interesting, or whatever. Other projects that have boards---like the Document Foundation---also have *paid developers*. We do not, unless someone wants to crowdfund something, the way automatic spellcheck was done IIRC. Then they can put some conditions on what gets done and how. To take an example: Yes, lots of people would love it if there were a better LyX <--> ODT conversion, so they could work with people using other programs. This issue has been raised over and over again. But why should I spend my time working on something I'll never use? More importantly, I think it's more or less our collective judgement that this is a pipedream: You will *never* get a converter that is reliable enough for on-the-fly collaboration between people use LyX and people using LibreOffice. What you might get some day is a decent one-way conversion for journals that don't accept LaTeX. But even that is very hard. None of the existing tools is reliable. Here's some evidence. I have recently been involved with two book projects with a major academic press. Both are collections of papers; both had some people submit papers in LaTeX and some in DOCX. The press needed everything in one form and so decided to convert the LaTeX submissions to DOCX (which was the wrong choice). It was a *disaster*, so much so that some people were all but threatening to withdraw their submissions. It took over a month to get it sorted out. They deal with this kind of thing *all the time*. And even they can't get it right, just one way. Oh, and you forgot this part: > The idea is that playing in a big band is fun despite that e.g. you > cannot play your trombone when you like it but only in a way it fits > to the whole band. What do you call it when one player wants to do one thing and every single other player wants to do a different thing, and then rather than play "in a way that fits to the whole band" the first player takes their trombone and goes home? Riki
Re: thoughts about LyX's future and proposals
On 07/17/2018 09:29 AM, William Adams wrote: > I've asked before, and I'd really like to see direct support for > pandoc in File | Open/Save or (Import/Export) whatever makes sense --- > just install pandoc if it's not available and allow one to directly > convert stuff into and out of LyX. We already configure pandoc as a converter between LaTeX and ODT or DOCX, both ways. If you have it installed, you should see both these options on the export menu. If not, try reconfiguring. Riki
Re: thoughts about LyX's future and proposals
Uwe Stöhr wrote: >> So what can be done? In my opinion, we should >> - define the goal of LyX together with our users. Maybe the result is to >> hide background stuff, maybe it is the opposite. Whatever it might be, >> that should be the base for future development. >> - setup a "board of development" that take care of user feedback and who >> define the things the next version of LyX should have. Such a board should >> only be 50% consist of developers. Translators are not treated as >> developers. The idea is to see what people really need and to organize its >> development so that several developers develop a certain feature. > > I only made these 2 proposals and thought they are worth to be considered. > It is OK not to agree, but what about other ideas or do you think we should > just continue as we did the last months? I mean criticism should be > constructive. So I would her your ideas for future development. I find the idea of consumer-driven comittee which dictates for free what the other volunteers should do in their spare time quite bizarre concept. If non-dev user becomes a major force in defining the goals of the project in the next release he should be asked for money to fund that. That is how "real" life of software you like referring to works. So to be constructive - if there are features of LyX which critical mass of users finds to be missing - make it project, list it at https://www.lyx.org/Donate and attract enough users to donate for such project. This is actually much better measure than pointless discusssions on what "average user" desperately needs. Maybe you have clear idea what those features are (like pandoc). If not you have all my blessing to run some campaign in mail lists or on our web page, in media or wherever... Pavel
Re: thoughts about LyX's future and proposals
Le 17/07/2018 à 02:17, Uwe Stöhr a écrit : So what can be done? In my opinion, we should - define the goal of LyX together with our users. Maybe the result is to hide background stuff, maybe it is the opposite. Whatever it might be, that should be the base for future development. - setup a "board of development" that take care of user feedback and who define the things the next version of LyX should have. Such a board should only be 50% consist of developers. Translators are not treated as developers. The idea is to see what people really need and to organize its development so that several developers develop a certain feature. I only made these 2 proposals and thought they are worth to be considered. It is OK not to agree, but what about other ideas or do you think we should just continue as we did the last months? I mean criticism should be constructive. So I would her your ideas for future development. OK, here are my _final_ words on the subject then. Considering the number of active developers, we do not have that much free goodwill to spend on design by committee. I already have a day job, thanks. I am not looking for a new boss telling me what I should be doing during my free time. Despite your insistence that we do not love our users, I do my best. If it is not good enough for you, so be it. I hope this is a clear enough answer, it is as constructive as I can be. JMarc PS: remember that LyX is a platypus: something so weirdly designed that everybody is surprised that it even exists. I understand you would better have something useful like a cow or a duck. However, these are boring animals and everybody loves platypuses :)
Re: thoughts about LyX's future and proposals
I've asked before, and I'd really like to see direct support for pandoc in File | Open/Save or (Import/Export) whatever makes sense --- just install pandoc if it's not available and allow one to directly convert stuff into and out of LyX. I'd be fine w/ a separate menu or menu entry for pandoc conversions --- it'd make LyX a lot more useful to me --- most of my computer usage these days is on a tablet w/ a stylus, so CLI stuff is awkward, requiring that I attach a keyboard or bring up a virtual one rather than a writing area. William On Mon, Jul 16, 2018 at 8:17 PM, Uwe Stöhr wrote: > Am 10.07.2018 um 00:19 schrieb Uwe Stöhr: > > As result I wrote this lengthy mail and hope you read it till the end >> where I make some proposals: >> > > Obviously nobody has any comments on my thoughts about LyX's future. That > is sad because I only got few private mails as replies stating that indeed > the missing fileformat conversion capabilities are a real problem in real > life. > > So what can be done? In my opinion, we should >> - define the goal of LyX together with our users. Maybe the result is to >> hide background stuff, maybe it is the opposite. Whatever it might be, that >> should be the base for future development. >> - setup a "board of development" that take care of user feedback and who >> define the things the next version of LyX should have. Such a board should >> only be 50% consist of developers. Translators are not treated as >> developers. The idea is to see what people really need and to organize its >> development so that several developers develop a certain feature. >> > > I only made these 2 proposals and thought they are worth to be considered. > It is OK not to agree, but what about other ideas or do you think we > should just continue as we did the last months? I mean criticism should be > constructive. So I would her your ideas for future development. > > thanks and regards > Uwe >
Re: thoughts about LyX's future and proposals
Am 10.07.2018 um 00:19 schrieb Uwe Stöhr: As result I wrote this lengthy mail and hope you read it till the end where I make some proposals: Obviously nobody has any comments on my thoughts about LyX's future. That is sad because I only got few private mails as replies stating that indeed the missing fileformat conversion capabilities are a real problem in real life. So what can be done? In my opinion, we should - define the goal of LyX together with our users. Maybe the result is to hide background stuff, maybe it is the opposite. Whatever it might be, that should be the base for future development. - setup a "board of development" that take care of user feedback and who define the things the next version of LyX should have. Such a board should only be 50% consist of developers. Translators are not treated as developers. The idea is to see what people really need and to organize its development so that several developers develop a certain feature. I only made these 2 proposals and thought they are worth to be considered. It is OK not to agree, but what about other ideas or do you think we should just continue as we did the last months? I mean criticism should be constructive. So I would her your ideas for future development. thanks and regards Uwe
thoughts about LyX's future and proposals
Dear LyX colleagues, apologies for being off so long I had an accident hindering me to use keyboards. However, this gave me some time to think about LyX in general. As result I wrote this lengthy mail and hope you read it till the end where I make some proposals: - I was developing LyX for about 15 years. I always focused on convenience. Since it took me hours to get a working LyX 1.3 installation I once started the development of a proper installer. - the installer was a success and more people used LyX under Windows. - I gave lectures about LyX at my university, tried to introduce LyX to friends and family members. Nevertheless the success was "modest" even under my students. - I learned bit by bit what people really need and bit by bit I lost confidence that LyX can suit their needs. One problem is that we as the LyX team never made a market analysis. I first started to understand real-life for software after leaving the university. In my experience these are the two important points of what a writing software must offer to be used by non-university people: * keep it simple: nobody has time to learn about the background of a program. That is not ignorance but lack of time. All the time we have to deliver things in timeframes defined by others (bosses or customers). So a typical task is "write an instruction manual within 2 days". How you do that doesn't matter, the deadline is the important thing. I never thought about how images spell-checking etc. are handled in Word and LibreOffice. I just use them because they allow me to deliver before the deadline. That makes my a typical user - I do nothing more with Word and LibreOffice than to use them. I don't have to know about their internals and that makes these programs attractive to me. As consequence I did not only set up the Win installer to hide background stuff but I also added support for as many languages to LyX as possible. I spent a lot of time with this and also with the developers of spell-checking libraries, of third-party programs like MiKTeX and even with font designers. * compatibility with other file formats: a major task is to collaborate with others. That means different persons with different hardware sitting in different cities or countries have to collaborate by editing the same text. Outside the university you cannot choose what program you can use. Every project has its own software requirements. Therefore you always have a required file format in which you have to deliver your work. That is for research projects often OpenDocument in industry projects in most cases Office Open XML. For longer and structured texts (LyX's core competence) I never had the case that only one persons is writing this. I am now away from the university for 7 years and have insights in several industry branches, automotive, packaging, machine building etc. I was involved in small and big research projects up to EU level. LyX dos not really provide the compatibility feature. As consequence I added basic support for file conversions via Pandoc. I also spent some time to improve Pandoc. The original idea of LyX was to hide the LaTeX stuff and provide a program with which users who just want or have to use can focus on writing without being forced to learn background stuff about LaTeX etc. In my opinion the development of LyX looses this goal. More and more expert things are build in to LyX while the basic stuff is not provided. For example: * Many documents are not typesetable in some languages like e.g. Arabic because there are no fonts covering all characters. Ask e.g. Hatim how often he has to do weird font stuff to get e.g. the LyX's docs translated to Arabic. That must be improved or LyX can't be used by average people for Arabic, Urdu etc. LaTeX allows font changes but LyX is lacking support for them. * the file format compatibility of LyX is really bad. There is so much more we can do. I am now fully convinced that if LyX is not able soon to get a proper result for the formats OpenDocument and HTML it will loose most of its userbase and won't get new users. It is a no-go that e.g. the unmaintained eLyXer gives still much better results in HTML than LyX's own engine in terms of readability of images and tables. I could add some more things. But this is not my point. I see that most LyX developers only code for their pleasure not for the things the potential customers need the most. I don't want to blame anybody but I want to make clear that we all need to improve our sights to the real world. There is a good reason why more than 90 % of PC users use Windows. For example I also made my step out of the Windows world to understand how it is under Linux. I found out that it does change the view on the treatment of third-party programs but the main deficiencies of LyX remain: missing file format conversion and simplicity. Up to now me only developed things some of use needed for the
