And, not entirely unexpectedly, a simple contribution becomes yet another flamefest... Well, let's get straight i0nto it.
On Tue, Sep 15, 2009 at 3:57 AM, rgheck <rgh...@bobjweil.com> wrote: > 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 want to think that you are being deliberately obtuse, as opposed to spontaneously. Because this is an instance of ME (eLyXer) adjusting to YOU (LyX) and distributing my software in a different way to solve a problem in LyX. LyX needs a bit of glue code anyway to adapt to eLyXer. You want to minimize this glue, fine. I will try that with the next version. But this glue code would be restricted to Python code anyway. > (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.) Ha ha ha. > It seems to me that there is a general failure here to understand something: [... blah blah blah ...] > cannot or will not understand that. What's so unclear here? Problems > integrating elyxer with Windosw$ are YOUR problems, not OUR problems. Way to help your users, Rich. > 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. I'm a Debian user myself, but thank you. I was just trying to solve a problem for the Windows integrator. > 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. The problem doesn't even come near Qt code -- it's all in the Python parts. Yes, reconfiguring and launching converters is done in Python. You might try one day to understand a problem before proposing solutions. It really makes a difference. > 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? No, you are the only one that knows how it works: take a patch that is offered and reject it without knowing what it does and why. Ignore the necessities of your users. And be sure to try to scare any contributors away. I'm embarrassed that you are part of it. > 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? Let me see. Any Python programs that want to? Even if you know about the concept of a library, you fail to grasp its utility: package classes so that they are used elsewhere. > 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. Well, that's what I did: listened to Windows packagers and try to come up with a solution. > 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. Once again you fail to grasp even the slightest thing related with the matters at hand. The issue with LyX on Mac OS X has nothing whatsoever to do with closed source development, but with how Mac OS X package installation works. It is well known and well documented, and it would work on Linux if anyone cared to adapt it. The clue train apparently left long ago. > 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. Very constructive, Richard. Don't let anyone come near your code to solve their pet problems. Let us forget about "scratch your itch" and all that bullshit: http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html Only the Heck of a way to do something is allowed: reject the offered patch, and then propose the would-be contributor to help YOU in YOUR pet project. Exercise for the reader: figure out why LyX has few developers. I had fun with the discussion, but it is not really any nearer getting the missing bits integrated and I have other things to do (like tend to user reports), so I will have to decline to engage in any further conversation unless there is some constructive progress from either side. Alex.
