Am 20.07.2011 22:32, schrieb Pavel Sanda:
yes, we are from different worlds. i read documentation exceptionaly and
most of my know-how of software comes from playing with trial and error.
thus the two hints inside the module are quite enough for user like me :)
in the same vein i'm not way too much worried about possible latex errors.
i have seen zilion of them while working with lyx and when they happen i just
fix the problem.
Sometimes I'm really close to stop working for LyX. I'm frustrated that we don't focus on real life.
Real life means for me that a student coming from school to the university has to write his first
internship report. He will not know computer internals, knows perhaps a little Word, how to use
Facebook and to write emails. LaTeX is complicated and you have to learn a lot to be able to use it.
That is why Matthias Ettrich came to the conclusion that LaTeX will only be a success when it is as
easy to handle like e.g. Word (he told me this at our last meeting) and therefore started LyX. That
is also my opinion and that is why I work for LyX.
Back to my example. The student decides to use LyX because a colleague told him about it and he is
happy that he can write all the complicated equation and citations easily. Short before the deadline
he thinks, that it would be fancy to use an initial for the acknowledgments. He is using your style
but suddenly cannot compile the file - panic! What means "LaTeX error"? what is this cryptic error
message is about? Damn, what nasty bug. The problem is now that he made a lot of other changes after
inserting the initial and therefore don't come to the idea that the initial module is the reason of
the bug. A nightmare for him and even if he is able to find the problem, he won't recommend LyX to
his friends and they not to their friends, and so on.
(I spent countless discussions where I tried to convince people to give LyX a try, but they had
heard from a friend of a friend, that it doesn't work and therefore didn't even try it out.)
So if we are not willing to produce working LaTeX code, we can quit LyX!
You have had a look at the lettrine manual when you implemented the module. So you have seen that
\lettrine requires two arguments but cut of one. As an experienced user you also know that incorrect
LaTeX code can destroy a whole document. The fact that you did this purposely made me angry. My
personal goal is to help that average computer users will and are able to use LyX and that it will
be more comfortable than e.g. Word and will therefore fight against this way of working. We are all
making bugs and every software has bugs but to introduce a bug purposely is something I cannot
understand.
My style needs TeX Code but as explained I had to use this to overcome your error prone solution.
Moreover, when a user wants to use the Initials module, he will now see in the description, where to
find a documentation how it works. This minimizes that people use it without reading the doc about
it. As soon as InsetLayout supports arguments, we can go away from my solution and implement a final
solution that works without any TeX Code. But using the module without having a look at the example
in the manual will never work. But this is not a problem as this applies for many things like
theorems or beamer.
thats why i'm not jumping for joy about the style solution. its just nicer
ERT and there is no way how to use it except of reading some additional
docs.
But the most important thing is that it works!
Our aim should be to
provide features that do work in all cases and don't interfere with other
ones, or even lead to LaTeX errors.
its nice to read this just mail after you calmly throw to the dustbin warnings
about latex issues (ie missing packages) in the manuals. because we can't
care about all cases.
Please don't mix this up. The package installation is something outside LyX.
We worked hard that this doesn't happen
otherwise LyX would be quite useless for real life documents like a thesis
or a business report. Where do you see that problems? If there is one it is
a bug we need to fix.
especially the starting pages of papers with wild combination of title, date,
subtitile, authors, affiliation, abstract are rich source of latex errs.
Can you please provide an example with the bug you are encountering.
uisng space inset is magic, ie. you can not trust that putting 1.mm space in
lyx document
will have this result in pdf output. you never know what happen unless you
latex it.
If this would be the case, LyX would be unusable. Of course you get 1 mm space when you insert it or
do you have an example where this is not the case?
or mixing different latex packages.
Not when using the packages supported by LyX. For TeX Code it is of course your turn as it is then
your decision that you want to use it purposely this way.
or using different output routes
like postscript vs pdf.
PDF is a subset of PostScript, so this is also not true. What is true is that the different
converters act sometimes differently but we already catch the known problems. As soon as a user
informed us about such a problem, we could fix this in the past.
OK, DVI is a special format and we therefore described everything in the docs according to PDF
output and describe the limitations of DVI.
or insert weird combination of insets into each other.
Do you have an example? If so, we must fix it.
for branch:
- new style can be added, lyx 2.0.0 won't process 2.0.1 files. i dont remember
what was the
previous policies about adding stuff.
If we are not allowed to add and rename styles, LyX would be unusable for many layouts. An example:
as Elsevier came up with its new class elsarticle that replaced elsart we had to add many new styles
and even a completely new layout file. Elsevier owns about 60% of the scientific publishing market
so that otherwise LyX would not have been usable for paper submissions to the most important
publisher until LyX 2.0. This would have been 1.5 years! Or take the Springer classes that in the
past frequently renamed their commands like \eml to \email. But paper submitters always have to use
the latest class files, so we cannot wait and have to adapt these changes in our layouts for the
next bugfix release of LyX. Then of course the older .x release was not able to process a file that
is created with the latest version of LyX.
- i dont see latex the problems described as something detrimental, the more
that the second
solution calls for the same problems (ie instruct user to use ERT commands).
As said, the TeX Code is only necessary because of an accidentally introduced LyX limitation for
InsetLayout. As soon we fix this (this would not be a fileformat change) the TeX Code braces can go.
But OK, let's leave your style because the final solution will be an InsetLayout. So we can then
adapt your style for the final solution.
regards Uwe
