On 09/14/2009 06:49 PM, Alex Fernandez wrote:
On Mon, Sep 14, 2009 at 2:58 AM, rgheck<rgh...@bobjweil.com> wrote:
I'm a little unclear what's meant by "integration" here. Could you explain?
Are we talking about the way that ps2pdf is integrated with LyX, or
something else?
"Integration" means, in general, making both things work together. This time it
is a little different than what is done with ps2pdf -- eLyXer is now also distributed as
a library (elyxerconv), as well as an executable. With this patch, integration is now
done using the library. A little bit of glue Python code is required to call this
library, and this is elyxerbridge.py.
And why is that a good thing? Why does it matter, from LyX's point of
view, how elyxer is distributed? Why should LyX adjust itself to the
requirements of some downstream library? This is very much the opposite
of how things are normally done. YOU (downstream) adjust to US
(upstream), unless you have a very good reason to the contrary, and I do
not see one. Which is why I was asking.
(I see even less of a reason to worry about this given the progress on
native HTML output, which everyone who has considered the question and
who knows anything about the matter knows is the only sensible option,
long term.)
It seems to me that there is a general failure here to understand
something: If we add some code to LyX to take care of some problem that
is randomly here or there (i.e., if we hack the source in some
unprincipled way), then that code has to be maintained, and the burden
of maintaining it will fall upon those of use who maintain LyX, NOT upon
those who are calling for the hack in question, since they don't even
have commit rights, for one thing. (The same applies to any
converter-specific code that might be entered in the LyX tree.) Someone
has to maintain the code, and the simple fact is that it will end up
being me, or Jurgen, or Vincent, or one of the other active developers,
or someone who comes along later. I don't really care for this scenario.
I have no interest in making sure that elyxerbridge.py works with the
latest version of elyxer, or keeps working with the latest version of
python, let alone that it continues to be a good workaround for whatever
Micro$oft bug is motivating this whole disaster in the first place.
Whether anyone else wants to deal with this garbage, I don't know, but
even if someone does now, that isn't the issue. The issue is that this
hasn't got anything to do with LyX, and I really do not understand why
you either cannot or will not understand that. What's so unclear here?
Problems integrating elyxer with Windosw$ are YOUR problems, not OUR
problems.
In particular, I don't understand why the situation with elyxer is any
different than the situation with any third-party converter that we call.
You put it somewhere in your path, and voila, LyX finds it, configures it,
etc, etc. I can't see why it would have to go into some LyX-related
directory, or why that would be a moderately good idea. What is it that I'm
missing?
As Uwe has explained above, Windows integration with the executable does not
work well due to a bug in the shell [snip].
File a bug with Micro$oft, then. Don't like the fact that they don't
give a &()^&)( if you file a bug? Try using a real operating system.
Micro$oft's problems are not LyX's problems. Period.
Maybe this problem could be solved by using the Qt framework in a way we
presently aren't. Qt hides a lot of our cross-platform problems. And if
it doesn't, then you should look into some other issue in src/support/.
That is where the issues about spaces in filenames should be handled,
NOT in shipping some special library that is really needed only on
Window$ and then hacking the LyX sources to deal with this
platform-specific problem.
Frankly, I find the entire attitude behind that suggestion to be just
weird (which is the nice way of putting it). Does no one around here
understand anything about FOSS and its principles?
This trick of distributing a library (a very common thing in software
engineering) eases end-user installation, since the user does not have
to place anything in any path.
I do know about libraries, thank you. (Linux is kind of big on
libraries.) In this case, however, so far as I can tell, the library
makes absolutely no independent sense. It is a hack. The whole point of
a library is that it's something that is shared, i.e., something whose
functions might be called from lots of different sorts of programs.
Which programs other than LyX and elyxer do you imagine will be calling
this library?
As for end-user installation, this is a packaging issue. If it's a
Window$ problem, talk to the Window$ packagers. Don't make those of use
who use software whose bugs we can handle deal with THEIR issues.
And yes, I would and have said say exactly the same thing about Mac OSX.
The issues with LyX running on Snow Leopard (or whatever) illustrate
precisely what's wrong with the closed-source development model, from
our point of view.
But it requires some help from LyX (which apparently is hard to obtain these
times).
No, it's very easy, if you're actually interested in working with LyX
itself, as opposed to getting LyX to do your own little pet thing your
own little pet way. This is an utterly minor issue, as far as LyX is
concerned.
Well, I think we all know that there are ways it could be better. Jurgen
knows that, I know that, we all know that. But simply complaining about it,
yet again, doesn't help. And offering to do something, again, that the
overwhelming majority of developers have repeatedly rejected won't help
either.
If you read my message carefully you will maybe note that I was not
offering to do anything about it this time around. Sam Liddicott said
it best after the last time:
> So I've learned that I can offer what I offer, and if it isn't
wanted, I can let it go without wasting too much of my own time.
What will definitely not help is sitting around doing nothing about it.
Yes, well, I wondered why you said anything, then, since you clearly
aren't offering to help, and so are apparently just whinging. If LyX has
fewer developers than are required to deal with all the enhancement
requests that get made, let alone all the bugs that get reported, then,
well, I seriously doubt that this is OUR problem. Pretty much every FOSS
project is resource starved. Yes, I know that you previously offered to
"help". But we are not going to let people who know nothing about LyX
hack their way through the code to solve some pet problem of theirs. And
that ain't gonna change.
Richard
