On 10/24/2009 01:41 PM, Uwe Stöhr wrote:
rgheck schrieb:
The fact is that we currently don't have a feature that generates
HTML. Our native HTML export is, strictly spoken, currently vapor
ware. We currently don't have something better than eLyXer so why
are you opposed to it?
First of all, I am sick and effing tired of these sorts of remarks
about native HTML output. I expect it from Alex, but not from you. I
did a good bit of work on that, then had to stop due to severe back
problems and serious personal loss, not to mention teaching,
advising, and research, just like a lot of other people around here,
not to mention doing my best to fix 1.6 bugs.
You misunderstood me. I never said that native HTML export is not a
very useful feature and also never doubt your knowledge about coding.
You did a lot for LyX and I hope you will also do in the future.
Please calm down. The fact is that we don't have currently something
better to generate HTML output so why not having a few files more in
our SVN tree? Native HTML is work in progress but is just not yet ready.
I do not need to calm down. I am quite calm, if increasingly frustrated.
Did it not occur to you that NOTHING in 1.7/2.0 needs to be ready yet?
or what?
I leave the discussions about programming and (X)HTML internals to you
both. I only want to have it in our SVN to give it a chance and to
later merge the advantages of both approaches to our native support.
I do not understand what putting in elyxer is our tree has to do with
"giving it a chance", and there is no prospect of any such merge, from
our side. If Alex wants to take advantage of my work, he can do so, but
his is of no help to me. That, indeed, is pretty much what I've been
saying for a long time.
As for why I and many others are opposed to adding elyxer to svn, we
are opposed to adding something to LyX svn that we will then have to
maintain and that no-one in the current development team wants to
maintain. (I for one do not want anything to do with that code.)
Well the idea was to give Alex SVN permissions to maintain it in SVN.
And as Pavel has said, that is not good enough. If it's in our tree,
then WE have to maintain it.
We think adding HTML export is worthwhile, even though very few of us
have any use for it---I actually have no use for it---but we are
certain that the approach taken by elyxer is wrong, as we have tried
time and again to explain.
I fully understand you here but don't understand why this is a reason
for not allowing Alex to do his work in our SVN. Alex and you have
different opinions about the HTML handling, so why not giving
everybody the right to develop his idea? In the end the user will
decide what suits him more. When finally you solution has shown its
strength and is more stable than eLyXer, people will use your solution.
Who is stopping Alex from developing his idea? He seems to be doing
fine. I don't see what merging the two trees has to do with that.
But the most obvious question is this one: What precisely is the
point of adding elyxer to the svn tree? There is no interaction
between it and any of the LyX code except configure.py and one of the
scripts, i.e., no more interaction than any other converter. It was
once suggested that maybe it would encourage Alex to get involved,
but he has repeatedly made clear that he has no interest in doing
anything else with LyX, since he has (inter alia) no interest in
learning C++. None of us have any interest in touching his code,
either. So why one tree?
OK, I started as user without any programming knowledge. I loved LyX
but was frustrated about installing it and therefore wrote the Windows
installer assisted by Angus Leeming. Over the time Angus pushed me to
become a developer and I started with small bug fixes and this way
learned a bit C++ and Qt. So once you work with a program you will
start fixing bugs, at least to get your scripts running - you often
have no other choice.
I'm happy that my installer is in SVN although there is another
approach: Joost's installer. The users can decide what to they ant to
use and that is my idea for the HTML output.
Sure, but none of this answers the question what the benefit is of
having one tree.
Can we please drop this? We have discussed this over, and over, and over.
Richard
